Détecter les corruptions silencieuses de données sur Amazon SageMaker HyperPod et s'en remettre
Les corruptions silencieuses de données (SDC, pour silent data corruption) surviennent lorsqu'un composant matériel, typiquement un GPU, renvoie un résultat faux mais plausible sans lever la moindre erreur. En entraînement distribué, cette valeur erronée se propage dans les gradients et les poids de chaque réplique, et la perte peut sembler normale pendant des heures, jusqu'à ce qu'une divergence inexpliquée ou un modèle plus faible révèle le problème, une fois le calcul gaspillé. Le phénomène n'est pas théorique : pendant 54 jours de pré-entraînement de Llama 3 405B sur jusqu'à 16 000 GPU H100, Meta a attribué 6 de ses 419 interruptions imprévues à des SDC, et il ne s'agit que des cas ayant interrompu le job et ayant pu être retracés. Amazon propose désormais, pour SageMaker HyperPod, trois contrôles à intégrer dans une boucle d'entraînement PyTorch DistributedDataParallel. Le premier détecte les valeurs non finies (NaN, Inf, débordement) dans les gradients, y compris celles introduites par l'all-reduce. Le deuxième, un audit par relecture en anneau, fait recalculer à chaque GPU un micro-lot d'un autre nœud, puis compare la perte bit à bit et les gradients par empreinte, ce qui attrape les valeurs finies mais fausses. Le troisième compare les empreintes des poids de toutes les répliques après la mise à jour, pour repérer les corruptions de l'optimiseur ou des poids stockés. Les tests, menés avec des fautes injectées par logiciel sur un cluster de 4 instances ml.p5.48xlarge (32 GPU H100), puis répétés sur trois instances, le minimum requis, ont validé l'approche.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est considérable pour les équipes qui entraînent de grands modèles, car les protections existantes ne voient pas ce type de défaut. HyperPod remplace déjà les nœuds qui signalent une panne, grâce à son agent de surveillance de santé, à ses contrôles approfondis et à la récupération automatique, mais un SDC, par définition, ne déclenche aucun signalement. La mémoire ECC protège contre les inversions de bits en mémoire, pas contre une multiplication erronée dans un cœur tensoriel. Les erreurs Xid du pilote NVIDIA restent muettes, les tests DCGM tournent sur un nœud inactif, hors de la charge réelle, et les sommes de contrôle de NVLink, PCIe, EFA ou des points de contrôle vérifient le transport et le stockage, pas l'exactitude du calcul. Un point de contrôle empoisonné mais cohérent passe ainsi tous les tests. La seule parade consiste donc à vérifier le résultat du calcul lui-même, en comparant les répliques entre elles, ce qui permet de désigner un rang suspect avant que des jours de calcul ne soient perdus.
Ces défauts proviennent de défauts de fabrication, des transistors marginaux ayant échappé au tri du fondeur, et du vieillissement du silicium dans une unité précise, le plus souvent une voie de multiplication-accumulation d'un cœur tensoriel, justement la ressource la plus sollicitée par l'entraînement. Le circuit fonctionne la plupart du temps et ne se trompe que sous contrainte : température élevée, chute de tension ou motifs d'opérandes particuliers, d'où un résultat comme 4,0001 au lieu de 4,0000 que rien ne signale. La solution s'articule en quatre étapes : détecter dans la boucle d'entraînement, localiser le nœud (sur les clusters orchestrés par Amazon EKS, le nom du nœud Kubernetes contient l'identifiant de l'instance, ce qui rend la correspondance directe), contenir en arrêtant le job, isolant le nœud et consultant ses métriques GPU dans les tableaux de bord d'observabilité, puis confirmer, remplacer le nœud après examen et reprendre depuis un point de contrôle antérieur à la fenêtre suspecte. À mesure que les clusters atteignent des dizaines de milliers de GPU, ce type de vérification applicative pourrait devenir une pratique standard.
Les équipes européennes qui entraînent de grands modèles sur des clusters GPU peuvent adopter ces contrôles pour éviter de gaspiller des jours de calcul.
Le vrai sujet, ce n'est pas la panne, c'est celle qui ne prévient pas : à 16 000 GPU, un calcul faux mais plausible devient une ligne de budget, pas une anomalie rare. Selon Le Fil IA, quand la supervision matérielle ne voit plus rien, la fiabilité d'un entraînement se joue dans la boucle d'entraînement elle-même, en faisant vérifier les GPU les uns par les autres. Bon, sur le papier, ça ajoute du calcul de relecture et ça demande de l'intégrer à la main dans PyTorch. Mais face à des jours de GPU jetés sur un modèle bancal, ça va coûter bien moins cher que de ne rien contrôler.