Ošetření selhání v klastrech AI: Co se skutečně porouchá a jak se z toho zotavit

Distribuované školení je jedinou pracovní zátěží, kde selhání hardwaru nejsou vzácnou nepříjemností – jsou provozní daní, kterou platíte nepřetržitě. Meta ve svém pozdější analýze Llama 3.1 405B zaznamenala 419 neočekávaných přerušení během 54 dnů na clusteru s 16 384 GPU: jednu událost každé tři hodiny, přičemž zhruba polovinu z nich představují chyby GPU a HBM. To je ustálený stav při náročném provozu tisíců GPU.

Většina zákazníků Kentina se s takovými čísly nikdy nesetká. Jemné ladění 8GPU s jedním uzlem je statisticky tiché. Ale režimy selhání, diagnostické nástroje a vzorce obnovy jsou stejné. Tento článek je poctivým katalogem: co selhává, jak si toho všimnete, co s tím děláte a kde se v našem měřítku inženýrské úsilí skutečně vyplatí.

Skutečné režimy selhání

Důležité jsou dvě kategorie – hardwarové události (GPU, PSU, NIC, disk provádí nějakou fyzickou akci) a softwarové události (CUDA, NCCL, framework, operační systém reaguje špatně na přechodové jevy). Níže je uvedeno zhruba, jak často se každá z nich projevuje na pracovní stanici s více GPU nebo v malém clusteru.

Chyby XID GPU

Protokoly jádra (dmesg, journalctl -k) jsou zdrojem pravdy. NVIDIA při jakékoli chybě GPU vygeneruje řádek XID. Ty, které skutečně vidíte:

Dvě poznámky z vlastní zkušenosti:

• Zákazníci panikaří kvůli XID 79. „GPU zmizela.“ U sestavy s 4× nebo 8× riser je XID 79 téměř vždy problém s riserem PCIe, napájecím konektorem, který se odpojil při teplotních cyklech, nebo tepelným vypnutím – neznamená to nefunkční GPU. Před RMA znovu usaďte, znovu zapojte kabel a znovu otestujte.
• XID 48 a 63 jsou skutečné. Vady ECC se u intenzivně používaných karet objevují v průběhu měsíců. GPU automaticky vyřazuje stránky, dokud nedojde volné řádky. Poté je karta pro trénování nebezpečná; většina operátorů ji vymění.

Nedostatek paměti v CUDA uprostřed běhu

Nejčastější chyba trénování na našem hardwaru a téměř vždy chyba operátora, nikoli hardwaru. Typický vzorec: trénování probíhá bez problémů po dobu 200 kroků, poté se zhroutí s... CUDA error: out of memoryPříčinou je obvykle:

1. Aktivační paměť roste s délkou sekvence — delší vzorky později v epoše překračují rozpočet.
2. Partnerský proces na stejném GPU. nvidia-smi zobrazuje dva PIDy; jeden měl být ukončen, ale nebyl.
3. Fragmentace paměti. Alokátor mezipaměti v PyTorchu odmítá velký souvislý blok i s dostatečnou volnou pamětí. Oprava: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Zdvojnásobení výkonu GPU nepomůže. Správnou odpovědí je snížení velikosti mikrodávek, povolení gradientního kontrolního bodování nebo shardování optimalizátoru (viz K02).

Časové limity NCCL a síťové závady

Kolektivy NCCL (all_reduce, all_gather, reduce_scatter) jsou synchronní napříč všemi ranky. Pokud se jedna rank zastaví – vadná síťová karta, přetížený přepínač, závada plánovače jádra, pomalá jedna grafická karta – každá další rank čeká na další kolektiv a celá úloha se zablokuje. Bez asynchronní úpravy chyb je zastavení tiché; úloha se zdá být „zaseknutá“, dokud nedojde k vypršení časového limitu watchdogu (výchozí hodnota je 30 minut).

Oprava spočívá v jedné proměnné prostředí:

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

PyTorch poté přeruší s příkazem SIGABRT na kolektivu s vypršeným časovým limitem. V kombinaci s torchelastic se úloha restartuje od posledního kontrolního bodu. Poznámka: starší NCCL_ASYNC_ERROR_HANDLING je zastaralé.

Odpojení uzlu a selhání zdroje napájení

Na víceuzlových clusterech může uzel vypadnout z důvodu resetu síťové karty, výpadku portu přepínače, paniky jádra, zásahu OOM-killer nebo události napájení. Detekce je stejná jako u časového limitu NCCL. Pro sestavení s jedním uzlem a 8 GPU – většina našich zákazníků – se tato kategorie nepoužije.

Mrtvý zdroj je vážná chyba. Na serveru s 8 grafickými kartami a duální ATX zdroje v konfiguraci s dělenými lištami, selhání zdroje napájení ne Stejná redundance. Zdroj PSU A napájí GPU 0–3, zdroj PSU B napájí GPU 4–7. Při ztrátě zdroje PSU B se čtyři GPU během milisekund ztratí na hodnotě XID 79. Obnova znamená fyzickou výměnu. Skutečná redundance vyžaduje jednotky CRPS v konfiguraci 1+1 s možností výměny za provozu, což je sestava serverové třídy, nikoli pracovní stanice s GPU pro spotřebitele.

Chyby zápisu do úložiště během kontrolního bodu

Méně časté, ale bolestivé. Úloha běží deset hodin, dosáhne kontrolního bodu a zápis selže, protože NFS server je plný, lokální NVMe překročil alokaci DWPD a přechází do režimu pouze pro čtení, byl dosažen limit inode nebo byla změněna oprávnění. Poškození je úměrné intervalu kontrolních bodů; pokud to zachytíte pouze na další pokusem můžete ztratit hodinu nebo i více.

Pomalé úniky ECC

Tichý zabiják. GPU začne vysílat XID 92 (jednobitový ECC) jednou týdně, poté denně a nakonec každou hodinu. Každá událost je „zadržena“ a úloha pokračuje v běhu, ale přesnost se snižuje a ztráta trénování pomalu vede k vzestupnému trendu. Než si toho někdo všimne, stovky stránek jsou vyřazeny a karta směřuje k XID 48. Proto je monitorovací sekce důležitější než sekce obnovy.

Detekce – na co se dívat

Tři vrstvy: úroveň jádra (řádky XID v dmesg), dodavatel GPU (exportér DCGM do Prometheusu, dcgmi diag pro aktivní kontroly) a na úrovni frameworku (watchdog PyTorch, vyrovnávací paměť trasování NCCL, upozornění na ztrátu/propustnost).

Důležitá upozornění:

• Žádný XID 48 / 63 / 79 / 92 řádek v dmesg → stránka
• Teplota GPU > 85 °C po dobu delší než 5 minut → strana
• Zvyšování počtu volatilních chyb ECC → tiket, nikoli stránka
• DCGM dcgm_thermal_violation nenulové → problém s chlazením, zkontrolujte proudění vzduchu
• Tréninková ztráta se nesnižuje po více než 100 krocích → stojí za to se podívat

Příklady skutečných protokolů selhání

Co ve skutečnosti vidíte v journalctl -k když se aktivuje XID 79 (RTX 5090, stoupající kabel se v důsledku tepelného cyklování vymrštil):

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.

Jak vypadá zkráceně č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ásí to 3. místo, ale 3. místo téměř nikdy není skutečným problémem. Pomalé místo je to, které nedorazilo. Vyrovnávací paměť trasování NCCL ukládá, které místa byla blokována při kterém volání – takhle najdete skutečného viníka.

Vzory zotavení

Kontrolujte dostatečně často, aby byl restart levný

Pro 7B jemné ladění na 8× RTX 5090 s lokálními NVMe kontrolními body: ~14 GB zapsaných rychlostí ~3 GB/s ≈ 5 s na kontrolní bod, každých 30 minut je 0.3% režie a ztráta v nejhorším případě je 15 minut. Pro 70B FSDP segmentovaný kontrolní bod na stejném hardwaru: ~140 GB segmentovaných na 8 GPU paralelně, podobná režie. Levné, udělej to.

Kompletní kontrolní bod před trénováním Llama-70B přes síťové úložiště běží o velikosti ~520 GB a může trvat 20+ minut; právě zde obchody třídy Meta zavádějí asynchronní stupňovité kontrolní body (rychlý lokální zápis, pomalé vypouštění do trvalého úložiště). U velikosti Kentina: kontrolní bod každých 15–30 minut do lokálního NVMe, synchronizace do NAS na konci běhu. Cokoli propracovanějšího je přehnané inženýrství.

Automatický restart s torchelastic

torchrun podporuje elastický trénink ihned 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, řetězec je: NCCL kolektiv se zasekne → PyTorch watchdog aktivuje → proces se přeruší pomocí SIGABRT → torchelastic ukončí sourozenecké pozice a restartuje od latest_checkpoint.ptCelková doba sekvence je obvykle 60–120 sekund. Přerušované záblesky se objevují. Trvalá chyba (GPU přešla na XID 79) spálí procesor. --max-restarts rozpočet a poté je v procesu zapojení člověk.

Provozní praxe

Největším faktorem ovlivňujícím náklady na selhání není kód pro obnovení – je to to, co děláte. před práce začíná.

Předletové kontroly

Před spuštěním čehokoli, co bude běžet déle než několik hodin, spusťte ověřovací sekvenci:

# 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 čistém serveru s 8× RTX 5090, all_reduce_perf Měla by se pohybovat v rozmezí šířky pásma sběrnice 50–80 GB/s v závislosti na topologii PCIe. Výrazně nižší hodnota znamená problém s rozšiřujícím modulem nebo topologií – opravte ho před trénováním. V rámci předběžného testování kvality (PQA) na každé sestavě, která opouští Kentino, spouštíme gpu-burn po dobu celé hodiny.

Dávejte pozor na pomalé úniky

Reálné kódové základny hromadí paměť: logovací hook uchovává referenci tenzoru, cesta k výjimce zapomene vymazat buffer, plánovač LR uvolní uzávěr. Výsledkem je OOM v kroku 5000 z běhu o 10 000 krocích. Nejlevnější zmírnění: print torch.cuda.memory_allocated() každých N kroků do trénovacího logu. Pokud roste, nemělo by to tak být.

Statistická realita v měřítku Kentina

A tady záleží na upřímnosti ohledně velikosti. Míra selhání se zvyšuje s počtem hodin GPU; velké clustery selhávají neustále, protože v nich běží mnoho GPU po mnoho hodin.

Odhady kalibrované podle metadat (jedno selhání na přibližně 50 000 pozorovaných hodin GPU). Skutečná čísla se liší podle modelu GPU – spotřebitelské grafické karty 4090 a 5090 s rozšiřujícími kartami selhávají častěji než datové karty L40 v nativních šasi, zejména kvůli opotřebení PCIe a napájecích konektorů.

Poučení: v měřítku s jedním uzlem a 8 GPU počítejte s jednou hardwarovou událostí za rok intenzivního používání, nikoli za týden. Většina jemných ladění se provede bez jakýchkoli problémů. Zákazníci, kteří je zaznamenají, provádějí nepřetržité školení a dominantním typem selhání je strana rozšiřující karty/napájecího zdroje, nikoli křemík GPU.

Cena restartu

Náklady na restart se skládají z ztráty času na školení plus času diagnostického technika. U sestavy s 8× RTX 5090, která stojí řekněme 300 EUR/den s amortizací, je dalších 30 minut 6 EUR. Čas technika na diagnostiku, opětovné zapojení kabelu a restart je jedna až tři hodiny. Ztráta výpočetních prostředků je způsobena zaokrouhlovací chybou; náklady jsou náklady na práci. Proto je správnou investicí monitorování a předběžná příprava, nikoli exotická infrastruktura pro obnovu.

Většina online obsahu o ošetřování selhání je napsána pro hyperscale vrstvu. U Kentina je většina obsahu přehnaně náročná. Pravidlo 80/20 je: monitorování protokolů jádra, kontrolní bod pro lokální NVMe, nastavení... TORCH_NCCL_ASYNC_ERROR_HANDLING=1Před velkými úlohami spusťte gpu-burn.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.