NVIDIA Mission Control 2.5 führt autonome Wiederherstellung für Kubernetes-KI-Workloads ein

NVIDIA hat Mission Control 2.5 veröffentlicht und damit seine Engine zur autonomen Fehlerbehebung auf KI-Workloads ausgeweitet, die über NVIDIA Run:ai auf Kubernetes verwaltet werden. Bisher war diese Funktion auf Slurm-basierte Hochleistungsrechnenumgebungen beschränkt. Das Update ermöglicht es KI-Fabriken, Infrastruktur-Anomalien automatisch zu erkennen, zu diagnostizieren und ohne manuelle Eingriffe zu beheben.

Was passiert ist

Die zentrale Neuerung in dieser Version ist die direkte Integration eines Frameworks zur autonomen Fehlerbehebung in den Kubernetes-Scheduling-Loop. Dieses System wurde entwickelt, um die spezifischen Herausforderungen des modernen KI-Trainings anzugehen, bei dem Jobs über Hunderte von Knoten hinweg tagelang oder wochenlang laufen. In diesem Maßstab werden traditionelle reaktive Überwachung und manuelle Fehlersuche zu Engpässen, die teure Beschleunigerkapazität verschwenden.

Mission Control 2.5 führt einen dreischichtigen Regelkreis ein, der den Kubernetes-Scheduler, einen Dienst zur autonomen Job-Wiederherstellung und einen Dienst zur autonomen Hardware-Wiederherstellung koordiniert. Diese Architektur ermöglicht es der Plattform, zwischen verschiedenen Fehlertypen zu unterscheiden. Sie kann einen Job aufgrund eines vorübergehenden Softwarefehlers neu starten, während gleichzeitig ein Knoten mit Hardware-Degradation isoliert wird, um sicherzustellen, dass fehlerhafte Ressourcen nachfolgende Workloads nicht stören.

Diese Erweiterung markiert einen Wandel von scheduler-spezifischen Incident-Workflows hin zu einem einheitlichen, scheduler-bewussten Betriebsmodell. Plattformteams, die gemischte Umgebungen aus Kubernetes und Slurm verwalten, können nun eine konsistente Resilienzstrategie anwenden. Das Ziel besteht darin, die mittlere Reparaturzeit (Mean-Time-to-Repair) zu minimieren und die Auslastung der GPU-Cluster zu maximieren, indem Workloads produktiv gehalten werden, statt in Unsicherheit festzustecken.

Wie es funktioniert

Die Engine zur autonomen Fehlerbehebung arbeitet als koordiniertes System aus drei unterschiedlichen Komponenten. Erstens kümmert sich der Kubernetes-Scheduler, betrieben durch NVIDIA Run:ai, um die Platzierung von Workloads, die Warteschlangenverwaltung und die Durchsetzung von Richtlinien. Er bestimmt basierend auf verfügbarer Kapazität und Ressourcenanforderungen, wo Jobs ausgeführt werden sollen.

Zweitens fungiert der Dienst zur autonomen Job-Wiederherstellung als Kontextschicht. Er überwacht laufende Jobs, verfolgt deren Ausführungsort und analysiert die Fehlerhistorie sowie die Job-Topologie. Wenn ein Fehler auftritt, klassifiziert dieser Dienst das Problem, um den geeigneten Wiederherstellungspfad zu bestimmen, wie etwa einen Retry, Restart oder Re-Queue. So stellt er sicher, dass das System nicht überreagiert auf geringfügige, vorübergehende Softwarefehler, indem unnötige Hardware-Bereinigungen vermieden werden.

Drittens verwaltet der Dienst zur autonomen Hardware-Wiederherstellung die Gesundheit der Infrastruktur. Er überwacht Knoten und GPUs auf Anzeichen von Degradation, wie ECC-Fehler oder Kommunikations-Timeouts. Wird ein Hardwarefehler erkannt, isoliert dieser Dienst den betroffenen Knoten vom Scheduling-Pool und initiiert Diagnosen. Dieser Prozess läuft parallel zur Job-Wiederherstellung ab, sodass der Workload auf gesunden Knoten fortgesetzt werden kann, während die fehlerhafte Hardware repariert oder validiert wird.

Wichtige Details

