توجيه الاستدلال في Kubernetes: وازن التوكنز لا الطلبات

يرى موازن الأحمال المعتاد طلبات، بينما يرى خادم النموذج اللغوي أعمالًا قد تختلف تكلفتها بدرجات كبيرة: قد يعيد Prompt استخدام Prefix دافئًا، وقد يملأ آخر نافذة السياق، وقد يطلب ثالث LoRA Adapter محملًا على نسخة واحدة فقط. لذلك قد يبدو توزيع طلب واحد على كل Pod عادلًا في العدد، بينما ينتج طوابير غير متوازنة بشدة.

يعالج Gateway API Inference Extension الحالي هذا الاختلاف للنماذج التوليدية المستضافة ذاتيًا على Kubernetes. يستطيع HTTPRoute استهداف InferencePool بدل Service عادية. وتسأل البوابة Endpoint Picker أو EPP عن نسخة خادم النموذج الأنسب، ثم تمرر الطلب إليها. تنص الوثائق الرسمية على أن القرار يستطيع استخدام مقاييس وقدرات خدمة النموذج، مثل حالة Prefix Cache وتوفر LoRA؛ ويسمي دليل InferencePool تحديدًا امتلاء KV cache وطول طابور الطلبات المعلقة والـAdapters النشطة.

هذا شرح مبني على الوثائق الحالية، وليس ادعاءً بأن المشروع أطلق اليوم. جرى التحقق من الوثائق في 29 سبتمبر 2026، وهي تصف InferencePool v1 بأنه مستقر، كما توثق خطة نشطة لنقل أجزاء من المشروع إلى مستودعات Gateway API وllm-d. لذلك تعامل مع عقد API وتنفيذ Gateway المختار وتنفيذ EPP الإنتاجي كثلاثة مكونات مترابطة لكنها مستقلة في الإصدارات.

ابدأ بفشل الجدولة لا بملف CRD

يجيب Round Robin عن سؤال شبكي: أي Endpoint سليم أخذ عددًا أقل من الأدوار؟ لكنه لا يجيب عن سؤال الاستدلال: أي نسخة تستطيع بدء الطلب أسرع وإنهاءه بأقل عمل مكرر؟ يخفي عدد الطلبات طول Prompt وحد التوكنز المولدة وحالة Batching وإعادة استخدام Cache ومكان الـAdapter.

ولا يحل Least Connections المشكلة بالكامل. قد يحتفظ Decode طويل باتصال واحد ويستهلك وقت المسرّع، بينما تعالج طلبات قصيرة كثيرة بكفاءة في Batch. واستخدام CPU أو GPU إشارة مجمعة ومتأخرة؛ وقد تكون Pod مشغولة هي الوجهة الأفضل لأنها تحمل Prefix المطلوب أصلًا. تحتاج الجدولة مجموعة صغيرة من الإشارات التي تتنبأ بزمن يراه المستخدم، لا كل ما يظهر في لوحة المراقبة.

حدد الهدف قبل الأوزان. يهتم Chat التفاعلي غالبًا بزمن أول توكن وبالذيل البطيء. وقد يهتم التلخيص غير المتزامن بالإنتاجية وتكلفة التوكن أكثر. تدعم الوثائق أولوية الخدمة كي تتقدم المهام الحساسة للتأخير على الأعمال المتسامحة، لكن الأولوية لا تخلق سعة. إذا وصف كل عميل طلبه بأنه حرج، فقد حصل الطابور على اسم جديد فقط.

افصل اختيار المجموعة عن اختيار النسخة

تنفذ البوابة الخطوة المألوفة أولًا: يختار HTTPRoute مجموعة InferencePool أو Service. استخدم هذه الطبقة لحدود السياسات المستقرة، مثل عائلة النموذج وإصداره وفئة المستأجر والمنطقة أو ملف الأمان. وبعد استهداف المجموعة، ترسل البوابة سياق الطلب إلى EPP الخاص بها. يقيّم EPP نسخ المجموعة ويعيد الوجهة المختارة، بينما تبقى البوابة مسؤولة عن التمرير.

