Mission Control 2.5 erweitert die Wiederherstellung auf Run:ai-Kubernetes

NVIDIA erklärte am 26. Oktober, dass Mission Control 2.5 seine autonome Wiederherstellung auf Kubernetes-Arbeitslasten unter NVIDIA Run:ai ausdehnt. Zuvor war dieser Dienst auf Hochleistungsrechenaufgaben mit Slurm begrenzt. Diese Ausgabe erscheint am 28. Oktober, das ursprüngliche Beitragsdatum ist also älter. Der Text beschreibt den Funktionsumfang und den Ablauf bei Fehlern. Er enthält keine gemessene Senkung der mittleren Reparaturdauer, keine Verfügbarkeitssteigerung und keinen kontrollierten Vergleich mit einem von Menschen betriebenen Cluster. Der Produktname darf nicht als Garantie einer sofortigen verlustfreien Fortsetzung jeder Trainingsaufgabe gelesen werden.

Der Regelkreis trennt drei Rollen. Der Kubernetes-Planer verteilt Arbeit auf geeignete Rechner. Der Dienst zur autonomen Job-Wiederherstellung erfasst den Kontext eines Fehlers und entscheidet über Neustart, neue Platzierung oder eine Weitergabe an Menschen. Der Dienst zur Hardware-Wiederherstellung prüft den Zustand der Geräte, sperrt verdächtige Knoten und beginnt die Diagnose. So kann eine Aufgabe auf gesunden Ressourcen weitergeführt werden, während die genaue Ursache eines Gerätefehlers noch untersucht wird. Ob und ab welchem Zeitpunkt eine Anwendung fortgesetzt werden kann, hängt aber von ihren Checkpoints und Einstellungen ab. Der Beitrag liefert keine allgemeine Zusage für alle Trainingsprogramme.

Bei einem GPU-Fehler während verteilter Arbeit können Speicherfehler, ein hängender Prozess oder ein Kommunikations-Timeout die ersten Anzeichen sein. Die Job-Seite sammelt Angaben zur Aufgabe und veranlasst über den Planer einen Neustart oder eine Verlagerung. Gleichzeitig nimmt die Hardware-Seite den betroffenen Rechner aus der Planung, protokolliert den Grund und startet Tests. Der nächste Job soll nicht auf derselben verdächtigen Maschine landen. Die Abbildungen im Artikel zeigen vorgesehene Kontrollwege; sie zählen keine tatsächlichen Vorfälle und belegen keine Häufigkeit erfolgreicher Wiederherstellung.

Ein vorübergehender Softwarefehler verlangt dagegen nicht zwingend eine Hardware-Sperre. Ein Prozess kann ausfallen oder kurz die Abstimmung verlieren, obwohl der Rechner gesund ist. Die Job-Seite kann entsprechend der Planerregel erneut starten; wiederholte oder nicht wiederholbare Fehler gehen zur weiteren Untersuchung. Als drittes Szenario beschreibt NVIDIA eine früh erkannte Verschlechterung eines Knotens. Häufige Gesundheitswarnungen oder Verbindungsprobleme können dazu führen, dass er keine neuen Aufgaben erhält und zuerst untersucht wird. Die Unterscheidung verhindert sowohl unnötig gesperrte gesunde Kapazität als auch endlose Wiederholungen auf fehlerhaften Geräten.

Ein Betreiber sollte für die eigene Anlage kontrollierte Fehler einspielen und anschließend Abschlussquote, seit dem letzten Checkpoint verlorene Arbeit, gesperrte Kapazität und Dauer bis zur Wiederaufnahme messen. Die genauen Ergebnisse hängen von Planer, Anwendung und Fehlerart ab. Der Beitrag verweist auf Produktdokumentation und Versionshinweise, darunter eine Funktion für KI-gestützte Erkennung von Netzwerkanomalien. Diese Hinweise ersetzen jedoch keine im Artikel fehlende quantitative Erfolgsmessung. Fest steht die Erweiterung auf Kubernetes mit Run:ai und der beschriebene dreiteilige Kontrollkreis. Aussagen über allgemeine Kostensenkung oder höheren GPU-Ertrag benötigen weitere Daten.