پرداخت به ازای نتیجه در برابر هزینهٔ توکنی در مدل‌های زبانی

اگر امروز بودجه‌ی شما بر اساس نرخ‌های اعلام‌شده در جدول قیمت‌های API تنظیم شده است، احتمالاً با یک شوک مالی روبرو خواهید شد. یک فراخوانی ساده از یک مدل «ارزان»، در صورت محاسبه خروجی‌های مفید، می‌تواند ۱۴.۷ برابر گران‌تر از آنچه تبلیغ شده است، تمام شود. این تفاوت شدید قیمت از چیزی به نام توکن‌های استدلالی (Reasoning Tokens) نشأت می‌گیرد؛ فرآیندهای فکری داخلی که مدل تولید می‌کند اما اغلب آن‌ها را از کاربر پنهان می‌کند، در حالی که بابت تک‌تک آن‌ها صورت‌حساب می‌فرستد.

برای سال‌ها، صنعت بر معیار «دلار در هر میلیون توکن» برای مقایسه مدل‌ها تکیه کرده است. هر ارائه‌دهنده‌ای این قیمت را منتشر می‌کند، هر جدول مقایسه‌ای بر اساس آن رتبه‌بندی می‌شود و هر فایل اکسل «ساخت در مقابل خرید» (build-versus-buy) بر مبنای آن اجرا می‌گردد. اما این استاندارد برای مهندسان و مدیران مالی، حس کاذب پیش‌بینی‌پذیری ایجاد می‌کند. در واقع، نرخ روی برچسب تنها یک وسیله برای پرت کردن حواس از هزینه واقعی یک «نتیجه‌ی مفید» است و می‌تواند تا ۱۰ برابر در جهتی باشد که گزینه گران‌قیمت را ارزان جلوه دهد.

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

به نقل از تحلیل فنی منتشر شده در وب‌سایت dev.to در ۲۶ ژوئیه ۲۰۲۶، هزینه‌ی واقعی کارهای هوش مصنوعی توسط مکانیسم‌های پنهان شکل می‌گیرد. نویسنده هفت تله‌ی مشخص را شرح می‌دهد که تیم‌های هوشمند را به محاسبه اشتباه هزینه‌ها و عملکرد سوق می‌دهد.

تله‌ی توکن‌های استدلالی

مدل‌های مدرن هنگام حل مسئله، توکن‌های استدلالی تولید می‌کنند. مدل متنی را برای رسیدن به پاسخ می‌سازد و شما بابت این فرآیند هزینه می‌پردازید، حتی اگر هرگز آن توکن‌ها را نبینید و نتوانید از آن‌ها استفاده کنید. در بسیاری از APIها، این توکن‌ها هرگز حتی به دست کاربر نمی‌رسند.

در یک ارزیابی مستند، نویسنده جایگزینی یک مدل با کاندید ارزان‌تر را بررسی کرد:

• مدل فعلی: ۰.۰۷ دلار ورودی / ۰.۲۷ دلار خروجی در هر میلیون توکن
• مدل کاندید: ۰.۰۵ دلار ورودی / ۰.۲۰ دلار خروجی در هر میلیون توکن

روی کاغذ، مدل کاندید در هر دو بخش حدود ۳۰٪ ارزان‌تر بود و جابجایی آن منطقی به نظر می‌رسید. اما یک درخواست واقعی داستان دیگری داشت. جزئیات صورت‌حساب نشان داد ۲۷۴ توکن پرامپت و ۱۳۲ توکن تکمیل (completion) استفاده شده است. از این ۱۳۲ توکن، ۱۲۳ مورد «استدلالی» بودند و تنها ۹ توکن پاسخ واقعی بود.

