Fejlhåndtering i AI-klynger: Hvad der rent faktisk går i stykker, og hvordan man gendanner det

Distribueret træning er den ene arbejdsbyrde, hvor hardwarefejl ikke er en sjælden gene - de er en driftsafgift, du betaler løbende. Metas offentliggjorte Llama 3.1 405B post-mortem registrerer 419 uventede afbrydelser over 54 dage på en klynge med 16,384 GPU'er: én hændelse hver tredje time, hvor GPU- og HBM-fejl er ansvarlige for omtrent halvdelen. Det er den stabile oplevelse af at køre tusindvis af GPU'er på højtryk.

De fleste Kentino-kunder vil aldrig se den slags tal. Finjusteringer af 8 GPU'er på én node er statistisk set stille. Men fejltilstandene, diagnosticeringsværktøjerne og gendannelsesmønstrene er de samme. Denne artikel er det ærlige katalog: hvad der fejler, hvordan du bemærker det, hvad du gør ved det, og hvor den tekniske indsats rent faktisk er det værd i vores skala.

De faktiske fejltilstande

To kategorier er vigtige — hardwarehændelser (GPU, PSU, NIC, disk gør noget fysisk) og softwarehændelser (CUDA, NCCL, frameworket, operativsystemet reagerer dårligt på en transient). Nedenfor er en grov rækkefølge af, hvor ofte hver enkelt bider på en arbejdsstation med flere GPU'er eller en lille klynge.

GPU XID-fejl

Kernelloggene (dmesg, journalctl -k) er kilden til sandheden. NVIDIA udsender en XID-linje ved enhver GPU-fejl. Dem du rent faktisk ser:

To bemærkninger fra erfaring:

• XID 79 er den, kunderne ringer panisk om. "GPU'en forsvandt." På en 4× eller 8× riser-build er XID 79 næsten altid et PCIe-riserproblem, et strømstik, der har brudt under termisk cykling, eller en termisk nedlukning – ikke en død GPU. Genmonter, tilslut kabel igen, test igen før RMA.
• XID 48 og 63 er virkelige. ECC-fejl opstår over måneder på kort, der bruges meget. GPU'en fjerner automatisk sider, indtil den løber tør for ekstra rækker. Derefter er kortet ikke sikkert at bruge til træning; de fleste operatører udskifter det.

CUDA-hukommelsesmangel midt i kørsel

Den mest almindelige træningsfejl på vores hardware, og næsten altid operatørens skyld, ikke hardwarens. Typisk mønster: træningen kører fint i 200 trin, og går derefter ned med CUDA error: out of memoryÅrsagen er normalt:

1. Aktiveringshukommelsen vokser med sekvenslængden — længere prøver senere i epoken sprænger budgettet.
2. En peer-proces på den samme GPU. nvidia-smi viser to PID'er; den ene skulle have været dræbt, men blev det ikke.
3. Hukommelsesfragmentering. PyTorchs caching-allokator afviser en stor sammenhængende blok, selv med tilstrækkelig ledig hukommelse. Rettelse: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Det hjælper ikke at fordoble GPU'en. Det rigtige svar er at reducere mikrobatchstørrelsen, aktivere gradient checkpointing eller sharding af optimeringsværktøjet (se K02).

NCCL timeouts og netværksfejl

NCCL-kollektiver (all_reduce, all_gather, reduce_scatter) er synkrone på tværs af alle ranger. Hvis én rang går i stå — defekt NIC, overbelastet switch, kernel scheduler-fejl, en enkelt langsom GPU — venter alle andre ranger på den næste kollektive funktion, og hele jobbet blokeres. Uden håndtering af asynkron fejl er stopet lydløst; jobbet ser ud til at "hænge", indtil en watchdog-timeout udløses (standard 30 minutter).

Løsningen er én miljøvariabel:

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

PyTorch afbryder derefter med SIGABRT på et timeout-kollektiv. Kombineret med torchelastic genstartes jobbet fra det sidste kontrolpunkt. Bemærk: den ældre NCCL_ASYNC_ERROR_HANDLING er udfaset.

