Link-Zuverlässigkeit und Überwachung in KI-Fabrics · Künstliche Intelligenz · Technologien · Dokumentation · CodingBox
CodingBox Dokumentation

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.

EreignisAuswirkung 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/Breitejedes All-Reduce wird davon ausgebremst; der Durchsatz des gesamten Clusters sinkt auf den Anteil dieses Links
Erhöhte Pre-FEC-BER, keine unkorrigierbaren Fehlernoch keine — aber die Reserve ist aufgebraucht; am nächsten warmen Nachmittag flappt er
Unkorrigierbare FEC-FehlerPaketverlust → RDMA-Neuübertragungsstürme → Stillstand
Harter AusfallJob-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.

AnnahmeWert
Optische Enden in der Fabric4 000 (ein zweistufiger 1 024-GPU-Cluster)
FIT pro Ende (ausgereifte 400G-Optik, gut gekühlt)200–500
Erwartete harte Ausfälle pro Monat4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
Beobachtete Link-Flap-Rate in der Praxis5–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

MetrikQuelleGesundReaktion
Pre-FEC-BER pro LaneCMIS-VDM; FEC-Zähler des Hosts< 10⁻⁷> 10⁻⁶ steigend; > 10⁻⁵ Austausch einplanen
Unkorrigierbare FEC-CodewörterHost0jeder Anstieg = Vorfall
Symbolfehler pro LaneHost (Ethernet) / perfquery (IB)ausgeglichen, nahe nulleine Lane dominiert
Rx-Leistung pro Lane vs. BaselineDDMinnerhalb 1 dB von Tag eins, Lanes innerhalb 2 dB zueinander−2 dB gegenüber Baseline
Tx-Bias-TrendDDMflach+15–20 % gegenüber Baseline (Tx-Bias & Laseralterung)
ModultemperaturDDM< 60 °C> 65 °C oder +10 °C gegenüber den Nachbarn
eSNR (CMIS)VDM> 18–20 dBfällt auf einer Lane
Link-Flaps pro PortSwitch-Logs, Fabric-Manager0jeder
Ausgehandelte Geschwindigkeit/BreiteSwitch / ibstatvollunter Nennwert

Definitionen und Formate: VDM- und FEC-Metriken, Monitoring.

Monitoring-Architektur

FabricErfassungTools
InfiniBandSubnet-/Fabric-Manager fragt Zähler und Kabel-EEPROM/DDM jedes Ports abUFM-Klasse-Manager, ibdiagnet, mlxlink -m
Ethernet (RoCE)gNMI/OpenConfig-Streaming von Transceiver- und FEC-Status alle 10–60 s; SNMP als Fallbackgnmic → Prometheus/Grafana, Hersteller-Telemetrie (DDM mit Tools auslesen)
Host-SeiteNIC-Zähler: Neuübertragungen, CNPs, Out-of-Order; NCCL/RCCL-Logs für TimeoutsNode Exporter
Job-SeiteVarianz der Step-Zeit, Straggler-ErkennungMetriken 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

  1. 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.
  2. Den Node entleeren (Drain), wenn dessen NIC-Port der Übeltäter ist; den Job darum herum planen.
  3. Das Modul auf der Werkbank prüfen: Identität, DDM pro Lane gegen die Tag-eins-Baseline, Prüfsummen, Firmware-Version (Check transceiver, DDM).
  4. MPO auf beiden Seiten reinigen und neu inspizieren, bevor das Modul verdächtigt wird — Schmutz ist die häufigste Ursache (Physische Fehlanpassungen).
  5. 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

PraxisWirkung
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 Baselinemacht aus absoluter Genauigkeit (±3 dB) präzise Deltas
Module < 60 °C halten — Luftstrom, gerippte/flache OSFP korrekt einsetzen, keine blockierten LufteinlässeLebensdauer verdoppelt sich pro −10 °C
Jeden Steckverbinder bei jeder Verbindung reinigen; Schutzkappen auf unbenutzten Portsdie meisten Flaps sind Schmutz
Aktuelle Firmware für Module und Hostsbehebt CMIS-Interop-Probleme (CMIS-Probleme)
Homogene, validierte Optik pro Ebeneweniger Überraschungen bei der DSP-Interop zwischen Host und Modul
Ersatzteile eingebrannt und mit Baseline, 3–5 %Austausch ohne einen zweiten Vorfall
Wöchentliche Trendprüfungalternde 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.


Wenn Sie in diesem Artikel eine Ungenauigkeit oder einen Fehler finden, markieren Sie die betreffende Stelle und drücken Sie Ctrl+Enter, um .