أنشئ بيئة تشغيل Kubernetes معتمدة لـ NVIDIA Dynamo

بناء بيئة تشغيل صالحة لـ Kubernetes لبرنامج NVIDIA Dynamo

تحتاج الفرق التي تطور تطبيقات الذكاء الاصطناعي إلى مسار قابل للتكرار من تكوين النموذج إلى نقطة نهائية لإجراء عمليات الاستدلال. يُعد برنامج NVIDIA Dynamo إطار عمل للتنبؤ الموزع مصممًا لتنسيق تقديم النماذج عبر وحدات GPU. لكن نشره على Kubernetes هو مجرد الخطوة الأولى فقط؛ فالنشر الناجح في البيئة الإنتاجية يتطلب أن تعمل برامج تشغيل GPU وتخصيص الموارد وجدولة المهام والشبكات وأدوات المراقبة كوحدة متكاملة. غالبًا ما يؤدي حل هذه الاعتماديات إلى سحب الوقت بعيدًا عن اختبار سلوك النماذج وأداء تقديم الخدمات.

لمواجهة هذه التعقيدات، تقدم منصة NVIDIA DSX AI Factory Platform بيئة تشغيل NVIDIA AI Cluster (AICR). تقوم هذه المنصة بتجميع برنامج NVIDIA Dynamo والبنية التحتية الداعمة له في وصفات مُختبرة ومُعتمدة. يحدد كل وصف تكوينًا محددًا لبيئة وعبء عمل معين، بما في ذلك إصدارات المكونات المحددة مسبقًا وقيود التوافق وعمليات التحقق من الصحة. توفر AICR لفرق المنصة طريقة قابلة للتكرار لنشر بيئة التشغيل والتحقق من صحتها، مما يضمن للمطورين أساسًا موحدًا لتقديم النماذج.

لماذا تُعد بيئة التشغيل الأساسية مهمة

يبدأ تشغيل نموذج باستخدام Dynamo على Kubernetes مع DynamoGraphDeployment الذي يحدد كيف يجب أن تعمل محركات مثل vLLM أو SGLang أو NVIDIA TensorRT LLM داخل البودز. لكن هذا الرسم التخطيطي يمثل فقط الجزء العلوي من الهيكل. يحتاج عنقود الاستدلال الإنتاجي إلى طبقة تشغيل قوية أسفله للإجابة على أسئلة البنية التحتية الحرجة مثل:

• هل تم تثبيت NVIDIA GPU Operator مع مجموعة برامج التشغيل المتوافقة مع العقد؟
• هل يكشف العنقود عن وحدات GPU من خلال برنامج تشغيل تخصيص الموارد الديناميكي (DRA) المتوقع؟
• هل يمكن لجدولة المهام توزيع وحدات GPU ذات التوبولوجيا المطلوبة وفقًا لمفاهيم جدولة المجموعات؟
• هل تتوفر إشارات صحة العقد قبل أن يتم تحميل عبء العمل على عقدة غير مستقرة؟
• هل تم تكوين مسار Gateway API / Endpoint Picker (EPP) عندما يجب أن يكون النشر متوافقًا مع Kubernetes عند نقطة الدخول؟

يتعامل AICR مع هذه المخاوف عن طريق تجميع كل من Dynamo ومكونات وقت التشغيل الخاصة بالمجموعة التي يعتمد عليها في وحدة واحدة. يقدم AICR الإصدار 1.4.2 من مخطط dynamo-platform، والذي يشمل مشغل Dynamo وصور وقت التشغيل وموارد مثل nvidia.com/v1beta1 DynamoGraphDeployment CustomResourceDefinition (CRD). يحل هذا الإصدار محل إصدار API السابق v1alpha1.

يحدد الوصفة إصدارات المكونات ويسجل قيم التكوين ومختارات العقد والتحملات والتحققات الرقمية وتوقعات التحقق لضمان إمكانية تكرار عملية النشر. ومن الجدير بالذكر أنه مع Dynamo 1.4، تكتشف الواجهات الأمامية والعمال والخدمات الأخرى بعضها البعض من خلال موارد Kubernetes. ونتيجة لذلك، لم يعد المسار الافتراضي لـ AICR في Kubernetes يستخدم NATS، كما أن مخطط dynamo-platform لم يعد يقوم بتثبيته افتراضيًا. يظل NATS متاحًا كخيار اختياري للنشرات التي تحتاج إليه بشكل محدد.

