تتبرع NVIDIA بمشروع OpenShell إلى CNCF وتضيف أدوات مفتوحة المصدر لمصنع الذكاء الاصطناعي

أعلنت NVIDIA في 10 نوفمبر 2026، خلال KubeCon + CloudNativeCon، أنها ستسهم بمكوّن تشغيل OpenShell لأمن الوكلاء في حاضنة Cloud Native Computing Foundation (CNCF)، وستطرح ثلاثة مكوّنات مفتوحة المصدر لمنصة DSX AI Factory.

تربط الإعلانات بين حوكمة الوكلاء والبنية التحتية اللازمة لتشغيلهم بكفاءة. وتسهم NVIDIA أيضًا في مشروع Agent Substrate الذي نشأ في Google، وتضيف إلى DSX محرك Kubernetes ووصفات Kubernetes وSnapshot، لتغطي بذلك تنفيذ الجلسات وإدارة العناقيد والتعافي من أعطال الاستدلال.

انتقال OpenShell نحو الحوكمة المجتمعية

يطبّق OpenShell ضوابط حتمية عندما تستخدم الوكلاء المستقلة الأدوات، وتصل إلى خدمات الاستدلال، وتنفّذ أعباء العمل. ويشغّل الوكلاء في بيئات معزولة على مستوى النواة، مع سياسات YAML تصريحية تشمل الوصول إلى نظام الملفات والشبكة والعمليات وبيانات اعتماد مزوّد الخدمة. ولا تُدرج بيانات الاعتماد إلا في الطلبات الموجّهة إلى نقاط نهاية معتمدة، كما يتحقق التحقق الصوري مما إذا كان تغيير مقترح للسياسة سيمنح صلاحيات وصول جديدة تنطوي على مخاطر، وذلك قبل الموافقة عليه.

يخضع مكوّن التشغيل لترخيص Apache 2.0. وتفيد NVIDIA بأن مئات المؤسسات استخدمته، وأن عشرات الآلاف من المساهمات قُدّمت في أقل من عام، وأن حوكمة الحاضنة ستشمل المؤسسات التي تدمجه في منتجاتها. ولا يزال الانتقال جاريًا: إذ يفيد إشعار المشروع بأن التطوير ينتقل إلى مؤسسة ai-openshell، فيما سيظل الرمز البرمجي والبلاغات وطلبات السحب في NVIDIA/OpenShell خلال هذه المرحلة.

يستهدف Agent Substrate موارد الحوسبة الخاملة

يعالج Agent Substrate كلفة إبقاء جلسات الوكلاء قيد التشغيل. فكثيرًا ما تنتظر الوكلاء الأوامر أو نتائج الأدوات أو ردود النماذج؛ وتُبقي حاوية Kubernetes Pod دافئة ومخصصة الموارد متاحة خلال فترات الانتظار هذه، بينما تؤدي إعادة إنشاء الحاوية إلى فقدان الحالة والتكبد من جديد كلفة بدء بارد. وتتعاون NVIDIA وGoogle أيضًا على دمج OpenShell لدعم الوكلاء عبر الأنظمة السحابية والأنظمة المحلية.

يربط تصميم Agent Substrate عددًا كبيرًا من الجلسات ذات الحالة بمجموعة أصغر من العمال الدافئين. ويحفظ نقاط استعادة للجلسات الخاملة، بما فيها حالة الذاكرة ونظام الملفات، ثم يحرر العمال الذين كانت تستخدمهم ويعيد تشغيلها على عمال متاحين، من دون تكرار المسار المعتاد لإنشاء حاوية Kubernetes Pod. ويظل العمال حاويات Kubernetes Pods عادية، لذلك تستمر سياسات جدولة العنقود وحصصه وتحديد مواضع الموارد في التطبيق. وتشمل أعباء العمل المستهدفة مساعدات البرمجة وبيئات التعلم المعزز وبيئات البحث المعزولة قصيرة الأجل التي تستخدم وحدات GPU.

تطوّر NVIDIA قابلية التشغيل البيني مع Dynamo للاستدلال وKAI Scheduler لموارد العناقيد المشتركة. ويمكن لـDynamo توفير الزمن المتوقع حتى ظهور الرمز الأول ومقدار تشبّع مجموعة وحدات GPU، كي يقرر Agent Substrate ما إذا كان سيُبقي الوكيل مقيمًا، أو سيعلّقه، أو سيستأنف تشغيله. ولا تزال واجهات API الخاصة به تتغير، ويُعاد بناء دعم وحدات GPU بالاستناد إلى التخصيص الديناميكي للموارد في Kubernetes، كما أن أجزاءً من تكامل Dynamo ما تزال تجريبية.

