Gestion des pannes dans les clusters d'IA : ce qui dysfonctionne réellement et comment le réparer

L'entraînement distribué est l'une des rares charges de travail où les pannes matérielles ne sont pas un simple désagrément ponctuel, mais un coût opérationnel permanent. Le rapport d'analyse post-mortem de Llama 3.1 405B, publié par Meta, recense 419 interruptions inattendues sur 54 jours pour un cluster de 16 384 GPU : un incident toutes les trois heures, dont environ la moitié sont imputables à des défaillances de GPU et de mémoire HBM. C'est le quotidien d'une utilisation intensive de milliers de GPU.

La plupart des clients de Kentino ne verront jamais de tels chiffres. Les réglages fins sur un seul nœud avec 8 GPU sont statistiquement peu fréquents. Cependant, les modes de défaillance, les outils de diagnostic et les procédures de récupération restent les mêmes. Cet article dresse un constat honnête : les défaillances, comment les détecter, comment les résoudre et où les efforts d’ingénierie se justifient réellement à notre échelle.

Les modes de défaillance réels

Deux catégories sont importantes : les événements matériels (problèmes physiques liés au GPU, à l’alimentation, à la carte réseau ou au disque) et les événements logiciels (réaction anormale de CUDA, NCCL, du framework ou du système d’exploitation à une perturbation transitoire). Voici un classement approximatif de la fréquence à laquelle chacun de ces événements survient sur une station de travail multi-GPU ou un petit cluster.

Erreurs XID du GPU

Les journaux du noyau (dmesg, journalctl -k) sont la source de vérité. NVIDIA émet une ligne XID pour chaque erreur du GPU. Voici celles que vous voyez réellement :

Deux leçons tirées de l'expérience :

• XID 79 est celui qui provoque les appels paniqués des clients. « La carte graphique a disparu. » Sur une configuration avec une carte riser 4x ou 8x, l'erreur XID 79 indique presque toujours un problème de carte riser PCIe, un connecteur d'alimentation débranché suite à des cycles thermiques, ou une coupure thermique ; il ne s'agit pas d'une carte graphique défectueuse. Vérifiez la connexion, le câblage et effectuez un nouveau test avant de procéder à un retour en garantie.
• Les identifiants XID 48 et 63 sont réels. Les défauts de la correction d'erreurs ECC apparaissent progressivement sur les cartes fortement utilisées, au fil des mois. Le GPU met automatiquement hors service les pages jusqu'à épuisement des lignes disponibles. Une fois ce seuil atteint, la carte devient impropre à la formation ; la plupart des opérateurs la remplacent.

Erreur de mémoire insuffisante CUDA en cours d'exécution

L'erreur d'entraînement la plus fréquente sur notre matériel est presque toujours due à une erreur de l'opérateur, et non au matériel. Le schéma typique est le suivant : l'entraînement se déroule correctement pendant 200 étapes, puis plante. CUDA error: out of memoryLa cause est généralement :

1. La mémoire d'activation augmente avec la longueur de la séquence — des échantillons plus longs, plus tard dans l'époque, font exploser le budget.
2. Un processus homologue sur le même GPU. nvidia-smi affiche deux PID ; l'un était censé être arrêté et ne l'a pas été.
3. Fragmentation de la mémoire. L'allocateur de cache de PyTorch refuse un bloc contigu de grande taille même avec suffisamment de mémoire libre. Solution : PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True.

Doubler la puissance du GPU ne résout pas le problème. La solution consiste à réduire la taille des micro-lots, à activer la sauvegarde des gradients ou à partitionner l'optimiseur (voir K02).

Délais d'attente NCCL et problèmes de réseau

