Řešení poruch v AI clusterech: co se opravdu rozbije a jak to obnovit

Distribuovaný trénink je jediný workload, kde hardwarové poruchy nejsou vzácnou nepříjemností — jsou provozní daní, kterou platíte průběžně. Publikovaný post-mortem Llama 3.1 405B od Mety zaznamenává 419 neočekávaných přerušení za 54 dní na clusteru s 16,384 GPU: jedna událost každé tři hodiny, přičemž zhruba polovinu měly na svědomí poruchy GPU a HBM. Taková je ustálená realita tvrdého provozu tisíců GPU.

Většina zákazníků Kentina na čísla tohoto řádu nikdy nenarazí. Doladění na jednom uzlu s 8 GPU je statisticky klidná záležitost. Režimy selhání, diagnostické nástroje i postupy obnovy jsou ale stejné. Tento článek je poctivým katalogem: co selhává, jak si toho všimnete, co s tím uděláte a kam se v našem měřítku vyplatí investovat inženýrské úsilí.

Skutečné režimy selhání

Záleží na dvou kategoriích — hardwarové události (GPU, zdroj, síťová karta nebo disk udělají něco fyzického) a softwarové události (CUDA, NCCL, framework či operační systém zareagují špatně na krátkodobý výpadek). Níže jsou seřazené zhruba podle toho, jak často na multi-GPU workstationu nebo malém clusteru kousnou.

Chyby XID na GPU

Zdrojem pravdy jsou logy jádra (dmesg, journalctl -k). NVIDIA vypíše řádek XID při jakékoli poruše GPU. Ty, se kterými se reálně setkáte:

Dvě poznámky ze zkušenosti:

• XID 79 je ten, kvůli kterému zákazníci volají v panice. „GPU zmizelo.“ U sestav se 4× nebo 8× riserem je XID 79 téměř vždy problém PCIe riseru, napájecí konektor, který se uvolnil při teplotním cyklování, nebo tepelné vypnutí — nikoli mrtvé GPU. Než budete řešit reklamaci, přesaďte kartu, překabelujte a otestujte znovu.
• XID 48 a 63 jsou skutečné. Vady ECC se u intenzivně vytěžovaných karet objevují v řádu měsíců. GPU vyřazuje stránky automaticky, dokud mu nedojdou záložní řádky. Poté už karta není pro trénink bezpečná; většina provozovatelů ji vymění.

Vyčerpání paměti CUDA uprostřed běhu

Jednoznačně nejčastější selhání tréninku na našem hardwaru — a téměř vždy je to chyba obsluhy, nikoli hardwaru. Typický průběh: trénink běží v pořádku 200 kroků a pak spadne s hláškou CUDA error: out of memory. Příčina bývá:

1. Paměť aktivací roste s délkou sekvence — delší vzorky v pozdější fázi epochy rozpočet přetáhnou.
2. Souběžný proces na stejném GPU. nvidia-smi ukazuje dva PID; jeden z nich měl být ukončen a nebyl.
3. Fragmentace paměti. Cachovací alokátor PyTorche odmítne velký souvislý blok i při dostatku volné paměti. Řešení: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Zdvojnásobení GPU nepomůže. Správná odpověď je zmenšit mikro-dávku, zapnout gradient checkpointing nebo rozdělit optimalizátor (viz K02).

Timeouty NCCL a výpadky sítě

Kolektivní operace NCCL (all_reduce, all_gather, reduce_scatter) jsou synchronní napříč všemi ranky. Pokud se jeden rank zasekne — vadná síťová karta, zahlcený switch, zaškobrtnutí plánovače jádra, jediné pomalé GPU — všechny ostatní ranky čekají u další kolektivní operace a celá úloha se zablokuje. Bez asynchronního zpracování chyb je zaseknutí tiché; úloha vypadá, že „visí“, dokud se nespustí watchdog timeout (ve výchozím nastavení 30 minut).

Řešením je jediná proměnná prostředí:

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

