NVIDIA beschreibt seinen AI Factory Operations Agent auf DGX SuperPOD: sechs Fachagenten auf NemoClaw und OpenShell, mit Nur-Lese-Zugangsdaten für Kubernetes-Prüfungen; keine Genauigkeitszahl, Container-Images nur mit NGC-Einladung

Am 4. November 2026 veröffentlichte NVIDIA im Entwicklerblog „How NVIDIA Uses AI Agents to Streamline AI Factory Operations“, verfasst von Kavya G Y und Rohan Adwankar. Der Beitrag stellt den AI Factory Operations Agent vor, den NVIDIA nach eigenen Angaben gebaut hat, um den Betrieb der eigenen internen DGX-SuperPOD-Cluster zu vereinfachen und die manuelle Arbeit seiner Site-Reliability-Ingenieure (SRE) zu verringern. Statt Dashboards für Rechenleistung, Netzwerk, Hardware und Scheduler einzeln zu prüfen, stellt ein SRE Fragen in einer Chat-Oberfläche, und spezialisierte Teilagenten sammeln und korrelieren die Belege. Die Teilagenten verständigen sich über das Model Context Protocol (MCP). Auf der Seite steht außerdem eine automatische Zusammenfassung eines NVIDIA-Nemotron-Modells; wir haben sie nicht verwendet, sondern uns auf den Text des Beitrags und das GitHub-Repository gestützt.

Die Architektur beruht auf NVIDIAs NemoClaw-Blueprint. Eine nutzerseitige Agenten-Laufzeit nimmt die Frage des SRE entgegen und leitet sie an einen Fachagenten weiter. Die Agenten erreichen die Infrastruktur über OpenClaw-Plugins und MCP-Server, wobei jeder MCP-Server nur wenige freigegebene Betriebswerkzeuge bereitstellt. Das Framework baut auf NVIDIA OpenShell auf und kann laut Beitrag vollständig lokal betrieben werden, mit lokal bereitgestellten offenen NVIDIA-Nemotron-Modellen für die Inferenz. NVIDIA sagt, das Framework laufe auf seinen internen Produktionsclustern mit DGX H100, DGX B200 und DGX GB300. Das beschreibt NVIDIAs eigenen Einsatz und keine für andere Nutzer genannte Hardwareanforderung.

Der Einsatz erfolgt als Kubernetes-Control-Plane-Anwendung. Helm installiert die Weboberfläche, das OpenClaw-Gateway, die MCP-Werkzeugserver, den Inferenz-Endpunkt und die OpenShell-Laufzeit als Dienste. Für Shell-Befehle legt OpenShell pro Sitzung eine eigene Kubernetes-Sandbox an, statt die Befehle im Haupt-Gateway-Pod auszuführen. Die Kubernetes-Inspektion läuft über ein serverseitiges Werkzeug run_kubectl mit einer fest gewählten kubectl-Binärdatei und registrierten Nur-Lese-Zugangsdaten, und OpenShell erhält weder kubectl noch Kubernetes-Zugangsdaten. Der Beitrag zeigt das Ergebnis von kubectl-auth-can-i-Prüfungen aus Sicht des Agenten: Er kann Pods und ConfigMaps lesen, aber keine Secrets lesen und keine Pods anlegen oder ändern. Das ist ein anschauliches Bild der Berechtigungsgrenze, entnommen aus einer bestimmten Konfiguration.

Sechs Fachagenten werden genannt. Der Job-Recovery-Agent erkennt Trainingsausfälle und sinkenden Goodput und führt eine Ursachenanalyse über Scheduler, Anwendung, Hardware und Netzwerk durch. Der Hardware-Agent ordnet PCIe-, ECC-, GPU-, NVMe- und Temperaturfehler bis zur Komponente ein. Der Observability-Agent fragt Prometheus, Telemetrie und Grafana-Loki-Logs ab und baut Dashboards nach Bedarf. Der Research-Agent durchsucht vorgeladene Dokumentation wie NVIDIA-Mission-Control-Handbücher und DGX-SuperPOD-Referenzarchitekturen, und Teams können eigene Runbooks ergänzen. Der Kubernetes-Agent bietet Nur-Lese-Überblick über Pods, Dienste, Deployments, GPU-Ressourcen und Knotenzustand. Der Cluster-Management-Agent arbeitet über Diagnosewerkzeuge mit den APIs von NVIDIA Base Command Manager und berät nur. Übergreifende MCP-Werkzeuge sind Websuche, Codeausführung und Grafana-Dashboards, und Teams können eigene MCP-Server anbinden.

