دمجت dBrain.cloud LocalAI وKubeflow في منصة حاويات للـ AI المؤسسي

شرح فريق dBrain كيف قام ببناء طبقتين مختلفتين للعمل مع الذكاء الاصطناعي على منصتهم الموجهة للحاويات: LocalAI للنشر السريع للنماذج الجاهزة و Kubeflow لدورة التطوير الكاملة. أظهرت الممارسة أن أكبر حجم من العمل لم يكن في النماذج ذاتها، بل في دمجها في البنية الأساسية والشبكات القائمة.

طبقتان من المنصة

اختارت dBrain LocalAI للنماذج الجاهزة. هذه الأداة مفتوحة المصدر تمكّن من نماذج الدردشة وتوليد الصور والفيديوهات والتعرف على الكلام وتركيبه، فضلاً عن السيناريوهات متعددة الأنماط. الميزة المهمة للمنصة التي تتمتع بموارد محدودة هي القدرة على تحميل وتفريغ النماذج بمرونة واستخدام معالج الرسومات حيث يكون ضروريًا، مع تقديم نقطة نهاية محلية للمطورين متوافقة مع API OpenAI. هذا مهم بشكل خاص عندما تكون موارد الحوسبة محدودة وتحتاج توزيع الحمل بين الخدمات إلى إعادة توازن سريعة.

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

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

• KServe لاستضافة النماذج وإدارتها
• Trainer للتدريب والتحسين
• Notebooks للتجريب السريع والضبط الدقيق
• Katib لضبط المعاملات الفائقة
• Model Registry و Pipelines للتخزين وأتمتة العمليات

لماذا بدون Knative

كان الجزء الأكثر جدلاً من التكامل هو KServe، الذي يتمتع بوضعي استدلال: وضع Knative والوضع القياسي. تركز الوثائق بشكل أساسي على توجيه الفرق نحو Knative. بالنسبة للكثيرين، يبدو هذا كخيار افتراضي. لهذا النهج مزايا قوية: يمكن للخدمات أن تتسع إلى الصفر بدون حركة مرور، ثم تستيقظ بسرعة عند الطلب، وتكتسب المنصة آليات مريحة للمراجعات وتقسيم حركة المرور والإصدارات الكناري.

لكن dBrain اختارت بوعي مسارًا مختلفًا. السبب ليس الأداء، بل التكلفة التشغيلية. يجلب Knative معه طبقة شبكة منفصلة وحاويات بروكسي قائمة إضافية داخل الكبسولات والاعتماد على تطبيقات البوابة مثل Istio أو Kourier. بالنسبة لمنصة المؤسسة، هذا يعني المزيد من المكونات للصيانة، المزيد من الأماكن التي قد تتعطل فيها الأشياء، وتشخيصات أكثر تعقيدًا. في النهاية، اختار الفريق الوضع القياسي، الذي يعتمد على Kubernetes Deployments و Services العادية ويتناسب بشكل أفضل مع نموذج التشغيل الموجود بالفعل.

الهجرة إلى Gateway API

لم يحل اختيار الوضع القياسي جميع المشاكل—بل نقلها إلى طبقة الشبكة. لكي يعمل هذا الوضع، يلزم Gateway API. كانت لدى dBrain بالفعل دعم أساسي لهذا المعيار، لكن معظم خدمات المنصة تم نشرها تاريخيًا عبر Ingress. لم يكن من الممكن الاحتفاظ بالمخطط القديم جنبًا إلى جنب مع الجديد: في بنيتهم، لم يستطع KServe في الوضع القياسي أن يتعايش بشكل صحيح مع نموذج ingress. أخذ الفريق في الاعتبار التكيف الموجه أو تبديل وحدة تحكم ingress، لكنه اعتبره إجراءً مؤقتًا.

بدلاً من ذلك، قررت إكمال الهجرة ونقل كامل نموذج الشبكة للمنصة إلى Gateway API. كانت هذه خطوة أكثر تكلفة في البداية، لكنها أزالت التسويات الوسيطة وأعدت البنية الأساسية لمعيار Kubernetes الجديد. في الواقع، أصبح تكامل خدمات الذكاء الاصطناعي إصلاحًا للبنية الأساسية أثر ليس فقط على مجموعة ML بل وأيضًا على نشر جميع الخدمات.

ماذا يعني هذا

توضح حالة dBrain بشكل جيد الواقع الحالي للذكاء الاصطناعي للمؤسسات: اختيار نموذج أو إطار عمل لم يعد كافيًا. يبدأ العمل الحقيقي حيث تحتاج إلى الجمع بين النشر السريع للنماذج الجاهزة و MLOps الكامل للتطوير الداخلي والتشغيل المتوقع في Kubernetes. النجاح لا يأتي للمجموعة الأكثر عصرية، بل للمجموعة التي يمكن الحفاظ عليها بشكل مستقر في الإنتاج. هذا هو السبب في أن قرارات البنية الأساسية هنا تؤثر على العمل بقدر اختيار النماذج ذاتها.