صورت‌حساب‌های زیرساخت LLM به ندرت به صورت ناگهانی و شوکه‌کننده ظاهر می‌شوند. آن‌ها به صورت تدریجی انباشته می‌شوند—چند دلار اضافی برای هر هزار درخواست، افزایش اندک در نرخ توکن‌های خروجی، یا تعدیل پنجره بافت (context-window) که بی‌صدا هزینه مکالمات طولانی را بالا می‌برد. تا زمانی که تغییر ملموس شود، شما جریان‌های کاری، تعهدات مشتری و پیش‌بینی‌های بودجه خود را بر اساس اعدادی ساخته‌اید که دیگر وجود ندارند.

به همین دلیل است که آخرین اصلاحات قیمت‌گذاری Mancer 2، Novita و StreamLake به جای فصل آینده، همین حالا شایسته توجه شما هستند. هیچ‌کدام از این پلتفرم‌ها به دلیل افزایش ناگهانی ده برابری خبرساز نشده‌اند، اما تغییرات تدریجی در چندین ارائه‌دهنده به سرعت روی هم انباشته می‌شوند. اگر بارهای کاری عملیاتی (production workloads) را اجرا می‌کنید، به‌طور منظم fine-tune می‌کنید یا ترافیک را بین چندین API هدایت می‌کنید، حتی یک تعدیل نرخ اندک می‌تواند اقتصاد واحد (unit economics) شما را تغییر دهد.

چرا تغییرات کوچک قیمت‌گذاری در مقیاس بالا اهمیت دارند

اکثر تیم‌های مهندسی یک API مدل زبانی بزرگ را بر اساس معیارهای کیفیت و تأخیر (latency) انتخاب می‌کنند. هزینه نیز وارد بحث می‌شود، اما اغلب به عنوان یک پاورقی ایستا در نظر گرفته می‌شود. در واقعیت، قیمت‌گذاری یکی از پویاترین متغیرها در پشته (stack) شماست. صورت‌حساب مبتنی بر توکن به این معنی است که هزینه‌های شما به صورت خطی با میزان استفاده افزایش می‌یابد، اما با رفتار کاربر نیز مقیاس‌پذیر می‌شود. سیستم پرامپت‌های طولانی‌تر، طرح‌های خروجی JSON سنگین‌تر و نگهداری تاریخچه چت، همگی تعداد توکن‌ها را افزایش می‌دهند. وقتی یک ارائه‌دهنده نرخ خود را تغییر می‌دهد، تأثیر آن فقط یک افزایش هزینه ثابت نیست؛ بلکه ضریبی برای هر تعامل در آینده است.

Mancer 2، Novita و StreamLake هر کدام جایگاه متفاوتی در بازار استنتاج (inference) دارند و تعدیلات اخیر در هر سه مورد به این معناست که توسعه‌دهندگانی که زمانی برای هزینه‌های API به یک صفحه گسترده (spreadsheet) ساده تکیه می‌کردند، اکنون به یک استراتژی نظارتی فعال‌تر نیاز دارند. اگر با این به‌روزرسانی‌ها مانند یادداشت‌های اداری جزئی برخورد کنید، با این خطر روبرو هستید که تأثیر آن‌ها را تنها پس از دریافت صورت‌حساب ماهانه متوجه شوید.

چه چیزی تغییر کرده و کجا را باید بررسی کرد

به‌روزرسانی‌های Mancer 2

Mancer 2 تغییرات قیمت‌گذاری‌ای را اعمال کرده است که بر نحوه بودجه‌بندی شما برای نقاط پایانی (endpoints) آن تأثیر می‌گذارد. اگر در حال حاضر از Mancer 2 برای ترافیک عملیاتی استفاده می‌کنید، اولین چیزی که باید بررسی کنید این است که آیا این به‌روزرسانی بر توکن‌های ورودی، توکن‌های خروجی یا هر دو تأثیر می‌گذارد. برخی از ارائه‌دهندگان فقط قیمت بخش تولید (generation-side) را تعدیل می‌کنند که به برنامه‌هایی که خروجی‌های طولانی و ساختاریافته برمی‌گردانند آسیب می‌زند. برخی دیگر هزینه بخش پرامپت را افزایش می‌دهند که باعث جریمه شدن پرامپت‌نویسی‌های پیچیده few-shot یا تزریق بافت (context injection) بزرگ می‌شود. بدون خواندن جزئیات دقیق، نمی‌توانید فرض کنید که تأثیر تغییرات یکسان است. داده‌های لاگ خود را با نرخ جدید مقایسه کنید تا ببینید کدام یک از موارد استفاده شما گران‌تر می‌شود.

تغییرات قیمت‌گذاری Novita

