جدول جست‌وجوی مدرن در برابر متدهای قدیمی محاسبهٔ توکن

اگر امروز برای استنتاج مدل‌های زبانی بودجه تخصیص می‌دهید، احتمالاً بخشی از سرمایه شما به دلیل جداول قیمت‌گذاری قدیمی در حال نشت است. زیرساخت‌های مالی بسیاری از تیم‌های مهندسی، هزینه‌ها را اشتباه گزارش می‌کنند چون ابعاد جدید صورت‌حساب‌ها را نادیده گرفته‌اند. در واقع، تا تاریخ ۱۲ اوت ۲۰۲۶، تکیه بر شمارش ساده توکن‌های ورودی و خروجی برای هرگونه استقرار در مقیاس تولید (Production)، اساساً شکست خورده است. در نتیجه، زیرساخت هوش مصنوعی شما احتمالاً در حال از دست دادن پول است یا هزینه‌ها را به غلط گزارش می‌کند، زیرا جدول قیمت‌گذاری شما منسوخ شده است.

برای سال‌ها، صنعت بر این فرض بود که هر توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — یا ورودی است یا خروجی. این منطق برای نسل اول APIها درست بود، اما مدل‌های امروزی از لایه‌های پیچیده حافظه پنهان (Caching) و استدلال (Reasoning) استفاده می‌کنند که ابعاد کاملاً جدیدی به صورت‌حساب‌ها اضافه کرده است. این پیچیدگی‌ها باعث شده تا بسیاری از سازمان‌ها متوجه شوند که مدل‌های قیمت‌گذاری صرفاً توکنی ممکن است بودجه‌های عملیاتی را به اشتباه هدایت کنند. وقتی تیم‌ها سعی می‌کنند این هزینه‌های جدید را در جداول قدیمی جای دهند، قراردادهای نامستندی می‌سازند — مانند ایجاد ردیف‌های مدل مصنوعی به نام «model-cached» یا قرار دادن ضرایب سخت‌افزاری (Hard-coded) در تخمین‌زننده‌ها — که منجر به اختلافات مداوم بین بخش‌های مالی و مهندسی می‌شود.

شکست جداول دو ستونی

جدولی که فقط بر اساس «مدل» و «جهت» (ورودی/خروجی) طراحی شده، این فرض خطرناک را دارد که هر توکن تنها یک قیمت دارد و هر نوع توکن فقط یک نرخ قیمتی دارد. طبق گزارش‌های فنی، این موضوع دیگر در هیچ API مدرنی صادق نیست. امروزه یک پاسخ واحد می‌تواند هم‌زمان در چندین بعد صورت‌حساب شود و دو مورد از این ابعاد اصلاً بر اساس تعداد توکن نیستند.

این یک خطای کوچک در اعداد نیست، بلکه یک شکست ساختاری است؛ جایی که جدول اصلاً جایی برای قرار دادن این اطلاعات ندارد. چون این قراردادها مستند نشده‌اند، با تغییر ارائه‌دهنده یا به‌روزرسانی مدل، از بین می‌روند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، نبودِ یک استاندارد مستند باعث می‌شود با هر تغییر ارائه‌دهنده، کل سیستم محاسبه از نو فرو بریزد. بازسازی درست این جدول، تنها یک روز زمان می‌برد اما درگیری‌های ماهانه بر سر تفاوت اعداد بخش مالی و مهندسی را به کلی حذف می‌کند.

دو باگ مرگبار در محاسبه هزینه‌ها

به نقل از راهنمای فنی dev.to، فرمول رایج تعداد ورودی × نرخ ورودی + تعداد خروجی × نرخ خروجی در دو جهت مخالف، اشتباه است، زیرا مهندسان تصور می‌کنند نام فیلدها به اندازه کافی گویا هستند:

• کم‌محاسبه در Anthropic: در Anthropic Messages API، فیلد input_tokens به معنای کل ورودی نیست. مستندات مربوط به محدودیت‌های نرخ (Rate-limits) صراحتاً می‌گوید این فیلد توکن‌های بعد از آخرین نقطه شکست حافظه پنهان (Cache Breakpoint) را نشان می‌دهد. ورودی کل در واقع مجموع cache_read_input_tokens و cache_creation_input_tokens و input_tokens است. برای مثال، در یک سند ۲۰۰ هزار توکنی که کش شده و یک سؤال ۵۰ توکنی برای آن پرسیده می‌شود، مقدار input_tokens برابر ۵۰ گزارش می‌شود. اگر تخمین‌زننده فقط همین عدد را ضرب در نرخ ورودی کند، تنها بخش کوچکی از حجم واقعی را گزارش می‌کند. از آنجایی که خواندن از کش با نرخ کاهش‌یافته محاسبه می‌شود و رایگان نیست، هزینه نهایی کمتر از واقعیت تخمین زده می‌شود.
• محاسبه مضاعف در OpenAI: در OpenAI Chat Completions، فیلد prompt_tokens نشان‌دهنده کل ورودی است. فیلد prompt_tokens_details.cached_tokens جزئیاتی از این مقدار را می‌دهد که از کش سرو شده است و cache_write_tokens نیز در کنار آن گزارش می‌شود. مهندسی که برای رفع باگ اول (در Anthropic)، تعداد کش را به مجموع ورودی اضافه می‌کند، در اینجا توکن‌های کش‌شده را دو بار و با نرخ کامل محاسبه می‌کند. برای جلوگیری از چنین تداخلاتی، برخی تیم‌ها از قراردادهای اندازه‌گیری برای حذف محاسبات دوبرابره استفاده می‌کنند.

