تضاد بنیادین میان اقتصاد بازار و فیزیک سخت‌افزار می‌تواند منجر به فاجعه‌ای در سرعت پاسخ‌دهی مدل‌ها شود. طبق یافته‌های منتشر شده در ۱ اکتبر ۲۰۲۶ توسط پژوهشگران UC Berkeley، TTIC و Google Research، رقابت بدون محدودیت برای اولویت در واحد پردازش گرافیکی (GPU) می‌تواند میانگین تأخیر (Latency) استنتاج را تا ۱۲ برابر افزایش دهد.
مدل کاربردی فعلی
در حال حاضر، اکثر آزمایشگاه‌های پیشرو با محاسبات مانند یک سرویس عمومی با قیمت ثابت و محدودیت‌های نرخ ساده برخورد می‌کنند. شما مبلغی مشخص به‌ازای هر میلیون توکن می‌پردازید و یک سقف نرخ ثابت را می‌پذیرید. در این مدل، وقتی تقاضا از ظرفیت پیشی می‌گیرد، ارائه‌دهندگان از لایه‌بندی‌های کلی استفاده می‌کنند: مشتریان سازمانی پهنای باند اختصاصی (Provisioned Throughput) می‌گیرند، مشترکان اولویت نرم دارند و کاربران API دسته‌ای (Batch) در ازای تخفیف ۵۰ درصدی، پذیرفتند که پاسخ را در یک بازه زمانی ۲۴ ساعته دریافت کنند.
این مدل برای عامل‌های (Agents) خودمختاری که ترافیکی ناگهانی و وابسته به وضعیت تولید می‌کنند، ناکارآمد است. این چالش با دیدگاه‌های گوگل همسو است که معتقدند مدل‌های توکن‌محور در مقیاس عامل‌ها با شکست مواجه می‌شوند. برخلاف کاربران انسانی که تحمل تأخیر یکسانی دارند، عامل‌ها در حلقه‌های ابزاری چندمرحله‌ای عمل می‌کنند. برخی درخواست‌ها، مانند بررسی تراکنش‌های زنده یا به‌روزرسانی‌های رابط کاربری (UI)، اگر دو ثانیه تأخیر داشته باشند، ارزش کاربردی خود را از دست می‌دهند؛ اما برخی دیگر، مانند نمایه‌سازی داده‌های پس‌زمینه یا مراحل ارزیابی، می‌توانند ۳۰ دقیقه منتظر بمانند بدون اینکه ارزش تجاری پروژه نابود شود.
راهکار اقتصادی
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی استنتاج در مقیاس بالا اشاره کردیم، مدیریت حافظه کلید اصلی بهره‌وری است. برای حل این مشکل، اقتصاددانان پیشنهاد می‌کنند از حراج‌هایی استفاده شود که در آن کاربران برای اولویت قیمت می‌دهند؛ شبیه به دفتر سفارشات سهام یا بازار گاز در بلاک‌چین. در این حالت، درخواست‌های باارزش‌تر به ابتدای صف می‌روند و درخواست‌های کم‌ارزش‌تر عقب می‌نشینند تا بازار به‌طور بهینه پاک‌سازی شود.
اما مشکل اینجاست که سامانه‌های سرویس‌دهی مدرن مانند SGLang برای بقا به کش پیشوند (Prefix Caching) متکی هستند. بهینه‌سازی این لایه‌ها پیش‌تر در تجربه‌ی مایکروسافت برای کاهش هزینه‌های عملیاتی PTUها به عنوان یک کلید حیاتی شناسایی شده بود. این سامانه‌ها با ذخیره پرامپت‌های سیستمی مشترک، اسناد بازیابی شده یا تعاریف ابزارها در یک درخت رادیکس (Radix Tree)، از محاسبه مجدد KV Cache برای هر درخواست در مرحله پیش‌پُرکردن (Prefill) جلوگیری می‌کنند. طبق گزارش پژوهشگران، وقتی یک درخواست با قیمت بالا اما پرامپت منحصربه‌فرد به ابتدای صف می‌پرد، GPU را مجبور می‌کند کش فعال را تخلیه کرده و ماتریس‌های توجه (Attention) را از ابتدا محاسبه کند. این فروپاشی در نرخ命中 (Hit Rate) کش، توان عملیاتی ماشین فیزیکی را نابود می‌کند.
حراج‌های آگاه از سخت‌افزار
برای رفع این نقص، کیگان هریس، سیدهارت پراساد، اشر تراکمن، نیکا حق‌طلب و مایکل آی. جردن یک مکانیزم حراج آگاه از سخت‌افزار پیشنهاد داده‌اند. این رویکرد شامل محدودیت‌های فنی دقیقی است:
- پیمایش درخت رادیکس: زمان‌بندی به جست‌وجوی اول-عمق (Depth-First Search) در درخت رادیکس محدود شده است تا بازاستفاده از پیشوندها به‌طور ساختاری بهینه بماند.
- ترتیب شاخه‌ها: قیمت‌های پیشنهادی تعیین می‌کنند که شاخه‌های فرزند با چه ترتیبی بازدید شوند؛ به این صورت که شاخه‌ها بر اساس میانگین قیمت پیشنهادی در زیردرخت‌هایشان مرتب می‌شوند.
- پرداخت‌های VCG: سیستم از پرداخت‌های شبه‌خطی ویکری-کلارک-گرووز (Vickrey-Clarke-Groves) استفاده می‌کند تا اطمینان حاصل شود که کاربران فوریت واقعی خود را گزارش می‌دهند، نه اینکه سعی در بازی با صف کنند.
- عامل‌های تنظیم‌کننده: از آنجا که عامل‌ها بر اساس بودجه‌های ثابت در هزاران فراخوانی عمل می‌کنند، از گرادیان کاهشی (Gradient Descent) آنلاین برای تنظیم پویا و خودکار ضرایب قیمت استفاده می‌کنند.
در آزمایش‌های تجربی، این حراج محدودشده توانست حدود ۸۰ درصد از دستاوردهای رفاهی یک بازار بدون محدودیت را به دست آورد، در حالی که نرخ命中 کش و زمان تا نخستین توکن (Time to First Token) را کاملاً حفظ کرد.
این تغییر، فرض اصلی اقتصاد APIهای هوش مصنوعی را دگرگون می‌کند. این یافته نشان می‌دهد با تبدیل شدن عامل‌ها به مصرف‌کنندگان اصلی توکن‌ها، اشتراک‌های ثابت SaaS جای خود را به قیمت‌گذاری پویا بر اساس تراکم (Congestion Pricing) خواهند داد. با این حال، این مهندسی مالی باید تابع سلسله‌مراتب حافظه GPU باشد. عدم توجه به این جزئیات فنی می‌تواند منجر به جهش‌های پیش‌بینی‌نشده در هزینه‌ها شود، مشابه تله‌های عملیاتی که هزینه‌های برخی مدل‌ها را تا چندین برابر افزایش داد.
برای توسعه‌دهندگان، این بدان معناست که هزینه یک فراخوانی API به‌زودی نه تنها به تعداد توکن‌ها، بلکه به فوریت تسک و میزان مشترک بودن پیشوند پرامپت بستگی خواهد داشت. بهره‌وری بودجه عامل شما به این بستگی دارد که پرامپت‌هایتان چقدر با وضعیت‌های کش‌شده سایر کاربران همراستا باشد.
با گسترش حجم کاری عامل‌ها فراتر از رابط‌های چت انسان‌محور، باید منتظر ادغام این مکانیزم‌های حراج در فریم‌ورک‌های سرویس‌دهی تولیدی باشید.
گام بعدی شما
- در طراحی پرامپت‌های عامل‌های خود، از ساختارهای پیشوند مشترک (Shared Prefixes) برای کاهش هزینه‌های احتمالی در مدل‌های قیمت‌گذاری پویا استفاده کنید.
- اگر از فریم‌ورک‌های سرویس‌دهی مانند vLLM یا SGLang استفاده می‌کنید، نرخ命中 کش خود را در شرایط ترافیک متغیر رصد کنید.
- منتظر ادغام مکانیزم‌های حراج در لایه‌های ارکستراسیون مدل‌ها باشید تا مدیریت بودجه عامل‌ها بهینه شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و مدیریت حافظه در نسل جدید مراجعه کنید.
گفتگو