NVIDIA nennt fünf Lehren aus dem Produktionseinsatz: klare Agentengrenzen, zuerst nur lesen, damit genaue Untersuchungen Vertrauen schaffen, bevor automatisiert wird, Korrelation über Schichten hinweg, um Ursachen zu finden, die isolierte Werkzeuge übersehen, präzise MCP-Werkzeugdefinitionen für besseres Routing sowie sichtbare Werkzeugaufrufe, Belege und Schlussfolgerungen, damit SREs vor dem Handeln prüfen können. Der Beitrag sagt, NVIDIA verfeinere das Framework, indem es die Genauigkeit der Ursachenanalyse messe und die Zustimmung der SREs verfolge. Er veröffentlicht jedoch keine Genauigkeitszahl, keine Zustimmungsrate, keine Vorfallzahlen und keine gesparte Zeit. Das Demovideo wird als in einen DGX-Cluster eingespielter Vorfall für eine interne Vorführung beschrieben.

Die Verfügbarkeit muss man genau lesen, weil die beiden Quellen Verschiedenes betonen. Der Beitrag nennt das Orchestrierungs-Framework experimentelle Open-Source-Software, deren APIs, Konfiguration und Bereitstellungsanforderungen sich zwischen Veröffentlichungen ändern können, und verweist auf das GitHub-Repository. Das Repository unter der Apache-2.0-Lizenz spricht ebenfalls von einer experimentellen Veröffentlichung und ergänzt, dass in der Early-Access-Phase das veröffentlichte Helm-Chart und die Container-Images eine Einladung zu einer privaten NGC-Registry erfordern und eine Anmeldung bei nvcr.io allein keinen Pull-Zugriff gibt. Es nennt Kubernetes, kubectl und Helm 3 als Voraussetzungen, einen OpenAI-kompatiblen Endpunkt oder ein vom Chart verwaltetes vLLM für das Modell und eine GPU nur, wenn man dieses vLLM bereitstellt. Getrennt davon sagt der Beitrag, NVIDIA-Kunden könnten über ihren Account Manager Zugang zu den von NVIDIA entwickelten Cluster-Betriebsagenten anfragen. Das README nennt außerdem Abläufe, die der Beitrag nicht erwähnt, etwa die Analyse von Slurm-Jobs und VictoriaMetrics-Abfragen, sowie vier Schnittstellen: Browser-Oberfläche, HTTP-API, Kommandozeilen-Client und eine MCP-Brücke für Coding-Agenten.

Für mandantenfähige Cluster beschreibt der Beitrag begrenzte Agenten, Werkzeuge, Sandboxes und Kubernetes-Berechtigungen, sodass SREs eines Mandanten nur ihre eigenen Namespaces, Jobs und Knoten sehen, während der zentrale Betrieb eine breitere Sicht behält und OpenShell Beschränkungen auf Kernel-Ebene durchsetzt. Empfohlen wird eine eigene GPU-beschleunigte Control Plane, die vom Produktionscluster getrennt ist, damit das Denken der Agenten keine Trainings-GPUs belegt; für kleinere Installationen werden eine RTX PRO Workstation oder ein DGX Spark erwähnt.

Unsere Einschätzung: Dies ist ein Architektur- und Erfahrungsbeitrag eines Anbieters über sein internes Werkzeug. Die Entwurfsentscheidungen sind konkret und wiederverwendbar, nämlich Nur-Lese-Zugangsdaten, Sandboxes pro Sitzung und enge MCP-Werkzeuge, doch es gibt kein gemessenes Ergebnis, das man gegen den Aufwand abwägen könnte. Teams, die es erwägen, sollten den Zugang zu den Container-Images als Hürde einplanen und es zuerst auf einem Nicht-Produktionscluster testen.