Activez une formation plus rapide avec la bibliothèque parallèle de données Amazon SageMaker | Services Web Amazon

La formation sur les grands modèles de langage (LLM) est devenue de plus en plus populaire au cours de l'année dernière avec la sortie de plusieurs modèles accessibles au public tels que Llama2, Falcon et StarCoder. Les clients forment désormais des LLM d'une taille sans précédent allant de 1 milliard à plus de 175 milliards de paramètres. La formation de ces LLM nécessite des ressources de calcul et du temps importants, car des centaines, voire des milliers d'unités de traitement graphique (GPU) doivent être utilisées pour gérer les vastes ensembles de données de formation et les tailles de modèles actuels. Un goulot d'étranglement dans la formation distribuée peut être la communication GPU gérée par la bibliothèque de communication collective NVIDIA (NCCL). Dans certaines tâches de formation à grande échelle, plus de temps peut être consacré à la communication inter-GPU qu'au calcul réel du GPU. Pour atténuer le goulot d'étranglement de la communication GPU et permettre une formation plus rapide, Amazon Sage Maker est ravi d'annoncer une opération collective AllGather optimisée dans le cadre de la bibliothèque parallèle de données distribuées SageMaker (SMDDP). AllGather est l'opération collective la plus utilisée dans les solutions populaires de parallélisme de données économes en mémoire telles que Optimiseur de redondance zéro DeepSpeed ​​(ZeRO) et les Parallélisme des données entièrement partagées (FSDP), et c'est le principal contributeur à la surcharge de communication GPU. Dans cet article, nous présentons un aperçu général du fonctionnement de SMDDP, de la manière dont vous pouvez activer SMDDP dans vos scripts de formation Amazon SageMaker et des améliorations de performances auxquelles vous pouvez vous attendre.

Vue d'ensemble de la solution

Traditionnel formation parallèle aux données implique de répliquer un modèle entier sur plusieurs GPU, chaque modèle s'entraînant sur différentes fragments de données de l'ensemble de données. Lors du passage en arrière, les gradients sont moyennés parmi les travailleurs GPU afin que chaque réplique de modèle soit mise à jour avec les mêmes valeurs de gradient, bien qu'elles soient entraînées avec des fragments de données différents. Cette technique permet un entraînement beaucoup plus rapide sur de vastes ensembles de données en parallélisant la consommation des données d'entraînement. Cependant, certains des grands modèles actuels (par exemple, le Llama2 70B) sont beaucoup trop volumineux pour tenir entièrement dans la mémoire du GPU, ce qui rend le parallélisme de données traditionnel inutilisable. Pour continuer à profiter des avantages du parallélisme des données tout en surmontant la mémoire GPU limitée, les solutions parallèles de données fragmentées telles que DeepSpeed ​​ZeRO, PyTorch FSDP et Amazon bibliothèque de parallélisme de modèles SageMaker ont gagné en popularité.

