لا تتمثل «مصنع الذكاء الاصطناعي» في نموذج واحد أو عنقود Kubernetes منفرد، بل في أسطول مشترك من وحدات معالجة الرسوميات GPU تستخدمه فرق متزامنة لأغراض مختلفة: الضبط الدقيق، وتشغيل الاستدلال، والتقييم. ويرى مقال منشور على مدونة CNCF أن التحدي المؤسسي الحقيقي لم يعد تدريب النموذج فقط، بل منح كل فريق وصولاً آمناً ومعزولاً إلى العتاد نفسه، مع إبقاء استخدام وحدات GPU مرتفعاً والتكلفة قابلة للقياس.
كتب المادة Hrittik Roy، بصفته CNCF Ambassador وPlatform Advocate في vCluster، وتقدم قراءة عملية لكيفية تركيب هذه البيئة فوق Kubernetes. الفكرة المركزية في المقال أن Kubernetes يوفر أساساً ناضجاً للحاويات، وRBAC، والتوسع التلقائي، والسياسات، لكنه احتاج إلى منظومة إضافية للتعامل مع المسرّعات والعزل بين المستأجرين على العقد نفسها.
الاختناق هو الاستغلال لا سرعة الاستدلال وحدها
تمثل وحدات GPU النفقات الرأسمالية الأكبر في بنية الذكاء الاصطناعي، ولذلك تصبح نسبة الاستغلال مؤشراً اقتصادياً أكثر أهمية من تسجيل سرعة قصوى في تشغيل واحد. ويعرض المقال مشكلتين رئيسيتين: نموذج تخصيص الموارد، ونموذج العزل.
في نموذج device plugin التقليدي، يطلب الحمل مثلاً nvidia.com/gpu: 1 ويحجز وحدة كاملة حتى لو استخدم عشرة في المئة منها فقط. أما Dynamic Resource Allocation أو DRA، الذي أصبح متاحاً بصورة عامة في Kubernetes 1.34، فيتيح للمجدول التعامل مع المسرّعات كأجهزة ذات خصائص وذاكرة وطوبولوجيا. لكنه لا يقسم وحدة GPU إلى حصص من تلقاء نفسه؛ إذ تأتي الكثافة من طبقة الجهاز، مثل HAMi، وهو مشروع في مرحلة Incubating ضمن CNCF يفرض حدوداً برمجية للذاكرة والحوسبة على مستوى الحاوية ويدعم عدة مورّدين للمسرّعات.
في المقابل، قد يؤدي تخصيص عتاد منفصل لكل فريق إلى عزل قوي لكنه يترك جزءاً كبيراً من السعة غير مستخدم. لذلك يميز المقال بين تخصيص وحدة كاملة عندما تكون حدود الثقة صارمة، وتقسيم الوحدة داخل نطاق ثقة واحد لرفع الكثافة. وتوفر NVIDIA MIG عزلاً للذاكرة والأعطال على مستوى العتاد، لكن المقال يلفت إلى أن استخدامها فاصلاً بين مستأجرين عدائيين ما زال موضع نقاش؛ ولذلك يبقى تخصيص GPU كاملة الخيار المحافظ في حالات الثقة المنخفضة.
طبقات المصنع من المعدن إلى الحمل
تبدأ المنظومة من التزويد بالعتاد الخام. إذ تُكتشف العقد وتُفحص وحدات GPU وحالة ذاكرة ECC وهويات بطاقات الشبكة، ثم تُثبت صورة نظام التشغيل التي تتضمن تعريف GPU ومكتبات CUDA وNCCL. بعد ذلك تطبق إعدادات BIOS المناسبة، وتخضع العقد لاختبارات التحمل واختبارات NCCL للتأكد من اتصال وحدات GPU بالعرض الكامل للنطاق الترددي، قبل تسجيل النتيجة في مصدر للحقيقة مثل NetBox. ويمكن بناء هذه الدورة عبر مدير عتاد خاص بالمورّد أو باستخدام أدوات مفتوحة مثل Metal3 مع Ironic أو vMetal.
بعد التخصيص، تتولى أدوات مثل KAI Scheduler وVolcano عمليات الجدولة الجماعية والمراعية للطوبولوجيا، بينما يدير Kueue الانتظار والقبول والحصص. وفي طبقة الأحمال، يمكن استخدام vLLM لمحركات الاستدلال، وKServe لتوفير نقاط نهاية قياسية والتوسع التلقائي، إضافة إلى NVIDIA Dynamo وllm-d للاستدلال المفكك في البيئات الأكبر. وتوفر Gateway API التوجيه، فيما يضيف LiteLLM بوابة متوافقة مع واجهة OpenAI.
لا تقتصر المنصة على الحاويات. يوضح المقال أن بيئات التدريب قد تستخدم Slurm عبر Slinky من SchedMD، الذي يمثل خدمات Slurm كموارد مخصصة ويدمجها مع GPU Operator وDRA. كما يمكن لـ KubeVirt تشغيل الآلات الافتراضية كأحمال Kubernetes، بحيث تُدار الآلات الافتراضية والحاويات من الأسطول نفسه وبصلاحيات وحصص موحدة.
العزل ليس مجرد مساحات أسماء
يقسم المقال مشكلة العزل إلى مستويين. في مستوى التحكم، يمنح نمط tenant cluster كل فريق واجهة Kubernetes افتراضية تتضمن خادم API وموارد مخصصة وقواعد قبول وRBAC مستقلة، مع تشغيلها كحمل فوق عنقود أساسي واحد. ويقدم vCluster مثالاً على ذلك، مع إمكانية استخدام أدوات مألوفة مثل kubectl وHelm وArgo CD من دون امتدادات احتكارية.
أما مستوى البيانات فيحتاج إلى عزل الشبكات والتخزين والحصص وبيئة التشغيل. يمكن استخدام Cilium للـCNI والسياسات، وMultus وSR-IOV للمسار السريع، مع InfiniBand أو RoCEv2 لنقل حركة GPU بين العقد. كما تُستخدم VPCs منفصلة عبر VXLAN وEVPN، أو مفاتيح تقسيم في InfiniBand، بينما تنقل وحدات DPU مثل NVIDIA BlueField أو AMD Pensando بعض وظائف العزل والتشفير بعيداً عن المعالج المضيف. ويؤكد المقال أن معيار السحابة الحقيقية هو العزل المفروض عتادياً عند الحاجة، وليس الاعتماد على namespaces وحدها.
ما الذي يحول الأسطول إلى خدمة سحابية؟
القراءة التحريرية: القيمة العملية في هذا الطرح أنه ينقل النقاش من «أي نموذج أسرع؟» إلى سؤال تشغيل البنية نفسها. فالمنصة لا تصبح خدمة سحابية لمجرد تجميع وحدات GPU؛ بل عندما يستطيع المستأجر إنشاء العناقيد وحذفها عبر API أو Terraform أو GitOps، وتكون الموارد معرفة بصيغة إعلانية تديرها Flux أو Argo CD، مع هوية OIDC وصلاحيات RBAC.
وتحتاج الخدمة كذلك إلى قياس وفوترة مفهومين. يقترح المقال استخدام بيانات DCGM لحساب ثواني GPU، ثم توزيعها على المستأجرين عبر OpenCost. كما تعد المراقبة والموثوقية جزءاً من المنتج، لا ملحقاً تشغيلياً: فـDCGM يراقب التدهور، ويحول Node Problem Detector إشارات الأعطال إلى حالات للعقد، فيما تعزل دورة المعالجة العقدة المشكوك فيها وتفرغها قبل جدولة أحمال جديدة. وتشمل طبقة الأمن أدوات مثل Keycloak عبر OIDC، وOpenBao مع External Secrets Operator، وKyverno أو OPA للضوابط، وFalco وTrivy لأمن التشغيل وسلسلة التوريد.
يبقى الاختبار الأصعب هو الانتقال من عرض تجريبي إلى إنتاج واسع. فالمثال الذي يشغل فريقين ونموذجين على GPU واحدة مقسمة لا يثبت وحده صلاحية التصميم عند مئات العقد وعدة مراكز بيانات. ويشير المقال إلى دور أدوات التحقق مثل NVIDIA AI Cluster Runtime وبرنامج Kubernetes AI Conformance الذي قُدم مع إصدار 1.35، لكنه يترك أسئلة تشغيلية مفتوحة حول نصف قطر الانفجار، وحدود العزل بين المستأجرين، والاختيار بين حزمة NVIDIA DSX OS وتجميع طبقات مفتوحة المصدر.
الخلاصة أن نجاح «مصنع الذكاء الاصطناعي» يتوقف على الجمع بين الكثافة والعزل والفوترة مع مراعاة طوبولوجيا العتاد: مواقع وحدات GPU بالنسبة إلى NVLink أو NVSwitch، واتصالها بشبكة InfiniBand أو RoCE، ومواضع GPU وNIC وCPU على عقد NUMA. فجدولة الحمل من دون هذه المعطيات قد تجعل عمليات الاتصال الجماعي تتباطأ عند أبطأ وصلة، حتى لو بدت المنصة سليمة على مستوى البرمجيات.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.