NVIDIA fait don d’OpenShell à la CNCF et ajoute des outils open source pour les usines d’IA

NVIDIA a annoncé le 10 novembre 2026, lors de KubeCon + CloudNativeCon, qu’elle contribue son environnement d’exécution sécurisé pour agents, OpenShell, au programme Sandbox de la Cloud Native Computing Foundation (CNCF) et publie trois composants open source pour sa plateforme DSX AI Factory.

Ces annonces associent la gouvernance des agents à l’infrastructure nécessaire pour les exécuter efficacement. NVIDIA contribue également au projet Agent Substrate, créé par Google, et ajoute Kubernetes Engine, Kubernetes Recipes et Snapshot à DSX, couvrant l’exécution des sessions, la gestion des clusters et la reprise après incident de l’inférence.

OpenShell s’oriente vers une gouvernance communautaire

OpenShell applique des contrôles déterministes lorsque des agents autonomes utilisent des outils, accèdent à des services d’inférence et exécutent des charges de travail. Il exécute les agents dans des bacs à sable isolés au niveau du noyau, avec des politiques déclaratives YAML qui encadrent l’accès au système de fichiers, au réseau, aux processus et aux identifiants du fournisseur. Les identifiants ne sont insérés que dans les requêtes destinées à des points de terminaison approuvés, et une vérification formelle détermine si une modification de politique proposée accorderait de nouveaux accès risqués avant son approbation.

L’environnement d’exécution est distribué sous licence Apache 2.0. NVIDIA indique que des centaines d’organisations l’ont utilisé, que des dizaines de milliers de contributions ont été reçues en moins d’un an et que la gouvernance du Sandbox fera intervenir les organisations qui l’intègrent à leurs produits. La transition est toujours en cours : un avis du projet précise que le développement est transféré à l’organisation ai-openshell, tandis que le code, les problèmes signalés et les demandes de fusion restent sur NVIDIA/OpenShell pendant le transfert.

Agent Substrate vise à réduire le coût des ressources inactives

Agent Substrate s’attaque au coût du maintien des sessions d’agents. Les agents attendent souvent des invites, des résultats d’outils ou des réponses de modèles ; un Pod Kubernetes maintenu à chaud conserve des ressources pendant ces périodes d’attente, tandis que la recréation du Pod entraîne une perte d’état et un nouveau démarrage à froid. NVIDIA et Google collaborent également à une intégration d’OpenShell destinée aux agents déployés dans des environnements multinuages et sur site.

La conception d’Agent Substrate répartit de nombreuses sessions avec état sur un pool plus restreint de workers maintenus à chaud. Elle crée des points de contrôle pour les sessions inactives, y compris pour leur mémoire et l’état de leur système de fichiers, libère les workers concernés et restaure les sessions sur des workers disponibles sans reprendre le processus habituel de création d’un Pod Kubernetes. Les workers restent des Pods Kubernetes ordinaires : la planification des clusters, les quotas et les politiques de placement continuent donc de s’appliquer. Les charges de travail visées comprennent les assistants de programmation, les environnements d’apprentissage par renforcement et les bacs à sable de recherche sur GPU de courte durée.

NVIDIA développe l’interopérabilité avec Dynamo pour l’inférence et KAI Scheduler pour le partage des ressources du cluster. Dynamo peut fournir des estimations du délai avant le premier jeton et du taux de saturation du pool de GPU, afin qu’Agent Substrate puisse décider de maintenir un agent actif, de le suspendre ou de le reprendre. Ses API évoluent encore, la prise en charge des GPU est en cours de refonte autour de l’allocation dynamique des ressources de Kubernetes, et certaines parties de l’intégration de Dynamo sont expérimentales.

DSX ajoute la gestion des clusters et accélère les restaurations

