‏روتینگ هوشمندِ مدل‌های زبانی روی کوبرنتیز

نویسنده می‌گه اگه مدل‌های زبانی (LLM) رو روی کوبرنتیز سرو کنی ولی روتینگ آگاه از اینفرنس نداشته باشی، احتمالاً لودبالانسرت داره ظرفیت GPU رو هدر می‌ده. مدیریت ترافیک معمولی HTTP درخواست‌ها رو کورکورانه پخش می‌کنه و فرض می‌کنه همهٔ بک‌اندها قابل‌تعویض با هم‌ان، در حالی که سرورهای مدل حالت‌دار (stateful) هستن و آمادگیِ متفاوتی برای هر درخواست دارن. برای همین خیلی وقت‌ها درخواست به بک‌اندی می‌ره که بهترین گزینه نیست.

راه‌حلی که این مقاله معرفی می‌کنه افزونهٔ Inference Extension برای Gateway API کوبرنتیزه. این افزونه قبل از انتخاب مقصد، وضعیت فعلیِ هر بک‌اند رو نگاه می‌کنه: مثل وضعیت کشِ Key-Value یا همون KV (که اگه پیشوندِ یه پرامپت قبلاً محاسبه شده باشه، دوباره محاسبه نمی‌شه)، آماده‌بودن آداپترهای LoRA توی حافظهٔ GPU، و طول صفِ هر سرور. این‌جوری درخواست به سراغ بک‌اندی می‌ره که سریع‌تر می‌تونه جواب بده.

نویسنده چرخهٔ عمر درخواست رو سه‌مرحله‌ای توضیح می‌ده. اول گیت‌وی درخواست رو با قوانین HTTPRoute چک می‌کنه و اسم مدل رو از مسیر، هدر یا از بدنهٔ JSON (با کمک Body-Based Router) بیرون می‌کشه و به InferencePool درست وصلش می‌کنه. بعد به جای انتخاب خودش، تصمیمِ پیچیدهٔ انتخاب نهاییِ پاد رو به یه مؤلفهٔ جدا به اسم Endpoint Picker یا همون EPP می‌سپاره.

گیت‌وی از فیلتر ext_proc ـه Envoy استفاده می‌کنه تا اطلاعات درخواست رو به EPP بده. خودِ EPP پادهای ناسالم رو حذف می‌کنه، اندازهٔ پی‌لود رو چک می‌کنه (اگه از حد بگذره خطای 413 می‌ده) و بعد چند سیگنال رو با هم وزن‌دهی می‌کنه تا بهترین بک‌اند رو امتیاز بده. نکتهٔ مهم اینه که EPP فقط IP مقصد رو برمی‌گردونه و خودِ روتینگ فیزیکی رو گیت‌وی انجام می‌ده. معماریِ افزونه قابل‌برنامه‌ریزیه، یعنی می‌تونی وزنِ هر سیگنال رو خودت تنظیم کنی.

یه قابلیت دیگه flow control ـه که با یه صفِ مرکزی توی EPP جلوی هدررفتِ منابع رو می‌گیره. به جای این‌که درخواست به صفِ یه پادِ شلوغ بچسبه، توی صف مرکزی می‌مونه و فقط وقتی یه بک‌اندِ مناسب آزاد شد فرستاده می‌شه. این صف هم اولویت‌بندی (با InferenceObjective) رو ممکن می‌کنه و هم اجازه می‌ده درخواست‌های کم‌اولویت موقع اشباع کنار گذاشته بشن (خطاهای 429 یا 503). همین صف مرکزی حتی اسکیل‌تا‌صفرِ GPU برای کارهای پس‌زمینه رو ممکن می‌کنه.

نویسنده چهار استراتژیِ روتینگ رو هم برمی‌شمره: روتینگ آگاه از مدل، آگاه از آداپتر LoRA، آگاه از پیشوند (prefix) برای استفاده از کشِ KV، و اولویت‌دهی و دورریزِ ترافیک. برای هرکدوم سیگنال‌هایی مثل نرخ هیتِ کشِ KV، تأخیرِ TTFT، نرخِ جابه‌جاییِ آداپتر و رخدادهای shedding رو پیشنهاد می‌ده که باید مانیتور بشن. بخش پایانی مقاله هم نشون می‌ده چطور با ابزارهای Datadog (یکپارچه‌سازیِ vLLM، OpenMetrics، مانیتورینگ GPU و کوبرنتیز) این سیگنال‌ها رو کنار هم می‌بینی تا بفهمی مشکل از تنظیمات روتینگه یا از کمبود واقعیِ ظرفیت.

نکات کلیدی:

• لودبالانسر معمولی همهٔ سرورهای مدل رو مثل هم می‌بینه و ظرفیت GPU رو هدر می‌ده
• افزونهٔ Inference Extension قبل از روتینگ، وضعیت KV cache و آداپتر LoRA و طول صف رو می‌سنجه
• گیت‌وی تصمیم انتخاب پاد رو به مؤلفهٔ EPP می‌سپاره و فقط روتینگ فیزیکی رو انجام می‌ده
• flow control با یه صف مرکزی، اولویت‌بندی و دورریزِ کنترل‌شده و حتی اسکیل‌تا‌صفر رو ممکن می‌کنه
• هدف نهایی کم‌کردن تأخیر تولید اولین توکن (TTFT) و استفادهٔ بهینه از GPU ـه