چون شما بابت تمام ۱۳۲ توکن هزینه می‌پردازید اما فقط از ۹ توکن استفاده می‌کنید، قیمت مؤثر هر توکن مفید ۲.۹۳ دلار شد؛ یعنی ۱۴.۷ برابر نرخ تبلیغاتی. مدل «۳۰٪ ارزان‌تر»، در واقع تقریباً ده برابر گران‌تر از مدلی بود که قرار بود جایگزین آن شود. این موضوع با بررسی صورت‌حساب خود ارائه‌دهنده‌ی سرویس تأیید شد.

این مکانیسم یک «بیماری بودجه» ایجاد می‌کند. در برخی مدل‌ها، استدلال در یک فیلد جداگانه قرار می‌گیرد در حالی که فیلد محتوا خالی می‌ماند. اگر محدودیت خروجی (output limit) را پایین بگیرید، استدلال تمام بودجه را می‌بلعد پیش از آنکه هیچ پاسخی تولید شود. برای مثال، در محدودیت ۱۰۰ توکن، پاسخ خالی بود؛ اما در ۲۰۰ توکن، پاسخ درست دریافت شد. این باعث می‌شود توسعه‌دهندگان به غلط نتیجه بگیرند که مدل ناتوان است، در حالی که مدل صرفاً با محدودیت بودجه مواجه شده است.

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

پارادوکس صحت

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

در آزمونی با ۸۰۰ تسک «فراخوانی ابزار» (tool-calling)، رتبه‌بندی صحت امیدوارکننده بود:

• مدل پیشرو A: ۹۵.۹٪
• مدل پیشرو B: ۹۵.۱٪
• مدل نویسنده: حدود ۹۴٪
• مدل باز (Open) قدرتمند: ۹۳.۶٪
• مدل ارزان C: ۹۳.۰٪
• مدل ارزان D: ۹۱.۰٪

اگر این اعداد را به‌تنهایی بخوانیم، مدل‌های ارزان با اختلاف تنها چهار درصد، گزینه‌ای بسیار اقتصادی به نظر می‌رسند. اما نویسنده ستون دوم را اضافه کرد: «تله‌ها». تله‌ها درخواست‌هایی هستند که پاسخ درست در آن‌ها «رد کردن» (refusal) است، چون ابزار در دسترس نیست یا درخواست اشتباه است.

• مدل پیشرو A: ۱۰۰٪ تله‌ها را مدیریت کرد
• مدل نویسنده: ۱۰۰٪ تله‌ها را مدیریت کرد
• مدل باز قدرتمند: ۱۰۰٪ تله‌ها را مدیریت کرد
• مدل ارزان C: ۹۰٪ تله‌ها را مدیریت کرد
• مدل ارزان D: ۵۲٪ تله‌ها را مدیریت کرد

مدل ارزان D که صحت ۹۱٪ داشت، در نیمی از موارد تله، ابزار اشتباه را انتخاب می‌کند. در سیستمی با دسترسی‌های واقعی، این یعنی مدل ممکن است با اطمینان دستور delete_records را اجرا کند، در حالی که باید می‌گفت «من ابزاری برای این کار ندارم».

راهکار: مجموعه‌ای از تسک‌ها بسازید که پاسخ درست در آن‌ها «امتناع» باشد. نرخ امتناع را به‌صورت جداگانه اندازه بگیرید و هرگز آن را با میانگین صحت کلی ترکیب نکنید.

اقتصاد مسیریابی و تأیید

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

در بررسی ۳۰ روز ترافیک تولیدی با مجموع ۶۸,۳۶۹ درخواست، نویسنده دریافت که اگر همه درخواست‌ها با نرخ مدل‌های پیشرو پردازش می‌شدند، هزینه ۱۶۶.۲۵ دلار می‌شد. اما هزینه واقعی بین ۴۶ تا ۵۱ دلار بود؛ که نشان‌دهنده حاشیه سود ناخالص حدود ۷۰ درصدی است.