NVIDIA Kubernetes Engine et NVIDIA Kubernetes Recipes (NVKE et NVKR) sont disponibles en préversion publique sous licence Apache 2.0. NVIDIA précise que leurs API, leur configuration et leur comportement peuvent changer et ne les recommande pas encore pour les charges de travail en production. NVKR crée des images reproductibles de nœuds et de conteneurs, ainsi que des fichiers binaires et des graphiques Helm, à partir de sources dont les versions sont figées, et consigne les éléments utilisés. NVKE s’appuie sur ces artefacts pour provisionner et exploiter des clusters au moyen d’une API REST et de contrôleurs, mais les deux projets peuvent être adoptés indépendamment.

NVKE crée des clusters de charges de travail clients dotés de plans de contrôle Kubernetes, d’instances etcd et de pools de nœuds distincts. Il obtient de la capacité sur des serveurs physiques par l’intermédiaire de NVIDIA Infra Controller et de son fournisseur Cluster API, CAPNICo ; avant de recevoir ses identifiants de jonction, un nœud doit présenter une identité SPIFFE attestée. Firmus et SK Telecom intègrent les projets à leurs usines d’IA, tandis que Mirantis, Netris, OpenNebula Systems, Rafay, Spectro Cloud et vCluster prévoient des intégrations liées à leurs plateformes d’infrastructure, à leurs offres Kubernetes gérées ou à l’automatisation réseau.

NVIDIA Snapshot réduit les démarrages à froid de l’inférence en créant un point de contrôle de la mémoire CPU et GPU d’une charge de travail entièrement initialisée. La restauration exige le même modèle de GPU et le même pilote ; elle évite de charger à nouveau les poids, de relancer la compilation et de capturer les graphes CUDA.

Sur des GPU B200 avec un stockage VAST NFS, NVIDIA fait état de restaurations de 3,6 à 42,7 secondes pour des configurations vLLM, SGLang et TensorRT LLM, soit des accélérations de 8× à 36× par rapport aux démarrages à froid. Les tests portaient sur des modèles allant de 600 millions de paramètres à des configurations de huit GPU, avec des points de contrôle approchant 1 To. La création d’un point de contrôle prenait de 15 secondes à 5,5 minutes, et le temps cumulé de création du point de contrôle et de restauration était inférieur à celui d’un démarrage à froid dans chacune des configurations testées.

Ces chiffres ne mesurent pas le démarrage complet d’une machine : le provisionnement de l’infrastructure et le chargement des images de conteneurs ne font pas partie du temps de restauration mesuré. Le cache clé-valeur est également libéré avant chaque création de point de contrôle plutôt que conservé dans l’artefact ; les résultats portent donc sur la restauration d’une charge de travail initialisée sur une infrastructure compatible.

Lors de son propre test de GLM-5.3 sur NVIDIA HGX B300, Crusoe a utilisé un point de contrôle contenant 594 Go d’état GPU. Crusoe a mesuré la restauration de l’état GPU à 15,0 secondes depuis un stockage NVMe local, contre 33,3 secondes depuis NFS. Avec l’artefact stocké sur NVMe, la création du pod et sa mise en état de fonctionnement ont pris 31 secondes, contre environ huit minutes pour un démarrage à froid, ce qui montre que le stockage est un facteur majeur des performances de restauration. Crusoe a également contribué en amont à des améliorations des performances et des outils de diagnostic.

Ensemble, ces projets intègrent davantage d’éléments du plan de contrôle et du processus de reprise de l’usine d’IA dans des dépôts ouverts, mais à différents stades de maturité : le transfert de gouvernance d’OpenShell n’est pas achevé, Agent Substrate évolue, et NVKE et NVKR restent en version préliminaire. Les tests de performance de Snapshot fournissent la preuve la plus claire d’un gain opérationnel mesuré, tandis que ses exigences de compatibilité et les résultats de Crusoe sur le stockage montrent qu’une reprise plus rapide dépend à la fois de l’état réutilisable des charges de travail et de l’infrastructure qui les entoure.