اگر بارهای کاری عملیاتی را روی مدلهای زبانی بزرگ (LLM) اجرا میکنید، میدانید که عملکرد مدل تنها نیمی از نبرد است. نیم دیگر، صورتحساب پایان ماه است. سه ارائهدهنده — Mancer 2، Novita و StreamLake — اخیراً قیمت مدلهای خود را تغییر دادهاند. اگر به هر یک از این APIها متکی هستید، فاکتور بعدی شما ممکن است با فاکتور قبلی متفاوت باشد.
این دیگر موضوع غیرعادی نیست. بازار LLM هنوز در حال آزمایش روشهای مختلف برای محاسبه هزینه استنتاج (inference) است. برخی ارائهدهندگان به ازای هر هزار توکن صورتحساب صادر میکنند. برخی دیگر درخواستها را در قالب سطوح (tiers) مختلف دستهبندی میکنند یا تخفیفهای استفاده مداوم ارائه میدهند. وقتی یک پلتفرم قیمت واحد خود را تغییر میدهد یا ساختار سطوح خود را بازسازی میکند، تأثیر آن بر بودجه شما میتواند از یک مزاحمت جزئی تا افزایش شدید هزینهها متغیر باشد. پیگیری این بهروزرسانیها اختیاری نیست؛ بلکه بخشی از وظیفه شماست.
چرا قیمتگذاری API شایسته توجه شماست
توسعهدهندگان اغلب با قیمتگذاری API مانند یک مورد ثابت و فراموششده برخورد میکنند. شما یک مدل را محک میزنید، ارائهدهندهای را انتخاب میکنید و به سراغ ساخت ویژگیهای جدید میروید. این روش تا زمانی که کار میکند، خوب است؛ اما زمانی که دیگر کار نمیکند، مشکل شروع میشود. در فضای فعلی، تغییرات قیمت میتواند بدون هیاهوی خاصی رخ دهد. یک ارائهدهنده ممکن است هزینه یک مدل قدیمی را کاهش دهد و همزمان قیمت نقطه پایانی (endpoint) جدیدتر خود را افزایش دهد. دیگری ممکن است هزینههای اضافی برای توکنهای خروجی (output tokens) وضع کند که در فصل گذشته وجود نداشتند. اگر مراقب نباشید، تنها زمانی متوجه خواهید شد که صورتحساب ابری شما از راه برسد.
جزئیات دقیق در صورتحساب LLM، این موضوع را بهویژه دشوار میکند. شما بهندرت مبلغ ثابتی را در ماه پرداخت میکنید؛ بلکه هزینه هر توکن ورودی (prompt token) و هر توکن خروجی (completion token) را میپردازید. افزایش قیمت در بخش خروجی میتواند بیشتر از بخش ورودی دردناک باشد، زیرا خروجیها اغلب طولانیتر از ورودیها هستند. اگر اپلیکیشن شما متنهای طولانی، کد، یا زنجیرههای استدلال چندمرحلهای تولید میکند، افزایش اندک قیمت به ازای هر توکن، به سرعت در هزینهها اعمال میشود.
همچنین مشکل «انحراف» (drift) وجود دارد. پروفایل توکنهای اپلیکیشن شما در طول زمان تغییر میکند. ممکن است یک سیستم پرامپت (system prompt) جدید اضافه کنید که توکنهای ورودی بیشتری مصرف کند. ممکن است به سمت پرامپتنویسی زنجیره تفکر (chain-of-thought) بروید که خروجیهای طولانیتری تولید میکند. حتی اگر قیمت ارائهدهندگان ثابت میماند، هزینههای شما تغییر میکرد. وقتی قیمت ارائهدهندگان همزمان تغییر میکند، اثر ترکیبی آنها میتواند تیمی را که دید کافی ندارد، غافلگیر کند.
چه چیزی تغییر کرد
Mancer 2، Novita و StreamLake همگی تغییرات قیمتی خود را اعمال کردهاند. جزئیات در هر پلتفرم متفاوت است، اما جهت کلی یکسان است: ساختار هزینهای که ماه گذشته استفاده میکردید، ممکن است دیگر معتبر نباشد.
Mancer 2 قیمت مدلهای خود را بهروزرسانی کرده است، به این معنی که توسعهدهندگانِ استفادهکننده از endpointهای آن باید هزینههای هر درخواست خود را دوباره ارزیابی کنند. اگر لیست قیمتهای قدیمی را در مستندات داخلی خود ذخیره کردهاید، آن اعداد دیگر معتبر نیستند.
Novita نیز در تمام خدمات خود تغییرات قیمتی ایجاد کرده است. برای تیمهایی که Novita را به دلیل تناسب با یک بودجه مشخص انتخاب کرده بودند، نرخهای جدید میتواند هزینه کل مالکیت (total cost of ownership) پروژههای در حال اجرا را تغییر دهد.
StreamLake نیز قیمتگذاری خود را تغییر داده است. هرگونه یکپارچهسازی (integration) که بر اساس لیست قیمتهای قبلی StreamLake ساخته شده، باید پیش از شروع چرخه صورتحساب بعدی بازبینی شود.
از آنجایی که اینها سه پلتفرم مجزا با سه مدل قیمتگذاری متفاوت هستند، هیچ قاعده کلی وجود ندارد که آیا بیشتر پرداخت خواهید کرد یا کمتر. یک ارائهدهنده ممکن است نرخهای سطح شروع (starter-tier) را کاهش داده و همزمان قیمت ظرفیت پردازش (throughput) ویژه را افزایش داده باشد. دیگری ممکن است هزینههای اضافی پنجره بافت (context-window) را تغییر داده باشد. تنها فرض مطمئن این است که فایل اکسل قدیمی شما دیگر درست نیست.
هزینههای پنهان نادیده گرفتن تغییرات نرخ
بیایید ببینیم این موضوع در عمل چه معنایی دارد. فرض کنید یک دستیار پشتیبانی مشتری دارید که روزانه ده هزار گفتگو را مدیریت میکند. هر گفتگو بهطور متوسط شامل دو هزار توکن ورودی و چهارصد توکن خروجی است. تغییر حتی چند سنت در هر میلیون توکن میتواند ماهانه صدها دلار هزینه اضافه کند. اگر تغییر قیمت بر توکنهای خروجی تأثیر بگذارد و دستیار شما به دلیل ارتقای مدل، پاسخهای طولانیتری تولید کند، شما دو برابر ضربه خواهید خورد.
سپس اثر ضربشونده (multiplier effect) وجود دارد. بسیاری از اپلیکیشنها برای هر درخواست کاربر، تنها یک بار LLM را فراخوانی نمیکنند. آنها آن را در یک حلقه، یا در یک خط لوله (pipeline) با مراحل بازیابی (retrieval)، یا با استفاده از مدلهای جایگزین (fallback) فراخوانی میکنند. تغییر قیمت در مدل جایگزین ممکن است فوری به نظر نرسد، تا زمانی که مدل اصلی شما به محدودیت نرخ (rate limit) برسد و شما مجبور شوید در یک روز بد، هزینههای مدل پشتیبان گرانتر را بپردازید.
فراتر از هزینههای اضافی، ریسکهای دیگری هم وجود دارد. اگر قیمتها کاهش یابد و شما متوجه نشوید، ممکن است استفاده از سرویس را بیدلیل محدود کنید. در آن صورت میتوانستید به کاربران بیشتری خدمات دهید، اسناد بزرگتری را پردازش کنید یا قیمتهای خود را برای مشتریان کاهش دهید. بیاطلاعی هم میتواند از این جهت و هم از آن جهت ضرر داشته باشد.
چگونه عادت پیگیری هزینهها را ایجاد کنیم
برای کنترل این موضوع نیازی به یک تیم مالی بزرگ ندارید. شما فقط به یک روال منظم و مکانی برای ثبت تغییرات نیاز دارید.
با متمرکز کردن لیست نرخها (rate cards) شروع کنید. یک سند ساده داشته باشید — خواه یک صفحه ویکی مشترک باشد، یا یک جدول در Notion، یا یک پیام پینشده در کانال توسعهدهندگان — که قیمت فعلی هر توکن یا هر درخواست را برای تمام مدلهای مورد استفاده شما لیست کند. هر زمان که ارائهدهنده (provider) تغییری را اعلام کرد، بلافاصله سند را بهروزرسانی کنید. منتظر جلسه بازبینی اسپرینت نمانید.
در مرحله بعد، میزان استفاده خود را بر اساس ارائهدهنده و مدل برچسبگذاری (tag) کنید. اکثر ابزارهای نظارتی (observability tools) به شما اجازه میدهند متادیتای سفارشی به فراخوانیهای API اضافه کنید. از این برچسبها برای تولید خلاصههای هفتگی هزینهها استفاده کنید. اگر شاهد جهش ناگهانی در هزینهها بودید، میتوانید در عرض چند ثانیه — و نه چند روز — متوجه شوید که علت آن افزایش مصرف بوده یا تغییر نرخها.
یک سیستم هشدار نرخ مصرف (burn-rate alert) بسازید. نیازی نیست این سیستم خیلی پیچیده باشد. یک اسکریپت زمانبندیشده که داشبورد میزان استفاده شما را بررسی کند و هر روز صبح عددی را در Slack ارسال کند، کافی است. وقتی عدد بالا میرود، همان روز متوجه میشوید، نه سی روز بعد که تیم مالی یک ایمیل تند و تیز برایتان میفرستد.
انتخاب مدلهای خود را هر فصل بازبینی کنید. بهترین مدل برای مورد استفاده شما در ماه ژانویه ممکن است در ماه ژوئن بهترین نباشد؛ نه به این دلیل که مدل ضعیف شده، بلکه به این دلیل که فضای قیمتگذاری تغییر کرده است. ارائهدهندهای که زمانی بسیار گران بود، ممکن است نرخهای خود را کاهش داده باشد، یا مدلی که قبلاً ارزان و محبوب بود، قیمتهایش را بالا برده باشد. بنچمارکهای خود را با قیمتهای لحظهای (live prices) بسنجید، نه قیمتهای گذشته.
در نهایت، قیمتگذاری را در تصمیمات معماری خود لحاظ کنید. اگر میدانید ارائهدهندهای اغلب نرخهای خود را تغییر میدهد، سیستم را بهگونهای طراحی کنید که بتوانید بدون بازنویسی نیمی از کد، نقاط اتصال (endpoints) را عوض کنید. کلاینت را پشت یک اینترفیس داخلی انتزاع (abstract) کنید. نام مدل را در یک فایل تنظیمات (configuration file) نگه دارید، نه به صورت hard-coded در لایه پرامپت خود.
از کجا بهروزرسانیهای قابل اعتماد دریافت کنیم
وبلاگها و مستندات ارائهدهندگان منابع رسمی هستند، اما در یک هفته شلوغ، بهراحتی ممکن است آنها را از قلم بیندازید. یک گزینه، دنبال کردن مجموعههای منتخب (curated roundups) است که دقیقاً این نوع تغییرات را در کل اکوسیستم ردیابی میکنند. برای بررسی کامل تغییرات اخیر Mancer 2، Novita و StreamLake، خلاصه دقیق را در اینجا مشاهده کنید:
تغییرات در قیمتگذاری LLM: Mancer 2، Novita و StreamLake
اگر میخواهید در جریان اخبار باشید و با سایر توسعهدهندگانی که سعی دارند هزینههای زیرساخت هوش مصنوعی خود را مدیریت کنند، تبادل نظر کنید، انجمنای وجود دارد که ارزش پیوستن به آن را دارد:
بهترین دفاع در برابر صورتحسابهای غافلگیرکننده، شبکهای از افراد است که تغییرات را به محض وقوع گزارش میدهند.
نکته اصلی
نوسان قیمت، ویژگی بازار فعلی LLM است، نه یک نقص. هزینه اجرای مدلها کاهش مییابد، ارائهدهندگان با ساختارهای نرخگذاری آزمایش میکنند و رقابت باعث تغییر اعداد و ارقام میشود. این در بلندمدت خبر خوبی است، اما تنها در صورتی که حواستان به آن باشد. با هزینههای API خود همانگونه رفتار کنید که با معیارهای آپتایم (uptime metrics) رفتار میکنید: آنها را اندازهگیری کنید، برایشان هشدار تنظیم کنید و بهطور منظم آنها را زیر سوال ببرید. تغییرات اخیر Mancer 2، Novita و StreamLake فقط آخرین یادآوری هستند که قیمت زیرساخت هوش مصنوعی شما هرگز واقعاً ثابت نیست.