NVIDIA décrit son agent d’exploitation d’usine d’IA sur DGX SuperPOD : six agents de domaine sur NemoClaw et OpenShell, avec identifiants en lecture seule pour les vérifications Kubernetes ; aucune précision publiée, images soumises à une invitation NGC

Le 4 novembre 2026, NVIDIA a publié sur son blog pour développeurs « How NVIDIA Uses AI Agents to Streamline AI Factory Operations », signé Kavya G Y et Rohan Adwankar. Le texte présente l’AI Factory Operations Agent, que NVIDIA dit avoir conçu pour simplifier l’exploitation de ses propres grappes DGX SuperPOD internes et réduire le travail manuel de ses ingénieurs de fiabilité de site (SRE). Au lieu de consulter un à un les tableaux de bord du calcul, du réseau, du matériel et de l’ordonnanceur, un SRE pose ses questions dans une interface de discussion, et des sous-agents spécialisés rassemblent et recoupent les preuves. Les sous-agents communiquent par le Model Context Protocol (MCP). La page contient aussi un résumé automatique généré par un modèle NVIDIA Nemotron ; nous ne l’avons pas utilisé et nous nous sommes appuyés sur le texte du billet et sur le dépôt GitHub.

L’architecture s’articule autour du plan NemoClaw de NVIDIA. Un environnement d’exécution d’agent tourné vers l’utilisateur reçoit la question du SRE et la route vers un agent de domaine. Les agents atteignent l’infrastructure par des extensions OpenClaw et des serveurs MCP, chaque serveur MCP exposant un petit ensemble d’outils d’exploitation approuvés. Le cadre repose sur NVIDIA OpenShell et, selon le billet, peut fonctionner entièrement sur site, l’inférence étant assurée localement par les modèles ouverts NVIDIA Nemotron. NVIDIA dit que le cadre tourne sur ses grappes de production internes DGX H100, DGX B200 et DGX GB300. C’est la description de son propre déploiement, pas une exigence matérielle énoncée pour les autres utilisateurs.

Le déploiement est une application de plan de contrôle Kubernetes. Helm installe l’interface web, la passerelle OpenClaw, les serveurs d’outils MCP, le point d’inférence et l’environnement OpenShell comme services. Pour l’exécution de commandes shell, OpenShell crée un bac à sable Kubernetes distinct par session plutôt que de lancer les commandes dans le pod principal de la passerelle. L’inspection de Kubernetes passe par un outil run_kubectl côté serveur qui utilise un binaire kubectl figé et des identifiants en lecture seule enregistrés, et OpenShell ne reçoit ni kubectl ni identifiants Kubernetes. Le billet montre le résultat de vérifications kubectl auth can-i du point de vue de l’agent : il peut lire les pods et les configmaps, mais pas les secrets, ni créer ou modifier des pods. C’est une bonne image de la frontière des permissions, tirée d’une configuration précise.

Six agents de domaine sont listés. L’agent de reprise des tâches détecte les échecs d’entraînement et la baisse du débit utile et fait une analyse de cause racine à travers l’ordonnanceur, l’application, le matériel et le réseau. L’agent matériel trie les pannes PCIe, ECC, GPU, NVMe et thermiques jusqu’au composant. L’agent d’observabilité interroge Prometheus, la télémétrie et les journaux Grafana Loki et construit des tableaux de bord à la demande. L’agent de recherche explore une documentation préchargée, comme les manuels de NVIDIA Mission Control et les architectures de référence DGX SuperPOD, et les équipes peuvent ajouter leurs propres procédures. L’agent Kubernetes offre une vision en lecture seule des pods, services, déploiements, ressources GPU et états de nœuds. L’agent de gestion de grappe travaille avec les API de NVIDIA Base Command Manager via des outils de diagnostic, à titre consultatif. Les outils MCP transversaux comprennent la recherche web, l’exécution de code et les tableaux de bord Grafana, et les équipes peuvent brancher leurs propres serveurs MCP.

NVIDIA tire cinq leçons de l’usage en production : garder des frontières d’agents nettes, commencer en lecture seule pour que l’investigation exacte construise la confiance avant toute automatisation, corréler les couches pour trouver des causes que des outils isolés manquent, définir précisément les outils MCP pour améliorer le routage, et montrer appels d’outils, preuves et conclusions pour que les SRE vérifient avant d’agir. Le billet dit que NVIDIA affine le cadre en mesurant la précision de l’analyse de cause racine et en suivant l’accord des SRE. Il ne publie aucun chiffre de précision, aucun taux d’accord, aucun nombre d’incidents ni aucun temps gagné. La vidéo de démonstration est décrite comme un incident injecté dans une grappe DGX pour une démonstration interne.

La disponibilité demande une lecture attentive, car les deux sources insistent sur des points différents. Le billet qualifie le cadre d’orchestration de logiciel libre expérimental, dont les API, la configuration et les exigences de déploiement peuvent changer d’une version à l’autre, et renvoie au dépôt GitHub. Le dépôt, sous licence Apache 2.0, parle aussi d’une version expérimentale et ajoute qu’au stade d’accès anticipé, le chart Helm et les images de conteneurs publiés exigent une invitation à un registre NGC privé, et qu’une simple connexion à nvcr.io ne donne pas le droit de les récupérer. Il demande Kubernetes, kubectl et Helm 3, un point d’accès compatible OpenAI ou un vLLM géré par le chart pour le modèle, et un GPU seulement si l’on déploie ce vLLM. Par ailleurs, le billet dit que les clients de NVIDIA peuvent demander à leur gestionnaire de compte l’accès aux agents d’exploitation de grappes développés par NVIDIA. Le README liste aussi des flux que le billet ne nomme pas, comme l’analyse de tâches Slurm et les requêtes VictoriaMetrics, ainsi que quatre interfaces : interface web, API HTTP, client en ligne de commande et passerelle MCP pour les agents de code.

Pour les grappes multilocataires, le billet décrit des agents, outils, bacs à sable et permissions Kubernetes limités en portée, de sorte que les SRE d’un locataire ne voient que leurs espaces de noms, tâches et nœuds, tandis que l’exploitation centrale garde une vue plus large, OpenShell appliquant des restrictions au niveau du noyau. Il recommande un plan de contrôle dédié, accéléré par GPU et isolé de la grappe de production, pour que le raisonnement des agents n’utilise pas les GPU d’entraînement, et mentionne une station RTX PRO ou un DGX Spark pour les petits déploiements.

Notre lecture : c’est un billet d’architecture et de retours d’expérience d’un fournisseur décrivant son outil interne. Les choix de conception sont concrets et réutilisables, à savoir identifiants en lecture seule, bacs à sable par session et outils MCP étroits, mais aucun résultat mesuré ne permet de les peser. Les équipes qui l’envisagent devraient traiter l’accès aux images de conteneurs comme une étape bloquante et l’essayer d’abord sur une grappe hors production.