Technique
Schéma animé : un pas d'entraînement distribué
Pour : ingénieurs et SRE · architectesPrérequis : Notions de base sur l'entraînement de modèles sur GPU.
En entraînement distribué par parallélisme de données, chaque GPU calcule des gradients sur sa part du lot, puis tous les GPU en font la moyenne avant de mettre à jour le modèle. Cette moyenne, l’AllReduce, impose une barrière : personne ne peut commencer avant que le plus lent ait fini. L’animation déroule un pas sur 8 GPU, phase par phase et montre ce que les tableaux de bord habituels ne montrent pas. Le détail des phases est dans le chapitre Anatomie d’un pas d’entraînement distribué.
Paramètres
Les 8 GPU et le ring AllReduce
Chronologie du pas, GPU par GPU
Ce que le pas coûte
Durées illustratives : chargement 6 ms, passe avant 10 ms, passe arrière 16 ms, AllReduce 10 ms, optimiseur 2 ms ; le ralentissement s'applique aux passes avant et arrière du traînard. Simplification : les phases sont séquentielles ; en pratique PyTorch DDP recouvre une partie de l'AllReduce avec la passe arrière (gradients regroupés par seaux), ce qui réduit l'attente sans la supprimer.
À essayer
Section intitulée « À essayer »- Regardez un pas sans traînard. Pendant l’AllReduce, chaque GPU envoie un huitième de ses gradients à son voisin, quatorze fois de suite : sept étapes de reduce-scatter (les petites cases de chaque GPU se remplissent à mesure que les contributions s’additionnent), puis sept étapes d’all-gather (chaque GPU reçoit les morceaux déjà moyennés). Utilisez « Étape suivante » pour suivre les échanges un par un.
- Ralentissez le GPU 2 à 1,5×. Les sept autres finissent leur passe arrière et attendent, hachurés, à la barrière. La durée du pas passe de 44 à 57 ms et l’efficacité tombe vers 77 %. Pourtant l’utilisation GPU affichée augmente : l’attente est comptée comme de l’occupation.
- Comparez les deux jauges. À 2×, l’utilisation affichée dépasse 90 % alors que le calcul utile tombe sous 25 %. C’est l’écart de l’exemple illustratif du chapitre de référence : 87 % affichés pour environ 19 % de calcul réel.
- Activez le préchargement. Le chargement des données se recouvre avec le calcul et disparaît presque de la chronologie : le pas raccourcit et le calcul utile progresse. Avec un traînard à 2×, le gain reste de 5 ms alors que le traînard en coûte 26 : on ne corrige pas un problème de synchronisation par une optimisation des entrées-sorties.
Ce que l’animation simplifie
Section intitulée « Ce que l’animation simplifie »Les durées sont des ordres de grandeur choisis pour la lisibilité et les phases sont strictement séquentielles. En pratique, PyTorch DDP lance l’AllReduce par paquets de gradients pendant la passe arrière, ce qui masque une partie de la communication et NCCL découpe chaque envoi en morceaux plus fins. Le principe reste : un ring AllReduce fait circuler environ 2 × (N - 1) / N fois la taille des gradients par GPU et la barrière aligne tout le monde sur le plus lent.
Ce qu’il faut mesurer en vrai
Section intitulée « Ce qu’il faut mesurer en vrai »| Question | Quoi mesurer | Avec quel outil |
|---|---|---|
| Le pas ralentit-il ? | durée de pas, par rang et en médiane | instrumentation de la boucle d’entraînement (horodatage par pas et par rang), exportée vers une base de séries temporelles (VictoriaMetrics, Prometheus ou un équivalent SaaS) |
| Y a-t-il un traînard ? | écart entre le rang le plus lent et la médiane | même métrique, alerte sur l’écart plutôt que sur la moyenne |
| Le GPU calcule-t-il vraiment ? | activité des SM, occupation, utilisation des tensor cores | métriques de profilage DCGM : DCGM_FI_PROF_SM_ACTIVE, DCGM_FI_PROF_SM_OCCUPANCY, DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, via dcgm-exporter |
| Où part le temps du pas ? | décomposition chargement, calcul, communication | PyTorch Profiler ou Nsight Systems sur quelques pas, pas en continu |
| Le réseau est-il en cause ? | latence des collectives, retransmissions et attentes sur les ports InfiniBand | logs NCCL (NCCL_DEBUG=INFO), compteurs de ports InfiniBand |
DCGM_FI_DEV_GPU_UTIL, l’équivalent de la colonne d’utilisation de nvidia-smi, mesure seulement la part du temps où un noyau tourne : utile pour repérer un GPU inactif, trompeur pour juger de l’efficacité. La pile complète est décrite dans La pile d’observabilité HPC IA et le simulateur de l’effet traînard chiffre le coût à l’échelle d’un cluster.