NVIDIA veröffentlicht Open-Source-Controller zur GPU-Cluster-Validierung
Die NVIDIA Cluster Readiness Engine führt echte verteilte Workloads aus, misst Goodput und Bandbreite und meldet fehlerhafte Knoten – bevor Produktions-Workloads starten.
Mit KI erstellt◆ Fakten auf einen Blick
- NVCRE ist ein Open-Source-Kubernetes-Controller.
- NVCRE führt echte verteilte Workloads (Training und Kommunikation) über topologiebewusste Knotengruppen aus, misst die Ergebnisse und meldet, welche Knoten bei welchem Test fehlgeschlagen sind.
- NVCRE zertifiziert GPU-Cluster, bevor Produktions-Workloads darauf laufen, und erkennt Hardwarefehler, die nur unter realer verteilter Last auftreten.
- NVCRE überlässt die Quarantäne der Plattform: Es cordoned, taintet oder modifiziert Knoten nicht selbst.
- NVCRE richtet sich an Plattform- und Infrastrukturteams, die GPU-Cluster aufbauen, validieren oder weiterverkaufen.
- Der v0.1.0-Katalog enthält NCCL-All-Reduce-, All-Gather- und All-to-All-Tests über Knoten hinweg, Single-Node-NCCL-Loopback- und NVSwitch-Loopback-Tests, DCGM-Level-4-Diagnosen sowie Nemotron-5-8B- und 56B-Trainingsläufe.
NVIDIA veröffentlicht Open-Source-Controller zur GPU-Cluster-Validierung
NVIDIA hat mit der NVIDIA Cluster Readiness Engine (NVCRE) einen Open-Source-Kubernetes-Controller vorgestellt, der GPU-Cluster vor dem Start von KI-Workloads validiert. Der Controller führt echte verteilte Workloads – darunter Trainingsläufe und Kommunikationstests – über topologiebewusste Knotengruppen aus, misst die Ergebnisse und meldet, welche Knoten bei welchem Test fehlgeschlagen sind. Die topologiebewusste Gruppierung basiert auf der erkannten GPU-Architektur und Plattform: Knoten, die über schnelle Verbindungen wie NVLink oder denselben Netzwerk-Switch verbunden sind, werden zu Gruppen zusammengefasst, um realistische Kommunikationsmuster zu testen. Das ist notwendig, weil ein Cluster alle Health-Checks bestehen kann und dennoch unter realer Last versagt: Eine einzelne langsame GPU, ein unter Last degradierender Netzwerk-Link oder eine Konfiguration, die Daten über einen langsameren Pfad leitet, werden erst sichtbar, wenn tatsächlich verteilte Workloads laufen.
NVCRE zertifiziert GPU-Cluster auf Basis dieser Messungen: Der Goodput wird aus Trainingslogs anhand konfigurierbarer LogProfile-Muster geparst. Diese Muster definieren, welche Logzeilen als erfolgreiche Trainingsschritte gelten; aus deren Zeitstempeln und Häufigkeit wird der tatsächlich nutzbare Durchsatz berechnet. Die Per-Bus-Bandbreite wird aus NCCL-Logs extrahiert und zeigt die Datenrate einzelner Busse. Das Node-Health-Monitoring wertet während der Läufe CEL-Ausdrücke aus, die bei klaren Signalen wie GPU-Taints oder Node-Conditions anschlagen. Ein Knoten gilt als fehlgeschlagen, wenn ein Test nicht bestanden wird oder eine CEL-Expression einen Fehlerzustand signalisiert. Damit erkennt NVCRE Hardwarefehler, die nur unter realer verteilter Last auftreten, und zertifiziert GPU-Cluster, bevor Produktions-Workloads darauf laufen. Die Quarantäne fehlerhafter Knoten überlässt NVCRE der Plattform: Der Controller cordoned, taintet oder modifiziert Knoten nicht selbst. Das Werkzeug richtet sich an Plattform- und Infrastrukturteams, die GPU-Cluster aufbauen, validieren oder weiterverkaufen.
Funktionsumfang, Installation und Einschränkungen
Der in Version 0.1.0 veröffentlichte Katalog umfasst NCCL-All-Reduce-, All-Gather- und All-to-All-Tests über Knoten hinweg, Single-Node-NCCL- und NVSwitch-Loopback-Tests, DCGM-Level-4-Diagnosen sowie Trainingsläufe mit Nemotron-5-8B und 56B. NVCRE erkennt die GPU-Architektur, indem es das Label `nvidia.com/gpu.product` vom Kubernetes-Node-Objekt ausliest; die Plattform wird aus dem Feld `providerID` desselben Node-Objekts abgeleitet (z. B. `aws:///...` oder `gce:///...`). Anhand dieser Kombination wählt NVCRE aus dem Katalog vordefinierte Overrides aus, die die Kommunikationskonfiguration der Tests anpassen – etwa durch Setzen von Umgebungsvariablen für NCCL oder Auswahl des richtigen Netzwerk-Transports: EFA auf AWS, TCPXO oder RoCE auf GCP, InfiniBand auf Azure.
Die Goodput-Messung wertet Trainingslogs anhand konfigurierbarer LogProfile-Muster aus. Diese Muster sind Teil der Katalogkonfiguration und können angepasst werden; sie identifizieren die relevanten Logzeilen, aus denen der Goodput berechnet wird. Die Per-Bus-Bandbreitenmessung wird aus NCCL-Logs geparst und zeigt die Datenrate einzelner Busse. Das Node-Health-Monitoring nutzt CEL-Ausdrücke, die während der Workloads ausgewertet werden und bei klaren Signalen wie GPU-Taints oder Node-Conditions anschlagen. Per-Node-Fehlerberichte nennen für jeden fehlgeschlagenen Knoten einen Grund. Die adaptive Fehlerisolierung gruppiert Knoten topologiebewusst – basierend auf der erkannten GPU-Architektur und Plattform, etwa NVLink-Verbindungen oder Netzwerkpfaden – und isoliert fehlerhafte Knoten anhand der Testergebnisse und Node-Health-Metriken: Knoten, die einen Test nicht bestehen oder bei denen eine CEL-Expression einen Fehler signalisiert, werden von weiteren Läufen ausgeschlossen, sodass die verbleibenden Knoten weiter getestet werden können. Checkpoint-Restart setzt Trainingsjobs nach Unterbrechungen fort. Die Ressource WorkloadRun bündelt einen Trainings-, NCCL- oder Custom-Workload in einem Objekt. Das CLI `nvcrectl` unterstützt setup, render, run, report und cleanup.
Die Installation erfolgt über `nvcrectl setup init` mit den Phasen deps (Kubeflow Trainer) und helm (NVCRE Helm-Chart). Image und Chart sind öffentlich auf GHCR verfügbar, jedes Release-Artefakt ist signiert. Voraussetzungen sind ein Kubernetes-Cluster mit NVIDIA-GPU-Knoten, einheitliches Label `nvidia.com/gpu.product` (bereitgestellt durch den NVIDIA GPU Operator), Prometheus-Operator-CRDs sowie für GB200/GB300-Cluster der NVIDIA DRA-Treiber. NVCRE läuft nicht auf Nicht-NVIDIA-GPUs, da es auf NVIDIA-spezifische Signale wie DCGM-Diagnosen und NVLink-Topologie angewiesen ist.

