Live KI erstellt Tumor-Digital-Twins in unter zehn Minuten

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.

· Veröffentlicht: 24.09.2026 ·3 Min Lesezeit
NVIDIA veröffentlicht Open-Source-Controller zur GPU-Cluster-ValidierungMit 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.

A
Andreas Rüdiger
Herausgeber & Redaktionsleitung · KI-Modelle, Technik & Business

Andreas Rüdiger ist Gründer der Agentur INREMA und verantwortet KI Spotlight redaktionell. Sein Schwerpunkt liegt auf KI-Modellen, Recheninfrastruktur, technischen Entwicklungen und der wirtschaftlichen Einordnung. Er sorgt dafür, dass komplexe KI-Themen verständlich und nachvollziehbar aufbereitet werden. Mehr zu ihm auf inrema.de und andiger.de.

Ähnliche Artikel