نکته حیاتی این است که ۸۴٪ از کل هزینه توسط «ارتقاء» (escalation) به مدل گران‌قیمت ایجاد شده بود. هزینه‌های زیرساختی و سرویس‌دهی ارزان عملاً در حد خطاهای گرد کردن بودند. این یعنی اهرم اصلی هزینه، نه انتخاب مدل یا قیمت مذاکره شده، بلکه تعداد دفعاتی است که سیستم مجبور به ارتقاء می‌شود. کاهش ۱۰ درصدی در نرخ ارتقاء، ارزشمندتر از ۱۰ درصد تخفیف فروشنده است.

تأیید (Verification) است که مسیریابی را از یک قمار به یک مهندسی تبدیل می‌کند. تولید پاسخ درست گران است، اما بررسی آن اغلب بسیار ارزان است. نویسنده این بررسی‌ها را پیشنهاد می‌کند:

• اجرا: تست‌ها را اجرا کنید، نوع داده‌ها را چک کنید و ببینید آیا کد کامپایل می‌شود.
• توافق مستقل: از دو مدل مستقل بپرسید و ببینید آیا موافق‌اند.

در آزمونی شامل ۱۶۰ مورد در چهار خانواده‌ی تسک — شامل تله‌های سخت — دو نقطه-پایان (endpoint) مستقل در ۷۶٪ مواقع موافق بودند. در این موارد، احتمال غلط بودن پاسخ ۰.۰۰ بود. این یعنی ۷۶٪ مواقع، سیستم می‌تواند با قطعیت از پاسخ ارزان استفاده کند و فقط ۲۴٪ موارد نیاز به ارتقاء به مدل گران دارند.

راهکار: برای هر دسته از کارها، روشی برای بررسی ارزان پاسخ تعریف کنید. اگر نمی‌توانید، آن کار هنوز کاندیدای مسیریابی نیست.

شکست لیدربوردها

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

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

راهکار: بنچمارک‌ها را اجرا کنید چون رقبا این کار را می‌کنند، اما همیشه «نرخ اقدام اشتباه» را در کنار «نرخ موفقیت در تسک» گزارش دهید.

شکل حجم کاری در برابر معماری

اعداد میانگین هزینه به ازای هر درخواست گمراه‌کننده هستند چون ترکیب حجم کاری را پنهان می‌کنند. نویسنده دو سیستم یکسان با انواع تسک‌های متفاوت را مقایسه کرد:

• کارهای فراخوانی ابزار: به‌ندرت به مدل گران نیاز داشتند و منجر به سودآوری بالا شدند.
• کارهای کدنویسی: حدود ۵۷٪ از مسائل جدید نیاز به ارتقاء به مدل گران داشتند.

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

راهکار: هنگام مواجهه با «میانگین هزینه»، بپرسید «بر اساس چه ترکیبی از کارها؟». پیش از پیش‌بینی هزینه‌ها، ترکیب کاری خود را اندازه بگیرید.

سقف‌های صادقانه و واقعیت برابری

نویسنده تأکید می‌کند که ادعای «برابری» (Parity) تنها نسخه‌ای از ادعای عملکرد است که از سد شکاکان رد می‌شود. در یک اجرای پاک و بدون کش (cache-free) از یک بنچمارک استاندارد کدنویسی، نتایج چنین بود:

• مدل پیشرو B: ۹۳.۳
• مدل پیشرو A: ۹۲.۷
• آبشار (cascade) نویسنده: ۹۲.۱
• مدل ارزان خام: ۸۱.۱

معماری نویسنده حدود ۱۱ امتیاز به مدل ارزان اضافه کرد اما همچنان کمی پایین‌تر از مدل‌های پیشرو ماند. با وجود وسوسه برای ادعای «شکست دادن پیشروها»، اندازه‌گیری‌ها این ادعا را پشتیبانی نمی‌کردند. برابری با کسری از هزینه، محصول واقعی است.

