NVIDIA setzt ein Team aus KI-Agenten für den Betrieb seiner DGX-SuperPOD-Cluster ein

Eine Chat-Oberfläche statt vieler Dashboards

Mit wachsenden GPU-Clustern erstreckt sich der Betrieb über Compute, Netzwerk, Hardware und Scheduling. NVIDIA zufolge müssen SREs oft mehrere Dashboards durchsehen, um herauszufinden, warum die Trainingsleistung gesunken ist. Der AI Factory Operations Agent ersetzt diese Routine durch spezialisierte Agenten für verschiedene Betriebsbereiche, die über eine einzige Chat-Oberfläche erreichbar sind.

Laut NVIDIA erkennen diese Agenten im Produktivbetrieb Ausfälle, korrelieren Ursachen über mehrere Ebenen hinweg und liefern klare Empfehlungen. SREs können mit jedem Agenten in natürlicher Sprache arbeiten, zwischen Untersuchungen wechseln und jede Aktion zur Nachvollziehbarkeit protokollieren. Die Sub-Agenten kommunizieren über das Model Context Protocol (MCP), das nach Angaben von NVIDIA jede Organisation einsetzen kann.

Architektur auf Basis von NemoClaw, OpenShell und Nemotron

Das Entwicklerbeispiel basiert auf dem NVIDIA-NemoClaw-Blueprint. Eine nutzerseitige Agent-Runtime nimmt SRE-Anfragen entgegen und ruft die passenden Domänen-Agenten und Tools auf. Die Agenten verbinden sich über OpenClaw-Plugins und MCP-Server mit der Infrastruktur, wobei jeder MCP-Server einen begrenzten Satz freigegebener Betriebs-Tools bereitstellt. Nutzer können über eine integrierte Web-Oberfläche arbeiten oder bestehende Coding-Agent-Oberflächen per API anbinden.

Das Framework nutzt NVIDIA OpenShell und kann vollständig on-premises laufen, was laut NVIDIA Erweiterbarkeit und Datensouveränität unterstützt. Für die Inferenz kommen lokal betriebene offene NVIDIA-Nemotron-Modelle zum Einsatz, und das Framework läuft auf internen NVIDIA-Produktivclustern mit DGX H100, DGX B200 und DGX GB300.

Das System läuft als Kubernetes-Control-Plane-Anwendung, wobei Helm die Web-Oberfläche, das OpenClaw-Gateway, die MCP-Tool-Server, den Inferenz-Endpunkt und die OpenShell-Runtime als Kubernetes-Dienste bereitstellt. Für die Shell-Ausführung erzeugt OpenShell pro Sitzung eine eigene Kubernetes-Sandbox, statt Befehle im Haupt-Gateway-Pod auszuführen. Die Kubernetes-Inspektion läuft über ein serverseitiges Tool namens run_kubectl mit registrierten Nur-Lese-Zugangsdaten, während OpenShell selbst weder kubectl noch Kubernetes-Zugangsdaten erhält. In NVIDIAs Beispiel kann der Agent Pods und Configmaps abrufen, aber keine Secrets lesen und keine Pods erstellen oder aktualisieren.

Die Domänen-Agenten

NVIDIA nennt für den internen Einsatz sechs Agenten:

• Job Recovery Agent: erkennt Ausfälle von Trainingsjobs und Goodput-Einbußen, führt eine mehrschichtige Ursachenanalyse über Scheduler-, Anwendungs-, Hardware- und Netzwerkebene durch und empfiehlt Wiederherstellungsschritte, sobald die Ursache bestätigt ist.
• Hardware Agent: klassifiziert Fehler auf Geräteebene, etwa PCIe-Fehler, ECC-Fehler, GPU-Probleme, NVMe-Ausfälle und thermische Anomalien.
• Observability Agent: fragt historische Prometheus-Daten, Telemetrie und Grafana-Loki-Logs ab und baut Dashboards dynamisch in der Web-Oberfläche auf.
• Research Agent: durchsucht vorab geladene Dokumentation, darunter NVIDIA-Mission-Control-Handbücher und DGX-SuperPOD-Referenzarchitekturen, und akzeptiert hochgeladene Runbooks.
• Kubernetes Agent: bietet einen Nur-Lese-Einblick in Pods, Dienste, Deployments, GPU-Ressourcen, Knotenstatus und Scheduling-Zustand.
• Cluster Management Agent: nutzt die APIs von NVIDIA Base Command Manager über diagnostische MCP-Tools für beratende Verwaltung und Fehlersuche.

Zu den übergreifenden MCP-Tools gehören Websuche, Code-Ausführung und Grafana-Dashboards. Organisationen können zudem eigene MCP-Server und APIs anbinden, um bestehende Scheduler, Observability-Plattformen und Cluster-Manager einzubinden.

Erfahrungen aus der Praxis und Empfehlungen für den Einsatz

NVIDIA verfeinert das Framework nach eigenen Angaben weiter, indem es die Genauigkeit der Ursachenanalyse misst, die Zustimmung der SREs verfolgt und das Agenten-Ökosystem erweitert. Das Unternehmen nennt fünf Lehren: Agentengrenzen klar halten, weil sich überlappende Zuständigkeiten Rauschen erzeugen; mit Nur-Lese-Zugriff beginnen, da eine präzise Untersuchung das Vertrauen der SREs vor einer Automatisierung aufbaut; über Ebenen hinweg korrelieren, um Ursachen zu finden, die isolierte Tools übersehen; MCP-Tools präzise definieren, um Fehlgriffe bei der Tool-Auswahl zu verringern; und Tool-Aufrufe, Belege und Schlussfolgerungen zeigen, bevor SREs handeln.

Für große Installationen bevorzugt NVIDIA eine dedizierte, GPU-beschleunigte Control Plane, die vom Produktivcluster getrennt ist, damit das Agenten-Reasoning keine Trainings-GPUs beansprucht und Workloads nicht stört. Kleinere Installationen können je nach Datensouveränität, Clustergröße und verfügbarer GPU-Kapazität einen lokalen oder Cloud-Inferenz-Endpunkt nutzen, auch eine RTX PRO Workstation oder einen DGX Spark.

In mandantenfähigen AI Factories begrenzen abgegrenzte Agenten, Tools, Sandboxes und Kubernetes-Berechtigungen, worauf jeder Mandant zugreifen kann. Die SREs der Mandanten sehen nur ihre eigenen Namespaces, Jobs und Knoten, während der zentrale Betrieb eine breitere Sicht auf den Cluster behält. NVIDIA verweist auf das Entwicklerbeispiel zum AI Factory Operations Agent und ein Open-Source-Framework auf GitHub.