تغییرات قیمتگذاری API بهندرت سر و صدا به پا میکنند. نه هشداری در صفحه وضعیت (status-page) وجود دارد، نه اخطار منسوخ شدن و معمولاً هم ایمیل انبوهی ارسال نمیشود. اعداد در صفحه قیمتگذاری یک ارائهدهنده بهسادگی تغییر میکنند و دفعه بعد که وظیفه دستهای (batch job) شما به پایان میرسد، صورتحساب متفاوت به نظر میرسد. این دقیقاً همان اتفاقی است که برای Novita و StreamLake رخ داد. هر دو پلتفرم نرخنامههای LLM خود را بهروزرسانی کردهاند و اگر در حال اجرای بار کاری استنتاج (inference) روی هر یک از این سرویسها هستید، باید قبل از شروع وظیفه بعدی خود، اعداد جدید را بررسی کنید.
تهدید خاموشِ تغییر اهداف قیمتی
بیشتر تیمهای مهندسی با دقتی وسواسگونه، زمان بالا بودن سیستم (uptime)، تأخیر (latency) و دقت توکنها را زیر نظر میگیرند. با این حال، هزینه به ازای هر هزار توکن معمولاً فقط یک بار در زمان راهاندازی اولیه به آن نگاهی انداخته میشود و سپس به حاشیه میرود. این یک اشتباه است. در اپلیکیشنهای با حجم بالا — مانند چتباتهای پشتیبانی مشتری، خط لولههای خلاصهسازی اسناد، ابزارهای تولید کد — حتی تغییر ناچیز در قیمت هر توکن، تا پایان ماه به فشار بودجهای قابلتوجه تبدیل میشود.
برخلاف منسوخ شدن یک قابلیت که تغییر فوری در کد را تحمیل میکند، بهروزرسانی قیمت تأثیری بر یکپارچگی (integration) شما ندارد. درخواستهای شما همچنان کدهای وضعیت ۲۰۰ را برمیگردانند. بدنه JSON شما همچنان درست به نظر میرسد. تنها تفاوت در صورتحساب است. تا زمانی که بخش مالی متوجه این اختلاف شود، ممکن است شما قبلاً بودجه استنتاج یک اسپرینت را تمام کرده باشید. Novita و StreamLake هر دو اخیراً ساختارهای قیمتگذاری خود را تغییر دادهاند، به این معنی که هر خط لوله خودکار، تست استیجینگ یا بار کاری محیط عملیاتی (production) که به نقاط انتهایی آنها متصل است، ممکن است بیش از آنچه انتظار دارید یا کمتر از آن هزینه داشته باشد. حدس زدن یک استراتژی نیست.
آنچه از آخرین بهروزرسانیها میدانیم
نرخنامههای منتشر شده برای Novita و StreamLake هر دو تغییر کردهاند. اگرچه تفاوتهای دقیق بسته به سطح مدل و نوع توکن متفاوت است، اما نتیجه اصلی یکسان است: فرضیاتی که ماه گذشته درباره هزینههای استنتاج داشتید، ممکن است دیگر معتبر نباشند. Novita که طیفی از APIهای مدلهای زبانی بزرگ را در کنار خدمات ابری GPU ارائه میدهد، نحوه محاسبه هزینه دسترسی به مدلها را تغییر داده است. StreamLake نیز که به عنوان یک ارائهدهنده گستردهتر زیرساختهای ابری و هوش مصنوعی فعالیت میکند، برنامه قیمتگذاری LLM خود را به همین ترتیب بازنگری کرده است.
از آنجایی که این پلتفرمها هزینهها را به شکلهای متفاوتی ساختاردهی میکنند — برخی توکنهای ورودی و خروجی را جدا میکنند، برخی آنها را بستهبندی میکنند و برخی دیگر برای پنجرههای کانتکست طولانی یا نقاط انتهایی با توان عملیاتی بالا، مبلغ اضافی دریافت میکنند — نمیتوانید با اطمینان یک تخمین قدیمی را برای یک وظیفه جدید جایگزین کنید. یک گردش کار که روز دوشنبه مقرونبهصرفه بود، ممکن است تا چهارشنبه از حد تحمل بودجه فراتر رود، اگر ضریب توکنهای خروجی تغییر کرده باشد یا یک سطح تخفیف بازنگری شده باشد. جزئیات تغییرات نرخهای خاص در گزارش اصلی توسعهدهنده مستند شده است. شما باید آن گزارش را به عنوان مرجع اصلی خود در نظر بگیرید، نه خلاصهای از یک شخص ثالث را.
چگونه یک نرخنامه LLM را بخوانیم
قبل از اینکه بتوانید هزینههای قبلی را با هزینههای جدید مقایسه کنید، باید بدانید دقیقاً با چه چیزی روبرو هستید. اکثر ارائهدهندگان قیمتگذاری را به چند اهرم متمایز تقسیم میکنند و Novita و StreamLake نیز از این قاعده مستثنی نیستند.
اول، توکنهای ورودی را از توکنهای خروجی جدا کنید. ورودی چیزی است که به مدل میفرستید؛ خروجی چیزی است که مدل تولید میکند. در بسیاری از سیستمهای عملیاتی، حجم خروجی از حجم ورودی بیشتر است، بهویژه در وظایف خلاصهسازی چت یا نویسندگی خلاق. ارائهدهندهای که هزینههای ورودی را کاهش اما هزینههای خروجی را افزایش میدهد، در واقع میتواند صورتحساب کل شما را افزایش دهد.
دوم، مراقب قیمتگذاری پنجره کانتکست (context-window) باشید. مدلهای با کانتکست طولانی که دهها یا صدها هزار توکن را در یک مرحله پردازش میکنند، گاهی اوقات هزینههای اضافی دارند که به صورت خطی افزایش نمییابند. اگر اپلیکیشن شما کل پایگاههای کد یا اسناد حقوقی طولانی را به عنوان پرامپت ارسال میکند، افزایش اندک قیمت هر توکن در سطح کانتکست طولانی، ضربه سختتری نسبت به یک افزایش عمومی خواهد داشت.
سوم، به قوانین توان عملیاتی (throughput) و همزمانی (concurrency) توجه کنید. برخی نرخنامهها قیمتهای پایینتری برای استنتاج دستهای (batched) یا آفلاین ارائه میدهند، اما برای استریم در لحظه (real-time streaming) هزینه بیشتری دریافت میکنند. اگر اپلیکیشن کاربرمحور شما به پاسخهای با تأخیر کم وابسته است، ممکن است صرفنظر از حجم توکن، مجبور به استفاده از یک سطح قیمتی ویژه (premium) باشید.
در نهایت، هزینههای جانبی پنهان را بررسی کنید. خط لولههای تولید تقویتشده با بازیابی (RAG) اغلب پیش از رسیدن به خودِ LLM، از نقاط انتهایی embedding، ذخیرهسازهای برداری (vector stores) و APIهای بازرتبهبندی (reranking) عبور میکنند. اگرچه ممکن است Novita و StreamLake قیمتگذاری LLM خود را بهروز کرده باشند، اما خدمات مجاور در همان صورتحساب نیز ممکن است تغییر کرده باشند. کل صفحه را بخوانید، نه فقط نرخ اصلیِ هر میلیون توکن را.
محاسبه هزینهها پیش از استقرار بعدی
Once you have the fresh rate card, do not estimate. Measure. Pull your last seven to thirty days of request logs and calculate what that identical workload would cost under the new structure. If you are using a centralized logging tool or an observability dashboard, filter by the provider endpoint and export token counts. Most APIs return usage metadata in the response payload, so you can script this in a few lines of Python.
Start with a representative sample. Pick your busiest day from the previous billing cycle. Multiply the input tokens by the new input rate and the output tokens by the new output rate. Add any context-window or throughput surcharges that apply to your model tier. Compare that synthetic bill against what you actually paid. If the delta crosses your tolerance threshold—say, ten or twenty percent—you have a decision to make.
That decision does not always mean migrating providers. Sometimes it means switching model tiers within the same platform, trimming prompt length, enabling response caching, or throttling non-critical batch jobs to off-peak hours. The point is to make that decision with data rather than discovering the change on the next invoice.
You should also set hard spend caps or budget alerts if the platform supports them. Many API dashboards allow you to configure notification thresholds at the project or key level. Place them conservatively. If Novita or StreamLake push another rate change in the future, you want a financial circuit breaker, not a surprise four-figure overage.
The bigger picture: infrastructure costs are never static
These updates from Novita and StreamLake are reminders that the foundation-model market is still settling. Pricing is not an accident; it reflects compute availability, licensing deals, and competitive positioning. A provider might cut rates to attract volume, then raise them once a user base is locked in. Alternatively, a provider might raise rates to cover the cost of newer, more capable models while grandfathering older ones. Either way, relying on a single provider’s rate card as a constant is poor operational hygiene.
Teams who treat inference as a commodity layer already run multi-provider setups. They route simple queries to the cheapest endpoint that meets a quality bar and reserve expensive models for hard tasks. That architecture requires more upfront wiring, but it insulates you from exactly this kind of quiet price shift. Even if you are not ready to deploy a full routing layer, keeping a secondary provider warm and benchmarked gives you leverage when the primary one moves its prices.
Where to find the exact figures
The granular breakdown of what changed—model by model, token type by token type—is available in the original report. You can read the full details at the source link that tracked these updates. For ongoing discussions about infrastructure pricing, model releases, and cost optimization tactics, the GyaanSetu learning community is active on Telegram.
The takeaway
Do not let a pricing update become a post-mortem. Before you queue up your next training run, batch inference job, or production deployment against Novita or StreamLake, open their current pricing pages and rerun your last week’s numbers against the new rates. If the math still works, proceed with confidence. If it does not, you have the data to renegotiate your pipeline before the meter starts running again. Your future invoice will thank you.