Collectifs NCCL (all_reduce, all_gather, reduce_scatterLes opérations sont synchrones sur tous les rangs. Si un rang se bloque (carte réseau défectueuse, commutateur saturé, problème avec le planificateur du noyau, GPU lent), tous les autres rangs attendent la prochaine opération collective et l'ensemble du travail est bloqué. Sans gestion asynchrone des erreurs, le blocage est silencieux ; le travail semble « bloqué » jusqu'à ce qu'un délai d'attente (30 minutes par défaut) soit atteint.

La solution consiste en une variable d'environnement :

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

PyTorch s'interrompt alors avec SIGABRT En cas de dépassement du délai imparti pour une tâche collective. Combiné à Torchlastic, le travail redémarre à partir du dernier point de contrôle. Remarque : l'ancienne version NCCL_ASYNC_ERROR_HANDLING est obsolète.

Déconnexion des nœuds et défaillances de l'alimentation

Sur les clusters multi-nœuds, un nœud peut tomber en panne suite à une réinitialisation de la carte réseau, une instabilité des ports de commutation, un plantage du noyau, une interruption par le processus OOM-killer ou une coupure de courant. La détection est identique à celle du délai d'expiration NCCL. Cette catégorie ne s'applique pas aux configurations mono-nœud à 8 GPU (la plupart de nos clients).

Une alimentation défectueuse est une panne irrémédiable. Sur un serveur à 8 GPU avec Deux alimentations ATX en configuration à rail divisé, une panne d'alimentation pas La redondance est identique. L'alimentation A alimente les GPU 0 à 3, l'alimentation B alimente les GPU 4 à 7. En cas de défaillance de l'alimentation B, quatre GPU deviennent inopérants (XID 79) en quelques millisecondes. La récupération nécessite un remplacement physique. Une redondance réelle requiert des unités CRPS en configuration 1+1 remplaçables à chaud, ce qui correspond à une architecture serveur et non à une station de travail pour GPU grand public.

Échecs d'écriture dans le stockage pendant le point de contrôle

Moins fréquent, mais tout aussi problématique. La tâche s'exécute pendant dix heures, atteint un point de contrôle, puis l'écriture échoue car le serveur NFS est saturé, le SSD NVMe local a dépassé sa limite DWPD et passe en mode lecture seule, la limite d'inodes a été atteinte ou les permissions ont été modifiées. Les dégâts sont proportionnels à l'intervalle entre les points de contrôle ; si vous ne détectez l'erreur qu'à un seul point de contrôle, les conséquences peuvent être graves. next Vous risquez de perdre une heure, voire plus, en essayant.

Fuites ECC lentes

Le fléau silencieux. Un GPU commence à émettre des erreurs XID 92 (ECC mono-bit) une fois par semaine, puis quotidiennement, puis toutes les heures. Chaque événement est « contrôlé » et le traitement continue, mais la précision se dégrade et la perte d'entraînement augmente lentement. Avant même que quelqu'un ne s'en aperçoive, des centaines de pages sont mises hors service et la carte se dirige vers l'erreur XID 48. C'est pourquoi la section de surveillance est plus importante que la section de récupération.

Détection — que surveiller

Trois couches : niveau noyau (lignes XID dans dmesg), fournisseur de GPU (exportateur DCGM vers Prometheus, dcgmi diag pour les contrôles actifs), et au niveau du framework (chien de garde PyTorch, tampon de trace NCCL, alertes de perte/débit).

Les alertes importantes :

• Toutes XID 48 / 63 / 79 / 92 ligne dans dmesg → page
• Température du GPU > 85 °C pendant plus de 5 minutes → page
• Incrémentation du compteur d'erreurs volatiles ECC → ticket, pas page
• DCGM dcgm_thermal_violation Valeur non nulle → problème de refroidissement, vérifiez le débit d'air
• Perte d'entraînement ne diminuant pas après plus de 100 pas → à vérifier

Exemples réels de journaux d'erreurs

Ce que vous voyez réellement dans journalctl -k lorsque le XID 79 se déclenche (RTX 5090, câble riser débranché lors des cycles thermiques) :

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.

Voici à quoi ressemble un délai d'attente NCCL (en abrégé) :

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

Le nœud de rang 3 signale le problème, mais il n'en est presque jamais la cause. Le nœud lent est celui qui n'a pas répondu. Les traces NCCL indiquent quels nœuds ont été bloqués lors de quel appel ; c'est ainsi que l'on trouve le véritable responsable.

Modèles de récupération

Des points de contrôle suffisamment fréquents pour qu'un redémarrage ne coûte pas cher

Pour une optimisation fine de 7 octets sur 8 RTX 5090 avec des points de contrôle NVMe locaux : environ 14 Go écrits à environ 3 Go/s, soit 5 s par point de contrôle, toutes les 30 minutes, ce qui représente une surcharge de 0.3 % et une perte maximale de 15 minutes. Pour un point de contrôle FSDP de 70 octets réparti sur la même machine : environ 140 Go répartis en parallèle sur 8 GPU, avec une surcharge similaire. C'est économique, foncez !

Une sauvegarde complète du point de contrôle avant entraînement d'un Llama-70B sur un stockage réseau pèse environ 520 Go et peut prendre plus de 20 minutes ; c'est là que les entreprises utilisant des machines de type Meta introduisent la sauvegarde asynchrone et hiérarchisée (écriture locale rapide, écriture lente sur un stockage permanent). Pour les machines de taille Kentino : sauvegarde toutes les 15 à 30 minutes sur un disque NVMe local, synchronisation avec le NAS à la fin de l'exécution. Toute solution plus complexe serait surdimensionnée.

Redémarrage automatique avec torchelastic

torchrun Prend en charge l'entraînement élastique dès sa sortie de l'emballage :

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

Avec TORCH_NCCL_ASYNC_ERROR_HANDLING=1La chaîne est la suivante : blocage collectif NCCL → alerte du watchdog PyTorch → arrêt du processus avec SIGABRT → torchlastic interrompt les processus frères et redémarre. latest_checkpoint.ptLa séquence totale dure généralement entre 60 et 120 secondes. Des anomalies transitoires persistent. Une panne permanente (le GPU passe en mode XID 79) entraîne la destruction du processeur. --max-restarts Un budget est établi, et ensuite un humain intervient.

La pratique opérationnelle

Le principal levier pour réduire le coût d'une défaillance n'est pas le code de récupération, mais ce que vous faites. avant Le travail commence.

Contrôles pré-vol

Avant de lancer toute opération qui durera plus de deux heures, exécutez la séquence de validation :

# 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

Sur un serveur propre équipé de 8 cartes graphiques RTX 5090, all_reduce_perf La bande passante du bus devrait se situer entre 50 et 80 Go/s, selon la topologie PCIe. Une valeur nettement inférieure indique un problème de carte riser ou de topologie ; il est impératif de le résoudre avant l’entraînement. Nous effectuons un test GPU Burn d’une heure complète sur chaque machine quittant Kentino dans le cadre du contrôle qualité avant expédition.

Surveillez les fuites lentes.

Les bases de code réelles accumulent de la mémoire : un point d’entrée de journalisation conserve une référence à un tenseur, un chemin d’exception oublie d’effacer un tampon, un planificateur LR fuit une fermeture. Le résultat est une erreur de mémoire insuffisante (OOM) à l’étape 5000 d’une exécution de 10000 étapes. Solution la moins coûteuse : afficher torch.cuda.memory_allocated() Toutes les N étapes, le journal d'entraînement est ajouté. S'il s'allonge, il ne devrait pas s'allonger.

La réalité statistique à l'échelle de Kentino

C’est là que la transparence concernant la taille des clusters est cruciale. Les taux de panne sont proportionnels aux heures d’utilisation des GPU ; les grands clusters tombent constamment en panne car ils comportent de nombreux GPU fonctionnant pendant de nombreuses heures.

Les estimations sont basées sur les métadonnées (une panne pour environ 50 000 heures d'utilisation du GPU). Les chiffres réels varient selon le modèle de GPU : les 4090 et 5090 grand public avec cartes d'extension tombent plus souvent en panne que les L40 de centre de données dans leur boîtier d'origine, principalement à cause de l'usure des connecteurs PCIe et d'alimentation.

Conclusion : sur une architecture mono-nœud à 8 GPU, prévoyez un incident matériel par an en cas d’utilisation intensive, et non par semaine. La plupart des réglages finaux se déroulent sans incident. Les clients qui en constatent un effectuent des entraînements en continu, et la cause principale de la panne se situe au niveau de la carte d’extension/de l’alimentation, et non au niveau du GPU.

Coût d'un redémarrage

Le coût d'un redémarrage correspond au temps de formation perdu, auquel s'ajoute le temps de diagnostic du technicien. Sur une configuration à 8 cartes graphiques RTX 5090, par exemple à 300 €/jour amortis, 30 minutes supplémentaires représentent 6 €. Le temps nécessaire au technicien pour diagnostiquer le problème, reconnecter un câble et redémarrer le système est d'une à trois heures. La perte de puissance de calcul est négligeable ; le coût réel est la main-d'œuvre. C'est pourquoi il est judicieux d'investir dans la surveillance et la préparation du système avant le lancement, plutôt que dans une infrastructure de récupération complexe.

La plupart des ressources en ligne sur la gestion des pannes sont conçues pour les infrastructures hyperscale. À l'échelle d'un Kentino, elles sont souvent surdimensionnées. La règle 80/20 consiste à : surveiller les journaux du noyau, créer un point de contrôle sur le NVMe local et configurer… TORCH_NCCL_ASYNC_ERROR_HANDLING=1Exécutez GPU Burn avant les tâches importantes.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.