ابعاد ضروری برای یک جدول مدرن

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

• ورودی/خروجی بدون کش: نرخ‌های پایه برای پردازش استاندارد.
• خواندن از کش (Cache Reads): که در APIها به صورت cache_read_input_tokens یا prompt_tokens_details.cached_tokens گزارش می‌شوند. این‌ها معمولاً ارزان‌تر از نرخ پایه ورودی هستند.
• نوشتن در کش (Cache Writes): هزینه ایجاد یک حافظه پنهان. این فیلدی است که اکثر جداول نمی‌توانند نمایش دهند. در Messages API، این مورد به صورت cache_creation_input_tokens گزارش می‌شود و در یک شیء تو در تو به نام cache_creation ، مقادیر ephemeral_5m_input_tokens (۵ دقیقه) و ephemeral_1h_input_tokens (۱ ساعت) را تفکیک می‌کند؛ دو زمان ماندگاری متفاوت با قیمت‌های نوشتن متفاوت.
• توکن‌های استدلالی (Reasoning Tokens): این توکن‌ها — شبیه وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — در یک API به صورت completion_tokens_details.reasoning_tokens و در دیگری به صورت output_tokens_details.thinking_tokens گزارش می‌شوند. اگرچه عموماً با نرخ خروجی محاسبه می‌شوند، اما باید ستونی جدا داشته باشند چون بزرگ‌ترین منبع رشد هزینه‌های توجیه‌نشده هستند.
• سطوح سرویس (Service Tiers): در Messages API، فیلد service_tier مقادیر standard ،priority و batch را گزارش می‌کند که هر کدام ضریب قیمتی خاص خود را دارند. این مورد اختیاری نیست؛ ترافیک دسته‌ای (Batch) و تعاملی با قیمت اسمی یکسان، در واقع دو ردیف هزینه‌ای متفاوت هستند.
• هزینه‌های هر درخواست: استفاده از ابزارها در سمت سرور (Server-side tool use) بر اساس تعداد فراخوانی محاسبه می‌شود، نه توکن. شیء Usage مقادیر server_tool_use را با شمارش‌هایی مانند web_search_requests و web_fetch_requests حمل می‌کند. یک جدول توکن‌محور نمی‌تواند این را نمایش دهد و باعث می‌شود این مورد به عنوان بزرگ‌ترین باقی‌مانده‌ی توجیه‌نشده باقی بماند.
• صدا و سایر وجه‌ها (Modalities): این موارد در فیلدهای جزئیات خودشان گزارش شده و جداگانه قیمت‌گذاری می‌شوند. این ستون‌ها باید همین حالا اضافه شوند تا مجبور نشوید بعداً تاریخچه را دوباره استخراج کنید.

مهندسی راهکار

بازسازی جدول نیازمند یک طرحواره (Schema) خاص است تا دقت تاریخی حفظ شود. کلید جدول باید ترکیبی از (ارائه‌دهنده، مدل، سطح سرویس، تاریخ اجرا) باشد. استفاده از تاریخ اجرا (Effective Date) به تیم‌ها اجازه می‌دهد پس از تغییر قیمت، هزینه‌های گذشته را درست محاسبه کنند، نه اینکه داده‌های فصل قبل را به صورت عطف به ماسبق بازنویسی کنند.

نکته حیاتی این است که برای ابعاد غیرقابل‌اعمال از NULL استفاده شود نه صفر. صفر یعنی «رایگان» و NULL یعنی «غیرقابل‌اعمال». تخمین‌زننده‌ای که نتواند تفاوت این دو را تشخیص دهد، به طور خاموش یک بعد بدون قیمت را به عنوان «شامل در قیمت پایه» در نظر می‌گیرد. همچنین برای جلوگیری از باگ‌های ذکر شده، یک پرچم بولی به نام input_count_includes_cache باید برای هر ارائه‌دهنده ذخیره شود تا تخمین‌زننده بر اساس این پرچم تصمیم بگیرد و فرض شخصی نکند.

