NVIDIA pousse OpenShell et ses outils open source pour encadrer les agents IA

NVIDIA a annoncé le 10 novembre 2026, à KubeCon + CloudNativeCon, le don d’OpenShell au Cloud Native Computing Foundation, tout en publiant trois composants open source pour sa DSX AI Factory Platform. L’enjeu dépasse le simple geste communautaire: il s’agit de rendre plus sûrs des agents IA qui manipulent des outils, consomment du calcul et doivent parfois redémarrer sans tout perdre. Dans ce contexte, l’entreprise relie gouvernance, orchestration Kubernetes et reprise après incident dans un même paquet technique.

Des agents mieux encadrés, enfin sans magie noire

OpenShell, runtime de sécurité pour agents IA, applique des contrôles déterministes quand des agents autonomes accèdent à des outils, à des services d’inférence ou exécutent des charges de travail. Le moteur fonctionne dans des bacs à sable isolés au niveau du noyau, avec des politiques déclaratives en YAML qui couvrent l’accès au système de fichiers, au réseau, aux processus et aux identifiants fournisseurs. Les identifiants ne sont injectés que dans les requêtes destinées à des points de terminaison approuvés. NVIDIA ajoute aussi une vérification formelle pour tester si une modification de politique ouvrirait un accès risqué avant validation. L’idée est simple, même si l’outillage ne l’est pas: éviter qu’un agent trop curieux ne fasse ce qu’il ne devrait pas faire.

Le projet est distribué sous licence Apache 2.0. NVIDIA dit que des centaines d’organisations l’ont déjà utilisé et que des dizaines de milliers de contributions sont arrivées en moins d’un an. Le transfert vers le CNCF reste toutefois en cours: un avis de projet indique que le développement migre vers l’organisation ai-openshell, tandis que le code, les tickets et les pull requests demeurent chez NVIDIA/OpenShell pendant la transition.

Agent Substrate veut éviter le coût des agents qui attendent

Agent Substrate s’attaque à un problème très concret: les agents restent souvent inactifs en attendant une instruction, une réponse d’outil ou un résultat de modèle, mais conservent malgré tout de la mémoire et du CPU. Selon NVIDIA, donner à chaque agent son propre Pod Kubernetes bloque des ressources et fait gonfler le nombre d’objets persistants à suivre. Le projet vise donc à découpler les sessions d’agents avec état et leur identité du calcul actif, puis à remettre ces sessions en mémoire quand c’est nécessaire, avec un temps de restauration annoncé sous les 500 millisecondes.

Le mécanisme repose sur un petit nombre de workers “chauds” qui hébergent plusieurs sessions. Lorsqu’un agent devient inactif, son état — mémoire et système de fichiers compris — est checkpointé, le worker est libéré, puis l’agent est restauré sur une ressource disponible sans repasser par la création classique d’un Pod. Les workers restent des Pods Kubernetes ordinaires, ce qui conserve les règles habituelles de planification, de quotas et de placement. Les cas d’usage visés incluent les assistants de code, les environnements de reinforcement learning et les sandboxes GPU de courte durée.

Open source, mais pas encore figé

NVIDIA prévoit aussi une interopérabilité avec Dynamo pour l’inférence et KAI Scheduler pour le partage des ressources cluster, deux briques liées à sa DSX AI Factory Platform. Dynamo peut fournir une estimation du temps avant le premier token et de la saturation des pools GPU, afin qu’Agent Substrate décide de garder un agent en mémoire, de le suspendre ou de le relancer. Les API évoluent encore, la prise en charge GPU est en cours de reconstruction autour de Kubernetes Dynamic Resource Allocation, et une partie de l’intégration reste expérimentale.

Autrement dit, l’architecture existe déjà, mais elle n’a pas encore la stabilité d’un produit bien assis. Open source ne veut pas dire prêt à brancher partout le lendemain matin, même si la tentation est forte.

Snapshot promet de réduire le temps de reprise à quelques secondes

NVIDIA Snapshot, lui, cible un autre point de friction: le démarrage à froid des inférences. L’outil checkpointe un workload entièrement initialisé, y compris la mémoire CPU et GPU, puis le restaure sans refaire le chargement des poids, la compilation ni la capture des CUDA graphs. La restauration exige le même modèle de GPU et le même driver, ce qui limite le périmètre mais accélère fortement la reprise.

Sur des GPU B200 avec stockage VAST NFS, NVIDIA rapporte des restaurations de 3,6 à 42,7 secondes selon les configurations vLLM, SGLang et TensorRT LLM, soit des gains de 8x à 36x face au cold start. Les essais couvraient un modèle de 600 millions de paramètres jusqu’à des configurations à huit GPU avec des checkpoints approchant 1 To. La création d’un checkpoint prenait entre 15 secondes et 5,5 minutes, et le temps combiné checkpoint + restore restait inférieur à un démarrage à froid dans tous les cas testés.

Ces mesures ne couvrent pas tout le démarrage d’une machine: le provisioning de l’infrastructure et le chargement des images conteneur restent hors du chemin de restauration chronométré. Autre détail important, le cache clé-valeur est libéré avant chaque checkpoint plutôt que conservé dans l’artefact, ce qui signifie que les résultats concernent la reprise d’un workload déjà initialisé sur une infrastructure compatible.

Les gains dépendent aussi du stockage, pas seulement du GPU

Crusoe a aussi testé son propre cas d’usage GLM-5.3 sur NVIDIA HGX B300 avec un checkpoint de 594 Go d’état GPU. L’entreprise a mesuré une restauration de l’état GPU en 15,0 secondes depuis un NVMe local, contre 33,3 secondes depuis NFS. Avec l’artefact sur NVMe, la création du Pod jusqu’à l’état prêt prenait 31 secondes, contre environ huit minutes pour un cold start. Cette comparaison montre que le stockage pèse lourd dans la performance finale. Crusoe a également contribué des changements de performance et de diagnostic en amont.

Pris ensemble, ces projets déplacent davantage de contrôle d’exécution, de sécurité et de reprise vers des dépôts ouverts. Mais ils n’avancent pas tous au même rythme: OpenShell est en transition, Agent Substrate continue d’évoluer, tandis que NVKE et NVKR restent en public preview. La promesse est claire; le maintien à terme dépendra surtout de l’outillage autour, des API et du matériel compatible.