Nodeafbrydelse og strømforsyningsfejl

På klynger med flere noder kan en node falde fra hinanden på grund af en NIC-nulstilling, switchport-flap, kernelpanik, OOM-killer-hit eller strømforsyningshændelse. Detektion er det samme som NCCL-timeout. For 8-GPU-builds med én node – de fleste af vores kunder – gælder denne kategori ikke.

En død strømforsyning er en hård fejl. På en server med 8 GPU'er dobbelte ATX-strømforsyninger i split-rail-konfiguration, en strømforsyningsfejl gør ikke lige stor redundans. Strømforsyning A driver GPU'er 0-3, strømforsyning B driver GPU'er 4-7. Mister man strømforsyning B, forsvinder fire GPU'er til XID 79 inden for millisekunder. Gendannelse betyder fysisk udskiftning. Ægte redundans kræver CRPS-enheder i 1+1 hot-swap, hvilket er en serverklasse-build, ikke en forbruger-GPU-arbejdsstation.

Fejl ved skrivning af lager under kontrolpunkt

Mindre almindeligt, men smertefuldt. Jobbet kører i ti timer, rammer et kontrolpunkt, og skrivningen mislykkes, fordi NFS-serveren er fuld, den lokale NVMe overskrider sin DWPD-allokering og går i skrivebeskyttet tilstand, en inode-grænse blev nået, eller tilladelser blev ændret. Skaden er proportional med kontrolpunktsintervallet; hvis du kun opdager det på næste forsøg kan du miste en time eller mere.

Langsomme ECC-lækager

Den stille dræber. En GPU begynder at udsende XID 92 (single-bit ECC) en gang om ugen, derefter dagligt og derefter time for time. Hver hændelse "indesluttes", og jobbet fortsætter med at køre, men nøjagtigheden forskydes, og træningstabet udvikler en langsom opadgående bias. Når nogen bemærker det, er hundredvis af sider udgået, og kortet er på vej mod XID 48. Derfor er overvågningssektionen vigtigere end gendannelsessektionen.

Detektion — hvad man skal holde øje med

Tre lag: kerneniveau (XID-linjer i dmesg), GPU-leverandør (DCGM-eksportør til Prometheus, dcgmi diag til aktive kontroller) og framework-niveau (PyTorch watchdog, NCCL-sporingsbuffer, advarsler om tab/gennemstrømning).

De vigtige advarsler:

• Enhver XID 48 / 63 / 79 / 92 linje i dmesg → side
• GPU-temperatur > 85 °C i mere end 5 minutter → side
• ECC volatile fejlantal stiger → sag, ikke side
• DCGM dcgm_thermal_violation ikke-nul → køleproblem, kontroller luftstrømmen
• Træningstab falder ikke for >100 skridt → værd at se på

Eksempler på logfiler fra virkelige fejl

Hvad du rent faktisk ser i journalctl -k når XID 79 aktiveres (RTX 5090, riserkabel trukket ud under termisk cykling):

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.

Sådan ser en NCCL-timeout ud, forkortet:

[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'

Rang 3 rapporterer det, men rang 3 er næsten aldrig det egentlige problem. Det er den langsomme rang, der ikke ankom. NCCL-sporingsbufferen dumper, hvilke ranger der blev blokeret ved hvilket kald – det er sådan, du finder den virkelige synder.

Genopretningsmønstre

Tjek ofte nok til, at en genstart er billig

For en 7B finjustering på 8× RTX 5090 med lokale NVMe-checkpoints: ~14 GB skrevet med ~3 GB/s ≈ 5 s pr. checkpoint, hvert 30. minut er 0.3% overhead, og worst-case tab er 15 minutter. For et 70B FSDP sharded checkpoint på den samme boks: ~140 GB sharded på tværs af 8 GPU'er parallelt, lignende overhead. Billigt, gør det.

Et fuldt Llama-70B pretrain-checkpoint over netværkslagring kører ~520 GB og kan tage 20+ minutter; det er her, Meta-klassebutikker introducerer asynkrone, lagdelte checkpoints (hurtig lokal skrivning, langsom dræning til holdbar lagring). Ved Kentino-størrelse: checkpoint hvert 15.-30. minut til lokal NVMe, synkronisering til NAS ved kørselsafslutning. Alt mere kompliceret er over-engineering.

Automatisk genstart med lommelygte

torchrun understøtter elastisk træning direkte fra kassen:

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

Med TORCH_NCCL_ASYNC_ERROR_HANDLING=1, kæden er: NCCL kollektiv hænger → PyTorch watchdog hæver → proces afbrydes med SIGABRT → torchelastic dræber sibling ranks og genstarter fra latest_checkpoint.ptDen samlede sekvens er normalt 60-120 sekunder. Midlertidige fejl fortsætter. En permanent fejl (GPU'en blev XID 79) brænder --max-restarts budget, og så er et menneske med i billedet.

Den operationelle praksis

Den største belastningsfaktor for fejlomkostninger er ikke gendannelseskoden – det er hvad du gør før jobbet starter.

Check før flyvning

Før du starter noget, der skal køre mere end et par timer, skal du køre valideringssekvensen:

# 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

På en ren 8× RTX 5090-server, all_reduce_perf bør lande i busbåndbreddeområdet 50-80 GB/s afhængigt af PCIe-topologien. Væsentligt under det betyder et riser- eller topologiproblem — ret det før træning. Vi kører gpu-burn i en hel time som en del af QA før afsendelse på alle builds, der forlader Kentino.

Hold øje med langsomme lækager

Rigtige kodebaser akkumulerer hukommelse: en logging hook indeholder en tensorreference, en exception path glemmer at rydde en buffer, en LR scheduler lækker en lukning. Resultatet er OOM ved trin 5000 i en kørsel på 10000 trin. Billigste afhjælpning: print torch.cuda.memory_allocated() hvert N trin til træningsloggen. Hvis den vokser, bør den ikke være det.

Den statistiske virkelighed på Kentino-skalaen

Det er her, at det er vigtigt at være ærlig omkring størrelse. Fejlprocenter skaleres med GPU-timerne; store klynger fejler konstant, fordi de har mange GPU'er, der kører i mange timer.

Estimater kalibreret i forhold til metadataene (én fejl pr. ~50,000 observerede GPU-timer). De reelle tal varierer afhængigt af GPU-modellen — forbruger-4090'ere og 5090'ere med risers fejler oftere end datacenter-L40'ere i deres native chassis, primært på grund af PCIe og slid på strømstik.

Konklusion: Ved en enkelt node med 8 GPU'er skal man forvente én hardwarehændelse pr. år med intensiv brug, ikke pr. uge. De fleste finjusteringer udføres uden at man ser nogen. Kunder, der ser dem, kører træning kontinuerligt, og den dominerende fejltilstand er riser/PSU-siden, ikke GPU-siliciumet.

Omkostningerne ved en genstart

Genstartsomkostninger er tabt træningstid plus diagnosticeringsingeniørens tid. På en 8× RTX 5090-build til f.eks. €300/dag amortiseret, er yderligere 30 minutter €6. Ingeniørens tid til at diagnosticere, geninstallere et kabel og genstarte er en til tre timer. Beregningstabet er en afrundingsfejl; arbejdskraften er omkostningerne. Derfor er den rigtige investering overvågning og pre-flight, ikke eksotisk gendannelsesinfrastruktur.

Det meste indhold online om fejlhåndtering er skrevet til hyperscale-niveauet. På Kentino-størrelse er det meste overdreven engineering. 80/20 er: overvåg kernelogfiler, checkpoint til lokal NVMe, sæt TORCH_NCCL_ASYNC_ERROR_HANDLING=1Kør gpu-burn før store job.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.