Together AI erklärt Auto Repair für GPU Clusters: vom Fehler zum gesunden Node

Warum NotReady nicht ausreicht

Together AI argumentiert, dass GPU-Fehler im Cluster-Maßstab zum Alltag gehören. Als Beispiele nennt das Unternehmen einen Xid-Fehler, einen Double-Bit-ECC-Fehler, eine GPU, die vom PCIe-Bus fällt, und einen instabilen InfiniBand-Link, die einen verteilten Trainingsjob ausbremsen oder ein Inference-Replikat lahmlegen können. Ein Problem zu erkennen, sei meist der leichte Teil, so das Unternehmen. Schwierig sei alles, was zwischen dem Fehler und einem gesunden Node liegt.

Die meisten Auto-Repair-Verfahren für Nodes stützten sich laut Together AI auf ein einziges Signal: Der Node ist NotReady. Dieses Signal sehe gleich aus, ob ein Node defekt oder nur kurz nicht erreichbar ist, und es sage nichts darüber, warum der Node ausgefallen ist. Eine Grundlage, um zwischen Neustart und neuer Maschine zu wählen, fehle damit. Wenn ein Speicher- oder Netzwerkereignis viele Nodes gleichzeitig trifft, springen alle betroffenen Nodes auf NotReady. Together AI zufolge verfügt das System über einen eingebauten Circuit Breaker, der den massenhaften Austausch von Nodes verhindert.

Die Regel ist einfach: Keine Reparatur eines Nodes ohne einen fehlgeschlagenen Health Check als Grundlage, und jede Reparatur trägt ihre Belege mit sich. Laut Together AI nutzen Kunden der GPU Clusters und die interne Inference-Plattform des Unternehmens die Funktion bereits. Angekündigt hatte das Unternehmen sie Anfang des Jahres.

Erkennung auf beiden Seiten des Hypervisors

Die GPUs in Together GPU Clusters werden für Bare-Metal-Leistung direkt an die VM des Kunden durchgereicht. GPU-Fehler sind daher aus der VM heraus sichtbar, Host- und Fabric-Fehler dagegen vom Host aus. Die Erkennung läuft auf beiden Seiten und führt an einer Stelle zusammen.

• Innerhalb der VM überwachen Exporter das Kernel-Log auf Xid-Fehler und GPUs, die vom PCIe-Bus fallen.
• DCGM deckt ECC-Double-Bit-Fehler, Row-Remap-Fehler, PCIe-Replay-Rate und thermisches Throttling ab.
• Node Problem Detector erfasst schreibgeschützte Dateisysteme, XFS-Shutdowns, Kernel-Deadlocks und wiederholte Neustarts von kubelet oder containerd.
• Unter Slurm meldet ein Exporter Nodes, die als DOWN oder DRAIN markiert sind.
• Auf dem Host überwacht Together AI den Zustand der InfiniBand-Rails und Link-Flapping, zugeordnet zu der VM, der diese Rails gehören, sowie die Erreichbarkeit des Hosts.

Jeder Alarm enthält eine stabile Zusammenfassung, eine allgemeinverständliche Beschreibung und eine maschinenlesbare Evidence-Payload. Bei einem Xid sind das jeder Code und sein NVIDIA-Mnemonic, bei thermischem Throttling die Spitzentemperatur und die Zahl der Throttle-Ereignisse. Das Unternehmen trennt beobachtete von handlungsrelevanten Signalen: Jeder reparaturrelevante Alarm setzt den Node auf Degraded, aber nur Signale mit einer Aktionszuordnung lösen eine Reparatur aus. Speicherplatzmangel auf dem Datenträger wird beispielsweise angezeigt, löst aber keinen Neustart aus, weil ein Neustart ihn nicht beheben würde. Alarme ohne Zuordnung werden gezählt, protokolliert und an das Support-Team von Together AI weitergeleitet.

Kunden legen die Richtlinie fest

Laut Together AI entscheidet die Plattform, welche Aktion zu welchem Signal passt, und ordnet jeweils die leichteste Lösung zu. Ob und wann gehandelt wird, bestimmt dagegen der Kunde.