راهکار: تنها اعدادی را منتشر کنید که باعث چاپلوسی نشوند. ادعایی که نتواند در برابر بررسی مشتری دوام بیاورد، یک ریسک (liability) است.

خطر اندازه‌گیری غلط

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

• خوانش جزئی: یک تجزیه‌کننده (parser) فقط ۵ سطر از ۷۹ سطر فایل را خواند و فاجعه گزارش کرد.
• ارجاع به خود: یک بررسی‌کننده، رشته‌های خطا را با خروجی کنسول خودش تطبیق داد و خطاهایی یافت که خودش چاپ کرده بود.
• خطاهای مقیاس: یک معیار ۱۳۵٪ حد مجاز را گزارش کرد، در حالی که عدد واقعی ۲۷٪ بود.
• ریزش‌های پنهان کرنل: صف درخواست‌های سرور فشار را به نرمی مدیریت می‌کرد، اما صف accept در سطح سیستم‌عامل روی ۵ تنظیم شده بود. درخواست‌های bursts عمیق‌تر از ۵، قبل از اجرای کد توسط کرنل رد می‌شدند. چون تست‌های بار فقط ترافیکی می‌فرستادند که سرور پذیرای آن بود، تست‌ها ساختاراً قادر به یافتن این باگ نبودند.
• شکست‌های خاموش: یک فلگ پیکربندی می‌گفت ویژگی «خاموش» است، اما کد قدیمی عملاً آن ویژگی را حذف کرده بود. تأخیر (latency) کمتر شده بود (چون هیچ کاری انجام نمی‌شد) و داشبوردها سبز بودند، در حالی که ویژگی ۱۰۰٪ مرده بود.
• سوگیری نمونه‌گیری: بدترین تأخیر ۱۷ ثانیه با ۱۰ نمونه اندازه گرفته شد. با ۸۲۸ نمونه، بدترین مورد واقعی ۱۲۶ ثانیه بود.

برای اجتناب از این تله‌ها، چهار عادت سخت‌گیرانه توصیه می‌شود:
۱. هر بار فقط یک متغیر را تغییر دهید. اگر یک اصلاحیه سه چیز را تغییر دهد، شما فهمیده‌اید که آن «بسته» کار می‌کند، اما نفهمیده‌اید چرا.
۲. اصلاحیه خود را خاموش کنید. تأیید کنید که مشکل بازمی‌گردد؛ تستی که همیشه پاس می‌شود، هیچ چیزی به شما نمی‌آموزد.
۳. اندازه نمونه را با آمار تطبیق دهید. میانه‌ها (Medians) با ده‌ها نمونه تثبیت می‌شوند، اما دنباله‌های بدترین حالت (worst-case tails) به صدها نمونه نیاز دارند.
۴. شکاف‌هایی را که نمی‌توانید توضیح دهید، دنبال کنید. هرگز عددی را که کمی عجیب است با بهانه‌های پذیرفتنی مثل «سربار شبکه» نپوشانید، زیرا این بهانه اغلب روی یک نقص واقعی می‌پوشاند.

این چارچوب عملیاتی ثابت می‌کند که برابری با مدل‌های پیشرو با کسری از هزینه ممکن است، به شرطی که اندازه‌گیری را جدی بگیرید — که این کار نادرتر و به‌مراتب ارزان‌تر از مالکیت یک مدل پیشرو است.

گام بعدی شما

• در پاسخ‌های API خود، فیلد reasoning_tokens را استخراج کنید تا هزینه واقعی هر پاسخ مفید را محاسبه نمایید.
• برای مدل‌های ارزان، یک «مجموعه تست امتناع» بسازید تا نرخ خطاهای فاجعه‌بار (مانند اجرای دستورات حذف) را شناسایی کنید.
• استراتژی «مسیریابی» را پیاده‌سازی کنید تا تسک‌های ساده را به مدل ارزان بسپارید و فقط موارد پیچیده را به مدل گران ارتقاء دهید.

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