Buoyant تطلق Kinference: مستوى تحكم مفتوح المصدر لاستدلال النماذج على Kubernetes وvLLM

أصدرت Buoyant، المعروفة بعملها على Linkerd، مشروع Kinference، وهو مشروع مفتوح المصدر مصمم لبناء منصات استدلال النماذج على Kubernetes. يعمل Kinference كمستوى تحكم لاستدلال النماذج على Kubernetes وvLLM، ويدير توجيه الطلبات إلى مجموعة من عمال vLLM. يطبق سياسات التوجيه، وحدود معدل الرموز، وموازنة أحمال تراعي ذاكرة KV-cache، ومقاييس لكل مستأجر، مستهدفًا الطبقة التي تعلو خادم النموذج. المشروع مرخص بموجب Apache 2.0 ومتاح على GitHub. الإصدار الحالي هو v0.1.0-alpha.7.

باختصار

• الحجم: الإصدار v0.1.0-alpha.7، مكتوب بلغة Rust، بترخيص Apache 2.0، ويُضبط عبر 5 من CRDs الخاصة بـ Kubernetes.
• يعمل على: أي عنقود Kubernetes ممكّن بوحدات GPU ويشغل vLLM. استخدم اختبار Buoyant 3 وحدات GPU من نوع L40S لكل مجموعة.
• الأداء: تحسينات كبيرة في حركة المرور ذات البادئات المشتركة مقارنة بتوجيه Kubernetes Service القياسي (وفقًا لتقرير الشركة).
• أفضل حالة: انخفض متوسط TTFT من 6.88 ثانية إلى 0.31 ثانية (بنسبة 95%) في عبء عمل ببادئة مشتركة.
• أسوأ حالة: لا تحسن في متوسط TTFT مع مطالبات بدون بادئات مشتركة (6.92 ثانية مقابل 6.83 ثانية).

ما هو Kinference؟

Kinference هو مستوى تحكم مدفوع بالسياسات يحول Kubernetes وvLLM إلى منصة استدلال متعددة المستأجرين. وفقًا لأسئلة Buoyant الشائعة، يعمل vLLM كمستوى البيانات بينما يعمل Kinference كمستوى التحكم.

كيف يعمل Kinference؟

يتكون النظام من مكونين: بوابة حركة المرور ومعالج الاستدلال. يوفر المعالج واجهة gRPC، ويعالج الطلبات ويعيد نقطة النهاية المختارة مع جسم قد يكون معدلًا. ويعمل بالتعاون مع وكيل (proxy) مثل Buoyant Gateway.

يراقب Kinference أحداث ذاكرة KV-cache في vLLM ومقاييس المحرك، ويستخدم حاليًا حزمة dynamo-kv-router من NVIDIA لمعالجة أحداث التخزين المؤقت. تُدار التهيئة عبر خمسة تعريفات موارد مخصصة (CRDs): GatewayBackend وInferencePolicy وInferencePool وInferenceProvider وInferenceWorkerSet.

ما هي سياسات الاستدلال؟

سياسات الاستدلال هي قواعد تعريفية تحدد كيفية توجيه كل طلب أو رفضه. يمكن أن تطابق هذه القواعد بناءً على المستأجر، والنموذج المطلوب، وحالة مجموعة GPU، والوسوم الدلالية. تشمل السياسات النموذجية المتاحة على موقع المشروع:

• من البسيط إلى الأرخص: توجيه المطالبات منخفضة التعقيد إلى نموذج أصغر ما لم يجعل تداخل ذاكرة التخزين المؤقت النموذج الأكبر أسرع.
• الانفجار إلى السحابة: تجاوز العمال الذين لديهم أكثر من مطالبتين في قائمة الانتظار، والعودة إلى مزودين مثل Bedrock إذا لزم الأمر.
• بيانات PII تبقى محلية: استبعاد المزودين الخارجيين عند تفعيل وسم PII، مع الفشل المغلق باستخدام onEmpty: Reject.
• المعالجة الدفعية على وحدات GPU الخاملة: توجيه طلبات المعالجة الدفعية فقط إلى العمال الذين تقل نسبة استخدام ذاكرة KV-cache لديهم عن 70%.
• الأسماء المستعارة للنماذج: الاحتفاظ باسم واحد ثابت، مثل standard-model، تدعمه نماذج متعددة.

تنتهي معظم السياسات بـ minimize: PredictedTTFT، حيث يتوقع Kinference زمن الوصول إلى أول رمز لكل نقطة نهاية مرشحة بناءً على تداخل ذاكرة التخزين المؤقت وطول قائمة الانتظار. تُخزن السياسات في Git ويمكن التحقق منها دون اتصال باستخدام أداة سطر الأوامر kinfctl.

يمثل Kinference تقدمًا كبيرًا للمطورين الذين يديرون نماذج متعددة مفتوحة الأوزان لعملاء داخليين متنوعين، مما يبسط عملية استدلال النماذج على Kubernetes.

رابط ذو صلة: buoyant.io

المصدر: MarkTechPost