مسارات التوجيه والبنية التحتية

يستخدم Dynamo 1.4.2 بروتوكول TCP لمستوى الطلبات وبروتوكول ZMQ لأحداث ذاكرة التخزين المؤقت من نوع KV. تسمح هذه البنية التحتية لكل من موجه الواجهة الأمامية الأصلي لـ Dynamo وتوسيع API للتنبؤ (GAIE) / مكون اختيار نقطة النهاية (EPP) باتخاذ قرارات التوجيه المدركة لذاكرة التخزين المؤقت. يعتمد الاختيار بين هذه المسارات على المتطلبات المحددة للتوبولوجيا والإدارة لعملية النشر.

المسار 1: موجه الواجهة الأمامية لـ Dynamo

يكشف المسار الافتراضي عن واجهة أمامية لـ Dynamo خلف خدمة Kubernetes. عند التشغيل مع DYN_ROUTER_MODE=kv، يقوم الموجه بتحويل كل طلب إلى رموز، ويقيّم العمال المؤهلين باستخدام التداخل في البادئات والحمل الحالي، ثم يختار عاملاً ويرسل الطلب عبر مستوى طلبات Dynamo، الذي يستخدم بروتوكول TCP افتراضيًا.

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

في هذا الإعداد، يختار واجهة المستخدم الخاصة بـ Dynamo عامل vLLM بناءً على تداخل ذاكرة التخزين المؤقت KV وحجم العبء. تستخدم الطلبات مستوى طلبات TCP، بينما تصل أحداث ذاكرة التخزين المؤقت KV للعامل إلى واجهة المستخدم عبر مستوى الأحداث المدعوم بـ ZMQ.

المسار 2: توسيع واجهة برمجة التطبيقات للبوابة وخدمة Dynamo EPP

يدمج المسار الثاني Dynamo مع واجهة برمجة التطبيقات للبوابة وتوسيع واجهة برمجة التطبيقات للبوابة للتنبؤ (GAIE). في مثال AICR، يقوم agentgateway بتحويل HTTPRoute إلى InferencePool. يقوم مشغل Dynamo بإنشاء هذا InferencePool من DynamoGraphDeployment؛ حيث يحدد المختار البودات العاملة المؤهلة، بينما يحدد endpointPickerRef خدمة Dynamo EPP.

تستدعي البوابة خدمة Dynamo EPP عبر واجهة اختيار نقطة النهاية الخاصة بـ GAIE. تقوم خدمة EPP بتحويل الطلب إلى رموز وتستخدم موجه KV الخاص بـ Dynamo لاختيار نقطة نهاية. تعيد خدمة EPP بيانات الاختيار والتوجيه إلى تنفيذ البوابة، التي تعمل كبروكسي HTTP فعلي. في هذا الوضع، يحتوي كل بود عامل قابل للتوجيه على وحدة Dynamo Frontend الجانبية التي تستقبل الطلب من البوابة وتحوله إلى حاوية العامل المحلية. تعمل واجهة المستخدم مع --router-mode direct، مع تطبيق اختيار EPP دون إعادة التوجيه.

يكون هذا المسار مناسبًا عندما يدير فريق المنصة نقاط الدخول المشتركة في Kubernetes ويحتاج إلى تكوين اختيار نقاط نهاية النماذج وأوقات التوقف وإعادة المحاولة والبدائل عبر آليات واجهة برمجة التطبيقات للبوابة. يُلاحظ أن كلا طريقتي التوجيه يمكن أن تعملا خلف واجهة برمجة التطبيقات للبوابة HTTPRoute؛ الفرق يكمن في العنصر الذي يدير النقل إلى العامل: واجهة المستخدم الخاصة بـ Dynamo أو البوابة نفسها.

