Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Améliorations de l'initialisation de la communication collective
NCCL et Gloo sont des bibliothèques de communication fondamentales qui permettent des opérations collectives (telles que la réduction complète et la diffusion) dans le cadre de processus de formation distribués. Cependant, l'initialisation traditionnelle de NCCL et de Gloo peut créer des goulots d'étranglement lors de la restauration des défaillances.
Le processus de restauration standard exige que tous les processus soient connectés à un processus centralisé TCPStore et coordonnés via un processus racine, ce qui entraîne une surcharge coûteuse qui devient particulièrement problématique lors des redémarrages. Cette conception centralisée crée trois problèmes critiques : la surcharge de coordination due aux TCPStore connexions obligatoires, les délais de restauration, car chaque redémarrage doit répéter la séquence d'initialisation complète, et un point de défaillance unique dans le processus racine lui-même. Cela impose des étapes de coordination coûteuses et centralisées chaque fois que la formation est initialisée ou redémarrée.
HyperPod l'entraînement sans point de contrôle élimine ces problèmes de coordination, permettant ainsi de remédier plus rapidement aux défaillances en rendant l'initialisation « sans racine » et « ». TCPStoreless
Configurations sans racines
Pour activer Rootless, il suffit d'exposer les variables d'environnement suivantes.
export HPCT_USE_ROOTLESS=1 && \ sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
HPCT_USE_ROOTLESS : 0 ou 1. À utiliser pour activer et désactiver Rootless
sysctl -w net.ipv4.ip_local_port_range="20000 65535" : définit la plage de ports du système
Consultez l'exemple
Sans racines
HyperPod La formation sans point de contrôle propose de nouvelles méthodes d'initialisation, Rootless et, pour les groupes de processus TCPStoreless NCCL et Gloo.
La mise en œuvre de ces optimisations implique de modifier NCCL, Gloo et : PyTorch
Extension de la bibliothèque tierce APIs pour permettre les optimisations Rootless et Storeless NCCL et Gloo tout en maintenant la rétrocompatibilité
Mettre à jour les backends des groupes de processus pour utiliser de manière conditionnelle des chemins optimisés et gérer les problèmes de restauration en cours de processus
Contourner la TCPStore création coûteuse au niveau de la couche PyTorch distribuée tout en conservant des modèles d'adresses symétriques grâce à des compteurs de groupes globaux
Le graphique suivant montre l'architecture des bibliothèques de formation distribuées et les modifications apportées à la formation sans point de contrôle.
NCCL et Gloo
Il s'agit de packages indépendants qui exécutent les fonctionnalités de base des communications collectives. Ils fournissent des clés APIs, telles que ncclCommInit Rank, pour initialiser les réseaux de communication, gérer les ressources sous-jacentes et effectuer des communications collectives. Après avoir apporté des modifications personnalisées dans NCCL et Gloo, Rootless et Storeless optimisent (par exemple, en évitant de se connecter) l'initialisation du TCPStore réseau de communication. Vous pouvez alterner entre l'utilisation des chemins de code d'origine ou des chemins de code optimisés de manière flexible.
PyTorch backend de groupe de processus
Les backends du groupe de processus, en particulier ProcessGroup NCCL et NCCL ProcessGroupGloo, les implémentent ProcessGroup APIs en invoquant leurs bibliothèques APIs sous-jacentes correspondantes. Puisque nous étendons les bibliothèques tierces APIs, nous devons les invoquer correctement et effectuer des changements de chemin de code en fonction des configurations des clients.
Outre les chemins de code d'optimisation, nous modifions également le backend du groupe de processus pour prendre en charge la restauration en cours de processus.
