58,7 % des interruptions inattendues proviennent des GPU, trois incidents nécessitant une intervention humaine significative
Selon les informations, au cours des 54 jours de pré-entraînement, il y a eu 466 interruptions de travail au total. Parmi celles-ci, 47 étaient des interruptions planifiées, causées par la maintenance automatisée, telles que les mises à niveau de firmware ou les mises à jour de configuration ou de jeux de données initiées par les opérateurs ; 419 étaient des interruptions inattendues, principalement dues à des problèmes matériels confirmés, y compris des défaillances de GPU, de composants hôtes ou des problèmes suspectés d'être liés au matériel, comme la corruption silencieuse des données et des événements de maintenance non planifiés sur un seul hôte.
Les problèmes de GPU étaient la principale catégorie d'interruptions inattendues, représentant 58,7 % de tous les problèmes imprévus, incluant diverses défaillances de GPU telles que NVLink et des défaillances de mémoire HBM3. Ce n'est pas surprenant, car les GPU H100 de Nvidia consomment environ 700W et subissent un stress thermique important. Malgré le grand nombre de défaillances, seuls trois incidents ont nécessité une intervention humaine significative, les problèmes restants étant gérés automatiquement.
Les 41,3 % restants des interruptions inattendues étaient causés par une combinaison d'erreurs logicielles, de câbles réseau et d'adaptateurs réseau. Il est intéressant de noter que seuls deux CPU ont connu des défaillances pendant cette période.
Pendant les 54 jours de pré-entraînement de Llama 3 405B, les causes profondes des interruptions inattendues ont été classifiées.
Un autre défi auquel l'équipe de formation du grand modèle Llama 3 405B a été confrontée était les changements de consommation d'énergie simultanés de dizaines de milliers de GPU, ce qui a mis le réseau électrique du centre de données sous pression.
Au cours de l'entraînement, des milliers de GPU peuvent simultanément augmenter ou diminuer leur consommation d'énergie, par exemple en attendant qu'un point de contrôle soit terminé ou qu'une communication collective se termine, ou lors du démarrage ou de l'arrêt de l'ensemble de la tâche d'entraînement. Lorsque cela se produit, cela peut entraîner des fluctuations instantanées de la consommation d'énergie du centre de données de l'ordre de dizaines de mégawatts, ce qui peut surcharger le réseau électrique.
C'est un défi persistant, ce qui signifie que Meta doit s'assurer que ses centres de données disposent d'une alimentation suffisante pour maintenir le fonctionnement normal du modèle 405B ainsi que des futurs modèles Llama à plus grande échelle. À mesure que la complexité des modèles d'IA augmente, les ressources de calcul nécessaires augmentent également.
Les efforts derrière la réalisation de 90 % de temps d'entraînement effectif
Pour améliorer l'efficacité, Meta a développé divers outils et stratégies d'optimisation, notamment la réduction du temps de démarrage des tâches et des points de contrôle, l'utilisation extensive de l'enregistreur de vol NCCL intégré à PyTorch, et l'identification des GPU en retard. Parmi ceux-ci, NCCLX a joué un rôle crucial dans la détection et la localisation des défaillances, en particulier pour les problèmes liés à NVLink et RoCE, son intégration avec PyTorch permettant de surveiller et de mettre automatiquement en timeout les communications bloquées causées par les défaillances NVLink.
Il est entendu que l'enregistreur de vol NCCL de PyTorch peut enregistrer les métadonnées collectives et les traces de pile dans un tampon circulaire, permettant ainsi un diagnostic et une résolution rapides des problèmes de blocage et de performance à grande échelle, en particulier ceux liés à NCCLX. De plus, comme Meta utilise un mélange de NVLink et RoCE dans son réseau, le débogage des problèmes dans la formation à grande échelle est devenu plus complexe. Les transferts de données via NVLink sont généralement effectués par des opérations de chargement/stockage émises par les noyaux CUDA, et les défaillances des GPU distants ou des connexions NVLink se manifestent généralement par des opérations de chargement/stockage bloquées dans les noyaux CUDA, sans retourner de codes d'erreur explicites.
NCCLX améliore la vitesse et la précision de la détection et de la localisation des défaillances grâce à une conception collaborative étroite avec PyTorch, permettant à PyTorch d'accéder à l'état interne de NCCLX et de suivre les informations pertinentes. Bien qu'il ne soit pas possible d'empêcher complètement les blocages dus aux défaillances NVLink, le système surveille l'état de la bibliothèque de communication et met automatiquement en timeout lorsque de tels blocages sont détectés. De plus, NCCLX suit l'activité du noyau et du réseau pour chaque communication NCCLX et fournit un instantané de l'état interne des collectifs NCCLX défaillants, y compris les transferts de données terminés et en attente entre tous les rangs.
Parfois, les problèmes matériels peuvent entraîner l'apparition de "traînards" qui fonctionnent toujours mais lentement, et qui sont difficiles à détecter. Même un seul "traînard" peut ralentir le fonctionnement de milliers d'autres GPU, se manifestant souvent par des communications normales mais lentes. Pour y remédier, Meta a développé des outils pour prioriser les communications potentiellement problématiques provenant de groupes de processus sélectionnés, détectant et résolvant ainsi efficacement les retardataires, assurant que le ralentissement soit minimisé et maintenant l'efficacité globale de l'entraînement.
Une autre observation intéressante concerne l'impact des facteurs environnementaux sur les performances de l'entraînement à grande échelle. Pour Llama 3 405B, Meta a remarqué une variation de débit de 1-2 % à un certain moment de la journée, cette fluctuation étant due aux températures plus élevées à midi affectant l'ajustement dynamique de la tension et de la fréquence des GPU, influençant ainsi les performances d'entraînement. Mais ce n'est pas un gros problème, la mise à l'échelle dynamique de la tension et de la fréquence des GPU est généralement affectée par les changements de température.
Conclusion
Considérant qu'un cluster de 16384 GPU H100 a connu 419 défaillances inattendues en 54 jours, soit 7,76 fois par 24 heures, on ne peut s'empêcher de se demander quelle serait la fréquence des défaillances du Memphis Supercluster de xAI équipé de 100000 GPU H100 ?
La semaine dernière, Elon Musk s'est vanté sur la plateforme sociale X d'avoir lancé "le cluster d'entraînement d'IA le plus puissant au monde", déclarant qu'il créerait "l'IA la plus puissante au monde selon tous les critères" d'ici décembre de cette année. Selon les informations, le Memphis Supercluster a commencé l'entraînement, utilisant un refroidissement liquide et une architecture d'interconnexion réseau RDMA unique.
En termes d'échelle GPU, le Memphis Supercluster de xAI pourrait faire face à un taux de défaillance exponentiellement plus élevé, avec potentiellement six fois plus de composants défaillants, ce qui pose un défi encore plus grand pour son futur entraînement d'IA.
Liens de référence :
https://www.inspire2rise.com/meta-faces-frequent-gpu-failures-llama-3-training.html
https://ai.meta.com/research/publications/the-llama-3-herd-of-models/