تدفق وصفة AICR

تفصل AICR بين إعداد وقت التشغيل ونشر التطبيقات من خلال تدفق مكون من خمس خطوات مصمم لضمان الاستقرار والدقة قبل تثبيت أعباء العمل التطبيقية.

الخطوة 1: أخذ لقطة للعنقود

يبدأ العملية بالتقاط الحالة الحالية للعنقود لإنشاء أساس لعملية النشر.

الخطوة 2: إنشاء وصفة التنبؤ الخاصة بـ Dynamo

باستخدام اللقطة، يقوم النظام بإنشاء وصفة تنبؤ خاصة بـ Dynamo مصممة لتلبية متطلبات البيئة وأعباء العمل المحددة.

فحص خارج الشبكة اختياري

يمكن للفرق إجراء فحص خارج الشبكة اختياري للتحقق من إعدادات الوصفة قبل الانتقال إلى عملية النشر.

الخطوة 3: تحويل حزمة الأداء إلى صيغة قابلة للنشر

يتم تحويل الوصفة المُعتمدة إلى حزمة نشر، مع تجهيز جميع الموارد والإعدادات الضرورية.

الخطوة 4: نشر بيئة الأداء

يتم نشر بيئة الأداء باستخدام أدوات مثل Helmfile أو GitOps. تقوم هذه الخطوة بتطبيق الإعدادات على المجموعة، وتثبيت المشغل والصور والبنية التحتية الداعمة.

الخطوة 5: التحقق من بيئة الأداء المُثبتة

قبل تثبيت أعباء العمل التطبيقية، يجب التحقق من بيئة الأداء المُثبتة لضمان توفر جميع المتطلبات وجاهزية النظام لتنفيذ المهام.

ما هي عمليات التحقق في AICR

يضمن نظام AICR للتحقق أن البنية التحتية تلبي المتطلبات الصارمة لعمليات التعلم الآلي الموزع. تتحقق عملية التحقق من وجود وصحة مشغل GPU من NVIDIA، وتوافق مجموعة برامج التشغيل، وإمكانية استخدام وحدات GPU من خلال برنامج تخصيص الموارد الديناميكي (DRA)، بالإضافة إلى توفر إشارات حالة العقد. كما يتحقق النظام من أن مسار API Gateway أو Endpoint Picker مُعد بشكل صحيح وفقًا لتصميم توجيه البيانات المختار.

من خلال أتمتة هذه الفحوصات، يسمح نظام AICR لفرق المنصة بالتركيز على منطق التطبيقات بدلاً من إصلاح مشاكل البنية التحتية. يدعم هذا النهج الهدف الأوسع لمنصة NVIDIA DSX AI Factory: مساعدة النظام البيئي على تصميم وبناء وتشغيل مصانع ذكاء اصطناعي أكثر كفاءة.

الخلاصة

يتطلب بناء بيئة أداء مُعتمدة لـ Kubernetes لنظام NVIDIA Dynamo أكثر من مجرد نشر رسم بياني للنموذج؛ فهو يتطلب نهجًا منسقًا في إدارة البنية التحتية واستراتيجيات التوجيه وعمليات التحقق. يوفر نظام NVIDIA AI Cluster Runtime (AICR) الإطار اللازم لتغليف نظام Dynamo ومكوناته المعتمدة في وصفات قابلة لإعادة تنفيذها. سواء باستخدام موجه Dynamo Frontend الأصلي لنقاط النهاية الخاصة بكل نموذج أو استخدام توسيع Gateway API Inference للوصول المشترك، يضمن نظام AICR أن بيئة الأداء الأساسية قوية ومُختبرة وجاهزة لأعباء العمل الإنتاجية.

للفرق التي تسعى إلى تبسيط عمليات مصانع الذكاء الاصطناعي الخاصة بها، يوفر استكشاف بيئة NVIDIA AI Cluster Runtime مسارًا منظمًا لتكوين والتحقق من بنية الاستدلال بكفاءة.

المصدر: https://developer.nvidia.com/blog/build-a-validated-kubernetes-runtime-for-nvidia-dynamo