NVIDIA beschreibt das Kubernetes-Rezept für Vera Rubin NVL72 Unterstützung

NVIDIA erklärte, dass sein KI Cluster Runtime Kubernetes-Cluster für Vera Rubin NVL72 Compute-Trays am Tag eins bereitmachen kann, indem es abgestimmte Einstellungen packt, Bereitstellungsbündel generiert und den laufenden Cluster validiert. Das Unternehmen stellte die Initiative als Teil seiner DSX KI Factory Platform dar und erklärte, dass die Arbeit die Hardware-, Treiber- und Scheduleränderungen behandelt, die erforderlich sind, wenn neue GPU-Systeme in einen cloud-nativen Stack eingeführt werden.

Welche Veränderungen haben sich für Vera Rubin NVL72

In dem Beitrag sagte NVIDIA, Vera Rubin NVL72 sei eine Weiterentwicklung derselben MGX-Rack-Scale-Architektur, die von GB200 NVL72 verwendet wird, jedoch mit mehreren benutzersichtbaren Änderungen, auf die Plattformteams einplanen müssen. Das Unternehmen erklärte, das neue System erfordere den R615.23 Driver Branch, wobei frühe Unterstützung für R610 und offizielle Plattformunterstützung in R620 vorgesehen ist. Es wurde außerdem erwähnt, dass Vera Rubin ConnectX-7 NICs und BlueField-3 DPUs durch ConnectX-9 SuperNICs und BlueField-4 DPUs ersetzt und dass DOCA 3.3.0 die erste GA-Version ist, die ConnectX-9 unterstützt.

NVIDIA erklärte, dass sich die Topologie auch in wichtigen Bereichen für I/O-intensive Workloads wie RDMA-Netzwerke und GPUDirect Storage ändert. Laut dem Beitrag stellt der Compute Tray von Vera Rubin NVL72 acht ConnectX-9 PCI-Gerätegruppen mit 32 Funktionen offen, im Vergleich zu vier ConnectX-7 Adaptern auf dem NVIDIA DGX GB200 NVL72 Compute Tray. Das Unternehmen erklärte außerdem, dass die Verbindung von GPU zu NIC NODE innerhalb eines Sockets und SYS über Sockets hinweg ist und dass PCI-Funktionszählungen keine physischen Portzahlen darstellen.

Der Beitrag sagte weiter, dass Rubin-GPUs neue MIG-Profile einführen, aber dass die dort beschriebenen Vera-Rubin-Rezepte die gesamte GPU-Zuweisung verwenden und MIG nicht konfigurieren. Es wurde hinzugefügt, dass Multi-Node-NVIDIA-NVLink-Workloads weiterhin IMEX verwenden und dass DRA v0.5.0 eine Alpha-Host-Managed-Option mit nur Domänenisolation enthält, während der im Beitrag beschriebene Cluster den driverManaged-Modus verwendet.

Validierung auf früher Hardware

NVIDIA gab an, den Vera Rubin NVL72 Stack end-to-end mit dem offiziellen GPU Operator v26.7.0 Release, dem offiziellen DRA-Treiber v0.5.0 Release und einem host-installierten R615 -Treiber validiert zu haben. Das Unternehmen erklärte, dass sowohl die Trainings- als auch die Inferenzrezeptvarianten erfolgreich für Bereitstellung und Konformität validiert wurden und dass das Trainingsrezept außerdem ein Performance-Gate auf Basis eines Cross-Node NCCL All-Reduce über das NVIDIA NVLink-Fabric über eine IMEX ComputeDomain bestand.

In der Validierungstabelle berichtete NVIDIA ein Leistungsergebnis von 744.71 GB/s Busbandbreite bei 16 GiB für das erste Cross-Node NCCL All-Reduce über beide Rechentrays. Das Unternehmen sagte, die Inferenzvariante habe dieselbe Bereitstellungs- und Konformitätsmatrix auf dem identischen Cluster bestanden, aber diese Schlussfolgerung für die Leistung bleibt vorerst aufgeschoben.

Der Beitrag sagte außerdem, dass die ersten Validierungsrunden vorübergehend durch ein Hardware- oder Fabric-Problem in einem der frühen Vera-Rubin-Cluster blockiert wurden, das eins Rechentray aus dem NVLink-Fabric fernhielt. NVIDIA sagte, das Problem habe nichts mit dem GPU-Operator oder dem DRA-Treiber zu tun und sei nach dem Wiedereinsetzen der Hardware behoben worden.

Rezeptbasierte Bereitstellung und aufgezeichnete Limits

Laut NVIDIA erfasst AICR die Plattformentscheidungen, die erforderlich sind, um einen funktionierenden Vera-Rubin-Cluster als versioniertes Rezept aufzubauen, einschließlich Treibermodus, Container-Laufzeitverkabelung, Komponentenversionen und plattformspezifischen Einstellungen. Das Unternehmen erklärte, dass die neue Vera-Rubin-Rezeptfamilie für rke2, den vr200 Beschleuniger und Ubuntu als Vorschau ausgeliefert wird, was bedeutet, dass sie für Early Adopters gedacht ist und noch nicht die Produktionsunterstützung und Lebenszyklusqualifikation eines Unterstützten Rezepts bietet.

Der Beitrag besagte, dass das Rezept den Host-Managed-Treibermodus kodiert, weil das Systemabbild den arm64 Open-Kernel-Module-Treiber vorinstalliert, während das Container-Toolkit vom Operator verwaltet bleibt. Es wurde außerdem erwähnt, dass das Rezept IMEX-unterstützte ComputeDomains für das NVL72 Fabric ermöglicht, die gesamte GPU-Zuweisung im Geräte-Plugin belässt und eine Reihe von Ebenen und Eigenheiten anpinnt, darunter Kubernetes 1.34.1 oder später, Ubuntu 26.04 und einen Vera-optimierten arm64 64k-Seiten-Kernel.

NVIDIA erklärte, dass die erste Bereitstellung des Bundles eine Plattformkombination anzielte, die zuvor nicht zusammen validiert worden war: arm64, Ubuntu 26.04, ein 64k-Seiten-Kernel, RKE2 und Vera Rubin. Das Unternehmen teilte mit, dass die Einrichtung innerhalb weniger Stunden vom Cluster-Handoff zu einer gesunden Laufzeit wechselte und dass ein zweiter Vera-Rubin-Cluster das Ergebnis am folgenden Tag reproduzierte.

Der Beitrag sagte außerdem, dass die validierte Grenze nicht endgültig sei. NVIDIA wies darauf hin, dass die Inference Serving Performance weiterhin von einem veröffentlichten Laufzeitbild abhängt, das gegen CUDA 13.4 oder später erstellt wurde, und erklärte, dass aktuelle öffentliche vLLM- und KI-dynamo-Bilder diese Anforderung noch nicht erfüllen, wie es für einen Vera-Rubin-Inferenz-Leistungsunterboden erforderlich ist. Das Unternehmen erklärte, dass die veröffentlichten Validierungsbelege daher als historischer Datensatz für die Rezeptkoordinate behandelt werden sollten, gegen die sie erfasst wurden.

NVIDIA gab an, dass die Vera-Rubin-Rezepte im Open-Source-NVIDIA/aicr-Repository in v1.0.0 veröffentlicht werden und dass Benutzer die validierte Konfiguration mit AICR-Rezeptbefehlen für entweder Trainings- oder Inferenzvarianten generieren können.