NVIDIA bündelt Konfiguration und Dauerprüfung von GPU-Clustern unter dem Namen DSX OS

DSX OS bündelt Konfiguration, Zertifizierung und Dauerprüfung für GPU-Kubernetes

NVIDIA stellt DSX OS in einem Entwicklerblog vor. Die Software ist als Open-Source-Schicht der DSX AI Factory Platform angelegt. Sie soll beschleunigte Kubernetes-Infrastruktur konfigurieren, zertifizieren und über den gesamten Lebenszyklus gesund halten. Leistungsschwache oder defekte Knoten sollen damit nicht erst im laufenden Training auffallen.

Den Einstieg bildet die AI Cluster Runtime (AICR). Im Schritt „Configure“ schafft sie nach NVIDIAs Darstellung eine reproduzierbare Grundlage für GPU-optimierte Kubernetes-Infrastruktur. Dazu nutzt sie versionsfixierte Konfigurationsrezepte, etwa für Netzwerk, Speicher und Treiber.

Die DSX-Dokumentation führt DSX OS neben DSX Sim, DSX MaxLPS, DSX Exchange, DSX Flex und DSX Reference Designs. Beschrieben wird es als Open-Source-Software für Aufbau, Betrieb und Skalierung mandantenfähiger AI-Factory-Infrastruktur. Welche Funktion zu welcher Komponente gehört, bleibt im vorliegenden Auszug unklar. Das betrifft auch die Beschreibungen zum Definieren, Konfigurieren, Validieren und Deployen beschleunigter Kubernetes-Umgebungen.

NVIDIA verspricht für AI Factories insgesamt „niedrigste Token-Kosten“, kürzere Time-to-First-Token und höhere Betriebsresilienz. Dabei handelt es sich um Herstellerangaben. Unabhängige Messungen oder Kundenberichte dazu liegen nicht vor.

Warum eine Abnahme bei Übergabe nach NVIDIAs Argumentation nicht reicht

Ein einzelner schwacher GPU-Knoten kann einen verteilten Trainingsjob ausbremsen. Das gilt auch dann, wenn er einfache Health-Checks besteht und eine normale Auslastung zeigt. So argumentiert NVIDIA. Betreiber merkten das bisher erst, wenn der Workload läuft. Eine Zertifizierung bei Übergabe verliere zudem an Aussagekraft, sobald Knoten getauscht, Treiber gepatcht und Kapazitäten erweitert werden.

Das Unternehmen empfiehlt deshalb Validierung nach Konfigurationsänderungen, bei Wachstum und vor der Rückkehr reparierter Knoten in den Betrieb. Als Kennzahl bevorzugt NVIDIA Goodput, also die Menge erfolgreich abgeschlossener Arbeit. Auslastungsmetriken könnten Verluste verschleiern, heißt es. Auch das ist Herstellerargumentation und keine Messung.

Die technische Grundlage existiert nach NVIDIA-Dokumentation bereits. DCGM Diagnostics bietet gestufte aktive Tests: Level 1 sind Schnellchecks im Sekundenbereich, Level 2 dauert etwa zwei Minuten, Level 3 etwa 15 Minuten, Level 4 ist länger. Vorgesehen sind sie unter anderem für Bereitschaftsprüfungen vor dem Workload-Start und vor der Rückkehr eines Knotens in den Betrieb.

Offen: Was DSX OS über die vorhandenen DCGM-Diagnosen hinaus leistet

Der Blogtext liegt nur ausschnittsweise vor. Ob DSX OS die vorhandenen Diagnosefunktionen lediglich neu verpackt oder erweitert, lässt sich daraus nicht ableiten. Neue Tests, Messzahlen oder Fallbeispiele fehlen. Die GitHub-Organisation „DSX AI Factory“ (dsx-ai-factory) listet unter anderem Run:ai und „Exemplar Performance“. Im Auszug wird sie aber nicht ausdrücklich DSX OS zugeordnet.

Zum Hintergrund dienen zwei Drittquellen, die DSX OS nicht behandeln. Laut Berichten, die sich auf Meta stützen, gab es beim Training von Llama 3 405B 419 unerwartete Unterbrechungen in 54 Tagen. Rund 78 % davon waren hardwarebedingt. Das Material wurde nicht direkt geprüft. Ein Bericht von Lablup zu einem B200-Cluster findet keine einzelne Metrik, die Ausfälle über alle Fehlertypen hinweg zuverlässig vorhersagt. Auf die Wirkung von DSX OS lässt sich daraus nichts schließen.

Belastbare Aussagen über den Nutzen setzen unabhängige Messungen voraus.