Niezawodność łączy i monitorowanie w fabric AI

Zadanie treningowe to synchroniczne obliczenie na tysiącach GPU: każda operacja zbiorowa czeka na najwolniejsze łącze. Jeden migoczący transceiver nie spowalnia jednego serwera o ułamek — zatrzymuje całe zadanie, a jeśli zawiedzie całkowicie, zadanie startuje od nowa od ostatniego punktu kontrolnego. Optyka przestaje więc być komponentem i staje się budżetem niezawodności. Ta strona omawia arytmetykę awarii, metryki przewidujące kłopoty, sposób, w jaki fabric monitorują i izolują złe łącza, oraz praktyki operacyjne, które utrzymują niski poziom awarii.

Dlaczego jedno łącze ma znaczenie

Zdarzenie	Wpływ na zadanie treningowe
Migotanie łącza (sekundy)	operacje zbiorowe przekraczają limit czasu albo są ponawiane; czas kroku skacze; przy wystarczająco długim zawieszeniu NCCL/RCCL przerywa zadanie
Łącze o obniżonej szybkości/szerokości	każdy all-reduce jest przez nie tempowany; przepustowość całego klastra spada do udziału tego łącza
Podwyższony pre-FEC BER, brak błędów nieskorygowanych	jeszcze nic — ale zapas zniknął; następnego ciepłego popołudnia łącze zacznie migotać
Błędy nieskorygowane FEC	utrata pakietów → burze retransmisji RDMA → zawieszenie
Awaria twarda	restart zadania od punktu kontrolnego: od minut do godziny utraconych obliczeń w całym klastrze

Koszt restartu od punktu kontrolnego dla zadania na tysiącu GPU mierzy się w godzinach GPU; to właśnie tę liczbę warto porównać z ceną lepszej optyki i lepszego QA.

Arytmetyka awarii

Niezawodność transceivera podaje się w FIT (awarie na 10⁹ godzin urządzenia) albo MTBF.

Założenie	Wartość
Końce optyczne w fabric	4 000 (klaster dwuwarstwowy, 1 024 GPU)
FIT na koniec (dojrzała optyka 400G, dobrze chłodzona)	200–500
Oczekiwane awarie twarde na miesiąc	4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
Obserwowany w praktyce wskaźnik migotania łącza	5–20 × wyższy niż awarii twardych — brud, graniczny zapas, temperatura, firmware

Awarie twarde są więc rzadkie i przewidywalne; dominują migotania i zdegradowane łącza, którym w większości da się zapobiec — dlatego monitorowanie i QA się zwracają.

Metryki przewidujące problemy

Metryka	Źródło	Zdrowy poziom	Działanie
Pre-FEC BER na linię	CMIS VDM; liczniki FEC hosta	< 10⁻⁷	> 10⁻⁶ i rośnie; > 10⁻⁵ zaplanuj wymianę
Nieskorygowane słowa kodowe FEC	host	0	każdy przyrost = incydent
Błędy symboli na linię	host (Ethernet) / `perfquery` (IB)	zrównoważone, blisko zera	jedna linia dominuje
Moc Rx na linię względem wartości bazowej	DDM	w zakresie 1 dB od pierwszego dnia, linie w zakresie 2 dB między sobą	−2 dB od wartości bazowej
Trend bias Tx	DDM	płaski	+15–20 % od wartości bazowej (Bias Tx i starzenie)
Temperatura modułu	DDM	< 60 °C	> 65 °C albo +10 °C względem sąsiadów
eSNR (CMIS)	VDM	> 18–20 dB	spada na jednej linii
Migotania łącza na port	logi przełącznika, fabric manager	0	jakiekolwiek
Wynegocjowana szybkość/szerokość	przełącznik / `ibstat`	pełna	poniżej znamionowej

Definicje i formaty: Metryki VDM i FEC, Monitoring.

Architektura monitorowania