يجعل هذا الفصل الملكية مفهومة. يحدد فريق المنصة المجموعات وسياسة Gateway، ويعرض فريق خدمة النماذج المقاييس والقدرات اللازمة لبروتوكول الخادم، ويملك تنفيذ EPP منطق التقييم. أما التطبيق فيطلب اسم نموذج وفئة خدمة موثقين بدل تعلم هويات Pods.

تنص وثائق InferencePool على أن Pods في المجموعة تشترك في إعداد الحوسبة ونوع المسرّع والنموذج الأساسي وخادم النموذج. هذا حد مهم: لا تخفِ عتادًا مختلفًا جذريًا أو سلوك خدمة غير متوافق خلف Score واحد ما لم يطبّع التنفيذ السعة صراحة. ويمكن لـHTTPRoute الإشارة إلى أكثر من مجموعة عند الحاجة إلى تقسيم حركة أعلى مستوى أو إطلاق تدريجي.

قيّم العمل بإشارات قليلة قابلة للدفاع

يبدأ Scorer عملي بتصفية النسخ التي لا تستطيع خدمة النموذج أو الـAdapter المطلوب. ثم يقدّر التشبع من طول الطابور وضغط KV cache، ويضيف ميزة لمطابقة Prefix مفيدة، ويطبق أولوية الخدمة. الصيغة الدقيقة شأن التنفيذ؛ فالمشروع الرسمي يحدد نموذج الامتداد ولا يفرض خوارزمية تقييم إنتاجية واحدة.

اجعل الوحدات صريحة. طول الطابور ليس زمن الانتظار. امتلاء Cache ليس احتمال Hit. ودرجة مطابقة Prefix لا تفيد إلا إذا كان عمل Prefill الموفر أكبر من كلفة الانتظار خلف العمل الحالي. طبّع المقاييس لكل خادم ونوع مسرّع، وضع حدًا لكل Bonus، وسجل المدخلات التي بنت القرار. وعندما يتساوى مرشحان تقريبًا، أضف عشوائية محدودة كي لا تتدافع كل البوابات نحو النسخة نفسها.

احذر البيانات القديمة. يسمح تدفق الطلب الموثق بجمع المقاييس بصورة غير متزامنة. أرفق وقت الرصد بكل Snapshot، وارفض البيانات بعد ميزانية حداثة قصيرة أو اخفض وزنها، وانتقل إلى سياسة Endpoint سليم أبسط إذا اختفت الإشارات. Score متقدم مبني على Telemetry قديمة أسوأ غالبًا من Fallback متواضع وحتمي.

صمم سلوك الفشل قبل حركة الإنتاج

يعرض InferencePool مرجع Endpoint Picker ونمط فشل. في المثال الرسمي، يسمح FailOpen للبوابة بإرسال الطلب إلى Endpoint تختاره إذا تعطل EPP أو لم يستطع الاختيار. يحافظ ذلك على الإتاحة، لكنه يلغي الضمانات الواعية بالاستدلال التي ربما كانت تحمي التأخير واستغلال المسرّعات. أما FailClose فيحمي شرط توجيه أو عزل صارمًا بثمن رفض الطلب.

اختر حسب النتيجة. قد يناسب Fail Open مساعدًا عامًا حيث التأخير الأسوأ أفضل من الانقطاع. وقد يكون Fail Close أكثر أمانًا إذا كان حد المجموعة يمثل نموذجًا أو Adapter أو موقعًا إلزاميًا لا تستطيع وجهة عشوائية خدمته. اختبر انتهاء مهلة EPP واستجابة غير صالحة وعدم وجود نسخة مؤهلة وقدم المقاييس وتعطل جزء من المجموعة. يجب أن يظهر الـFallback كحالة مستقلة في المراقبة، لا أن يختبئ داخل نجاح عادي.

تضيف الأسئلة الشائعة الحالية قيدًا تشغيليًا: يوفر المشروع الآن امتدادًا خفيفًا لاختبارات المطابقة، لا Controller إنتاجيًا افتراضيًا. قد توفر تطبيقات Gateway امتدادها أو تدمج Router موجودًا. اجتياز Conformance للعقد لا يثبت أن سياسة تقييم أو مسار مقاييس أو سلوك ضغط معين يناسب حملك.

تتبع مسار الطلب كاملًا