Dans le parallélisme des données fragmentées, plutôt que de répliquer l'intégralité du modèle sur les GPU Workers, les paramètres du modèle, les gradients et les états de l'optimiseur sont divisés et distribués (c'est-à-dire fragmentés) sur les GPU lors de la tâche de formation. Pour effectuer des calculs de passes avant et arrière, les paramètres sont collectés à partir de fragments sur d'autres processeurs GPU pour former une ou plusieurs couches de modèle. Une fois le calcul effectué, ces couches sont ensuite libérées de la mémoire pour permettre la collecte de l'ensemble suivant de couches. Notez qu'il existe des variantes du parallélisme des données fragmentées dans lesquelles seuls les états et les gradients de l'optimiseur sont fragmentés, mais pas les paramètres du modèle. AllGather est toujours utilisé dans ce type de parallélisme de données fragmentées, mais uniquement avant le calcul de la passe directe afin de rassembler les paramètres du modèle qui ont été mis à jour par différents fragments de gradient ou d'état d'optimisation provenant d'autres travailleurs GPU. Référez-vous aux différents Étages DeepSpeed ​​ZeRO et les terres parsemées de SHARD_GRAD_OP Stratégie de partitionnement FSDP pour plus de détails.

Une opération collective AllGather est effectuée chaque fois que les paramètres ne sont pas partagés. NCCL fournit l'implémentation open source standard de cette routine. Comme indiqué ci-dessous, chaque travailleur GPU impliqué dans AllGather commence avec un tampon d'entrée et se retrouve avec tous les tampons d'entrée des autres travailleurs concaténés ensemble. Lorsque AllGather est utilisé dans le parallélisme de données fragmentées, les tampons d'entrée contiennent les fragments de paramètres de modèle et les grands tampons de sortie contiennent une ou plusieurs couches de modèle matérialisées à partir des autres fragments.

Bien que NCCL soit généralement utilisé pour AllGather dans la formation distribuée, sa mise en œuvre de bas niveau sous-jacente n'est pas adaptée à l'infrastructure réseau d'Amazon Elastic Compute Cloud (Amazon EC2), et ses performances peuvent donc ralentir la formation de bout en bout. La bibliothèque SMDDP est une bibliothèque de communication collective pour les GPU NVIDIA qui remplace NCCL et offre de meilleures performances pour les tâches de formation distribuées avec PyTorch. Plus précisément, SMDDP fournit une implémentation optimisée d'AllGather pour Types d'instances p4d/p4de.

Étant donné que les opérations collectives telles que AllGather bloquent le calcul des passes avant et arrière, une exécution plus rapide de ces opérations se traduit directement par un temps de formation de bout en bout plus court sans effets secondaires sur la convergence. D’autres opérations collectives moins fréquemment utilisées dans la formation parallèle de données fragmentées sont gérées en recourant à NCCL.

Procédure pas à pas

AllGather optimisé pour AWS

AllGather optimisé pour AWS utilise les techniques suivantes pour obtenir de meilleures performances sur l'infrastructure AWS par rapport à NCCL :

1. Nous déplaçons les données entre les instances via Adaptateur de tissu élastique (EFA) réseau avec un modèle de communication tout-à-tout. EFA est la solution réseau à faible latence et à haut débit d'AWS, et un modèle tout-à-tout pour la communication réseau inter-nœuds est plus adapté aux caractéristiques de l'EFA et de l'infrastructure réseau d'AWS en nécessitant moins de sauts de paquets par rapport à l'anneau ou à l'anneau de NCCL. modèle de communication arborescente.
2. RDACopie pour coordonner le trafic réseau local NVLink et EFA. GDRCopy est une bibliothèque qui fournit une communication à faible latence entre les processus CPU et les noyaux GPU CUDA. Grâce à cette technologie, nous sommes en mesure de canaliser le mouvement des données intra-nœuds et inter-nœuds.
3. Utilisation réduite des multiprocesseurs de streaming GPU pour redonner plus de puissance de calcul aux noyaux de modélisation. Les instances AWS P4d/P4de sont équipées de GPU NVIDIA A100, chacun doté de 108 multiprocesseurs de streaming. Alors que NCCL nécessite jusqu'à 24 multiprocesseurs de streaming pour exécuter des collectifs, les collectifs SMDDP n'utilisent que neuf multiprocesseurs de streaming maximum. Les multiprocesseurs de streaming enregistrés peuvent être récupérés par les noyaux de calcul du modèle pour une exécution plus rapide.

Utilisation

Les collectifs SMDDP s'intègrent nativement à PyTorch via le groupe de processus abstraction dans le torch.distributed module. Un groupe de processus définit les interfaces pour les opérations collectives courantes telles que AllGather, ReductionScatter, AllReduce, etc. Les utilisateurs peuvent écrire du code distribué générique, puis choisir le sous-jacent. backend, qui fournit l'implémentation de ces opérations en fonction du périphérique de calcul utilisé. Les tâches de formation du processeur utilisent souvent le gloo or mpi backend tandis que les GPU NVIDIA utilisent le nccl arrière-plan.

La bibliothèque SMDDP entre en scène en s'enregistrant en tant que backend personnalisé dans l'abstraction du groupe de processus. Cela est effectué par l'instruction import, qui est affichée dans les extraits de code suivants. Ensuite, lors de la sélection du backend pour votre tâche de formation distribuée basée sur GPU, remplacez simplement nccl comprenant smddpL’ smddp le backend respecte la même sémantique que le nccl backend et prend en charge les mêmes scénarios de formation.

Vitesse profonde

import smdistributed.dataparallel.torch.torch_smddp
deepspeed.init_distributed(dist_backend="smddp") # replacing "nccl"

PDSF

import smdistributed.dataparallel.torch.torch_smddp
dist.init_process_group(backend="smddp")  # replacing "nccl"

Repères

Nous avons comparé les performances AllGather autonomes où l'opération collective est exécutée de manière isolée sans aucune formation de modèle. Vous trouverez ci-dessous un exemple de résultat sur 32 instances p4d comparant NCCL et SMDDP AllGather. L'axe X représente la taille de sortie d'AllGather et l'axe Y représente le taux d'utilisation du réseau EFA 4 Gbit/s de p400d. Les 4 sous-graphiques représentent les modèles de groupe de communication courants où nous avons respectivement 1, 2, 4 et 8 rangs par instance p4d participant à l'opération AllGather.

Ces microbenchmarks montrent que SMDDP surpasse NCCL avec deux caractéristiques clés :

1. Les performances maximales du SMDDP (environ 90 % d'utilisation de la bande passante) sont supérieures à celles du NCCL (environ 80 % d'utilisation de la bande passante) dans toutes les configurations.
2. SMDDP atteint des performances maximales avec des tailles de tampon beaucoup plus petites que NCCL. Cela améliore particulièrement les vitesses d'entraînement pour les modèles plus petits ou lorsque l'utilisateur définit une petite taille de tampon AllGather dans DeepSpeed ​​(où la taille d'AllGather ne doit pas nécessairement être égale à la taille de la couche).

Modèles de références de formation

Dans les tâches de formation à grande échelle où la communication GPU constitue un goulot d'étranglement important, SMDDP peut améliorer considérablement les vitesses de formation, telles que mesurées par le modèle TFLOPS/GPU.

configuration			Performance
Modèle/Formation	Grappe	Solution de parallélisme de données partagées	Modèle TFLOPS/GPU avec NCCL	Modèle TFLOPS/GPU avec SMDDP	% accélérer
13B Lama2 Longueur séquentielle : 4096 Taille globale du lot : 4 millions de jetons	64 nœuds p4d.24xlarge (512 GPU NVIDIA A100)	PyTorch FSDP	97.89	121.85	24.40%
65B GPT-NeoX Longueur séquentielle : 2048 Taille globale du lot : 4 millions de jetons	64 nœuds p4d.24xlarge (512 GPU NVIDIA A100)	DeepSpeed ​​ZeRO Stage 3*	99.23	108.66	9.50%

*Megatron-DeepSpeed ​​d'EleutherAI le référentiel a été utilisé. Le parallélisme tensoriel a également été activé avec un degré tenseur-parallèle de huit.

Remarque : Le modèle TFLOPS/GPU est basé sur le calcul d'utilisation du modèle FLOPS défini dans le document. ici et les chiffres de référence ailleurs peuvent citer le matériel TFLOPS/GPU comme mesure de performance. Le matériel TFLOPS/GPU peut être approximé comme 4/3 x modèle TFLOPS/GPU.

Conclusion

Dans cet article, nous vous avons montré comment accélérer considérablement les tâches de formation parallèle de données fragmentées sur Amazon SageMaker avec seulement deux lignes de changement de code. La formation distribuée à grande échelle devient de plus en plus omniprésente avec l'émergence des LLM, mais cette échelle entraîne des coûts élevés. En réduisant les goulots d'étranglement de communication entre les GPU, SMDDP vous aide à vous entraîner plus rapidement à grande échelle et à économiser sur les ressources de calcul. Vous pouvez trouver d'autres exemples SMDDP avec une formation parallèle de données fragmentées dans le Référentiel GitHub d'exemples Amazon SageMaker.

---

À propos des auteurs

Apoorv Gupta est ingénieur en développement logiciel chez AWS, axé sur la création de systèmes d'apprentissage en profondeur optimaux pour l'infrastructure et le matériel AWS. Il s'intéresse à l'informatique distribuée, aux systèmes d'apprentissage profond et aux accélérateurs de ML. En dehors du travail, Apoorv aime les voyages, la randonnée et les jeux vidéo.

Karan Dhiman est ingénieur en développement logiciel chez AWS, basé à Toronto, au Canada. Il est très passionné par le domaine de l'apprentissage automatique et par la création de solutions permettant d'accélérer les charges de travail informatiques distribuées.

Ruhan Prasad est un ingénieur en développement logiciel chez AWS qui travaille à rendre la formation distribuée en deep learning plus rapide, moins chère et plus facile à utiliser sur SageMaker. En dehors du travail, Ruhan aime jouer au tennis, voyager et cuisiner.

Zhao Qi Zhu est un ingénieur senior en développement logiciel chez AWS, passionné par les systèmes distribués et les optimisations de bas niveau. Il aime regarder des matchs de football tout en buvant des sodas (non diététiques).

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/enable-faster-training-with-amazon-sagemaker-data-parallel-library/