Im Tab Repairs steht die Auto-remediation-Richtlinie standardmäßig auf Approve before repair. Jede Empfehlung wartet also auf eine Person, die sie annehmen oder überstimmen kann. Kunden können auf Fully automatic umstellen, jedoch nicht pauschal. Eine Checkliste gruppiert Fehler nach der Reparatur, die sie auslösen, und die Freigabe lässt sich pro Xid-Code festlegen. Eine verbreitete Konfiguration, so das Unternehmen, genehmigt Neustarts bei Xid 119 und 95 automatisch, hält Migrationen aber weiter unter Freigabe.

Auch das Timing ist konfigurierbar. Da eine Reparatur den Node leert (Drain), hält Wait for idle sie zurück, bis der Node im Leerlauf ist. Unter Kubernetes heißt das, dass kein laufender Pod eine GPU anfordert, unter Slurm, dass keine Allokation auf dem Node besteht. Die maximale Wartezeit beträgt standardmäßig 2 Stunden bei einer Obergrenze von 24, und Do not interrupt running jobs hebt die Begrenzung ganz auf. Together AI rät, die Wartezeit mindestens auf das Checkpoint-Intervall zu setzen. Jede Reparatur hält fest, wer sie angefordert und wer sie genehmigt hat, welche Regel entschieden hat und wann.

Eigene Detektoren und die Eskalationsleiter

Teams, die bereits Tools wie DCGM-Dashboards, NVSentinel, hauseigene Scanner oder Prüfungen auf Job-Ebene einsetzen, können Reparaturen in dieselbe Pipeline einspeisen. Es gibt drei Einstiegspunkte: die API, die Konsole und Node Labels, die sich in der Preview befinden. Mit Node Labels kann jeder Detektor, der per RBAC Node-Metadaten schreiben darf, eine Reparatur anstoßen, indem er eine Annotation und ein Label hinzufügt. Die Reparatur wird mit dem Detektor als externem Anforderer erfasst. Detektorname plus Request-ID dienen als Idempotenzschlüssel, sodass ein Detektor, der denselben Fehler erneut meldet, einen Node nicht zweimal neu starten kann. Annotation-Anfragen können Reboot, Quick reprovision oder Migrate anfordern, während Remove allein Menschen vorbehalten bleibt. Sie durchlaufen weiterhin die Evidence-Prüfung, die Kapazitätsprüfung und die Budgets, und ein Limit pro Cluster begrenzt den Schaden durch einen fehlerhaften Detektor.

Jede Reparatur folgt dem Ablauf aus Cordon, Warten, Drain, Aktion und Wiedereingliederung. Die Aktionen reichen von der leichtesten bis zur schwersten:

• Reboot: startet die VM an Ort und Stelle neu, lokale Daten in /scratch und /tmp bleiben erhalten.
• Quick reprovision: baut die VM aus einem sauberen Image auf einem gesunden Host neu auf, lokale Daten gehen verloren.
• Migrate to new host: baut die VM auf anderer Hardware neu auf und schickt den alten Host zur erneuten Validierung.
• Remove: nimmt den Node für eine RMA aus dem Betrieb und wird immer von Menschen ausgelöst.

Tritt ein Fehler auf derselben Maschine erneut auf, nachdem dieselbe Aktion zweimal gelaufen ist, steigt die nächste Empfehlung eine Stufe auf. Aus einer dritten Runde von Xid-Neustarts wird eine Neubereitstellung, aus einer dritten Neubereitstellung eine Migration. Die Leiter wird pro Maschine, Cluster, Alarm und Xid-Code nachgehalten.

Verfügbarkeit und Bedeutung für Nutzer

Laut Together AI sind passive Health Checks, Reparaturempfehlungen, die Auto-remediation-Richtlinie, die Wait-for-idle-Steuerung, die Eskalationsleiter, die Sicherheitsmechanismen sowie die Reparatur per API und Konsole allgemein verfügbar. Auf Node Labels basierende Remediation-Verträge befinden sich in der Preview. Das Unternehmen erklärt, weiterhin Erkennungssignale und Reparaturaktionen zu ergänzen.

Für Teams, die große GPU-Flotten betreiben, behält der Ansatz die Kontrolle darüber, ob und wann Reparaturen laufen, beim Menschen und verknüpft jede Aktion mit Belegen und einem Audit-Eintrag.