• Dreischichtige Architektur: Das System integriert den Kubernetes-Scheduler, die autonome Job-Wiederherstellung und die autonome Hardware-Wiederherstellung in einen einzigen Regelkreis.
• Parallele Wiederherstellungs-Tracks: Bei Hardwarefehlern wird der Job sofort neu gestartet oder neu geplant, während der fehlerhafte Knoten im Hintergrund isoliert und diagnostiziert wird.
• Kontextbewusste Retries: Der Dienst zur Job-Wiederherstellung nutzt die Fehlerhistorie, um zwischen vorübergehenden Softwarefehlern und persistenten Hardwareproblemen zu unterscheiden, was verhindert, dass gesunde Knoten unnötig entfernt werden.
• Proaktive Erkennung von Degradation: Der Dienst zur Hardware-Wiederherstellung kann riskante Knoten identifizieren, bevor sie Job-Ausfälle verursachen, und sie präventiv aus dem Scheduling-Pool entfernen.
• Einheitliches Modell: Das Update bietet ein konsistentes Wiederherstellungsframework sowohl für Kubernetes- als auch für Slurm-Umgebungen und vereinfacht so die Operationen für Teams mit hybrider Infrastruktur.
• Zusätzliche Funktionen: Release 2.5 umfasst zudem Beta-Funktionen zur KI-gestützten Erkennung von Netzwerk-Anomalien, verbesserte Keycloak-Authentifizierung und Härtungs-Updates für Kubernetes.

Warum das wichtig ist

Für Engineering-Teams, die großskalige KI-Produkte entwickeln, ist die Zuverlässigkeit der Infrastruktur ein direkter Faktor für Entwicklungsgeschwindigkeit und Kosteneffizienz. Wenn ein verteiltes Trainingsjob nach tagelanger Laufzeit scheitert, sind die verlorenen Compute-Zeiten und verzögerten Modelliterationen erheblich. Durch die Automatisierung des Wiederherstellungsprozesses reduziert Mission Control 2.5 die operative Belastung für Plattform-Ingenieure, die andernfalls Logs manuell untersuchen, Knoten isolieren und Jobs neu starten müssten.

Die Fähigkeit, zwischen Software- und Hardwarefehlern zu unterscheiden, ist besonders kritisch. In vielen traditionellen Setups könnte ein einzelner Knotenausfall eine breite Alarmierung auslösen oder eine manuelle Inspektion des gesamten Clusters erfordern. Die Zurückhaltung dieses Systems beim Umgang mit vorübergehenden Softwarefehlern bedeutet, dass gesunde Hardware im Scheduling-Pool verbleibt und so die gesamte Cluster-Auslastung hoch bleibt. Umgekehrt verhindert die proaktive Entfernung degradierender Knoten kaskadierende Ausfälle, die mehrere gleichzeitige Trainingsläufe stören könnten.

Dieser Wandel hin zu selbstheilender Infrastruktur ermöglicht es Organisationen, ihre KI-Fabriken mit größerem Vertrauen zu skalieren. Da die Anzahl der gleichzeitigen Multi-Node-Workloads steigt, wächst die Komplexität des manuellen Managements exponentiell. Die automatische Wiederherstellung stellt sicher, dass die Infrastruktur diesen Maßstab bewältigen kann, ohne dass der operative Personalaufwand proportional zunimmt oder das Risiko menschlicher Fehler bei der Incident-Response steigt.

Was Sie tun können

• Prüfen Sie das offizielle Dokumentations-Hub, um den Upgrade-Pfad für bestehende Mission-Control-Nutzer zu verstehen, die auf Version 2.5 migrieren.
• Bewerten Sie Ihre aktuellen Kubernetes-Scheduling-Richtlinien, um sicherzustellen, dass sie mit den automatisierten Retry- und Restart-Fähigkeiten von NVIDIA Run:ai übereinstimmen.
• Implementieren Sie robuste Checkpointing-Strategien in Ihren Trainingspipelines, um die Engine zur autonomen Fehlerbehebung zu ergänzen und Datenverluste bei Job-Neustarts zu minimieren.
• Überwachen Sie den neuen Beta-Dienst zur KI-gestützten Erkennung von Netzwerk-Anomalien, um potenzielle Konnektivitätsprobleme zu identifizieren, bevor sie die Trainingsstabilität beeinträchtigen.
• Auditieren Sie Ihre Hardware-Wartungsworkflows, um sie mit den automatisierten Diagnose- und Quarantäne-Funktionen des Dienstes zur Hardware-Wiederherstellung zu integrieren.
• Testen Sie das Systemverhalten bei simulierten transienten Fehlern, um zu verifizieren, dass der Dienst zur Job-Wiederherstellung unnötige Hardware-Bereinigungen korrekt vermeidet.