تصور کنید برای کاهش هزینهها، سرویسدهنده هوش مصنوعی خود را به گزینهای ارزانتر تغییر میدهید، اما در پایان ماه با صورتحسابی مواجه میشوید که حتی از قبل هم گرانتر است. این تلهٔ رایج زمانی رخ میدهد که تیمها کاهش ۳۰ درصدی قیمت هر توکن را میبینند، اما نادیده میگیرند که مدل جدید ممکن است پاسخهایی ۵۰ درصد طولانیتر تولید کند. اکثر تیمها این اشتباه را میکنند که تغییر ارائهدهنده را صرفاً یک جایگزینی ساده در جدول قیمتها در یک فایل اکسل میبینند و متغیرهای پنهانی را که در واقع محرک اصلی صورتحساب هستند، نادیده میگیرند. این موضوع یادآور تلههای رایجی در رتبهبندی ابزارهای هوش مصنوعی است که در آن قیمتهای ظاهری، هزینههای واقعی اشتراک را پنهان میکنند. جایگزینی قیمت جدید به تنهایی شکست میخورد، زیرا این حقیقت را پنهان میکند که حداقل دو ورودی دیگر به طور همزمان تغییر میکنند و یکی از آنها میتواند در جهت مخالف قیمت حرکت کند.
این نوسانات هزینه دقیقاً زمانی ظاهر میشوند که شرکتها از مرحله آزمایشهای اولیه به تولید در مقیاس بالا و حجم زیاد میروند. در این محیط، تفاوت بین بودجه پیشبینیشده و قبض واقعی، اغلب به نحوه برخورد یک مدل خاص با یک پرامپت خاص بستگی دارد. برای کسانی که استقرارها در مقیاس بزرگ را مدیریت میکنند، مدلی که روی کاغذ «ارزانتر» است، در عمل مکرراً گرانتر تمام میشود.
معادله چهارعاملی هزینه
به نقل از راهنمای فنی منتشر شده در dev.to در ۱۲ اوت ۲۰۲۶، هزینههای ماهانه حاصلضرب چهار متغیر متغیر است. فرمول محاسبه به این صورت است: هزینه ماهانه = تعداد درخواستها در ماه × (توکنهای ورودی در هر درخواست × قیمت ورودی) + تعداد درخواستها در ماه × (توکنهای خروجی در هر درخواست × قیمت خروجی).
در حالی که قیمتها عمومی هستند، سه عامل دیگر نوسانیاند:
- قیمت هر توکن ورودی و خروجی: این اعداد باید در روز تغییر مدل ثبت شوند و در مستندات مدل تاریخگذاری گردند. آنها نباید به صورت سختافزاری (Hardcoded) در جایی قرار گیرند که خواننده آنها را به عنوان حقایق دائمی اشتباه بگیرد. معمولاً قیمت خروجی چندین برابر ورودی است، بنابراین بارهای کاری با خروجی زیاد، حساسیت بسیار بیشتری به تغییر قیمت دارند.
- توکنهای ورودی در هر درخواست: این مقدار باید اندازهگیری شود، نه حدس زده شود. حتی اگر تعداد کاراکترهای یک پرامپت ثابت بماند، تعداد توکن (Token) — مثل برشهای یک کیک طولانی که مدل تکهتکه میخورد — تغییر میکند، چون هر ارائهدهنده از توکنسازی (Tokenization) متفاوتی استفاده میکند.
- توکنهای خروجی در هر درخواست: این عامل بیشترین پراکندگی را دارد و احتمال غافلگیر شدن تیمها در اینجا بسیار زیاد است. اندازهگیری این مورد باید روی ترافیک واقعی باشد، نه چند تست دستی.
- تعداد درخواستها در ماه: این عدد میتواند تغییر کند؛ مثلاً اگر مدل جدید برای رعایت ساختار خروجی (Schema) به تلاشهای کمتری نیاز داشته باشد یا برعکس، برای رسیدن به همان پاسخ، به دفعات بیشتری فراخوانی شود.
تأثیر پنهان حافظه پنهان (Caching)
تخفیفهای خاص هر ارائهدهنده معمولاً هنگام مهاجرت منتقل نمیشوند. قابلیتهایی مثل حافظه پنهان پرامپت (Prompt Caching)، پردازش دستهای (Batch Processing) و تخفیفهای توان عملیاتی متعهد شده (Committed-throughput)، قوانین واجد شرایط بودن متفاوتی در میان فروشندگان مختلف دارند.
اگر هزینه فعلی شما به دلیل نرخ بالای برخورد با حافظه پنهان (Cache Hit Rate) در یک پیشوند سیستمی مشترک و طولانی پایین است، تا زمانی که مکانیسمهای خاص ارائهدهنده جدید را تأیید نکنید، مقایسه شما عادلانه نیست. شما باید حداقل طول پیشوند، زمان ماندگاری (TTL) و اینکه آیا نوشتن در حافظه پنهان با قیمت ویژه (Premium) محاسبه میشود یا خیر را بررسی کنید. یک بار کاری ممکن است روی کاغذ ارزان باشد، اما فقط به دلیل این عامل، در عمل گرانتر شود.
اندازهگیری نادیدنیها
برای تخمین دقیق، نمیتوان به شبیهسازهای محلی توکنساز تکیه کرد. بر اساس مستندات فنی، شما باید از فیلدهای Usage که در بدنه پاسخ API برگردانده میشوند استفاده کنید، زیرا اینها همان اعدادی هستند که در صورتحساب ظاهر میشوند. شمارشهای محلی، تقریبهایی هستند که سربارهای ساختاری هر پیام را نادیده میگیرند.
ارائهدهندگان مختلف نامهای متفاوتی برای این فیلدها دارند:
- OpenAI Chat Completions: از شیء
usageشاملprompt_tokensوcompletion_tokensوtotal_tokensاستفاده میکند. - OpenAI Responses API: از
input_tokensوoutput_tokensاستفاده میکند. - Anthropic Messages API: از شیء
usageشاملinput_tokensوoutput_tokensاستفاده میکند. همچنین زمانی که حافظه پنهان فعال است، فیلدهایcache_creation_input_tokensوcache_read_input_tokensرا شامل میشود. چون اینها با نرخهای متفاوتی نسبت به ورودیهای معمولی محاسبه میشوند، جمع کردن آنها در یک عدد واحد، مدل هزینه را غلط میکند.
رویه بازپخش (Replay)
برای ساخت یک مدل هزینه قابل دفاع، این گردشکار توصیه میشود:
- نمونهبرداری از چند صد درخواست واقعی تولید در یک چرخه کامل روز کاری، به جای استفاده از یک فایل تست کوچک.
- حذف دادههای حساس مشتریان (Redact) در حالی که طول متن حفظ شود تا تعداد توکنها تغییر نکند.
- بازپخش این درخواستها روی ارائهدهنده جدید با استفاده از پرامپتها و پارامترهای منتقل شده. پارامترهای منتقل شده حیاتی هستند؛ زیرا سقف خروجی (Output Cap) که نام یا مقدارش تغییر کند، طول خروجی را منحرف میکند.
- ثبت فیلدهای Usage برگردانده شده برای هر درخواست.
نکته حیاتی این است که به جای میانگین، توزیع توکنها را دنبال کنید. گزارش مقدار p50 (میانه) هزینه مورد انتظار را میدهد، اما p95 (صدک ۹۵ام) برای تعیین آستانه هشدارهای بودجه ضروری است. میانگین معمولاً توسط درخواستهای بسیار گران (دم بلند توزیع) منحرف میشود و منجر به تخمین بیش از حد هزینههای معمول و تخمین کمتر از حد هزینههای پیک میشود.
تدوین تخمین نهایی
در مدلسازی، قیمتها باید به عنوان ورودیهای نامگذاری شده در بالا قرار گیرند تا با تغییر قیمت، فقط یک نقطه ویرایش شود. یک مدل نمونه به سبک پایتون به این صورت خواهد بود:
P_IN_OLD, P_OUT_OLD = ..., ...P_IN_NEW, P_OUT_NEW = ..., ...TOK_IN_OLD, TOK_OUT_OLD = ..., ...TOK_IN_NEW, TOK_OUT_NEW = ..., ...REQS = 2_000_000
def monthly(p_in, p_out, t_in, t_out): return REQS * (t_in * p_in + t_out * p_out) / 1_000_000
پس از ساخت مدل، یک تحلیل حساسیت انجام دهید: هر یک از چهار رقم توکن اندازهگیری شده را به تنهایی ۲۰٪ افزایش و کاهش دهید. عاملی که بیشترین تغییر را در نتیجه ایجاد میکند، همان جایی است که نیاز به اندازهگیری دقیقتری دارد. معمولاً این عامل «طول خروجی» است، به دلیل قیمت بالاتر و واریانس بیشتر، هرچند در بارهای کاری تولید بازیابیافزا (RAG) — مثل دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — که دارای زمینههای (Context) بزرگ هستند، این عامل اغلب طول ورودی است.
مدیریت انتقال
تغییر ارائهدهنده را به صورت یک «روز جابهجایی» (Flag Day) مدل نکنید. اگر ترافیک به تدریج منتقل شود، هزینه دوره همپوشانی مجموع دو صورتحساب است. همچنین، هرگونه تخفیف مصرف متعهد شده در ارائهدهنده قبلی بر اساس حجم در حال کاهش محاسبه میشود که میتواند قیمت واحد را دقیقاً در لحظه خروج افزایش دهد. روند افزایش تدریجی (Ramp) را به طور صریح، ماه به ماه مدلسازی کنید.
برای جلوگیری از پیچیدگی مدیریت طرحهای مختلف API، استفاده از درگاههایی مانند Multigrid برای یکسانسازی اعداد Usage در یک طرح واحد قبل از رسیدن به انبار داده پیشنهاد میشود. در غیر این صورت، شیء خام Usage را برای هر ارائهدهنده ذخیره کرده و در انبار داده (Data Warehouse) نرمالسازی کنید تا از محاسبات جداگانه برای هر سرویس که توسط تیمهای مختلف نگهداری میشود، اجتناب کنید.
تطبیق با اولین صورتحساب
یک تخمین تنها پس از رسیدن اولین صورتحساب واقعی کامل میشود. شکاف بیش از ۱۰ درصدی معمولاً نشاندهنده عوامل فراموششده است:
- تلاشهای مجدد (Retries): درخواستهای شکستخوردهای که قبل از کرش کردن توکنی تولید کردهاند، اغلب همچنان قابل پرداخت هستند.
- بارهای کاری پنهان: کارهای دستهای شبانه، مجموعههای رگرسیون CI و خط لولههای ارزیابی معمولاً سهم دو رقمی از صورتحساب دارند اما در لاگهای اپلیکیشن دیده نمیشوند. در این راستا، برخی ابزارها مانند n8n توانستهاند هزینههای مقیاسپذیری عاملهای هوش مصنوعی را به طور چشمگیری کاهش دهند تا مدیریت این بارهای کاری بهینهتر شود.
- توکنهای استدلالی: مدلهایی که از زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر میکند تا به جواب برسد — استفاده میکنند، این توکنها را حتی اگر در متن نهایی نباشند، به عنوان توکن خروجی محاسبه میکنند.
- حسابداری حافظه پنهان: هزینههای نوشتن در حافظه پنهان که بالاتر از نرخ ورودی پایه محاسبه میشوند، یا نرخ برخورد (Hit Rate) در تولید که به دلیل تنوع بیشتر پیشوندها در ترافیک واقعی، کمتر از مرحله بازپخش است.
ثبت این رکورد تطبیق، تخمین تغییر ارائهدهنده دوم را بسیار ارزانتر و دقیقتر از بار اول میکند.
گام بعدی شما
- ترافیک تولید خود را برای یک روز کامل لاگ کنید و توزیع توکنهای ورودی/خروجی را استخراج کنید.
- یک محیط تست (Sandbox) ایجاد کنید و نمونهای از درخواستهای واقعی را روی مدل جدید بازپخش کنید تا «طول پاسخ» واقعی را بسنجید.
- در مدل بودجه خود، به جای میانگین، روی صدک p95 تمرکز کنید تا از شوکهای مالی ماهانه جلوگیری کنید.
اما داستان سختافزاری این تحول و تأثیر آن بر هزینه استنتاج حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو