Un nœud équipé de huit GPU peut fonctionner pendant des semaines sans problème, mais reste une pièce peu fiable pour un entraînement distribué impliquant des milliers de machines simultanément. La contradiction est apparente : lorsqu’une tâche synchronisée dépend de la disponibilité continue de tous ses participants, une faible probabilité de panne individuelle se multiplie pour rendre les interruptions une composante normale de l’exploitation quotidienne.

Une infographie récemment diffusée résume le problème avec un chiffre marquant : un taux de panne quotidienne de 1,5 % par nœud engendrerait une probabilité de 84,8 % de rencontrer au moins une défaillance dans un système de 1 000 GPU. Ce calcul est précis dans des conditions spécifiques, mais d’autres affirmations de cette illustration nécessitent un contexte plus approfondi. La fiabilité d’un cluster ne peut se déduire uniquement d’une formule ou du pourcentage publié par serveur.

Les clés de la fiabilité des clusters GPU en 20 secondes

• Les entraînements distribués synchronisent souvent des milliers de GPU à chaque étape.
• Une seule défaillance de nœud peut bloquer ou ralentir l’ensemble des autres.
• Avec 1 000 GPU réparties en 125 nœuds, un taux de panne quotidienne de 1,5 % par nœud donne une probabilité de 84,9 % de rencontrer au moins une panne.
• Ce calcul suppose des pannes indépendantes et des nœuds de huit GPU.
• En pratique, il existe aussi des erreurs corrélées liées au réseau, à l’alimentation, à la refroidissement, au firmware ou aux logiciels.
• La fiabilité utile s’évalue en temps effectif d’entraînement, pas seulement en disponibilité individuelle.
• Identifier rapidement un nœud défaillant et l’isoler est souvent plus pertinent que de diagnostiquer avant d’agir.
• Les points de contrôle limitent la perte de travail, mais peuvent surcharger le stockage.
• Les systèmes récents permettent de retirer une copie défectueuse pendant que le reste continue à s’entraîner.
• Le chiffre d’une panne toutes les 30 minutes pour 100 000 GPU ne découle pas directement du taux de 1,5 %.

La littérature technique confirme que les interruptions deviennent une norme à mesure que le cluster s’agrandit. Par exemple, l’entraînement de Llama 3 sur 16 384 GPU H100 a enregistré 466 interruptions en 54 jours, tandis que ByteDance a documenté plus d’une centaine d’incidents en quelques semaines lors de l’exploitation de MegaScale avec 12 288 GPU. D’autres études sur des systèmes distribués répertorient également des cas d’incidents quotidiens ou bi-quotidiens dans des déploiements d’environ 1 000 accélérateurs.

Comment un taux de 1,5 % devient une probabilité de 84,9 %

La formule utilisée dans l’image est :

P(au moins une panne) = 1 − (1 − p)^N

Ici, p représente la probabilité quotidienne de panne d’un nœud, et N le nombre de nœuds impliqués dans la tâche.

Un système avec 1 000 GPU ne correspond pas forcément à 1 000 éléments indépendants. Si chaque serveur héberge huit GPU, l’infrastructure se compose de 125 nœuds. Avec un taux quotidien de 1,5 % par nœud, la probabilité que zéro défaillance se produise est :

0,985^125 ≈ 15,1 %

Ainsi, la probabilité qu’au moins un nœud tombe en panne est d’environ 84,9 %. La valeur de l’infographie est cohérente si l’on suppose cette configuration — huit GPU par nœud, un taux constant, et des pannes indépendantes.

Cela ne signifie pas que 84,9 % des entraînements échoueront complètement, mais indique qu’à tout moment, il y a cette chance qu’au moins un des 125 nœuds présente un problème correspondant à ce taux. L’impact réel dépendra de l’architecture de l’entraînement, de la durée de la panne, et de la capacité à retirer ou remplacer la machine défaillante.

Il est aussi crucial de définir ce qu’on considère comme une panne : GPU qui ne répond plus, erreur ECC non récupérable, problème de HBM, perte de liaison NVLink, interface réseau dégradée, processus bloqué ou serveur retiré en prévention lors de détections d’anomalies.

Dès lors, les listes de nœuds exclus ne doivent pas simplement refléter des hardware cassés, mais représenter des machines retirées suite à une panne confirmée, une dégradation intermittente ou un comportement susceptible de ralentir le reste du cluster en opération collective.

Une étude réalisée sur un cluster de 504 GPU Nvidia B200 illustre cette complexité. Les chercheurs ont analysé 751 métriques via Prometheus et dix erreurs identifiées par codes XID, sans trouver une métrique unique qui dominerait la typologie d’incidents. De plus, trois des 63 nœuds concentraient plus de la moitié des exclusions, signalant que les problèmes ne sont pas toujours uniformément répartis.

