هزینه استنتاج هوش مصنوعی، نه آموزش، اقتصاد سرویس‌دهی مدل‌ها را بازتعریف می‌کند
هزینه یک دور آموزش مدل پیشرو عددی است که روزنامه‌نگاران عاشق نقل‌قول آن هستند — صدها میلیون دلار، ده‌ها هزار GPU، ماه‌ها زمان اجرا. اما برای اکثر شرکت‌های هوش مصنوعی، این عدد اشتباهی است که باید نگرانش بود. آموزش یک‌بار اتفاق می‌افتد (یا چند بار در سال، برای به‌روزرسانی). استنتاج (inference) در هر درخواست تک‌تک کاربران، برای همیشه، اتفاق می‌افتد و با موفقیت مقیاس می‌گیرد: هرچه محصولی بهتر عمل کند، اجرای آن هزینه بیشتری دارد. این دقیقاً برعکس بخشی از اقتصاد است که در بیشتر تاریخ نرم‌افزار برقرار بود، جایی که هزینه نهایی سرویس‌دهی به یک کاربر بیشتر نزدیک به صفر بود.
به همین دلیل استنتاج، نه آموزش، همان ردیف هزینه‌ای است که واقعاً نحوه ساخت محصول توسط شرکت‌های هوش مصنوعی در سال ۲۰۲۶ را بازتعریف می‌کند. شرکت‌هایی که در اقتصاد واحد (unit economics) پیش می‌افتند لزوماً آن‌هایی نیستند که بهترین مدل را دارند — بلکه آن‌هایی هستند که هزینه پاسخ‌دهی به یک درخواست را تا حد امکان پایین آورده‌اند، از طریق مجموعه‌ای از تکنیک‌هایی که اکنون به‌جای کنجکاوی‌های پژوهشی، به رویه استاندارد صنعت تبدیل شده‌اند.
محاسباتی که استنتاج را گران می‌کند
یک پاس رو به جلو (forward pass) ترانسفورمر تقریباً ۲ × تعداد پارامترها × تعداد توکن‌های پردازش‌شده عملیات اعشاری (FLOP) هزینه دارد. آموزش تقریباً سه برابر این مقدار به ازای هر توکن هزینه دارد، چون پاس رو به عقب (backward pass) و به‌روزرسانی گرادیان را هم اجرا می‌کند — اما آموزش برای تعداد محدود و ثابتی از توکن‌ها اتفاق می‌افتد. استنتاج چنین محدودیتی ندارد؛ با هر درخواست از هر کاربر، به‌طور نامحدود، مقیاس می‌گیرد. مدلی که روزانه یک میلیارد درخواست سرویس می‌دهد، در عرض چند هفته محاسبات تجمعی بیشتری نسبت به کل دوره آموزشش در چند ماه می‌سوزاند، وقتی محصول واقعاً استفاده واقعی پیدا کند.
طول زمینه (context length) این مسأله را بدتر می‌کند. حافظه نهان کلید-مقدار (KV cache) که یک ترانسفورمر طی تولید نگه می‌دارد، با طول دنباله × تعداد لایه‌ها × تعداد سرهای توجه × بُعد هر سر × اندازه بچ افزایش می‌یابد. اگر پنجره زمینه را از ۸K به ۱۲۸K یا بیشتر ببرید — کاری که محصولات امروزی به‌طور معمول انجام می‌دهند — حافظه لازم برای هر درخواست همزمان متناسب افزایش می‌یابد، که سقف تعداد درخواست‌هایی که یک GPU می‌تواند همزمان سرویس دهد را تعیین می‌کند. این سقف، بیش از خود FLOP خام، واقعاً هزینه هر درخواست را تعیین می‌کند.
تکنیک‌هایی که واقعاً هزینه را کاهش می‌دهند
کوانتیزیشن مستقیم‌ترین ابزار است: اجرای استنتاج با FP8 یا INT8 به‌جای FP16/BF16 تقریباً نیاز به پهنای باند حافظه را نصف می‌کند و می‌تواند توان عملیاتی را روی سخت‌افزار یکسان دو برابر یا بیشتر کند، با افت دقتی که به‌دقت مدیریت می‌شود. INT4 این موضوع را برای مدل‌هایی که افت دقت در آن‌ها قابل‌تحمل است، پیش‌تر می‌برد.
معماری‌های Mixture-of-Experts (MoE) معنای «اندازه مدل» را از نظر هزینه تغییر می‌دهند. DeepSeek-V3 در مجموع ۶۷۱ میلیارد پارامتر دارد اما فقط حدود ۳۷ میلیارد پارامتر را برای هر توکن فعال می‌کند — شما برای زیرمجموعه فعال، نه کل مدل، هزینه محاسباتی می‌پردازید. این دلیل اصلی این است که مدل‌های MoE می‌توانند قابلیت در مقیاس پیشرو را با بخشی از هزینه استنتاج یک مدل متراکم با همان تعداد کل پارامتر ارائه دهند.
انواع توجه (attention) مستقیماً به مسأله KV-cache می‌پردازند. Grouped-query attention (GQA)، که در Llama 3 و بسیاری از مدل‌های فعلی استفاده می‌شود، تصویرهای کلید/مقدار را بین گروه‌هایی از سرهای توجه به‌اشتراک می‌گذارد به‌جای این‌که به هر سر مجموعه مجزای خودش را بدهد، و این اندازه KV-cache را چندین برابر با افت کیفیت حداقلی کاهش می‌دهد. توجه نهان چندسر (MLA) شرکت DeepSeek کش را بیشتر فشرده می‌کند، با فرافکنی کلیدها و مقادیر به یک فضای نهان کوچک‌تر پیش از ذخیره‌سازی در کش.
دیکود گمانه‌زنی‌شده (speculative decoding) یک مدل «پیش‌نویس» کوچک و سریع اضافه می‌کند که چند توکن جلوتر را پیشنهاد می‌دهد، و مدل اصلی به‌جای تولید توکن به توکن، آن‌ها را به‌صورت موازی تأیید می‌کند. وقتی مدل پیش‌نویس درست حدس بزند — که در متون روزمره اغلب این‌طور است — این کار تأخیر و زمان GPU به ازای هر توکن خروجی را تقریباً نیمی تا دوسوم کاهش می‌دهد، بدون هیچ افتی در کیفیت خروجی (مدل بزرگ همچنان حرف آخر را درباره هر توکن می‌زند).
در زیرساخت سرویس‌دهی، بچ‌بندی پیوسته (continuous batching) و مدیریت KV-cache صفحه‌بندی‌شده — تکنیکی که vLLM آن را با نام PagedAttention رایج کرد — به سرور اجازه می‌دهد با مدیریت تخصیص کش شبیه یک سیستم حافظه مجازی، به‌جای رزرو یک بلوک ثابت بدترین‌حالت برای هر درخواست، درخواست‌های همزمان بسیار بیشتری را در همان حافظه GPU جا دهد. این یک برد خالص زیرساختی است: همان مدل، همان سخت‌افزار، توان عملیاتی به‌طور قابل‌توجه بیشتر.
مسیریابی: استفاده از مدل گران‌قیمت فقط در صورت نیاز
یک استراتژی جدا، به‌جای بهینه‌سازی استنتاج یک مدل واحد، روی این‌که کدام مدل به هر درخواست پاسخ دهد تمرکز می‌کند. یک لایه مسیریابی، درخواست‌های ساده و مطمئن را به یک مدل ارزان و سریع می‌فرستد و فقط درخواست‌های واقعاً دشوار را به یک مدل پیشرو و گران‌قیمت ارتقا می‌دهد. محصولاتی که به این شکل ساخته شده‌اند، میانگین هزینه هر درخواست به‌طور قابل‌توجهی پایین‌تر از هزینه اجرای همه درخواست‌ها از طریق مدل سطح‌بالا را گزارش می‌کنند، چون بیشتر درخواست‌های واقعی به استدلال سطح مدل پیشرو نیاز ندارند — آن‌ها فقط یک پاسخ صحیح و سریع می‌خواهند.
مشکلات مالی Character.AI — که در ۱۳ اکتبر ۲۰۲۶ درخواست ورشکستگی فصل ۱۱ داد — یک مطالعه موردی مفید در مورد چیزی است که وقتی این مسأله حل نشود رخ می‌دهد. یک محصول چت حجم استنتاج بسیار بالایی به ازای هر کاربر تولید می‌کند (مکالمات طولانی، پرتکرار و رفت‌وبرگشتی)، و اگر هزینه استنتاج هر پیام به‌طور تهاجمی نسبت به آنچه کاربران پرداخت می‌کنند یا آنچه تبلیغات تولید می‌کند کاهش نیابد، اقتصاد واحد به‌سادگی جمع نمی‌شود، هرقدر هم که پایگاه کاربری بزرگ شود.
سخت‌افزار استنتاج تخصصی
GPUهای همه‌منظوره همچنان گزینه پیش‌فرض هستند، اما سیلیکون استنتاج اختصاصی — LPU شرکت Groq، موتور مقیاس-ویفر Cerebras و معماری جریان‌داده SambaNova — انعطاف‌پذیری آموزش را با تأخیر و هزینه کمتر به ازای هر توکن در بارهای کاری فقط-استنتاج معامله می‌کنند. این‌ها بیشترین اهمیت را برای کاربردهای حجم‌بالا و حساس به تأخیر دارند (دستیارهای صوتی، ابزارهای برنامه‌نویسی بلادرنگ)، جایی که کاهش میلی‌ثانیه‌ها و سنت‌ها به ازای هر درخواست در مقیاس بسیار بزرگ، بر انعطاف‌پذیری یک شتاب‌دهنده همه‌منظوره برتری دارد.
نتیجه‌گیری کاربردی
اگر محصولی روی یک API مبتنی بر LLM می‌سازید، هزینه به ازای هر ۱۰۰۰ توکن خروجی را به‌عنوان معیار اصلی اقتصاد واحد خود دنبال کنید، نه هزینه به ازای هر درخواست — افزایش تدریجی طول زمینه، قاتل خاموش حاشیه سود است. برای هر ویژگی یک سقف سخت برای طول زمینه تعیین کنید به‌جای این‌که اجازه دهید بدون محدودیت رشد کند. از یک مدل ارزان و سریع به‌عنوان پیش‌فرض استفاده کنید و فقط در صورت تشخیص عدم‌قطعیت یا درخواست صریح کاربر برای استدلال عمیق‌تر، به مدل گران‌قیمت ارتقا دهید. و اگر در حال ارزیابی ارائه‌دهندگان API هستید، مستقیماً درباره استراتژی کوانتیزیشن، MoE و کش‌گذاری آن‌ها بپرسید — ارائه‌دهنده‌ای که استنتاج FP8 MoE را با بچ‌بندی آگاه از KV-cache اجرا می‌کند، می‌تواند به‌طور قابل‌توجهی ارزان‌تر از ارائه‌دهنده‌ای باشد که این‌کار را نمی‌کند، برای همان کیفیت اسمی مدل.