قامت Netflix بوصف دروس الإنتاج الكامنة وراء جلب استدلال LLM إلى منصة الخدمة الداخلية الخاصة بها، بما في ذلك التحديات المتمثلة في دعم أحجام النماذج المختلفة، ومتطلبات الأجهزة، ومحركات الاستدلال سريعة التطور.
يغطي حساب الشركة الاختيارات المعمارية والعمل التشغيلي المتضمن في تشغيل أحمال العمل المجمعة وفي الوقت الفعلي عبر وحدات المعالجة المركزية (CPUs) ووحدات معالجة الرسومات (GPU)، بدءًا من تعبئة النماذج ونشرها وحتى فك التشفير المقيد وتوافق الإصدارات.
يعتمد النظام الأساسي على طبقة العرض القائمة على JVM الخاصة بـ Netflix، والتي تستمر في التعامل مع التوجيه واسترجاع الميزات وإنشاء المرشحين والمعالجة اللاحقة والتسجيل. يمكن تشغيل النماذج الأصغر أثناء المعالجة على وحدات المعالجة المركزية (CPUs)، بينما يتم تفويض الطلبات الأكبر إلى MSS، حيث يتولى Triton تحميل النموذج، وتجميعه، وجدولة وحدة معالجة الرسومات (GPU)، وخدمة الإطارات المتعددة. يسمح ذلك لسير عمل الإنتاج المحيط بالبقاء متسقًا حتى أثناء انتقال الاستدلال بين الأجهزة المحلية والبعيدة.
ضمن مسار وحدة معالجة الرسومات، اختارت Netflix vLLM لملاءمتها التشغيلية وقابليتها للتوسعة مع الاحتفاظ بمسؤوليات إدارة النماذج والجدولة الخاصة بشركة Triton. يتحكم Triton في بيئة العرض حول النموذج، بينما يقوم vLLM بإجراء الاستدلال ويوفر آليات توسيع للسلوك المخصص. قد تؤدي تقارير Netflix التي تشير إلى عدم تطابق إصدارات Triton وvLLM إلى منع تحميل عمليات النشر، مما يتطلب اختبار الإصدارات المتوافقة وتثبيتها معًا.
قدمت النماذج المخصصة تحديًا آخر للتكامل. لم يكن التوافق مع ميزة Hugging Face في vLLM كافيًا لبعض طرز Netflix، لذلك استخدمت الشركة نقاط امتداد vLLM للبنيات المخصصة وسلوك فك التشفير.
قامت Netflix أيضًا بمقارنة طريقتين للتغليف من Triton: الواجهة الخلفية لـ Triton’s Python والواجهة الخلفية vLLM الخاصة بها. تفيد الشركة أن نهج vLLM-backend يسمح للنماذج والواجهات الأمامية بالتطور بشكل أكثر استقلالية من خيار Python-backend. يؤثر الاختيار على مدى إحكام اقتران النموذج ببيئة الخدمة الخاصة به بدلاً من تحديد المحرك الذي يقوم بالاستدلال.
لم تقم واجهة العرض المشتركة بإزالة الاختلافات بين المحركات الأساسية. على الرغم من أن Triton كشفت عن واجهة برمجة تطبيقات متوافقة مع OpenAI إلى جانب الواجهات الأمامية لـ KServe HTTP وgRPC، إلا أن Netflix لا تزال تواجه فجوات في كيفية التعامل مع بعض الميزات عبر عمليات التكامل هذه.
وكان فك التشفير المقيد أحد الأمثلة. فهو يسمح لـ Netflix بفرض استجابات النموذج في تنسيقات مثل JSON الصالح عن طريق تصفية الرموز المميزة التي قد ينشئها النموذج في كل خطوة. ونظرًا لأن هذه القواعد تعتمد على كل ما تم إنشاؤه حتى الآن، يجب أن يحافظ جهاز فك التشفير على الحالة طوال الطلب. عندما يتوقف vLLM مؤقتًا ثم يستأنف طلبًا لإدارة موارد وحدة معالجة الرسومات (GPU)، يمكن أن لا تكون هذه الحالة متزامنة مع سجل الرمز المميز، لذلك
أضافت Netflix منطقًا لاكتشاف التغيير وإعادة بنائه قبل استمرار عملية الإنشاء.
يؤثر التوافق أيضًا على النشر. قامت دبابيس Netflix باختبار إصدارات Triton وvLLM معًا لمنع فشل التحميل الخلفي، بينما تتعامل استراتيجيات النشر Red-Black وVersioned مع التغييرات على مستوى النموذج. تحافظ عمليات النشر ذات الإصدارات على المراجعات القديمة والجديدة متاحة بشكل منفصل، مما يسمح للمستهلكين بالترحيل بعد التكيف مع مخططات الإدخال أو الإخراج غير المتوافقة.
لقد وصفت أوبر نهجًا ذا صلة عند حدود التطبيق. تقدم بوابة الذكاء الاصطناعي التوليدية الخاصة بها واجهة متوافقة مع OpenAI عبر النماذج المستضافة خارجيًا والمدارة داخليًا، مع تركيز الاهتمامات بما في ذلك المصادقة والتخزين المؤقت وإمكانية المراقبة والتوجيه. يختلف التنفيذ عن منصة العرض الخاصة بـ Netflix، لكن كلاهما يفصل تكامل التطبيقات عن النماذج وأوقات التشغيل وبيئات الاستضافة التي تقف وراءها.
تُظهر تجربة Netflix كيف يمكن لواجهة العرض المشتركة أن تتوضع فوق عدة طبقات متميزة. يعكس هذا النوع من البنية جهدًا أوسع لمنح فرق التطبيقات سطحًا مستقرًا للتكامل بينما يستمر موفرو النماذج وأوقات تشغيل الخدمة في التغير. يوضح حساب Netflix أيضًا أن التجريد لا يزيل العمل الأساسي: لا تزال التعبئة وعناصر التحكم في التوافق وفك التشفير المقيد وعزل النشر تتطلب هندسة في كل طبقة.
