الگوریتم‌های بهینه‌ساز در برابر روترهای ساده در مدیریت حافظهٔ مدل‌ها

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

بسیاری از توسعه‌دهندگان تصور می‌کنند انتخاب مدل یک مسئلهٔ سادهٔ طبقه‌بندی است؛ یعنی وظایف سخت به مدل گران و کارهای ساده به مدل ارزان سپرده شود. آن‌ها باور دارند که تنها با بررسی یک جدول قیمت، می‌توانند عامل‌های هوش مصنوعی خود را بهینه کنند. اما در سامانه‌های عامل‌محور (Agentic) — که شبیه به تیمی از کارمندان است که هر کدام تخصص خاصی دارند و با هم مشورت می‌کنند — مسیریابی در واقع یک مسئلهٔ بهینه‌سازی کل سیستم است که در آن هزینه، تأخیر و کیفیت در یک کشمکش دائمی هستند. این چالش‌ها در واقع تکرار همان مشکلاتی است که در تحلیل پیشین ما درباره مهار هزینه‌های عملیاتی عامل‌ها به آن‌ها پرداختیم و دیدیم که صرفاً جایگزینی مدل‌های ارزان، راهکار قطعی نیست.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت حافظه در مدل‌های زبانی اشاره کردیم، تعامل مدل با زیرساخت سرویس‌دهنده کلید اصلی بهره‌وری است. به گزارش huggingface.co در ۱۵ ژوئیه ۲۰۲۶، رویکردهای سنتی مسیریابی اغلب در درک نحوه تعامل مدل‌ها با حجم‌های کاری واقعی در دنیای واقعی شکست می‌خورند.

پارادوکس هزینه و حافظه موقت

تاثیر حافظه موقت (Caching) — که مثل یادداشت‌های سریع یک آشپز است تا مجبور نباشد دستور پخت را هر بار از اول بخواند — در اینجا حیاتی است. بر اساس مستندات منتشر شده، یک آزمایش رودررو در چالش AppWorld با استفاده از یک عامل CodeAct، تفاوت تکان‌دهنده‌ای را در ۴۱۷ وظیفه مشاهده کرد. با وجود اینکه GPT-4.1 قیمت‌های برچسبی پایین‌تری برای توکن‌های ورودی و خروجی داشت، هزینه کل آن ۱۵۵ دلار (به طور متوسط ۰.۳۷ دلار برای هر وظیفه) شد. در مقابل، Claude Sonnet 4.6 تنها ۷۹ دلار (۰.۱۹ دلار برای هر وظیفه) هزینه داشت؛ این در حالی است که این مدل تقریباً سه برابر گام‌های استدلالی بیشتری برای اتمام همان وظایف طی کرد و قیمت‌های پایه بالاتری نیز داشت.

این اتفاق به این دلیل رخ داد که Sonnet 4.6 بهره بیشتری از قیمت پایین‌تر «خواندن حافظه» (Cache-read pricing) برد. چون حجم کاری عامل‌ها به‌طور مکرر بخش‌های بزرگی از متن (Context) را در گام‌های مختلف بازتولید و استفاده می‌کنند، هزینه واقعی ورودی به شدت افت می‌کند. وقتی نرخ برخورد با حافظه (Cache Hit Rate) بالا باشد، این صرفه‌جویی‌ها می‌تواند بر قیمت‌های پایه بالاتر و مسیرهای استدلالی طولانی‌تر غلبه کند. روترهایی که فقط به قیمت برچسبی نگاه می‌کنند، این تعامل حیاتی بین مدل، حجم کاری و زیرساخت سرویس‌دهنده را نادیده می‌گیرند.

خطاهای محاسباتی در پیچیدگی

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

علاوه بر سختی وظیفه، روترهای عملیاتی در محیط تولید باید چندین محدودیت هم‌زمان را مدیریت کنند:

• حکمرانی (Governance): رعایت قوانین حریم خصوصی، قوانین مکان ذخیره‌سازی داده‌ها (Data Residency) و استفاده از لیست مدل‌های تأییدشده.
• پایدارسازی (Reliability): حفظ یک تجربه پایدار و یکسان برای کاربر در حالی که توازنی بین هزینه‌ها و تأخیر برقرار است.
• زیرساخت (Infrastructure): مدیریت تراکم لحظه‌ای نقاط دسترسی (Endpoints) و بررسی در دسترس بودن سخت‌افزارها.
• دقت مسیریابی (Routing Granularity): مقایسه بین مسیریابی یک‌باره برای هر وظیفه در مقابل مسیریابی در هر گام از اجرا؛ روش دوم انعطاف‌پذیری را افزایش می‌دهد اما پیچیدگی عملیاتی را بالا می‌برد.

واقعیت تأخیر (Latency)

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

علاوه بر این، خودِ فرآیند مسیریابی نیز بار اضافی (Overhead) ایجاد می‌کند. تصمیماتی که در هر گام گرفته می‌شوند، تأخیر اضافی به خط لوله (Pipeline) تحمیل می‌کنند. بنابراین، روتری که سیستم سرویس‌دهنده را نادیده بگیرد، در واقع دارد واقعیت اشتباهی را بهینه می‌کند.

برای حل این مشکل، پژوهشگران به‌جای پرسیدن «کدام مدل بهتر است؟»، الگوریتمی ساختند که هزینه، کیفیت و تأخیر را به‌طور هم‌زمان بهینه می‌کند. آن‌ها این روش را روی محک AppWorld آزمایش کردند تا «نقطه عملیاتی» (Operating Point) ایده‌آل برای کل سیستم را بیابند.

جزئیات عملکرد

آن‌ها با استفاده از پیکربندی‌های مختلف روتر، یک مرز «صحت-هزینه» (Cost-Accuracy Frontier) را ترسیم کردند. در نتایج آن‌ها، هر مربع آبی رنگ نشان‌دهنده یک پیکربندی مختلف است که مجموعه‌ای از نقاط عملیاتی را ایجاد می‌کند. این نتایج نشان داد که رویکرد مبتنی بر بهینه‌سازی، فضای موازنه (Trade-off space) را بسیار موثرتر از روترهای استاندارد مبتنی بر سختی وظیفه (که با یک لوزی سبزآبی در داده‌ها مشخص شده‌اند) جست‌وجو می‌کند.

یافته‌های کلیدی عبارت‌اند از:

• پیکربندی بهینه برای تأخیر: دستیابی به صحت ۸۴٪ با هزینه ۹۳ دلار و زمان ۸۳ ثانیه. این یعنی ۲۱٪ کاهش هزینه و ۹٪ کاهش تأخیر نسبت به استفاده انحصاری از مدل Opus، در حالی که تنها ۴٪ افت در صحت مشاهده شد.
• پیکربندی بهینه برای هزینه: کاهش هزینه‌ها حتی بیشتر از نسخه بهینه‌ساز تأخیر، در حالی که صحت در یک محدوده رقابتی باقی ماند.
• بهره‌وری منابع: فرآیند بهینه‌سازی بسیار سبک است و تنها حدود ۶ میلی‌ثانیه زمان و ۲ کیلوبایت حافظه برای هر وظیفه مصرف می‌کند، که تضمین می‌کند خودِ روتر تبدیل به گلوگاه (Bottleneck) سیستم نشود.

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

گام بعدی شما

• اگر از چندین مدل در یک زنجیره استفاده می‌کنید، نرخ Hit حافظه موقت (Cache Hit Rate) خود را بررسی کنید تا مدل‌های گران‌تر اما بهینه‌تر در حافظه را شناس کنید.
• به‌جای روترهای ساده مبتنی بر طبقه‌بندی، معیارهای ترکیبی (Cost-Latency-Accuracy) را برای انتخاب مدل در هر گام پیاده‌سازی کنید.
• تأثیر تأخیرِ ناشی از خودِ روتر را در خط لوله (Pipeline) استنتاج خود اندازه بگیرید.

اما تأثیر این بهینه‌سازی‌ها بر سخت‌افزارهای نسل بعد حتی پیچیده‌تر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.