أصدرت Microsoft بنية مرجعية لتوجيه حركة مرور الوكيل على خدمة Azure Kubernetes. فهو يقسم المشكلة إلى ثلاثة اختيارات رئيسية: النموذج الذي يجيب على المكالمة، وكيفية إدارة المكالمة، والنسخة المتماثلة لوحدة معالجة الرسومات (GPU) التي تتعامل معها. يجمع التصميم بين ملحق Kubernetes Gateway API Inference Extension لموازنة التحميل، وagentgateway كوكيل AI، وRouteLLM للتوجيه الدلالي. يتصل الثلاثة جميعًا بنقطة نهاية واحدة متوافقة مع OpenAI.
الدافع هو أعباء عمل الوكلاء على وجه التحديد، وليس الدردشة. يمكن لمهمة وكيل واحدة إطلاق مئات من استدعاءات LLM في حلقة التخطيط والتنفيذ والمراقبة، ومعظم هذه الاستدعاءات (ملء وسيطة الأداة، وبوابة نعم/لا، وملخص) لا تحتاج إلى نموذج حدودي. يؤدي إرسال كل مكالمة إلى نموذج من الدرجة الأولى إلى زيادة التكاليف والتأخير بناءً على طول الحلقة. إن موازن التحميل البسيط الدائري يجعل الأمر أسوأ. قد يتم وضع قائمة انتظار لاستكمال 200 رمز مميز خلف تعبئة مسبقة بقيمة 100 ألف رمز مميز على حجرة GPU المزدحمة، بينما توجد حجرة خاملة أخرى غير مستخدمة في مكان قريب.
تقسم البنية المقترحة المشكلات حسب الإشارة تمامًا. يتحقق RouteLLM من الموجه ويتنبأ بما إذا كان النموذج الأرخص يمكن أن يطابق جودة إجابة النموذج الأقوى. ويستخدم جهاز توجيه تحليل المصفوفة المدرب على بيانات التفضيلات البشرية. Agentgateway هو وكيل مفتوح المصدر يعمل مع OpenAI. فهو يدير سياسات مثل المصادقة وحدود الأسعار لكل وكيل وتتبع التكلفة وأسوار الحماية. يفعل كل هذا دون التحقق من معنى المطالبات. يقوم منتقي نقطة النهاية الخاص بـ Gateway API Inference Extension بالتحقق من حالة وحدة معالجة الرسومات المباشرة. إنه ينظر إلى إشغال ذاكرة التخزين المؤقت KV الخاصة بـ vLLM وعمق قائمة الانتظار. ويساعد ذلك في تحديد النسخة المتماثلة من النموذج المختار الذي سيتعامل مع الطلب. يقوم Agentgateway باستدعاء Endpoint Picker مباشرة عبر ext-proc للمسار المستضاف ذاتيًا، مما يسمح للتصميم بتجاوز بوابة Gateway API المنفصلة بالكامل.
توفر KAITO تجمعات عقد GPU حسب الحاجة وتقوم بتشغيل vLLM. ويظهر مقاييس مثل vllm:num_requests_waiting و vllm:kv_cache_usage_perc، الذي يستخدمه منتقي نقطة النهاية. يذهب المسار القوي إلى Azure OpenAI عبر الواجهة الخلفية للذكاء الاصطناعي في بوابة الوكيل. يوجه المسار الضعيف إلى الكبسولات التي تخدمها KAITO من خلال الواجهة الخلفية للخدمة. تستخدم هذه الواجهة الخلفية ملف inferenceRouting سياسة. إنه يوجه التنسيب إلى منتقي نقطة النهاية، و destinationMode تم ضبطه على passthrough. يقوم Azure Managed Prometheus وGrafana باستخلاص كل من مقاييس التوجيه والتكلفة الخاصة بـ Agentgateway ومقاييس GPU الخاصة بـ vLLM للحصول على عرض مشترك.
الرقم الحامل في الإعداد بأكمله هو عتبة التصعيد الخاصة بـ RouteLLM. في اختبار الاقتران RouteLLM، حقق جهاز التوجيه mf حوالي 95% من جودة MT-Bench الخاصة بـ GPT-4. لقد أرسل حوالي 26% فقط من المكالمات إلى GPT-4، مما يوفر ما يصل إلى 85% من التكاليف مقارنة بتوجيه جميع المكالمات إلى النموذج القوي. تنص Microsoft على أن هذا الرقم لا ينطبق تلقائيًا. إنه مرتبط بزوج النموذج المستخدم لتدريب RouteLLM، وليس بالاقتران phi-4-mini/GPT-5.1. لذلك، يحتاج المستخدمون إلى معايرة الحد مقابل حركة المرور الفعلية وضبطه بناءً على تقسيم AgentGateway القوي/الضعيف، بدلاً من تقدير RouteLLM. يسلط المنشور الضوء على أن التخزين المؤقت السريع يجعل تكاليف الرمز المميز صعبة. يحصل رمز الإدخال المخبأ على خصم، ويقوم تبديل النماذج بتبريد كلا ذاكرة التخزين المؤقت. وهذا يعني أن التكلفة الحقيقية للمكالمة “القوية” أقل مما تبدو.
ينبه المؤلف إلى أن القطع المستخدمة في هذا المنشور حديثة:
العديد من القطع هنا حديثة، وأسماء الحقول تتنقل بين الإصدارات – تمت إعادة تسمية ملحق الاستدلال وإعادة هيكلة CRDs في طريقه إلى الإصدار 1. تم التحقق من صحة كل شيء أدناه بشكل شامل على AKS في منتصف عام 2026 مقابل Inference Extension v1.0.0 وagentgateway v1.3.1. تعامل مع البيانات على أنها شكل الحل، قم بتثبيت الإصدارات الخاصة بك، وقم بتأكيد الحقول مقابل المستندات في النهاية. التحلل مستقر. تتحرك الأعلام المحددة وحقول CRD بسرعة.
على سبيل المثال، InferencePool و InferenceObjective موجودة في مجموعات API مختلفة. تعمل جميع الطبقات الثلاث مفتوحة المصدر ضمن مجموعة AKS. وفي الوقت نفسه، تتم إدارة خدمة KAITO وAzure OpenAI ومكدس إمكانية المراقبة Prometheus/Grafana بواسطة Azure. تلاحظ Microsoft أن جهاز توجيه طراز Foundry الخاص بها هو إصدار مُدار من الطبقة الدلالية الخاصة بـ RouteLLM. وهذا يساعد الفرق التي تفضل عدم إدارة جهاز التوجيه بنفسها. ومع ذلك، لا يوجد حاليًا أي خيار مُدار للموضع المدرك لوحدة معالجة الرسومات الخاص بـ Endpoint Picker. ويجب تشغيله داخل المجموعة، بغض النظر عن البوابة المستخدمة.
يمكن للفرق التي تتبنى هذا أن تأخذه على شكل شرائح وليس دفعة واحدة. يحتاج النموذج المستضاف الواحد خلف مجموعة من الوكلاء بشكل أساسي إلى بوابة وكيل للحوكمة، مع عدم وجود أي شيء يمكن التوجيه إليه أو وحدات معالجة الرسومات لمواجهته. تستفيد الاستضافة الذاتية لفئة نموذج واحدة من KAITO وامتداد الاستدلال دون أي طبقة توجيه دلالية، نظرًا لوجود نموذج واحد فقط للاختيار. يستحق RouteLLM الإضافة عندما يكون لدى النموذج القوي فجوة سعرية واضحة مقارنة بالنموذج الضعيف، ويكون هناك قدر كبير من حركة المرور السهلة. يشير المنشور إلى أن هذا ينطبق على أي وكيل يعمل في حلقة تقريبًا.
