هزینه‌ی مدل‌های زبانی — توکن، قیمت‌گذاری و بهینه‌سازی

صورت‌حساب از کجا می‌آید

تیم‌ها معمولاً وقتی به هزینه‌ی مدل زبانی فکر می‌کنند که صورت‌حساب ماه دوم چند برابر ماه اول شده. تا آن لحظه هزینه یک عدد مبهم است، بعد از آن یک بحران. مشکل این است که واحد هزینه — توکن — چیزی نیست که در کد ببینید؛ نه سطر است، نه کاراکتر، نه درخواست.

فرمول ساده است: هزینه‌ی هر فراخوانی برابر است با تعداد توکن ورودی ضرب در نرخ ورودی، به‌علاوه‌ی تعداد توکن خروجی ضرب در نرخ خروجی. تمام کار بهینه‌سازی این است که بفهمید کدام‌یک از این چهار عدد در سیستم شما بزرگ است. تقریباً همیشه فقط یکی از آن‌ها مسئول بیشتر هزینه است، و تیم‌ها وقت زیادی صرف کوچک‌کردن بقیه می‌کنند.

توکن چیست و چرا کاراکتر نیست

مدل متن خام نمی‌بیند. متن اول توسط یک tokenizer به قطعه‌های عددی شکسته می‌شود. این قطعه‌ها نه حرف‌اند و نه لزوماً کلمه؛ الگوریتم‌های رایج (مثل BPE) با آمار روی یک پیکره‌ی بزرگ یاد می‌گیرند کدام دنباله‌های کاراکتر آن‌قدر پرتکرارند که ارزش یک واحد مستقل را داشته باشند.

نتیجه‌ی مستقیم: کلمه‌ی پرتکرار در آن پیکره یک توکن است و کلمه‌ی کم‌تکرار به چند تکه شکسته می‌شود. یک نام خاص، یک شناسه‌ی UUID، یا یک قطعه کد مینیفای‌شده می‌تواند به‌ازای هر چند کاراکتر یک توکن مصرف کند. قاعده‌ی سرانگشتی «هر چهار کاراکتر یک توکن» فقط برای انگلیسی روان تقریب قابل قبولی است.

چرا فارسی گران‌تر تمام می‌شود

پیکره‌ی آموزش این tokenizerها عمدتاً انگلیسی است. برای فارسی سه اثر روی هم جمع می‌شود:

• تکه‌شدن بیشتر. کلمه‌ای که در انگلیسی یک توکن است، معادل فارسی‌اش اغلب به دو تا چهار تکه می‌شکند. یعنی همان معنا با توکن بیشتری منتقل می‌شود و شما برای همان محتوا بیشتر می‌پردازید.
• نویسه‌های چندبایتی. حروف فارسی در UTF-8 بیش از یک بایت می‌گیرند و این معمولاً به توکن‌های کوتاه‌تر و پرتعدادتر منجر می‌شود.
• بی‌نظمی املایی. نیم‌فاصله (ZWNJ)، جایگزینی «ي» و «ك» عربی به‌جای «ی» و «ک» فارسی، فاصله‌های اضافه و ارقام عربی/انگلیسی مخلوط — هرکدام باعث می‌شوند شکل یکسانِ یک کلمه به دنباله‌های متفاوتی از توکن تبدیل شود.

مورد سوم تنها موردی است که کاملاً در کنترل شماست و هزینه‌ی رفعش نزدیک صفر است. یک مرحله‌ی normalization پیش از ارسال — یکسان‌سازی ی و ک، اصلاح نیم‌فاصله، حذف فاصله‌های تکراری، یکسان‌سازی ارقام — هم شمار توکن را پایین می‌آورد، هم کیفیت بازیابی و تطبیق را بهتر می‌کند، و هم شانس اصابت کش را بالا می‌برد. جزئیات این نوع پاک‌سازی در چالش‌های پردازش زبان فارسی آمده.

عمل درست این است که حدس نزنید: با ابزار شمارش توکن ارائه‌دهنده، چند نمونه‌ی واقعی از داده‌ی فارسی خودتان را قبل و بعد از normalization اندازه بگیرید. عدد را از متن خودتان دربیاورید، نه از قاعده‌ی سرانگشتی.

خروجی پنج برابر ورودی قیمت دارد

در هر پنج مدل جدول بالا، نرخ خروجی دقیقاً پنج برابر نرخ ورودی است. این عدم‌تقارن مهم‌ترین واقعیت قیمت‌گذاری است و بیشتر تیم‌ها آن را وارونه فرض می‌کنند: وقت زیادی صرف کوتاه‌کردن prompt می‌کنند در حالی که پرحرفی مدل چند برابر بیشتر خرج می‌گذارد.

