Riešenie porúch v klastroch umelej inteligencie: Čo sa vlastne pokazí a ako to zotaviť

Distribuované školenie je jediná pracovná záťaž, kde zlyhania hardvéru nie sú zriedkavou nepríjemnosťou – sú to prevádzkové dane, ktoré platíte nepretržite. Meta v štúdii Llama 3.1 405B zaznamenala 419 neočakávaných prerušení počas 54 dní na klastri so 16 384 GPU: jednu udalosť každé tri hodiny, pričom chyby GPU a HBM sú zodpovedné za zhruba polovicu. To je ustálený stav prevádzky tisícok GPU v náročnom stave.

Väčšina zákazníkov Kentina takéto čísla nikdy neuvidí. Jemné doladenie 8-GPU s jedným uzlom je štatisticky tiché. Ale režimy zlyhania, diagnostické nástroje a vzory obnovy sú rovnaké. Tento článok je úprimným katalógom: čo zlyháva, ako si to všimnete, čo s tým urobíte a kde sa inžinierske úsilie v našom meradle skutočne oplatí.

Skutočné režimy zlyhania

Dôležité sú dve kategórie – hardvérové ​​udalosti (GPU, zdroj, sieťová karta, disk vykonáva fyzickú činnosť) a softvérové ​​udalosti (CUDA, NCCL, framework, operačný systém reaguje zle na prechodový jav). Nižšie je uvedené zhruba poradie toho, ako často každá z nich narúša prácu na pracovnej stanici s viacerými GPU alebo v malom klastri.

Chyby GPU XID

Záznamy jadra (dmesg, journalctl -k) sú zdrojom pravdy. NVIDIA pri každej chybe GPU vygeneruje riadok XID. Tie, ktoré skutočne vidíte:

Dve poznámky zo skúsenosti:

• Zákazníci volajú kvôli XID 79. „GPU zmizla.“ Pri zostave s rozširujúcou kartou 4× alebo 8× je XID 79 takmer vždy problémom s rozširujúcou kartou PCIe, napájacím konektorom, ktorý sa vypol pri teplotných cykloch, alebo tepelným vypnutím – nie nefunkčnou grafickou kartou. Pred RMA ju znova osadte, prepojte káble a znova otestujte.
• XID 48 a 63 sú skutočné. Chyby ECC sa na intenzívne používaných kartách objavujú v priebehu mesiacov. GPU automaticky vyraďuje stránky, kým sa mu neminú voľné riadky. Potom už karta nie je bezpečná na trénovanie; väčšina operátorov ju vymení.

Nedostatok pamäte CUDA počas behu

Najčastejšia chyba trénovania na našom hardvéri a takmer vždy chyba operátora, nie hardvéru. Typický vzorec: trénovanie prebieha bez problémov 200 krokov, potom havaruje s CUDA error: out of memoryPríčinou je zvyčajne:

1. Aktivačná pamäť rastie s dĺžkou sekvencie — dlhšie vzorky neskôr v epoche premrhajú rozpočet.
2. Partnerský proces na tej istej grafickej karte. nvidia-smi zobrazuje dva PID; jeden mal byť ukončený, ale nebol.
3. Fragmentácia pamäte. Alokátor vyrovnávacej pamäte v PyTorch odmieta veľký súvislý blok aj s dostatočnou voľnou pamäťou. Oprava: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Zdvojnásobenie GPU nepomôže. Správnou odpoveďou je zníženie veľkosti mikrodávok, povolenie gradientového kontrolného bodovania alebo rozdelenie optimalizátora (pozri K02).

Časové limity NCCL a sieťové chyby

kolektívy NCCL (all_reduce, all_gather, reduce_scatter) sú synchrónne vo všetkých radoch. Ak sa jeden rad zastaví – chybná sieťová karta, preťažený prepínač, problém s plánovačom jadra, jedna pomalá grafická karta – každý ďalší rad čaká na ďalší kolektív a celá úloha sa zablokuje. Bez asynchrónneho spracovania chýb je zastavenie tiché; úloha sa javí ako „zaseknutá“, kým sa nespustí časový limit watchdogu (predvolene 30 minút).

Oprava spočíva v jednej premennej prostredia:

export TORCH_NCCL_ASYNC_ERROR_HANDLING=1
export TORCH_NCCL_TRACE_BUFFER_SIZE=20000  # for post-mortem analysis

PyTorch potom preruší s SIGABRT na kolektíve s vypršaným časovým limitom. V kombinácii s torchelastic sa úloha reštartuje od posledného kontrolného bodu. Poznámka: staršie NCCL_ASYNC_ERROR_HANDLING je zastarané.

Odpojenie uzla a poruchy zdroja

Na viacuzlových klastroch môže uzol vypadnúť z dôvodu resetu sieťovej karty, výpadku portu prepínača, paniky jadra, zásahu OOM-killer alebo udalosti napájania. Detekcia je rovnaká ako pri časovom limite NCCL. Pre zostavy s jedným uzlom a 8 GPU – väčšina našich zákazníkov – sa táto kategória neuplatňuje.

Nefunkčný zdroj je vážna porucha. Na serveri s 8 grafickými procesormi a duálne ATX zdroje v konfigurácii s delenými koľajnicami, porucha zdroja nie rovnaká redundancia. Zdroj PSU A napája GPU 0–3, zdroj PSU B napája GPU 4–7. Výpadok zdroja PSU B a štyri GPU zmiznú na XID 79 v priebehu milisekúnd. Obnova znamená fyzickú výmenu. Skutočná redundancia vyžaduje jednotky CRPS v režime 1+1 hot-swap, čo je zostava serverovej triedy, nie pracovná stanica so spotrebiteľskou GPU.

Zlyhania zápisu do úložiska počas kontrolného bodu

Menej časté, ale bolestivé. Úloha beží desať hodín, dosiahne kontrolný bod a zápis zlyhá, pretože NFS server je plný, lokálny NVMe prekročil svoju alokáciu DWPD a prechádza do režimu iba na čítanie, bol dosiahnutý limit inódov alebo boli zmenené povolenia. Poškodenie je úmerné intervalu kontrolných bodov; ak ho zachytíte iba na ďalšie pokusom môžete stratiť hodinu alebo viac.

Pomalé úniky ECC

Tichý zabijak. GPU začne vysielať XID 92 (jednobitový ECC) raz týždenne, potom denne a nakoniec každú hodinu. Každá udalosť je „zadržaná“ a úloha pokračuje, ale presnosť sa znižuje a strata tréningu pomaly smeruje nahor. Kým si to niekto všimne, stovky stránok sú už vyradené z prevádzky a karta smeruje k XID 48. Preto je monitorovacia sekcia dôležitejšia ako sekcia obnovy.

Detekcia – na čo sa pozerať

Tri vrstvy: úroveň jadra (riadky XID v dmesg), dodávateľ GPU (exportér DCGM do Prometheus, dcgmi diag pre aktívne kontroly) a na úrovni frameworku (watchdog PyTorch, vyrovnávacia pamäť sledovania NCCL, upozornenia na stratu/priepustnosť).

Dôležité upozornenia:

• Každý XID 48 / 63 / 79 / 92 riadok v dmesg → strana
• Teplota GPU > 85 °C dlhšie ako 5 minút → strana
• Zvyšovanie počtu volatilných chýb ECC → tiket, nie stránka
• DCGM dcgm_thermal_violation nenulové → problém s chladením, skontrolujte prietok vzduchu
• Tréningová strata sa neznižuje po viac ako 100 krokoch → stojí za to pozrieť

Príklady reálnych protokolov zlyhaní

Čo v skutočnosti vidíte v journalctl -k keď sa aktivuje XID 79 (RTX 5090, kábel riser sa vycúval v dôsledku tepelného cyklovania):

Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: Xid (PCI:0000:c1:00): 79, pid='<unknown>', name=<unknown>, GPU has fallen off the bus.
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: GPU 0000:c1:00.0: GPU is on Board .
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: A GPU crash dump has been created. If possible, please run
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: nvidia-bug-report.sh as root to collect this data before
Apr 22 03:14:17 kentino-ai-04 kernel: NVRM: the NVIDIA kernel module is unloaded.

Ako vyzerá skrátený časový limit NCCL:

[E ProcessGroupNCCL.cpp:475] [Rank 3] Watchdog caught collective operation timeout:
WorkNCCL(SeqNum=842, OpType=ALLREDUCE, NumelIn=268435456, NumelOut=268435456,
Timeout(ms)=1800000) ran for 1800321 milliseconds before timing out.
[E ProcessGroupNCCL.cpp:489] [Rank 3] Some NCCL operations have failed or timed out.
terminate called after throwing an instance of 'std::runtime_error'

Hlási to poradie 3, ale poradie 3 takmer nikdy nie je skutočným problémom. Pomalé poradie je to, ktoré nedorazilo. Vyrovnávacia pamäť sledovania NCCL ukladá, ktoré poradia boli blokované pri ktorom volaní – takto nájdete skutočného vinníka.

Vzory zotavenia

Kontrolujte dostatočne často, aby bol reštart lacný

Pre 7B jemné doladenie na 8× RTX 5090 s lokálnymi NVMe kontrolnými bodmi: ~14 GB zapísaných rýchlosťou ~3 GB/s ≈ 5 s na kontrolný bod, každých 30 minút je to 0.3 % réžia a strata v najhoršom prípade je 15 minút. Pre 70B FSDP segmentovaný kontrolný bod na tom istom zariadení: ~140 GB rozdelených na 8 GPU paralelne, podobná réžia. Lacné, urob to.

Kompletný predtréningový kontrolný bod Llama-70B cez sieťové úložisko beží na približne 520 GB a môže trvať viac ako 20 minút; práve tu obchody triedy Meta zavádzajú asynchrónne stupňovité kontrolné body (rýchly lokálny zápis, pomalé vyprázdňovanie do trvalého úložiska). Pri veľkosti Kentina: kontrolný bod každých 15–30 minút do lokálneho NVMe, synchronizácia do NAS na konci behu. Čokoľvek prepracovanejšie je prehnané inžinierstvo.

Automatický reštart s torchelastic

torchrun podporuje elastický tréning hneď po vybalení z krabice:

torchrun \
    --nnodes=1:1 \
    --nproc-per-node=8 \
    --max-restarts=3 \
    --rdzv-backend=c10d \
    --rdzv-endpoint=localhost:29500 \
    train.py --checkpoint-dir /mnt/nvme/ckpt

s TORCH_NCCL_ASYNC_ERROR_HANDLING=1, reťazec je: NCCL kolektív sa zasekne → PyTorch watchdog vyvolá → proces sa predčasne ukončí pomocou SIGABRT → torchelastic ukončí súrodenecké ranky a reštartuje od latest_checkpoint.ptCelková sekvencia trvá zvyčajne 60 – 120 sekúnd. Prechodné záblesky sa vyskytujú. Trvalá chyba (GPU prešla na XID 79) spáli... --max-restarts rozpočet a potom je v procese zapojený človek.

Prevádzková prax

Najväčším faktorom ovplyvňujúcim náklady na zlyhanie nie je kód obnovy – je to to, čo robíte pred práca začína.

Predletové kontroly

Pred spustením čohokoľvek, čo bude bežať dlhšie ako niekoľko hodín, spustite overovaciu sekvenciu:

# 1. Per-GPU stress test — catches silent thermal/ECC issues
gpu-burn 600                        # 10 minutes per GPU at full load

# 2. DCGM diagnostic — finds latent hardware faults
sudo dcgmi diag -r 3                # level 3 = thorough, ~15 min

# 3. NCCL fabric test — validates inter-GPU bandwidth on the box
mpirun -np 8 ./build/all_reduce_perf -b 8 -e 1G -f 2 -g 1

# 4. PyTorch dry-run — one step, full batch size, all ranks
torchrun --nproc-per-node=8 dryrun.py

Na čistom serveri s 8× RTX 5090, all_reduce_perf by sa mala pohybovať v rozsahu šírky pásma zbernice 50 – 80 GB/s v závislosti od topológie PCIe. Výrazne nižšia hodnota znamená problém s rozširujúcou platformou alebo topológiou – opravte ho pred tréningom. Ako súčasť predbežného testovania kvality na každej zostave, ktorá opúšťa Kentino, spúšťame gpu-burn celú hodinu.

Dávajte si pozor na pomalé úniky

Reálne kódové bázy akumulujú pamäť: hook logovania obsahuje referenciu tenzora, cesta výnimky zabudne vymazať vyrovnávaciu pamäť, plánovač LR unikne uzáver. Výsledkom je OOM v kroku 5000 z 10 000-krokového behu. Najlacnejšie zmiernenie: print torch.cuda.memory_allocated() každých N krokov do tréningového denníka. Ak rastie, nemalo by to tak byť.

Štatistická realita na úrovni Kentina

Tu je dôležité byť úprimný ohľadom veľkosti. Miera zlyhania sa zvyšuje s počtom hodín načítania grafických kariet (GPU); veľké klastre zlyhávajú neustále, pretože majú veľa GPU spustených mnoho hodín.

Odhady kalibrované podľa metadát (jedno zlyhanie na približne 50 000 pozorovaných hodín GPU). Skutočné čísla sa líšia podľa modelu GPU – spotrebiteľské 4090 a 5090 s rozširujúcimi kartami zlyhávajú častejšie ako dátové L40 v natívnom šasi, najmä kvôli opotrebovaniu PCIe a napájacích konektorov.

Ponaučenie: pri jednom uzle s 8 GPU očakávajte jednu hardvérovú udalosť za rok intenzívneho používania, nie za týždeň. Väčšina jemných doladení sa dokončí bez akýchkoľvek problémov. Zákazníci, ktorí ich zaznamenajú, nepretržite vykonávajú tréning a dominantným režimom poruchy je strana rozširujúcej karty/napájacieho zdroja, nie kremík GPU.

Náklady na reštart

Náklady na reštart sa skladajú z strateného času školenia plus času diagnostického technika. Pri zostave s 8× RTX 5090 za napríklad 300 €/deň s amortizáciou je ďalších 30 minút 6 €. Čas technika na diagnostiku, opätovné umiestnenie kábla a reštartovanie je jedna až tri hodiny. Strata výpočtového výkonu je chyba zaokrúhľovania; práca je nákladom. Preto je správnou investíciou monitorovanie a predbežná príprava, nie exotická infraštruktúra na obnovu.

Väčšina online obsahu o riešení zlyhaní je napísaná pre hyperscale úroveň. Pri veľkosti Kentino je väčšina z toho prehnaná. Pravidlo 80/20 je: monitorovanie protokolov jadra, kontrolný bod pre lokálny NVMe, nastavenie TORCH_NCCL_ASYNC_ERROR_HANDLING=1Pred veľkými úlohami spustite gpu-burn.

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.