KI SpotlightNewsMission Control 2.5: Autonome Recovery läuft auch auf Run:ai-Kubernetes
NVIDIA weitet die Recovery-Engine von Slurm aus. Die Engine selbst ist nicht neu. Die Leistungsversprechen stammen allein vom Hersteller.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Mission Control 2.5 erweitert die autonome Wiederherstellung auf Kubernetes-Workloads unter NVIDIA Run:ai.
- Vor Version 2.5 war die autonome Recovery-Engine auf Slurm-HPC-Workloads beschränkt.
- Mission Control 2.2.0 bietet bereits autonome Hardware- und Job-Recovery mit Slurm-Integration auf DGX B200.
- Für DGX B300 gelten laut Release Notes 2.2.0 nur BCM, Run:ai, LaunchPad-Zugang und Kubernetes-Sicherheitsrichtlinien.
- Der Autonomous Job Recovery erkennt, isoliert und behebt Fehler autonom und ist mit Slurm integriert.
Autonome Recovery läuft mit Mission Control 2.5 auch auf Run:ai-Kubernetes
NVIDIA erweitert Mission Control 2.5 um autonome Wiederherstellung für Kubernetes-Workloads, die mit NVIDIA Run:ai verwaltet werden. Laut einem Beitrag im NVIDIA-Entwicklerblog erkennt der Dienst Anomalien im Stack, diagnostiziert sie und behebt sie. Vor Version 2.5 war er nach Angaben des Blogs auf HPC-Workloads mit Slurm beschränkt.
Betroffen sind damit Betreiber von KI-Trainingsclustern auf Run:ai. Sie müssten für die Funktion vermutlich auf 2.5 wechseln. Das ist eine Schlussfolgerung aus der Blog-Aussage, keine bestätigte Angabe. Die Darstellung stützt sich allein auf diesen Herstellerbeitrag. Die Release Notes zu 2.5 liegen nicht vor, eine unabhängige Bestätigung gibt es nicht.
Slurm-Recovery gab es schon in 2.2.0, Run:ai-Scheduling seit 2.0
Neu ist demnach nur die Ausweitung auf Kubernetes und Run:ai, nicht die Engine. Schon die Release Notes zu Mission Control 2.2.0 nennen die Autonomous Resiliency Engine mit Slurm-Integration für workload-bewusste Recovery sowie autonome Hardware- und Job-Recovery. Mission Control 2.0 kombinierte den Base Command Manager wahlweise mit Slurm oder Run:ai für Scheduling und Orchestrierung.
NVIDIA beschreibt den Ablauf des Autonomous Job Recovery in der Dokumentation so: Das System erkennt einen Fehler, bricht den Job ab, startet ihn neu und lädt den letzten gespeicherten Checkpoint. Zwischen dem letzten Checkpoint und der Wiederaufnahme liegt Ausfallzeit, denn in dieser Phase werden die Ressourcen nicht genutzt. Die Dokumentation beschreibt diese Integration mit Slurm.
Wie sich 2.5 technisch von 2.2 unterscheidet, etwa bei den abgedeckten Fehlerklassen, den Voraussetzungen oder der Verfügbarkeit, lässt sich aus dem vorliegenden Material nicht belegen.
„Von Stunden auf Minuten“: Die Wirkung ist bisher nur Herstellerbehauptung
Die Leistungsversprechen stammen ausschließlich von NVIDIA. Nach Angaben des Herstellers senken automatisierte Fehlertoleranz und schnelles verteiltes Checkpointing die Ausfallzeit im Training „von Stunden auf Minuten“. Das System arbeite bei Ausfällen mit „null manuellem Eingriff“. Auf der Produktseite heißt es außerdem, Unternehmen könnten KI „mit der Effizienz heutiger Hyperscaler“ betreiben, mit „Always-on-Resilienz für maximierten ROI“.
Das ebenfalls von NVIDIA genannte Beispiel nennt einen Ausfall alle drei Stunden mit einer Stunde Recovery. Es ist eine Fragestellung, keine Messung. Messdaten mit Clustergröße, Messaufbau und Wiederherstellungszeiten vor und nach dem Einsatz liegen nicht vor, ebenso wenig Kundenreferenzen oder unabhängige Tests. Offen bleibt, wie viel Zeit die Recovery auf Run:ai tatsächlich spart.
