چرا مسیریابی سنتی برای عامل‌های هوش مصنوعی کافی نیست؟

مایکروسافت اخیراً یک معماری مرجع سه‌لایه برای مدیریت ترافیک عامل‌های هوش مصنوعی روی بستر Kubernetes Service منتشر کرده است. این پشته‌ی طراحی مسأله را به سه انتخاب کلیدی تقسیم می‌کند: مشخص می‌کند کدام مدل به درخواست پاسخ دهد، نحوه مدیریت آن چگونه باشد و کدام نسخه از GPU آن را پردازش نماید. تفاوت اصلی این معماری با راهکارهای معمول، تمرکز آن بر پردازش‌های عاملی است. یک عامل هوش مصنوعی ممکن است در حین اجرای یک وظیفه، صدها فراخوان به مدل‌های زبان بزرگ ارسال کند تا چرخه‌ی برنامه‌ریزی و مشاهده را طی نماید. بیشتر این فراخوان‌ها برای تکالیف جزئی مثل پر کردن آرگومان ابزارها یا تاییدیه‌های دوگانه طراحی شده‌اند و اصلا نیازی به مدل‌های پیشرو ندارند. ارسال هر درخواست به یک مدل رده‌بالا هم هزینه‌ی محاسباتی را به شدت افزایش می‌دهد و هم تأخیر سیستم را محاسب می‌کند. تعادل بارگذاری ساده و چرخشی این چالش را پیچیده‌تر می‌سازد؛ به طوری که یک پردازش 200 توکنی ممکن است در صف یک پاد GPU شلوغ گیر کند، در حالی که پادهای خاموش و بلااستفاده در کنار آن قرار دارند.

معماری سه‌لایه پیشنهادی چیست؟

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

  • RouteLLM به عنوان مغز متفکر مسیریابی معنایی عمل می‌کند. این لایه با بررسی پرامپت ورودی و استفاده از یک روتر مبتنی بر ماتریس‌فاکتورسازی که با داده‌های ترجیح انسانی آموزش دیده است، پیش‌بینی می‌کند آیا یک مدل ارزان‌تر می‌تواند کیفیت پاسخ مدل قوی‌تر را حفظ کند یا خیر.
  • agentgateway به عنوان یک پراکسی متن‌باز متناسب با اکوسیستم OpenAI عمل می‌کند. این واسط فراتر از مسیریابی، سیاست‌های امنیت و حکمرانی از جمله احراز هویت، محدودیت نرخ درخواست به تفکیک هر عامل، ردیابی هزینه‌ها و اجرای گاردریل‌ها را مدیریت می‌کند؛ بدون اینکه خودش محتوای پرامپت را تحلیل کند.
  • Kubernetes Gateway API Inference Extension مسئول تعادل بارگذاری فیزیکی در سطح گره‌هاست. ابزار Endpoint Picker در این لایه، وضعیت زنده‌ی کارت‌های گرافیک را پایش می‌کند و با اندازه‌گیری اشغال KV-cache در موتور vLLM و عمق صف‌ها، تصمیم می‌گیرد هر درخواست دقیقاً به کدام کپی از مدل انتخاب‌شده اختصاص یابد.
نمودار معماری مسیریابی عامل‌های هوش مصنوعی روی AKS

جریان ترافیک و صرفه‌جویی هزینه‌ها

در این چیدمان، سیستم بر اساس کیفیت مورد نیاز درخواست، ترافیک را به دو مسیر اصلی تقسیم می‌کند. مسیریابی‌های پیچیده از مسیر قوی عبور کرده و از طریق بک‌اند هوش مصنوعی در agentgateway به سرویس Azure OpenAI هدایت می‌شوند. در مقابل، درخواست‌های ساده‌تر از مسیر ضعیف به پادهای مدیریت‌شده توسط KAITO فرستاده می‌شوند که موتور vLLM را در خود اجرا کرده‌اند. این بک‌اند سرویس از پالیسی inferenceRouting استفاده می‌کند تا نقشه‌ی قرارگیری را به Endpoint Picker واگذار کند و وضعیت destinationMode را روی passthrough تنظیم نماید. برای پایش یکپارچه، استک Prometheus و Grafana ابری، هم متریک‌های هزینه و مسیریابی agentgateway و هم شاخص‌های سخت‌افزاری GPU و vLLM را جمع‌آوری می‌کنند تا نمایی ترکیبی ارائه دهند.

عدد حیاتی در این معماری، آستانه‌ی تشدید در RouteLLM است. نتایج آزمایش روی جفت مدل‌های مورد تست نشان می‌دهد روتر mf توانسته کیفیت عملکردی معادل 95 درصد مدل‌های زبانی پیشرو را روی benchmark های متداول کسب کند، در حالی که تنها 26 درصد از کل فراخوان‌ها را به مدل رده‌بالا ارجاع داده است. این استراتژی در مقایسه با ارسال همگام تمام درخواست‌ها به مدل پیشرو، تا 85 درصد در هزینه‌ها صرفه‌جویی ایجاد کرده است. با این حال، محققان تأکید می‌کنند که این اعداد عمومی نیستند و مستقیماً به جفت مدل‌های آموزش‌دیده در روتر وابسته‌اند. کاربران باید آستانه را بر اساس ترافیک واقعی خود کالیبره کرده و تقسیم‌بندی مسیرها را پایش کنند. نکته‌ی دیگری که محاسبات نهایی را پیچیده می‌سازد، پدیده‌ی کش پرامپت است؛ توکن‌های ورودی کش‌شده تخفیف می‌گیرند و تغییر مدل هر دو کش را از بین می‌برد، بنابراین هزینه‌ی واقعی یک فراخوان قوی معمولاً پایین‌تر از تراز محاسبه‌شده اولیه است.

هشدارهای فنی و پایداری نسخه‌ها

سازندگان راهکار صراحتاً هشدار می‌دهند که این بخش‌ها هنوز در مراحل اولیه‌ی بلوغ فنی قرار دارند و نام فیلدها یا ساختار Custom Resources بین نسخه‌های جدید تغییر می‌کند. تست‌های انتها-به-انتها روی بستر AKS و با پیکربندی‌های خاص Inference Extension 1.0.0 و agentgateway 1.3.1 اعتبارسنجی شده‌اند. پیشنهاد می‌شود مانیفست‌های منتشرشده صرفاً به عنوان نقشه‌ی معماری در نظر گرفته شوند، نسخه‌ها به طور دقیق قفل شوند و فیلدها با مستندات رسمی مطابقت داده شوند. پشته‌ی کل مسیریابی در داخل کلاستر اجرا می‌شود، در حالی که سرویس‌دهی GPU از طریق KAITO و پایش داده‌ها کاملاً توسط سرویس‌های مدیریتی ابری Azure مدیریت می‌گردند.