PyTorch pak při vypršení kolektivní operace skončí signálem SIGABRT. Ve spojení s torchelastic se úloha restartuje z posledního checkpointu. Pozn.: starší NCCL_ASYNC_ERROR_HANDLING je zastaralá.

Odpojení uzlu a selhání zdroje

V clusterech s více uzly může uzel vypadnout kvůli resetu síťové karty, zakolísání portu na switchi, panice jádra, zásahu OOM killeru nebo události v napájení. Detekce je stejná jako u timeoutu NCCL. Pro sestavy s jedním uzlem a 8 GPU — což je většina našich zákazníků — tato kategorie neplatí.

Mrtvý zdroj je tvrdé selhání. U serveru s 8 GPU a dvojicí ATX zdrojů v konfiguraci split-rail selhání zdroje neznamená redundanci. Zdroj A napájí GPU 0–3, zdroj B napájí GPU 4–7. Ztratíte-li zdroj B, čtyři GPU během milisekund zmizí s XID 79. Obnova znamená fyzickou výměnu. Skutečná redundance vyžaduje jednotky CRPS v režimu 1+1 hot-swap, což je serverová sestava, ne workstation se spotřebními GPU.

Selhání zápisu na úložiště při checkpointu

Méně časté, ale bolestivé. Úloha běží deset hodin, dojde ke checkpointu a zápis selže, protože je NFS server plný, lokální NVMe překročilo svou DWPD alokaci a přechází do režimu jen pro čtení, byl vyčerpán limit inodů nebo se změnila oprávnění. Škoda je úměrná intervalu checkpointů; pokud to odhalíte až při dalším pokusu, můžete přijít o hodinu i více.

Pomalé úniky ECC

Tichý zabiják. GPU začne hlásit XID 92 (jednobitová chyba ECC) jednou týdně, pak denně, pak každou hodinu. Každá událost je „zachycená“ a úloha běží dál, jenže přesnost se rozjíždí a trénovací ztráta začne pomalu stoupat. Než si toho někdo všimne, jsou vyřazeny stovky stránek a karta míří k XID 48. Právě proto je kapitola o monitoringu důležitější než ta o obnově.

Detekce — co sledovat

Tři vrstvy: úroveň jádra (řádky XID v dmesg), vrstva výrobce GPU (DCGM exportér do Promethea, dcgmi diag pro aktivní kontroly) a úroveň frameworku (watchdog PyTorche, trasovací buffer NCCL, alerty na ztrátu a propustnost).

Alerty, na kterých záleží:

• Jakýkoli řádek XID 48 / 63 / 79 / 92 v dmesg → okamžitý alert
• Teplota GPU > 85 °C déle než 5 minut → okamžitý alert
• Rostoucí počet volatilních chyb ECC → tiket, ne okamžitý alert
• DCGM dcgm_thermal_violation nenulové → problém s chlazením, zkontrolujte proudění vzduchu
• Trénovací ztráta neklesá déle než >100 kroků → stojí za prověření

Ukázky reálných logů selhání

Co reálně uvidíte v journalctl -k, když se spustí XID 79 (RTX 5090, riser kabel uvolněný teplotním cyklováním):

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á timeout NCCL, zkráceně:

[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 rank 3, jenže rank 3 téměř nikdy není skutečným problémem. Pomalý rank je ten, který nedorazil. Trasovací buffer NCCL vypíše, které ranky byly zablokované u kterého volání — tak najdete skutečného viníka.

Postupy obnovy

Dělejte checkpointy tak často, aby byl restart levný

Pro doladění modelu 7B na 8× RTX 5090 s checkpointy na lokálním NVMe: ~14 GB zapsaných rychlostí ~3 GB/s ≈ 5 s na checkpoint, což při intervalu 30 minut dělá 0.3% režie a nejhorší možná ztráta je 15 minut. Pro sharded FSDP checkpoint modelu 70B na téže skříni: ~140 GB rozdělených paralelně mezi 8 GPU, podobná režie. Je to levné, dělejte to.

Kompletní checkpoint z předtrénování Llama-70B přes síťové úložiště má ~520 GB a může trvat přes 20 minut; právě tam firmy velikosti Mety nasazují asynchronní vrstvené checkpointování (rychlý lokální zápis, pomalé odtékání do trvalého úložiště). V měřítku Kentina: checkpoint každých 15–30 minut na lokální NVMe a synchronizace na NAS po skončení běhu. Cokoli složitějšího je zbytečné přeinženýrování.

Automatický restart pomocí torchelastic

torchrun podporuje elastický trénink rovnou 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 vypadá řetězec takto: kolektivní operace NCCL se zasekne → watchdog PyTorche vyvolá výjimku → proces skončí signálem SIGABRT → torchelastic ukončí sourozenecké ranky a restartuje z latest_checkpoint.pt. Celá sekvence obvykle trvá 60–120 sekund. Krátkodobé výpadky systém přejde. Trvalá porucha (GPU odešlo s XID 79) vyčerpá rozpočet --max-restarts a pak už do hry vstupuje člověk.

Provozní praxe

Největší pákou na náklady selhání není kód pro obnovu — je to to, co uděláte předtím, než úloha vůbec začne.

Předletové kontroly

Než spustíte cokoli, co poběží déle než pár hodin, projděte validační 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 by se all_reduce_perf měl podle topologie PCIe pohybovat v pásmu 50–80 GB/s propustnosti sběrnice. Výrazně nižší hodnota znamená problém s riserem nebo topologií — vyřešte jej před tréninkem. U každé sestavy, která odchází z Kentina, pouštíme gpu-burn na celou hodinu jako součást předexpediční kontroly kvality.

Hlídejte pomalé úniky

Reálné kódové báze si paměť kumulují: logovací hook drží referenci na tensor, výjimková větev zapomene vyčistit buffer, LR scheduler nechá uniknout closure. Výsledkem je OOM v kroku 5000 z 10000krokového běhu. Nejlevnější obrana: vypisujte do trénovacího logu každých N kroků torch.cuda.memory_allocated(). Pokud hodnota roste, něco je špatně.

Statistická realita v měřítku Kentina

Tady je poctivost ohledně velikosti zásadní. Četnost selhání škáluje s GPU-hodinami; velké clustery selhávají neustále, protože mají mnoho GPU běžících mnoho hodin.

Odhady jsou kalibrované podle dat Mety (jedno selhání na ~50,000 pozorovaných GPU hodin). Reálná čísla se liší podle modelu GPU — spotřební 4090 a 5090 na riserech selhávají častěji než datacentrové L40s ve svém nativním šasi, zejména kvůli opotřebení PCIe a napájecích konektorů.

Shrnutí: v měřítku jednoho uzlu s 8 GPU počítejte s jednou hardwarovou událostí za rok intenzivního provozu, ne za týden. Většina doladění proběhne, aniž byste jedinou zaznamenali. Zákazníci, kteří je vidí, trénují nepřetržitě — a dominantním režimem selhání je strana riserů a zdrojů, nikoli křemík GPU.

Cena jednoho restartu

Cena restartu je ztracený čas tréninku plus čas inženýra na diagnostiku. U sestavy s 8× RTX 5090 amortizované řekněme na 300 € denně stojí dalších 30 minut 6 €. Čas inženýra na diagnostiku, přesazení kabelu a nové spuštění jsou jedna až tři hodiny. Ztráta výpočetního výkonu je zaokrouhlovací chyba; nákladem je práce. Právě proto je správnou investicí monitoring a předletová kontrola, ne exotická infrastruktura pro obnovu.

Většina obsahu o řešení poruch na internetu je psaná pro hyperscale vrstvu. V měřítku Kentina je většina z toho přeinženýrovaná. Pravidlo 80/20 zní: sledujte logy jádra, dělejte checkpointy na lokální NVMe, nastavte TORCH_NCCL_ASYNC_ERROR_HANDLING=1 a před velkými úlohami pouštějte gpu-burn.

---

Toto je součást Kentino Wiki, referenční série o AI výpočetním výkonu, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.