Cette concentration remet en cause une des hypothèses initiales : l’indépendance des pannes. En réalité, celles-ci peuvent se produire par lot, en fonction des versions de firmware, de la température, de la topologie réseau, de la charge ou de la configuration. Une panne électrique ou de refroidissement peut affecter plusieurs machines en même temps ; un petit groupe problématique peut expliquer une partie importante des incidents.

Le chiffre de 1 panne toutes les 30 minutes : un autre modèle

L’infographie mentionne qu’un cluster de 100 000 GPU pourrait subir une panne toutes les 30 minutes. Ce scénario paraît cohérent avec la fréquence très haute des incidents à ces échelles. Cependant, ce chiffre ne découle pas simplement de l’extrapolation du taux de 1,5 %.

Avec huit GPU par nœud, 100 000 accélérateurs représentent environ 12 500 machines. Si chaque machine présente une probabilité quotidienne de panne de 1,5 %, le nombre attendu de pannes serait de 187,5 par jour, ce qui correspond à un intervalle moyen d’environ 7,7 minutes entre incidents, et non 30 minutes.

Une panne toutes les 30 minutes correspondrait plutôt à une dizaine de pannes par jour, soit une fréquence quotidienne d’environ 48 incidents. Avec 12 500 nœuds, cela donnerait une probabilité individuelle d’environ 0,38 % en moyenne par jour, en supposant que la définition de panne soit la même et que le modèle de calcul soit ajusté.

Le document de référence dans l’image, l’article arXiv:2605.09370, n’analyse pas un cluster de 100 000 GPU. Il étudie 63 nœuds de 504 B200 sur 55 jours, avec 73 jours de logs opérationnels. Il donne des informations précieuses sur la détection, les points de contrôle, l’exclusion de nœuds et les tentatives de répartition, mais ne justifie pas à lui seul un intervalle de 30 minutes pour une infrastructure de cet ordre.

Des recherches spécifiques existent également sur des entraînements à l’échelle de 100 000 GPU. Leurs auteurs montrent une efficacité réelle de seulement 44 % en approche totalement synchronisée, en raison de la fréquence des incidents et du temps nécessaire pour se remettre. Le système FT-HSDP, par exemple, réduit le temps d’attente lors de la récupération de 10 à 3 minutes et augmente le temps utile d’entraînement à 80 %. Pas besoin d’un incident toutes les 30 minutes pour illustrer la portée du problème.

La donnée clé n’est pas le délai précis entre erreurs, qui varie selon le matériel et la méthode, mais le fait qu’une architecture conçue pour s’arrêter à chaque panne voit sa capacité opérationnelle fortement diminuer à grande échelle.

La fiabilité, construite au-delà du matériel

Investir dans du matériel de qualité diminue certes le taux de panne, mais ne suffit pas. Lors d’un entraînement synchronisé, chaque participant échange gradients ou résultats intermédiaires. Si un nœud disparaît, répond tard ou perd de la bande passante, les autres restent en attente.

L’infrastructure nécessite des mécanismes pour identifier, retirer et réorganiser rapidement le travail du nœud défaillant. La rapidité de cette décision est souvent plus critique que la précision du diagnostic initial.

Attendre plusieurs minutes pour diagnostiquer une panne de mémoire, GPU, contrôleur ou lien réseau peut paralyser des machines dont le coût horaire peut atteindre plusieurs centaines de milliers d’euros. Isoler d’abord, analyser ensuite, permet de retrouver plus rapidement la capacité utile, à condition qu’un groupe de secours ou une architecture tolérante permette de continuer avec moins de nœuds.

Cette philosophie se traduit par l’usage de vérifications préliminaires, de signaux d’activité, de métriques Nvidia DCGM, de journaux NCCL et de tests réseau réguliers. Ces systèmes recherchent à détecter aussi bien des erreurs évidentes que des nœuds en retard, tout en réduisant la performance globale si nécessaire.

Un lien réseau partiellement dégradé peut s’avérer très nuisible. Certaines bibliothèques basculent le trafic vers d’autres interfaces pour éviter un effondrement total, même si le serveur reste dans le groupe. Des algorithmes AllReduce récents, capables de maintenir des performances proches du normal lorsqu’un nœud perd une partie de sa bande passante, illustrent cette avancée.

L’objectif opérationnel ne consiste plus à maintenir toutes les machines en parfait état, mais à éviter qu’une machine problématique ne retire tout le groupe.

Les points de contrôle : une aide précieuse mais coûteuse

La solution classique en cas de panne consiste à enregistrer périodiquement l’état du modèle. Lorsqu’une interruption survient, le système recharge le dernier point de contrôle et reprend à partir de là.

Augmenter la fréquence des sauvegardes limite la perte de progrès, mais exige de transférer beaucoup de données GPU vers la mémoire du serveur et au stockage, ce qui peut saturer le réseau ou les systèmes de fichiers dans de grands modèles.

