Pipeline Parallelism

Le parallélisme de pipeline est une technique d’entraînement distribué qui découpe un réseau de neurones en profondeur en groupes consécutifs de couches appelés étapes, place chaque étape sur son propre GPU et transmet les activations d’une étape à la suivante. Pour occuper tous les GPU, chaque lot est divisé en micro-lots plus petits qui traversent les étapes comme des pièces sur une chaîne de montage. Cette technique est aussi appelée parallélisme de modèle entre couches. Les chercheurs de Google dirigés par Yanping Huang ont popularisé l’approche par micro-lots avec GPipe en novembre 2018 : ils ont entraîné un modèle AmoebaNet de 557 millions de paramètres à atteindre une précision top-1 de 84,4 % sur ImageNet, ainsi qu’un transformeur multilingue de traduction de 6 milliards de paramètres et 128 couches transformer.

Micro-lots et bulle du pipeline#

Avec un seul lot à la fois, une seule étape travaille tandis que les autres attendent : l’étape 2 ne peut commencer avant la fin de l’étape 1, et l’ordre s’inverse pendant la rétropropagation. Les micro-lots permettent à l’étape 1 de commencer le deuxième dès qu’elle a transmis le premier à l’étape 2. Les périodes d’inactivité restantes pendant le remplissage et la vidange du pipeline sont appelées la bulle. L’affichage d’un calendrier de propagation avant de type GPipe, pour 4 étapes et 6 micro-lots, en montre la forme :

stages, micro_batches = 4, 6
steps = micro_batches + stages - 1  # time steps until the last micro-batch leaves the last stage

for stage in range(stages):
    row = ""
    for t in range(steps):
        m = t - stage  # stage s starts micro-batch m once stage s-1 hands it over
        row += f" F{m}" if 0 <= m < micro_batches else "  ."
    print(f"GPU {stage}:{row}")

# Every stage idles for stages - 1 of the steps, in the forward and again in the backward pass
bubble = (stages - 1) / steps
print(f"Idle fraction: {bubble:.0%}")

Le résultat forme un escalier : le GPU 0 exécute des passes avant F0 à F5 pendant les six premières des neuf étapes, puis attend ; le GPU 3 attend trois étapes avant de commencer F0, et la dernière ligne affiche Idle fraction: 33%. La fraction de bulle est égale à (étapes − 1) / (micro-lots + étapes − 1) ; 24 micro-lots traversant les mêmes 4 étapes la réduisent donc à 11 %. Les gradients de tous les micro-lots s’additionnent avant une seule étape de l’optimiseur, selon le même calcul que l’accumulation des gradients ; la mise à jour équivaut donc à un entraînement sur le lot complet. GPipe supprime également les activations à l’intérieur de chaque étape et les recalcule pendant la passe arrière, une forme de checkpointing des gradients.

Calendriers de pipeline#

Les calendriers ultérieurs réorganisent le même travail pour économiser de la mémoire ou réduire la bulle :

• 1F1B : introduit par le système PipeDream en 2018, il alterne un micro-lot en propagation avant et un en propagation arrière par étape, une fois le pipeline rempli. Chaque étape ne conserve alors les activations que pour un nombre de micro-lots au plus égal au nombre d’étapes, plutôt que pour tous.
• 1F1B entrelacé : attribue à chaque GPU plusieurs étapes plus petites et non adjacentes. L’équipe Megatron-LM de NVIDIA a signalé un débit supérieur de plus de 10 % avec cette méthode et a entraîné un modèle de 1 000 milliards de paramètres à 502 pétaFLOP/s sur 3 072 GPU, soit 52 % du maximum théorique.
• Zéro bulle : divise la passe arrière en deux gradients : celui de l’entrée de l’étape, dont l’étape précédente a besoin, et celui des poids, qui peut remplir les périodes d’inactivité ultérieures. Cette méthode dépasse le débit de 1F1B jusqu’à 23 % avec un budget mémoire similaire.

PyTorch fournit ces éléments sous la forme de ScheduleGPipe, Schedule1F1B, ScheduleInterleaved1F1B, ScheduleInterleavedZeroBubble et ScheduleDualPipeV dans son API de pipeline, et cette API découpe également un modèle en étapes. L’équipe de DeepSeek-V3 a exécuté 16 étapes de pipeline et a utilisé DualPipe pour faire se chevaucher le calcul et la communication et réduire la bulle.

Place du parallélisme de pipeline#

Les étapes n’échangent que les activations à leurs frontières, une fois par micro-lot ; le parallélisme de pipeline tolère donc mieux les connexions plus lentes entre serveurs que le parallélisme tensoriel, qui communique à l’intérieur de chaque couche. Les grands entraînements combinent donc ces techniques. Meta a entraîné Llama 3 405B avec un parallélisme tensoriel à 8 voies au sein de chaque serveur à 8 GPU, 16 étapes de pipeline entre les serveurs et un parallélisme des données sur 64 à 128 répliques ; des moteurs d’inférence comme vLLM utilisent la même répartition lorsqu’un grand modèle de langage (LLM) nécessite plusieurs nœuds. L’étape la plus lente détermine le rythme de tout le pipeline, et les première et dernière étapes d’un modèle de langage comprennent aussi la table d’incorporation et la couche de sortie ; Llama 3 leur a donc attribué chacune une couche de transformeur de moins.

Les approches connexes répartissent le travail différemment :

• Parallélisme tensoriel : découpe les matrices de poids à l’intérieur de chaque couche, de sorte que chaque GPU participe à chaque couche.
• Parallélisme du contexte : répartit une longue séquence d’entrée entre les GPU.
• Apprentissage fédéré par découpage : découpe également un réseau en profondeur, mais entre des organisations, afin que le propriétaire des données n’envoie jamais de données brutes au serveur exécutant les couches suivantes.

Le parallélisme des données conserve chaque couche sur chaque GPU et répartit plutôt le lot ; c’est tout ce dont un modèle a besoin lorsqu’il tient sur un seul appareil. C’est ainsi qu’Ultralytics YOLO26 s’entraîne sur plusieurs GPU : avec device=[0, 1, 2, 3] et batch=64 en mode entraînement, chaque GPU exécute le modèle complet de détection d’objets sur 16 images, et PyTorch DistributedDataParallel calcule la moyenne des gradients entre les GPU après chaque passe arrière.