تضيف DSX إدارة العناقيد وتسريع عمليات الاستعادة

NVIDIA Kubernetes Engine وNVIDIA Kubernetes Recipes (NVKE وNVKR) متاحان في معاينة عامة بموجب ترخيص Apache 2.0. وتقول NVIDIA إن واجهاتهما وتهيئتهما وسلوكهما قد تتغير، ولا توصي بهما بعد لأعباء العمل الإنتاجية. وينشئ NVKR صورًا قابلة لإعادة الإنتاج للعُقد والحاويات والملفات الثنائية ومخططات Helm من مصادر مثبتة الإصدارات، ويسجل المدخلات المستخدمة. أما NVKE فيستخدم هذه المخرجات لتوفير العناقيد وتشغيلها عبر واجهة REST API ووحدات التحكم، مع إمكان اعتماد كل مشروع على حدة.

ينشئ NVKE عناقيد لأعباء عمل العملاء، مزودة بمستويات تحكم منفصلة في Kubernetes ومثيلات etcd ومجموعات من العُقد. ويحصل على سعة الأجهزة المجردة عبر NVIDIA Infra Controller ومزوّد واجهة Cluster API التابع له، CAPNICo؛ ويجب أن تقدم العقدة هوية SPIFFE موثقة قبل أن تتلقى بيانات اعتماد الانضمام. وتدمج Firmus وSK Telecom المشروعين في مصانع الذكاء الاصطناعي التابعة لهما، فيما تخطط Mirantis وNetris وOpenNebula Systems وRafay وSpectro Cloud وvCluster لتكاملات تشمل منصات البنية التحتية أو عروض Kubernetes المُدارة أو أتمتة الشبكات.

يعالج NVIDIA Snapshot حالات البدء البارد للاستدلال عبر حفظ نقطة استعادة لذاكرة وحدة المعالجة المركزية ووحدة معالجة الرسوميات في عبء عمل مهيأ بالكامل. وتتطلب الاستعادة استخدام طراز وحدة GPU نفسه وبرنامج التشغيل نفسه، كما تتجاوز إعادة تحميل الأوزان والتجميع والتقاط رسوم CUDA البيانية.

على وحدات B200 GPU مع تخزين VAST NFS، تفيد NVIDIA بأن الاستعادة استغرقت ما بين 3.6 و42.7 ثانية عبر إعدادات vLLM وSGLang وTensorRT LLM، وبأن السرعة زادت من 8x إلى 36x مقارنةً بالبدء البارد. وتراوحت الاختبارات بين نموذج يضم 600 مليون مُعامل وإعدادات تستخدم ثماني وحدات GPU مع نقاط استعادة اقترب حجمها من 1 TB. واستغرق إنشاء نقاط الاستعادة ما بين 15 ثانية و5.5 دقائق، وكان الزمن اللازم لإنشاء نقطة استعادة ثم الاستعادة أقصر من زمن بدء بارد واحد في كل إعداد خضع للاختبار.

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

استخدم اختبارها الخاص بـGLM-5.3 الذي أجرته Crusoe على NVIDIA HGX B300 نقطةَ تحقق احتوت على 594 جيجابايت من حالة وحدة معالجة الرسوميات. وقاست Crusoe استعادة حالة وحدة معالجة الرسوميات، فاستغرقت 15.0 ثانية من وحدة تخزين NVMe محلية، مقابل 33.3 ثانية من NFS. وعندما كان ملف البيانات على وحدة تخزين NVMe، استغرق إنشاء الـpod حتى جاهزيته 31 ثانية، مقارنةً بنحو ثماني دقائق عند بدء التشغيل البارد، ما يحدد التخزين عاملًا رئيسيًا في أداء الاستعادة. كما أسهمت Crusoe بتعديلات لتحسين الأداء والتشخيص في المشاريع upstream.

تُسهم هذه المشاريع مجتمعةً في نقل مزيد من مكونات مستوى التحكم في مصنع الذكاء الاصطناعي ومسار الاستعادة إلى مستودعات مفتوحة، لكنها تختلف في مستويات نضجها: فما زالت خطوة نقل OpenShell إلى الحوكمة مفتوحة المصدر غير مكتملة، ولا يزال Agent Substrate قيد التطوير، فيما لا يزال كل من NVKE وNVKR في مرحلة المعاينة. وتقدم اختبارات Snapshot المعيارية أوضح مكسب تشغيلي مقاس، بينما توضح متطلبات التوافق ونتائج Crusoe المتعلقة بالتخزين أن تسريع الاستعادة يعتمد على كل من حالة عبء العمل القابلة لإعادة الاستخدام والبنية التحتية المحيطة بها.