Novita نیز نرخ‌های خود را تغییر داده است. برای تیم‌هایی که از Novita به عنوان یک جایگزین بهینه از نظر هزینه برای APIهای بزرگتر ابری استفاده می‌کنند، حتی تغییر کسری از یک سنت در هر هزار توکن، زمانی که حجم درخواست‌ها به میلیون‌ها می‌رسد، اهمیت پیدا می‌کند. زیرساخت Novita اغلب برای پروژه‌هایی جذاب است که به توان عملیاتی (throughput) بالا بدون هزینه‌های اضافی پلتفرم‌های مدیریت‌شده نیاز دارند. وقتی این محاسبات تغییر می‌کند، باید مدل‌های هزینه هر درخواست خود را دوباره اجرا کنید. به‌ویژه بررسی کنید که آیا Novita قیمت‌گذاری پلکانی (tiered pricing) معرفی کرده، تخفیف‌های استنتاج انبوه (bulk-inference) را تعدیل کرده یا محدودیت‌های سطح رایگان را بازسازی کرده است یا خیر. هر یک از این اهرم‌ها می‌تواند بدون هشدار، یک بار کاری را از «ارزان‌ترین گزینه» به «میان‌رده» تبدیل کند.

تعدیلات StreamLake

StreamLake با مجموعه‌ای از تعدیلات خود، این سه تایی را تکمیل می‌کند. اگر StreamLake هر یک از بارهای کاری غنی از رسانه یا بافت طولانی (long-context) شما را مدیریت می‌کند، نرخ‌های جدید را با میانگین طول نشست‌های (session) تاریخی خود مقایسه کنید. ارائه‌دهندگانی که در بافت‌های طولانی‌تر تخصص دارند، گاهی اوقات نحوه محاسبه هزینه برای توالی‌های طولانی را تغییر می‌دهند، به این معنی که گران‌ترین درخواست‌های شما ممکن است بیشترین تأثیر را بپذیرند. فرض نکنید که درصد تغییر اعلام شده، میزان ریسک واقعی شما را نشان می‌دهد. نمونه‌ای معرف از درخواست‌های ماه گذشته خود را استخراج کرده و آن‌ها را بر اساس طرح (schema) جدید دوباره محاسبه کنید.

شما می‌توانید مقایسه کامل نرخ‌ها و جدول زمانی به‌روزرسانی را در تحلیل دقیق Narev در Dev.to مشاهده کنید. از آن به عنوان یک مرجع مکمل استفاده کنید، نه جایگزینی برای محاسبات خودتان.

چگونه یک به‌روزرسانی قیمت‌گذاری را بدون حاشیه بخوانیم

وقتی یک ارائه‌دهنده API نرخ‌های جدید را اعلام می‌کند، زبان بازاریابی معمولاً بر دسترسی‌پذیری و عملکرد تأکید دارد. آن را نادیده بگیرید. بر سه سوال ملموس تمرکز کنید.

First, does the update change input pricing, output pricing, or ancillary fees like embedding or fine-tuning? Split your own telemetry along those same axes. If 80 percent of your spend is on output generation and the provider only raised input costs, you might feel little pain. If you run summarization pipelines that emit short outputs from huge inputs, the opposite is true.

Second, have the rate limits or throughput tiers changed? Sometimes a provider keeps per-token pricing flat but lowers the free concurrency tier or introduces new queueing charges. That translates directly into latency and infrastructure cost.

Third, are there new cost-control tools? A pricing hike paired with a prompt-caching discount or batch-inference markdown might actually help you if you restructure your calls. The headline number never tells the whole story.

Keeping your stack predictable while costs shift

You cannot freeze provider pricing, but you can build systems that absorb change without rewriting code every quarter.

Start with request routing. If Mancer 2, Novita, and StreamLake each serve different workloads in your architecture, codify the cost-performance trade-off so you can swap traffic quickly. A fallback model that cost 20 percent more six months ago might now be the cheaper option after the latest round of updates. Without a router that considers live pricing, you leave money on the table.

Next, compress your context. Pricing changes hurt most when you are sending thousands of tokens per request out of habit. Audit your prompts for redundant system instructions, overly verbose schemas, and uncompressed chat history. Reducing input length by 30 percent neutralizes a 30 percent price increase. That is often faster than switching providers.

Cache aggressively. Many teams re-send identical or near-identical prompts because it is simpler than maintaining a cache layer. Once pricing moves, that laziness becomes expensive. Store recent completions and embeddings when your use case allows it, especially for analytical or repetitive workloads running through StreamLake or Novita endpoints.

Finally, assign someone to own the API bill review. It does not need to be a full-time role, but it needs to be a recurring calendar event. Once a month, reconcile predicted spend against actual spend, flag any provider whose rate slipped, and rerun the cost comparison against alternatives. Without ownership, pricing drift becomes architectural debt.

Make pricing hygiene part of your process

Infrastructure teams already review security patches and dependency updates on a schedule. Pricing should sit on that same checklist. The recent adjustments from Mancer 2, Novita, and StreamLake are not anomalies. They are evidence that the inference market is still finding its equilibrium. New hardware, optimized inference engines, and shifting demand will keep rate cards in motion for the foreseeable future.

The teams that manage this well do not predict every change. They simply maintain visibility. They know which endpoints cost what, which workloads are elastic, and where to move traffic when the math shifts. That discipline turns an otherwise disruptive update into a routine configuration tweak.

If you want a space to compare notes with other builders navigating the same set of changes, the GyaanSetu learning community is open. You can find us on Telegram.

The bottom line: Pricing on Mancer 2, Novita, and StreamLake has changed. Do not rely on memory or old documentation. Pull your logs, match them against the new rates, and decide whether your current routing still makes financial sense. The cheapest model last month is not guaranteed to be the cheapest model today.