Fabric	Zbieranie danych	Narzędzia
InfiniBand	subnet/fabric manager odpytuje liczniki każdego portu oraz EEPROM/DDM kabla	managery klasy UFM, `ibdiagnet`, `mlxlink -m`
Ethernet (RoCE)	strumieniowanie gNMI/OpenConfig stanu transceivera i FEC co 10–60 s; SNMP jako rezerwa	gnmic → Prometheus/Grafana, telemetria producenta (Odczyt DDM za pomocą narzędzi)
Strona hosta	liczniki NIC: retransmisje, CNP, pakiety poza kolejnością; logi NCCL/RCCL dla przekroczeń czasu	node exportery
Strona zadania	wariancja czasu kroku, wykrywanie opóźnionych uczestników	metryki frameworku treningowego

Skoreluj te trzy źródła: skok czasu kroku o 14:05, wychylenie pre-FEC BER na leaf 7 linia 3 o 14:04 i szczyt temperatury modułu w szafie 12 to kompletna diagnoza.

Izolacja i naprawa

Automatyczne wyłączenie portu / obejście trasy, gdy błędy nieskorygowane albo migotania przekroczą próg — fabric managery i NOS obsługują polityki błędów łącza; w międzyczasie routing adaptacyjny kieruje ruch wokół zdegradowanego łącza.
Opróżnij węzeł (drain), jeśli winny jest jego port NIC; zaplanuj zadanie z jego pominięciem.
Sprawdź moduł na stanowisku: dane identyfikacyjne, DDM na linię względem wartości bazowej z pierwszego dnia, sumy kontrolne, wersja firmware (Check transceiver, DDM).
Wyczyść i sprawdź ponownie MPO po obu stronach, zanim obwinisz moduł — brud to najczęstsza przyczyna (Niezgodności fizyczne).
Wymień i obserwuj: jeśli błędy podążają za modułem, zgłoś RMA; jeśli zostają przy porcie, sprawdź klatkę, światłowód i daleki koniec.

Praktyki obniżające wskaźnik awarii

Praktyka	Efekt
Kontrola wejściowa i wygrzewanie (24–72 h pod obciążeniem i w temperaturze)	usuwa wczesne uszkodzenia, zanim dotrą do zadania
Wartość bazowa DDM na linię w pierwszym dniu	zamienia dokładność bezwzględną (±3 dB) w precyzyjne delty
Utrzymuj moduły < 60 °C — przepływ powietrza, poprawnie dobrany OSFP z użebrowaniem/płaski, brak zablokowanych wlotów	żywotność podwaja się na każde −10 °C
Czyść każde złącze przy każdym połączeniu; zaślepki na nieużywanych portach	większość migotań to brud
Aktualność firmware modułów i hostów	poprawki interoperacyjności CMIS (Problemy z CMIS)
Jednorodna, zwalidowana optyka w każdej warstwie	mniej niespodzianek interoperacyjności DSP host/moduł
Zapas wygrzany i z wartością bazową, 3–5 %	wymiana bez drugiego incydentu
Cotygodniowy przegląd trendów	wymieniaj starzejące się lasery planowo, nie po awarii

Dokąd zmierza technologia

Wyższe szybkości na linię (200G/linię, 1,6T) jeszcze bardziej ściskają zapas; optyka liniowa (LPO) i optyka co-packaged usuwają DSP i jego monitorowanie — przenosząc widoczność BER na hosta — obiecując przy tym mniej komponentów i mniej ciepła (Modulacja i DSP, Optyka w AI). Niezależnie od modułu, dyscyplina pozostaje ta sama: wartość bazowa, monitorowanie delt, działanie na podstawie trendów.

W CodingBox

CodingBox to koniec tej pętli na stanowisku: odczyty kontroli wejściowej i wygrzewania, wartości bazowe na linię z pierwszego dnia przechowywane pod numerem seryjnym w code database, oraz odczyty pośmiertne wyjętych modułów — dane identyfikacyjne, firmware, sumy kontrolne i DDM porównane z ich własną historią — dzięki czemu decyzje o RMA opierają się na danych, a nie na ostatniej linii logu portu.

Jeśli znajdziesz nieścisłość lub błąd w tym materiale, zaznacz odpowiedni fragment i naciśnij Ctrl+Enter, aby .