یک حساب ساده برای یک پاسخ پشتیبانی با ۴٬۰۰۰ توکن ورودی و ۵۰۰ توکن خروجی:

• با claude-haiku-4-5: حدود ۰٫۰۰۶۵ دلار
• با claude-sonnet-5: حدود ۰٫۰۱۳ دلار
• با claude-opus-5: حدود ۰٫۰۳۳ دلار

عددها کوچک به نظر می‌رسند؛ در روزی ده هزار درخواست، همین تفاوت بین رده‌ی سبک و سنگین ماهانه چند هزار دلار می‌شود. راهنمای انتخاب رده در راهنمای مدل‌های کلاد آمده.

عدم‌تقارن خروجی یک اثر دوم هم دارد: خروجی به‌صورت توکن‌به‌توکن تولید می‌شود، پس پاسخ بلند علاوه بر گرانی، کند هم هست. کوتاه‌کردن خروجی تنها اهرمی است که همزمان هزینه و تأخیر را کم می‌کند.

اهرم‌های واقعی کاهش هزینه

به ترتیب نسبت اثر به زحمت:

1. کوتاه‌کردن خروجی. max_tokens را واقع‌بینانه ببندید. از مدل بخواهید JSON یا فهرست کوتاه بدهد نه مقدمه و نتیجه‌گیری. هرگز نخواهید متن ورودی را در پاسخ تکرار کند؛ برای ویرایش فایل، patch یا فقط بخش تغییرکرده را بخواهید نه بازنویسی کامل.
2. مدل درست برای هر کار. فاصله‌ی رده‌ها ده‌برابری است. کارهای مکانیکی — دسته‌بندی، استخراج فیلد، مسیریابی — روی رده‌ی سبک اجرا شوند.
3. prompt caching. اگر بخش ثابتی از ورودی (system prompt، تعریف ابزارها، سند مرجع) در درخواست‌های پیاپی تکرار می‌شود، پرداختن دوباره برای آن اتلاف است. روش کارش تطبیق پیشوند ورودی است و به ترتیب ثابت‌به‌متغیرِ prompt وابسته است.
4. نفرستادن آنچه لازم نیست. به‌جای ریختن کل مستندات در هر درخواست، فقط تکه‌های مرتبط را بازیابی کنید. خروجی ابزارها را قبل از افزودن به زمینه ببرید — یک پاسخ خام API معمولاً ده برابر بزرگ‌تر از فیلدهای مورد نیازش است.
5. هرس مثال‌ها. few-shot با دوازده مثال شروع می‌شود و کسی بعداً بررسی نمی‌کند که آیا چهار مثال هم همان نتیجه را می‌دهد یا نه. این را اندازه بگیرید؛ اغلب می‌شود نصفش کرد.
6. کش در لایه‌ی برنامه. درخواست‌های تکراری و قطعی (همان ورودی، همان خروجی) اصلاً نباید به مدل برسند. یک جدول ساده با کلید هش ورودی، ارزان‌ترین بهینه‌سازی ممکن است.
7. پردازش دسته‌ای. برای کارهایی که تأخیرشان مهم نیست، اگر ارائه‌دهنده حالت batch دارد معمولاً ارزان‌تر تمام می‌شود؛ نرخ دقیقش را از مستندات همان ارائه‌دهنده بگیرید.

و چند الگوی ضدهزینه که باید حذف شوند: retry بی‌سقف روی خطاها، حلقه‌ی ایجنت بدون حد بالای گام، و ارسال دوباره‌ی کل تاریخچه در سیستمی که فقط به دو پیام آخر نیاز دارد.

چه چیزی را اندازه بگیرید

توکن واحد حسابداری است، نه واحد تصمیم‌گیری. عددی که باید دنبال کنید هزینه به‌ازای هر کار موفق است — هر تیکت پاسخ‌داده‌شده، هر سند پردازش‌شده. مدل ارزانی که نصف موارد را خراب می‌کند و نیاز به تکرار یا دخالت انسان دارد، گران‌تر از مدل گران است.

حداقل چیزی که باید لاگ شود:

• توکن ورودی، توکن خروجی و مدل، به‌ازای هر فراخوانی
• برچسب مسیر یا قابلیت (chat، extract، route) تا بشود هزینه را به بخش‌های محصول نسبت داد
• توکن‌های خوانده‌شده از کش، اگر caching فعال است
• شاخص موفقیت همان درخواست

بدون این برچسب‌ها فقط یک عدد کل دارید و هیچ راهی برای فهمیدن اینکه کدام قابلیت آن را می‌سازد. با این برچسب‌ها معمولاً در همان هفته‌ی اول معلوم می‌شود که یک مسیر کوچک و کم‌اهمیت سهم نامتناسبی از صورت‌حساب دارد — و اصلاح همان یک مورد بیشتر از هر تغییر سراسری اثر می‌گذارد.