Link-Zuverlässigkeit und Überwachung in KI-Fabrics
Ein Trainingsjob ist eine synchrone Berechnung über Tausende von GPUs: Jede kollektive Operation wartet auf den langsamsten Link. Ein flappender Transceiver verlangsamt nicht nur einen Server um einen Bruchteil — er blockiert den gesamten Job, und fällt er ganz aus, startet der Job vom letzten Checkpoint neu. Optik hört damit auf, eine Komponente zu sein, und wird zu einem Zuverlässigkeitsbudget. Diese Seite behandelt die Ausfallmathematik, die Metriken, die Probleme vorhersagen, wie Fabrics schlechte Links überwachen und isolieren, sowie die betrieblichen Praktiken, die die Ausfallrate niedrig halten.
Warum ein Link so viel ausmacht
| Ereignis | Auswirkung auf einen Trainingsjob |
|---|---|
| Link-Flap (Sekunden) | kollektive Operationen laufen in Timeout oder Retry; Step-Zeit schnellt hoch; bei NCCL/RCCL bricht ein hinreichend langer Stillstand den Job ab |
| Link mit reduzierter Geschwindigkeit/Breite | jedes All-Reduce wird davon ausgebremst; der Durchsatz des gesamten Clusters sinkt auf den Anteil dieses Links |
| Erhöhte Pre-FEC-BER, keine unkorrigierbaren Fehler | noch keine — aber die Reserve ist aufgebraucht; am nächsten warmen Nachmittag flappt er |
| Unkorrigierbare FEC-Fehler | Paketverlust → RDMA-Neuübertragungsstürme → Stillstand |
| Harter Ausfall | Job-Neustart vom Checkpoint: Minuten bis eine Stunde verlorener Rechenzeit im gesamten Cluster |
Die Kosten eines Checkpoint-Neustarts bei einem Job mit tausend GPUs werden in GPU-Stunden gemessen; das ist die Zahl, die dem Preis besserer Optik und besserer QA gegenübersteht.
Ausfallarithmetik
Die Zuverlässigkeit von Transceivern wird in FIT (Ausfälle pro 10⁹ Gerätestunden) oder MTBF angegeben.
| Annahme | Wert |
|---|---|
| Optische Enden in der Fabric | 4 000 (ein zweistufiger 1 024-GPU-Cluster) |
| FIT pro Ende (ausgereifte 400G-Optik, gut gekühlt) | 200–500 |
| Erwartete harte Ausfälle pro Monat | 4 000 × 350 × 10⁻⁹ × 720 h ≈ 1 |
| Beobachtete Link-Flap-Rate in der Praxis | 5–20 × höher als harte Ausfälle — Schmutz, knappe Reserve, Thermik, Firmware |
So sind harte Ausfälle selten und vorhersehbar; Flaps und degradierte Links dominieren und sind größtenteils vermeidbar — deshalb rechnen sich Monitoring und QA.
Metriken, die Probleme vorhersagen
| Metrik | Quelle | Gesund | Reaktion |
|---|---|---|---|
| Pre-FEC-BER pro Lane | CMIS-VDM; FEC-Zähler des Hosts | < 10⁻⁷ | > 10⁻⁶ steigend; > 10⁻⁵ Austausch einplanen |
| Unkorrigierbare FEC-Codewörter | Host | 0 | jeder Anstieg = Vorfall |
| Symbolfehler pro Lane | Host (Ethernet) / perfquery (IB) | ausgeglichen, nahe null | eine Lane dominiert |
| Rx-Leistung pro Lane vs. Baseline | DDM | innerhalb 1 dB von Tag eins, Lanes innerhalb 2 dB zueinander | −2 dB gegenüber Baseline |
| Tx-Bias-Trend | DDM | flach | +15–20 % gegenüber Baseline (Tx-Bias & Laseralterung) |
| Modultemperatur | DDM | < 60 °C | > 65 °C oder +10 °C gegenüber den Nachbarn |
| eSNR (CMIS) | VDM | > 18–20 dB | fällt auf einer Lane |
| Link-Flaps pro Port | Switch-Logs, Fabric-Manager | 0 | jeder |
| Ausgehandelte Geschwindigkeit/Breite | Switch / ibstat | voll | unter Nennwert |
Definitionen und Formate: VDM- und FEC-Metriken, Monitoring.
Monitoring-Architektur
| Fabric | Erfassung | Tools |
|---|---|---|
| InfiniBand | Subnet-/Fabric-Manager fragt Zähler und Kabel-EEPROM/DDM jedes Ports ab | UFM-Klasse-Manager, ibdiagnet, mlxlink -m |
| Ethernet (RoCE) | gNMI/OpenConfig-Streaming von Transceiver- und FEC-Status alle 10–60 s; SNMP als Fallback | gnmic → Prometheus/Grafana, Hersteller-Telemetrie (DDM mit Tools auslesen) |
| Host-Seite | NIC-Zähler: Neuübertragungen, CNPs, Out-of-Order; NCCL/RCCL-Logs für Timeouts | Node Exporter |
| Job-Seite | Varianz der Step-Zeit, Straggler-Erkennung | Metriken des Trainings-Frameworks |
Die drei Ebenen korrelieren: ein Step-Zeit-Ausschlag um 14:05 Uhr, ein Pre-FEC-BER-Ausreißer auf Leaf 7, Lane 3, um 14:04 Uhr und eine Temperaturspitze eines Moduls in Rack 12 ergeben zusammen eine vollständige Diagnose.
Isolation und Abhilfe
- Automatisches Port-Disable/Route-around, wenn unkorrigierbare Fehler oder Flaps eine Schwelle überschreiten — Fabric-Manager und NOS unterstützen Link-Error-Policies; adaptives Routing lenkt Datenströme in der Zwischenzeit um einen degradierten Link herum.
- Den Node entleeren (Drain), wenn dessen NIC-Port der Übeltäter ist; den Job darum herum planen.
- Das Modul auf der Werkbank prüfen: Identität, DDM pro Lane gegen die Tag-eins-Baseline, Prüfsummen, Firmware-Version (Check transceiver, DDM).
- MPO auf beiden Seiten reinigen und neu inspizieren, bevor das Modul verdächtigt wird — Schmutz ist die häufigste Ursache (Physische Fehlanpassungen).
- Tauschen und beobachten: Wandern die Fehler mit dem Modul mit, per RMA austauschen; bleiben sie beim Port, Käfig, Faser und Gegenstelle prüfen.
Praktiken, die die Ausfallrate senken
| Praxis | Wirkung |
|---|---|
| Eingangsprüfung und Burn-in (24–72 h unter Last und Temperatur) | entfernt Frühausfälle, bevor sie einen Job erreichen |
| DDM pro Lane an Tag eins als Baseline | macht aus absoluter Genauigkeit (±3 dB) präzise Deltas |
| Module < 60 °C halten — Luftstrom, gerippte/flache OSFP korrekt einsetzen, keine blockierten Lufteinlässe | Lebensdauer verdoppelt sich pro −10 °C |
| Jeden Steckverbinder bei jeder Verbindung reinigen; Schutzkappen auf unbenutzten Ports | die meisten Flaps sind Schmutz |
| Aktuelle Firmware für Module und Hosts | behebt CMIS-Interop-Probleme (CMIS-Probleme) |
| Homogene, validierte Optik pro Ebene | weniger Überraschungen bei der DSP-Interop zwischen Host und Modul |
| Ersatzteile eingebrannt und mit Baseline, 3–5 % | Austausch ohne einen zweiten Vorfall |
| Wöchentliche Trendprüfung | alternde Laser planmäßig austauschen, nicht erst beim Ausfall |
Wohin sich die Technologie entwickelt
Höhere Lane-Raten (200G/Lane, 1,6T) verengen die Reserven weiter; lineare (LPO-) und Co-Packaged-Optik entfernen den DSP und damit sein Monitoring — die BER-Sichtbarkeit verschiebt sich zum Host —, versprechen dafür aber weniger Komponenten und weniger Wärme (Modulation & DSP, Optik in KI). Unabhängig vom Modul bleibt die Disziplin: Baseline erfassen, Deltas überwachen, auf Trends reagieren.
In CodingBox
CodingBox ist das Werkbank-Ende dieser Schleife: Auslesen bei Eingangsprüfung und Burn-in, Tag-eins-Baselines pro Lane, gespeichert nach Seriennummer in der Code-Datenbank, und Post-Mortem-Auslesungen ausgebauter Module — Identität, Firmware, Prüfsummen und DDM im Vergleich mit ihrer eigenen Historie —, sodass RMA-Entscheidungen auf Daten beruhen und nicht auf der letzten Logzeile des Ports.