Le rapport sur 504 B200 a analysé 523 opérations d’enregistrement et de chargement. Lors d’une récupération, la lecture n’a atteint que 21,5 % du débit maximal, tandis que l’écriture n’a représenté que 16 %. Les chercheurs ont observé des files d’attente simultanées sur NFS, RPC, et la couche transport, ce qui montre que disposer d’un stockage rapide ne garantit pas une utilisation optimale quand des centaines de processus accèdent en même temps.

Des projets comme DLRover tentent de réduire ces coûts en sauvegardant l’état dans la mémoire et en stockant les données de manière asynchrone. Selon leur rapport, cette combinaison de tolérance aux pannes et de récupération rapide a permis de porter le « goodput » d’un entraînement GLM-65B à 95 %, contre 69 % initialement. Bien que cette métrique soit interne, elle reflète une réalité essentielle : la proportion du temps utile consacré à produire des étapes d’apprentissage pertinentes.

Une GPU peut être occupée à attendre une communication, à répéter du travail perdu ou à charger un point de contrôle. La simple utilisation d’un GPU ne correspond pas toujours à sa productivité réelle.

Du redémarrage complet à la récupération par répliques

Les solutions modernes visent à dissocier la dépendance totale d’un entraînement à chaque nœud individuel.

FT-HSDP divise le travail en multiples répliques par parallélisme de données. Lorsqu’un GPU ou un serveur échoue, seule la réplique concernée est retirée. Les autres continuent à avancer pendant que la défaillante redémarre, recharge son état et se réintègre via un protocole spécifique.

Ce paradigme modifie la notion de tolérance aux pannes. L’entraînement de 100 000 GPU n’est plus considéré comme une seule machine géante totalement fiable, mais comme plusieurs groupes capables de supporter la perte temporaire de l’un d’eux.

La récupération asynchrone permet aussi de réduire la nécessité de réserver une capacité énorme de matériel inactif. Si des ressources de secours sont toujours nécessaires, elles peuvent faire partie intégrante du cluster et ne pas représenter une copie complète de l’entraînement.

L’expérience d’un cluster de 504 GPU montre que les tentatives automatiques de réessai ont réussi dans 33,3 % des cas, contre 12,5 % pour les essais manuels, avec une fréquence médiane de réessais toutes les 11 minutes. Cela prouve que l’automatisation, même imparfaite, peut surpasser une intervention humaine impulsive.

Ce qu’un opérateur en infrastructure IA doit mesurer

Le taux de panne publié pour une GPU ou un serveur est une donnée utile, mais insuffisante. La mesure réelle doit inclure le nombre d’interruptions par millier de GPU-et-heure, le délai de détection, la quantité de travail perdu et le temps nécessaire pour retrouver la performance antérieure.

Il faut aussi différencier les origines : GPU, HBM, NVLink, interfaces réseau, commutateurs, stockage, alimentation, refroidissement, pilotes, logiciels. Sans cette classification, une amélioration hardware peut simplement déplacer le problème vers une autre couche.

L’affirmation selon laquelle la mémoire HBM est devenue la cause principale d’incidents lors d’un entraînement de 32 000 accélérateurs est plausible, compte tenu de la complexité de ces mémoires empilées, mais elle n’est pas explicitement documentée dans les références de l’infographie. Jusqu’au rapport original, cette tendance doit rester en instance de validation, et non comme un constat universel pour toute l’industrie.

La fiabilité d’un grand cluster ne se limite pas aux caractéristiques techniques d’une GPU. Elle s’obtient en combinant observabilité, isolation, capacité de réserve, points de contrôle rapides et un modèle de gestion qui accepte l’échec comme une variable inhérente.

Dans une petite infrastructure, une panne reste un incident isolé. Dans un système de dizaines de milliers de GPU, elle devient une condition normale. La différence entre un cluster coûteux et un cluster productif réside dans la gestion des minutes qui suivent la panne.

Questions fréquentes

Le taux de panne de 84,8 % pour 1 000 GPU est-il correct ?
Oui, à condition d’avoir 125 nœuds avec huit GPU chacun, un taux de panne quotidien indépendant de 1,5 % par nœud et une hypothèse d’indépendance totale. Le résultat tourne autour de 84,9 %.

Une panne dans un nœud bloque-t-elle toujours tout l’entraînement ?
Pas nécessairement. Cela concerne surtout les architectures très synchronisées. Les systèmes avec répliques tolérantes peuvent isoler le nœud défaillant tout en laissant le reste avancer.

Un cluster de 100 000 GPU tombe-t-il en panne toutes les 30 minutes ?
Ce scénario est possible à haute fréquence, mais le délai dépend de la définition du fallback et de la méthodologie. La approximation du 30 minutes n’est pas une extrapolation directe du taux de 1,5 %.

Quelle métrique reflète le mieux la fiabilité du cluster ?
Le goodput, c’est-à-dire la proportion de temps consacrée à produire un travail utile, est plus représentatif que la simple disponibilité de chaque GPU.