AWS ajoute 3 contrôles à l'entraînement des modèles pour détecter les erreurs silencieuses des GPU

L'entraînement se poursuit, la courbe d'erreur a l'air normale, les GPU ne se plaignent pas. Pourtant, un accélérateur a déjà calculé un nombre erroné, et les autres copies du modèle l'ont intégré à la mise à jour commune. L'équipe continue de dépenser du temps de calcul alors que le résultat de l'entraînement a peut-être été corrompu. AWS a décrit comment rechercher de telles défaillances directement dans la boucle PyTorch DDP : répéter une partie des calculs sur un autre nœud et comparer les résultats.

C'est une analyse d'ingénierie utile pour les équipes qui entraînent des modèles sur plusieurs nœuds GPU. Elle comprend le code des contrôles et la procédure de reprise via SageMaker HyperPod. L'idée principale dépasse le cadre d'un cloud particulier : l'absence d'alertes matérielles ne signifie pas que les calculs sont corrects.

Comment une erreur devient collective

Dans l'entraînement avec parallélisme de données, plusieurs copies du modèle traitent différentes portions d'exemples. Le système moyenne ensuite leurs gradients, les valeurs qui servent à mettre à jour les poids. Chaque copie reçoit la même valeur moyenne et effectue la même mise à jour.

Supposons que trois GPU aient calculé des gradients de 0,20, 0,40 et 0,30. La moyenne est de 0,30. Mais si le deuxième accélérateur, à cause d'une panne, renvoie 4,00 au lieu de 0,40, les trois copies recevront une moyenne déjà fausse. Après la mise à jour, leurs poids resteront identiques. Une simple comparaison des copies montrera que tout est en ordre, alors que l'erreur s'est déjà propagée.

Les contrôles habituels protègent d'autres parties du système. Le contrôle de la mémoire aide à détecter la corruption de données en mémoire, les vérifications réseau, les erreurs de transmission. La somme de contrôle du modèle sauvegardé confirme l'intégrité du fichier. Pourtant, un fichier correctement écrit peut très bien contenir des poids corrompus par un calcul antérieur.

Pour donner l'ampleur du problème, AWS cite les données de l'entraînement de Llama 3 405B : en 54 jours, Meta a associé six de ses 419 interruptions inattendues à une corruption silencieuse des données. Cette statistique ne compte que les cas détectés qui ont pu être reliés à une panne et ne reflète pas la fréquence de toutes les erreurs inaperçues.

Trois contrôles dans la boucle d'entraînement

Le premier contrôle recherche les NaN et Inf dans les gradients locaux avant la moyenne, puis vérifie le résultat de la moyenne avant la mise à jour des poids. On peut ainsi interrompre l'étape avant qu'une valeur manifestement incorrecte ne fasse partie du modèle. Mais le nombre 4,00 paraît tout à fait valide et passera ce contrôle.

Il faut pour cela un deuxième contrôle : à des étapes choisies, chaque GPU retraite le micro-lot d'un autre nœud. Si les mêmes données et les mêmes conditions donnent des résultats différents, il y a matière à enquête. On compare la valeur de la fonction de perte et des empreintes compactes des gradients. Pour lever les ambiguïtés de comparaison, le schéma exige un troisième nœud.

Le troisième contrôle intervient après la mise à jour : il compare les empreintes des poids des différentes copies du modèle. Si une copie diffère d'une majorité stricte, on peut désigner l'instance suspecte. Le contrôle est effectué périodiquement et avant l'enregistrement du point de contrôle, afin de ne pas figer la corruption détectée dans une nouvelle sauvegarde.

En cas d'alerte, l'équipe arrête l'entraînement, associe le processus suspect à un nœud et interdit d'y placer de nouvelles tâches. Elle étudie ensuite les métriques, lance au besoin un diagnostic et, après vérification, remplace le nœud. Il est recommandé de reprendre l'entraînement à partir du point de contrôle enregistré avant l'intervalle suspect.

Ce qu'il faut considérer avant le déploiement

AWS a testé la solution sur quatre nœuds équipés de 32 NVIDIA H100, en injectant des erreurs par logiciel. Les tests ont aussi été répétés sur trois nœuds, le minimum pour le schéma proposé. Ces essais montrent le comportement des contrôles dans des scénarios donnés, mais ne prouvent pas la détection de toute panne matérielle.

Il existe aussi des angles morts concrets. Un nombre fini erroné à l'intérieur de l'opération de moyenne peut passer tous les contrôles. Le recalcul ne vérifie que des étapes choisies et exige des données reproductibles ; la comparaison des gradients repose elle aussi sur des calculs déterministes. La concordance d'empreintes compactes est un indice fort d'égalité des tenseurs, mais pas une preuve mathématique.

Conclusion pratique : pour les exécutions distribuées coûteuses, mieux vaut vérifier les résultats des calculs eux-mêmes et préparer la reprise à l'avance. On peut commencer par vérifier les NaN et Inf avant la mise à jour et la sauvegarde. Ensuite, mesurer le coût des recalculs sur sa propre charge et déterminer la fréquence de l'audit. Les points de contrôle doivent être stockés en dehors du nœud remplaçable : ses disques locaux sont détruits lors du remplacement.