راقب خمس لحظات: وصول الطلب إلى Gateway، واختيار المجموعة، وبدء قرار EPP، وتحديد النسخة، وخروج أول توكن. مرر Request ID ثابتًا عبر Gateway وEPP وخادم النموذج. سجّل النموذج المطلوب والمجموعة وعدد المرشحين وسبب الاختيار وأعمار الإشارات ونمط الفشل المستخدم وهل قبلت النسخة الطلب أم رفضته. لا تسجل نص Prompt افتراضيًا.

يلخص المخطط أدناه حلقة التحكم التي يجب اختبارها. تختار البوابة المجموعة عبر HTTPRoute، ويتلقى EPP سياق الطلب ويقرأ إشارات حديثة، ثم يعيد نسخة واحدة. تمرر البوابة الطلب بينما تستمر خوادم النموذج في تصدير حالة الطابور والذاكرة والقدرات. لا ينبغي أن يتحول مقياس واحد بصمت إلى سلطة توجيه.

قس زمن أول توكن والتأخير بين التوكنز والزمن الكلي والأخطاء حسب النموذج وفئة الخدمة. اربطها بزمن الطابور وإعادة استخدام Cache والتوكنز المعالجة وزمن قرار EPP ونسبة الإشارات القديمة ومعدل Fail Open وتوزيع الاختيارات. قد يتحسن المتوسط بينما تسوء تجربة أبطأ المستخدمين؛ لذا أظهر p95 وp99 وافصل انتظار الدخول عن زمن التوليد.

أطلقه كتجربة توجيه

ابدأ بقرارات Shadow. دع الموازن الحالي يخدم الحركة، بينما يحسب EPP ويسجل النسخة التي كان سيختارها. قارن زمن الطابور المتوقع وزمن أول توكن الفعلي وإعادة استخدام Cache من دون تغيير الطلبات. اختلاف وجهة Shadow عن وجهة الخدمة دليل مفيد، وليس برهانًا تلقائيًا على أن EPP كان أصح.

بعدها وجّه مجموعة صغيرة، واحتفظ بمجموعة ضابطة على السياسة القديمة. استخدم إصدارات النموذج وإعدادات التوليد وفئة الحركة نفسها. عرّف حدود التراجع قبل الاختبار: معدل الأخطاء وانتهاء مهلة EPP وتراجع زمن أول توكن وتراجع Tail Latency وتشبع المسرّع. يمكن لتقسيم الحركة باسم النموذج دعم إطلاق تدريجي، لكن لا تغيّر النموذج وخوارزمية التوجيه في التجربة نفسها إذا أردت نتيجة قابلة للتفسير.

تبقى السعة ضرورية. يضع التوجيه الواعي العمل في مكان أفضل، لكنه لا يصنع ذاكرة GPU أو Decode Throughput. اربطه بـAdmission Control وطوابير محدودة وإشارات Autoscaling تعكس العمل المعلق. احمِ الحركة التفاعلية من تجويع Batch، لكن احجز حصة قابلة للقياس للخلفية كي لا تصبح الأولوية استبعادًا دائمًا.

اعرف متى تكفي Service

استخدم Service عادية عندما تتقارب أحجام الطلبات وتكون النسخ قابلة للتبادل فعلًا ولا تهم Cache locality وتتفوق بساطة التشغيل على تحسين محدود. واستخدم InferencePool وEPP عندما تؤثر هوية النموذج أو الـAdapters أو حالة الطابور أو Prefix القابل لإعادة الاستخدام بوضوح في التأخير أو الكلفة، وعندما يستطيع الفريق تشغيل طبقة القرار الإضافية.

القاعدة الهندسية ليست «توجيهًا ذكيًا في كل مكان»، بل «وجّه بأصغر نموذج للواقع يغير النتيجة». ابدأ بتصفية القدرات وإشارات طابور حديثة. أضف وعي Prefix بعد قياس إعادة استخدام حقيقية. وأضف الأولويات مع ميزانيات صريحة. قيمة التوجيه الواعي بالاستدلال ليست أنه يبدو ذكيًا؛ بل أن كل قرار يمكن تفسيره ومراقبته والتراجع عنه.

إعداد: Noor Yasser