برای دقت حداکثری، نرخ‌ها باید به صورت اعداد صحیح در کوچک‌ترین واحد پولی (میکرو-واحد) در هر میلیون توکن ذخیره شوند، نه به صورت اعداد اعشاری (Float). ضرب اعداد اعشاری در تعداد توکن‌های بالا، نتایجی ایجاد می‌کند که با سنت‌های صورت‌حساب نهایی هم‌خوانی ندارد و هدف اصلی این تمرین، دقیقاً تطبیق تا آخرین سنت است.

علاوه بر این، تخمین‌زننده باید مستقیماً از شیء Usage ارائه‌دهنده استفاده کند، نه اینکه توکن‌ها را محلی بازتولید (Re-tokenising) کند. توکن‌سازی محلی منبع دوم حقیقتی است که اغلب در ترافیک‌های حساس، اشتباه عمل می‌کند.

اعتبارسنجی و اجرا

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

ساختار پایگاه‌داده باید بر اساس منطق «یک ردیف برای هر قیمت، نه یک ردیف برای هر مدل» باشد. یک طرحواره SQL پیشنهادی شامل ستون‌هایی برای provider ،model ،tier ،effective_from ،currency ،input_uncached ،output ،cache_read ،cache_write_short ،cache_write_long ،reasoning ،tool_call_request و پرچم بولی input_count_includes_cache است.

محاسبه بازگشت سرمایه (ROI) واقعی

با یک جدول درست، تیم‌ها می‌توانند نقطه سربه‌سر کش (Cache Break-even) را پیدا کنند. فرض کنید نرخ ورودی r، نرخ نوشتن کش w × r و نرخ خواندن کش c × r باشد و پیشوندی از P توکن در n درخواست تکرار شود. بدون کش، شما n × P × r پرداخت می‌کنید. با کش، شما یک بار هزینه نوشتن و n - 1 بار هزینه خواندن را می‌پردازید: P × r × (w + (n - 1) × c). کش زمانی برنده است که n > (w - c) / (1 - c). اگر دو زمان ماندگاری مختلف قیمت‌گذاری شده باشند، زمان طولانی‌تر مقدار w را بالا می‌برد و تنها زمانی به‌صرفه است که فاصله زمانی بین درخواست‌ها از زمان ماندگاری کوتاه‌تر بیشتر باشد.

به همین ترتیب، «حساسیت توکن‌های استدلالی» قابل محاسبه است. اگر توکن‌های استدلال با نرخ خروجی محاسبه شوند و به‌طور متوسط k برابر خروجی مرئی باشند، نرخ مؤثر خروجی شما (1 + k) برابر قیمت اسمی است. مقدار k را از لاگ‌های خود با تقسیم فیلد توکن‌های استدلال بر تعداد خروجی مرئی در یک روز محاسبه کنید. این موضوع توضیح می‌دهد چرا مهاجرت به مدلی که به‌ظاهر ارزان‌تر است، اگر نسبت k آن بالاتر باشد، در نهایت صورت‌حساب را افزایش می‌دهد.

در نهایت، «کف فراخوانی ابزار» (Tool-call floor) نشان می‌دهد که در خروجی‌های کوتاه، هزینه‌های هر درخواست غالب هستند. با تقسیم هزینه هر درخواست بر نرخ خروجی، می‌توانید تعداد توکن‌هایی را بیابید که در آن هزینه تولید با هزینه ابزار برابر می‌شود. زیر این آستانه، هزینه هر درخواست شما توسط استفاده از ابزار تعیین می‌شود و هیچ مقدار کوتاه‌سازی پرامپت کمکی به کاهش هزینه نخواهد کرد.

این تغییر در حسابداری، مدیریت هزینه هوش مصنوعی را از حدس و گمان به یک علم قطعی تبدیل می‌کند. با نرمال‌سازی داده‌های مصرف در یک کلاینت واحد قبل از رسیدن به سرویس‌های مجزا، سازمان‌ها می‌توانند تضمین کنند که مهاجرت بین ارائه‌دهندگان، مدل‌های بازپرداخت داخلی (Chargeback) آن‌ها را مختل نمی‌کند. در این راستا، باید توجه داشت که گاهی ناکارآمدی‌ها نه در مدل، بلکه در مدیریت زیرساختی و پلتفرم‌های GPU نهفته است.

گام بعدی شما

• بررسی مجدد فیلدهای Usage در APIهای Anthropic و OpenAI برای شناسایی توکن‌های کش‌شده و استدلالی.
• جایگزینی اعداد اعشاری (Float) با اعداد صحیح (Integer) در دیتابیس قیمت‌گذاری برای حذف خطاهای گرد کردن.
• محاسبه نسبت k (توکن‌های استدلالی به خروجی مرئی) برای ارزیابی واقعی هزینه مدل‌های استدلالی.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.