Linkbetrouwbaarheid en monitoring in AI-fabrics
Een trainingstaak is een synchrone berekening over duizenden GPU's: elke collectieve bewerking wacht op de langzaamste link. Eén transceiver met link flapping vertraagt niet één server een beetje, maar legt de hele taak stil. Valt die volledig uit, dan start de taak opnieuw vanaf het laatste checkpoint. Optiek is daardoor niet langer een component, maar een betrouwbaarheidsbudget. Deze pagina behandelt de faalberekeningen, de metriek die problemen voorspelt, hoe fabrics slechte links monitoren en isoleren, en de operationele werkwijzen die faalpercentages laag houden.
Waarom één link ertoe doet
| Gebeurtenis | Effect op een trainingstaak |
|---|---|
| Link flap (seconden) | collectieve bewerkingen verlopen door een time-out of proberen opnieuw; de staptijd piekt; met NCCL/RCCL breekt een lange genoeg onderbreking de taak af |
| Link met gereduceerde snelheid/breedte | elke all-reduce wordt erdoor getemporiseerd; de doorvoer van het hele cluster daalt tot het aandeel van die link |
| Verhoogde pre-FEC BER, geen niet-corrigeerbare fouten | nog geen effect, maar de marge is weg; op de volgende warme middag ontstaat link flapping |
| Niet-corrigeerbare FEC-fouten | pakketverlies → RDMA-hertransmissiestormen → stilstand |
| Volledige storing | taak start opnieuw vanaf checkpoint: minuten tot een uur aan verloren rekenwerk voor het hele cluster |
De kosten van een checkpoint-herstart bij een taak op duizend GPU's worden uitgedrukt in GPU-uren; dat getal moet worden vergeleken met de prijs van betere optiek en betere QA.
Faalaritmetiek
De betrouwbaarheid van transceivers wordt opgegeven in FIT (storingen per 10⁹ apparaaturen) of MTBF.
| Aanname | Waarde |
|---|---|
| Optische uiteinden in de fabric | 4 000 (een cluster met 1 024 GPU's en twee lagen) |
| FIT per uiteinde (rijpe 400G-optiek, goed gekoeld) | 200–500 |
| Verwachte volledige storingen per maand | 4 000 × 350 × 10⁻⁹ × 720 h ≈ 1 |
| Waargenomen frequentie van link flap in de praktijk | 5–20 × hoger dan volledige storingen — vuil, krappe marge, temperatuur, firmware |
Volledige storingen zijn dus zeldzaam en voorspelbaar; link flapping en gedegradeerde links overheersen en zijn meestal te voorkomen. Daarom verdienen monitoring en QA zichzelf terug.
Metriek die problemen voorspelt
| Metriek | Bron | Gezond | Actie |
|---|---|---|---|
| Pre-FEC BER per lane | CMIS VDM; FEC-tellers van de host | < 10⁻⁷ | > 10⁻⁶ stijgend; > 10⁻⁵ vervanging inplannen |
| Niet-corrigeerbare FEC-codewoorden | host | 0 | elke toename = incident |
| Symboolfouten per lane | host (Ethernet) / perfquery (IB) | evenwichtig, vrijwel nul | één lane overheerst |
| Rx-vermogen per lane versus baseline | DDM | binnen 1 dB van dag één, lanes onderling binnen 2 dB | −2 dB vanaf baseline |
| Trend van Tx-bias | DDM | vlak | +15–20 % vanaf baseline (Tx-bias en veroudering) |
| Moduletemperatuur | DDM | < 60 °C | > 65 °C of +10 °C ten opzichte van buren |
| eSNR (CMIS) | VDM | > 18–20 dB | dalend op één lane |
| Link flaps per poort | switchlogs, fabricmanager | 0 | elke |
| Onderhandelde snelheid/breedte | switch / ibstat | volledig | onder de nominale waarde |
Definities en formaten: VDM- en FEC-metrieken, DDM-monitoring.
Monitoringarchitectuur
| Fabric | Verzameling | Hulpmiddelen |
|---|---|---|
| InfiniBand | subnet-/fabricmanager polst tellers en kabel-EEPROM/DDM van elke poort | managers van de UFM-klasse, ibdiagnet, mlxlink -m |
| Ethernet (RoCE) | gNMI/OpenConfig-streaming van transceiver- en FEC-status iedere 10–60 s; SNMP als terugvaloptie | gnmic → Prometheus/Grafana, telemetrie van de fabrikant (DDM uitlezen met hulpmiddelen) |
| Hostzijde | NIC-tellers: hertransmissies, CNP's, out-of-order; NCCL/RCCL-logs voor time-outs | node-exporters |
| Taakzijde | variatie van staptijd, detectie van achterblijvers | metriek van het trainingsframework |
Breng de drie in verband: een piek in staptijd om 14:05, een afwijking in pre-FEC BER op leaf 7 lane 3 om 14:04 en een piek in moduultemperatuur in rack 12 vormen samen een volledige diagnose.
Isolatie en herstel
- Automatisch poort uitschakelen / omleiden wanneer niet-corrigeerbare fouten of flaps een drempel overschrijden — fabricmanagers en NOS ondersteunen beleid voor linkfouten; adaptieve routing leidt stromen ondertussen om een gedegradeerde link heen.
- Maak de node vrij als de NIC-poort de oorzaak is; plan de taak eromheen.
- Test de module op de werkbank: identiteit, DDM per lane vergeleken met de baseline van de eerste dag, checksums, firmwareversie (Check transceiver, DDM).
- Reinig en inspecteer opnieuw de MPO aan beide zijden voordat de module de schuld krijgt — vuil is de meest voorkomende oorzaak (Fysieke mismatches).
- Wissel en observeer: volgen de fouten de module, geef die dan op voor RMA; blijven ze bij de poort, kijk dan naar de cage, de glasvezel en het andere uiteinde.
Werkwijzen die het faalpercentage verlagen
| Werkwijze | Effect |
|---|---|
| Inkomende inspectie en inbranden (24–72 h onder belasting en temperatuur) | verwijdert kinderziektes voordat ze een taak bereiken |
| Baseline-DDM per lane op de eerste dag | maakt van absolute nauwkeurigheid (±3 dB) nauwkeurige delta's |
| Houd modules < 60 °C — luchtstroom, OSFP met koelribben/vlakke OSFP juist toegepast, geen geblokkeerde inlaten | levensduur verdubbelt per −10 °C |
| Reinig elke connector bij elke koppeling; kappen op ongebruikte poorten | de meeste flaps worden door vuil veroorzaakt |
| Actuele firmware voor modules en hosts | CMIS-interoperabiliteitscorrecties (CMIS-problemen) |
| Homogene, gevalideerde optiek per laag | minder verrassingen in DSP-interoperabiliteit tussen host en module |
| Ingebrande reserves met baseline, 3–5 % | vervanging zonder tweede incident |
| Wekelijkse trendbeoordeling | verouderende lasers volgens planning vervangen, niet na een storing |
Waar de technologie naartoe gaat
Hogere snelheden per lane (200G/lane, 1.6T) verkleinen de marges verder; lineaire (LPO) en co-packaged optiek verwijderen de DSP en de bijbehorende monitoring, waardoor de zichtbaarheid van BER naar de host verschuift. Tegelijk beloven ze minder componenten en minder warmte (Modulatie en DSP, Optiek in AI). Welke module ook wordt gebruikt, de discipline blijft hetzelfde: baseline vastleggen, delta's monitoren, op trends handelen.
In CodingBox
CodingBox vormt het werkbankuiteinde van deze cyclus: inkomende inspectie en uitlezingen bij inbranden, baselines per lane op de eerste dag opgeslagen per serienummer in de codedatabase, en uitlezingen na een incident van verwijderde modules — identiteit, firmware, checksums en DDM vergeleken met hun eigen geschiedenis. Zo berusten RMA-beslissingen op gegevens in plaats van op de laatste logregel van de poort.