L’AI Factory Operations Agent, un blueprint développé par NVIDIA, permet de déployer des agents spécialisés pour examiner les problèmes des clusters et optimiser les opérations des « usines d’IA » (AI factory). Cette annonce, publiée sur github.com, vise à remplacer l’examen manuel de multiples tableaux de bord par une corrélation automatique des preuves à travers les systèmes du cluster.

L’agent est conçu pour générer des résumés clairs des causes profondes et proposer des étapes suivantes, le tout dans un flux de travail auditable. Les capacités supportées incluent l’inspection des charges de travail Kubernetes en lecture seule, les requêtes sur Prometheus ou VictoriaMetrics, la création de tableaux de bord Grafana, et l’analyse des journaux Slurm pour identifier les problèmes.

Le besoin de centraliser le diagnostic est pressant. NVIDIA explique que les ingénieurs de fiabilité de site (SRE) doivent souvent examiner séparément les couches logicielles, matérielles et d’ordonnancement pour comprendre une chute de performance lors d’entraînements massifs. L’agent propose d’unifier cette investigation via une seule interface.

Gouvernance et sécurité de l’exécution

La sécurité est un point majeur de cette architecture. NVIDIA insiste sur le fait que les agents ne reçoivent pas les identifiants d’accès au cluster de manière globale. Pour l’inspection Kubernetes, l’outil utilise des binaires kubectl épinglés avec des identifiants en lecture seule. De plus, OpenShell isole l’exécution des commandes générales dans des environnements conteneurisés (sandboxed). Cette séparation est cruciale, car les clients navigateur ou MCP ne reçoivent pas les identifiants du cluster ; les Secrets Kubernetes restent montés uniquement dans les pods qui en ont besoin.

Le cadre repose sur une infrastructure Kubernetes compatible. Le runtime nécessite un endpoint compatible OpenAI ou un cluster capable de faire tourner vLLM. Les intégrations sont modulaires ; on peut ajouter de nouveaux agents pour différents domaines opérationnels — comme l’agent matériel pour les erreurs PCIe, ou l’agent de récupération de jobs — sans modifier le cœur du système.

Les multiples facettes de l’agent

Le cadre s’articule autour de plusieurs interfaces. Les opérateurs de cluster peuvent interagir via une interface web (Browser UI) pour des discussions interactives. Pour les scripts ou les services, il existe une API HTTP. Il y a aussi une interface mosaic CLI pour automatiser les tâches Shell ou Slurm. NVIDIA détaille ces rôles, précisant que l’interface utilisateur permet un suivi de chaque action, ce qui est essentiel pour bâtir la confiance des SRE.

Le système incorpore des agents spécifiques : un agent d’observabilité qui interroge des logs Prometheus et Grafana, un agent de recherche qui puise dans la documentation (comme les manuels Mission Control), et un agent de cluster management qui dialogue avec les APIs de Base Command Manager. Ces agents communiquent entre eux en utilisant le protocole MCP (Model Context Protocol).

L’implémentation de cette solution est marquée comme « Expérimentale » selon github.com. Pour ceux qui souhaitent l’intégrer, il est précisé que le déploiement des Helm charts et des images nécessite une invitation spécifique au registre privé NGC. Les guides d’installation sont détaillés dans le dépôt, et le projet est sous licence Apache 2.0.

Sources

• GitHub – NVIDIA/AI-Factory-Operations-Agent: Deploy AI agents to investigate cluster issues and streamline governed AI factory operations., github.com
• How NVIDIA Uses AI Agents to Streamline AI Factory Operations, NVIDIA, 4 novembre 2026
• Your AI Agent Needs an Operating Environment. Who’s Engineering It?, DevOps.com, 3 novembre 2026
• The 5 essential layers of AI agent sandboxing on Kubernetes, The New Stack, 29 octobre 2026

Crédits photo

• Image en une : Cable racks at grid computing, par U.S. Department of Energy, CC0, via Rawpixel via Openverse (recadrée)
• Image dans l’article : Automation T2, par AliciaNowaste, CC BY-SA 4.0, via Wikimedia Commons (recadrée)