Accueil › Glossaire › Model Parallelism

Model Parallelism

Le model parallelism (parallélisme de modèle) est une technique d’entraînement distribué qui partitionne un modèle de deep learning sur plusieurs GPU ou accélérateurs, permettant d’entraîner des réseaux qui dépassent la mémoire d’un seul processeur.

Quand un modèle fait 70 milliards de paramètres, il ne tient pas sur un seul GPU. Même avec 80 Go de HBM (la VRAM d’un H100), les poids, les gradients, les états de l’optimiseur et les activations explosent la mémoire disponible. Le model parallelism résout ce problème en découpant le modèle lui-même (et non les données) entre plusieurs processeurs qui travaillent en coordination.

Contrairement au data parallelism, qui réplique le modèle complet sur chaque GPU et distribue les mini-batches, le model parallelism partitionne l’architecture neuronale. C’est la brique fondamentale qui a rendu possible l’entraînement de GPT-3 (175B paramètres), DeepSeek V3 (671B paramètres MoE), et tous les LLM modernes à très grande échelle.

Pourquoi le model parallelism est indispensable

La croissance des LLM suit une trajectoire exponentielle. En quelques années, on est passé de BERT (340M paramètres) à des modèles dépassant le trillion de paramètres. Cette explosion crée un problème physique simple : la mémoire GPU ne suit pas.

Prenons un modèle de 70 milliards de paramètres en FP32. Les poids seuls occupent 280 Go (70B × 4 octets). En BF16, on descend à 140 Go, ce qui reste bien au-delà de la capacité d’un seul GPU (80 Go pour un H100, 192 Go pour un MI300X). Et il faut encore stocker les gradients, les états de l’optimiseur Adam (2 états supplémentaires par paramètre), et les activations intermédiaires.

Le budget mémoire total pour entraîner un modèle se décompose ainsi :

Le model parallelism est la réponse architecturale à ce défi. En partitionnant le modèle entre plusieurs GPU, chaque processeur ne stocke qu’une fraction des poids, des gradients et des états. Le coût est un overhead de communication entre les GPU, mais c’est le prix à payer pour rendre l’entraînement physiquement possible.

Les différents types de model parallelism

Le terme « model parallelism » recouvre en réalité plusieurs stratégies distinctes. Chacune partitionne le modèle différemment, avec des compromis spécifiques en termes de mémoire, de latence et de communication.

Tensor Parallelism (TP)

Le tensor parallelism (aussi appelé intra-layer parallelism) découpe les matrices de poids individuelles d’une couche entre plusieurs GPU. Concrètement, dans un bloc Transformer, les multiplications matricielles du MLP et de l’attention sont réparties sur N GPU qui calculent chacun une portion du résultat, puis synchronisent via des opérations all-reduce.

Cette technique a été formalisée par le paper Megatron-LM de NVIDIA en 2019. L’idée clé : dans un MLP à deux couches, on partitionne la première matrice en colonnes (column-parallel) et la seconde en lignes (row-parallel). Cela ne nécessite qu’un seul all-reduce dans la passe forward et un dans la passe backward par couche.

En pratique, pour le déploiement avec vLLM, vous configurez le TP avec le paramètre --tensor-parallel-size. Par exemple, pour servir un modèle Llama 70B sur 8 GPU :

vllm serve meta-llama/Llama-3-70B 
    --tensor-parallel-size 8

Pipeline Parallelism (PP)

Le pipeline parallelism (ou inter-layer parallelism) distribue les couches du modèle séquentiellement entre les GPU. Le GPU 0 traite les couches 1 à 8, le GPU 1 les couches 9 à 16, etc. Les activations sont passées d’un GPU au suivant comme dans une chaîne d’assemblage.

Le problème fondamental du PP est la « bulle de pipeline » (pipeline bubble) : quand le GPU 3 calcule, les GPU 0, 1 et 2 sont potentiellement inactifs, ce qui gaspille des ressources. Plusieurs algorithmes ont été développés pour réduire cette bulle :

L’algorithme DualPipe, introduit par DeepSeek pour l’entraînement de V3/R1, est une avancée notable. Il crée un flux bidirectionnel qui chevauche les passes forward et backward en sens opposés, ce qui réduit drastiquement le temps d’inactivité. DeepSeek a open-sourcé DualPipe sur GitHub en février 2025.

Expert Parallelism (EP)

L’expert parallelism est spécifique aux modèles Mixture of Experts (MoE). Au lieu de répliquer tous les experts sur chaque GPU, l’EP distribue les experts entre les GPU. Chaque processeur héberge un sous-ensemble d’experts et ne traite que les tokens qui sont routés vers ses experts.

DeepSeek V3 utilise un EP à 64 voies réparti sur 8 noeuds, combiné avec un PP à 16 voies. Cette configuration évite le tensor parallelism coûteux (un choix délibéré vu la bande passante limitée des GPU H800) tout en permettant d’entraîner un modèle MoE de 671B paramètres.

Sequence Parallelism (SP)

Le sequence parallelism distribue le calcul le long de la dimension de la séquence. Il est typiquement utilisé en complément du tensor parallelism pour les opérations qui ne bénéficient pas du TP (comme LayerNorm ou Dropout). Le SP réduit la mémoire des activations en partitionnant les tenseurs intermédiaires sur la dimension séquentielle.

Le context parallelism (CP) va plus loin en partitionnant les activations de toutes les couches le long de la séquence. C’est particulièrement utile pour l’entraînement avec de très longues séquences (long context). Megatron-LM supporte nativement le CP via le paramètre context_parallel_size.

Model Parallelism vs Data Parallelism

La distinction fondamentale : le data parallelism réplique le modèle, le model parallelism le partitionne.

En réalité, les systèmes modernes combinent les deux. On parle de parallélisme 3D quand on utilise simultanément le tensor parallelism, le pipeline parallelism et le data parallelism. La formule de base est :

nombre_total_GPU = TP × PP × DP

Par exemple, sur un cluster de 128 GPU (16 noeuds × 8 GPU), une configuration typique serait TP=8 (intra-noeud), PP=4 (inter-noeud), DP=4 (réplication).

FSDP : le meilleur des deux mondes

Fully Sharded Data Parallelism (FSDP), popularisé par PyTorch et par ZeRO de DeepSpeed, brouille la frontière entre data et model parallelism. FSDP fragmenté distribue les poids, les gradients et les états de l’optimiseur entre les GPU (comme le model parallelism) mais les reconstruit temporairement pour le calcul (comme le data parallelism).

FSDP fonctionne en trois étapes par couche :

1. All-gather : reconstitue les poids complets de la couche courante à partir des fragments distribués.

2. Calcul : exécute le forward ou backward normalement avec les poids complets.

3. Libération + Reduce-scatter : libère les poids reconstitués et distribue les gradients.

En mars 2026, NVIDIA a publié Megatron-FSDP, une implémentation haute performance qui promet jusqu’à 25% d’accélération et 23% d’économie mémoire par rapport à PyTorch FSDP2. Cette implémentation est compatible avec Megatron-LM, Hugging Face Transformers et TransformerEngine.

Frameworks et outils pour le model parallelism

L’écosystème des outils de parallélisme a considérablement mûri. Voici les frameworks principaux et leurs forces respectives.

Megatron-LM (NVIDIA)

Megatron-LM est le framework de référence pour l’entraînement de LLM à grande échelle. Développé par NVIDIA, il a popularisé le tensor parallelism pour les Transformers et supporte aujourd’hui l’ensemble du spectre : TP, PP, DP, EP, CP et FSDP. Le framework intègre Megatron Core, une bibliothèque modulaire avec des implémentations optimisées de chaque stratégie de parallélisme.

En mars 2026, Megatron-LM a ajouté le Context Parallelism dynamique (jusqu’à 1,48x d’accélération pour les séquences de longueur variable) et Megatron Bridge pour l’interopérabilité entre checkpoints Hugging Face et Megatron.

DeepSpeed (Microsoft)

DeepSpeed a été pionnier avec ZeRO (Zero Redundancy Optimizer), qui élimine la redondance de mémoire dans le data parallelism distribué. ZeRO se décline en trois stages : ZeRO-1 (fragmente les états optimiseur), ZeRO-2 (ajoute les gradients), ZeRO-3 (ajoute les poids). DeepSpeed supporte aussi le pipeline parallelism et l’offloading CPU/NVMe pour les configurations à mémoire limitée.

PyTorch natif

PyTorch intègre désormais nativement le tensor parallelism via torch.distributed.tensor.parallel, FSDP via torch.distributed.fsdp, et le pipeline parallelism via torch.distributed.pipelining. L’abstraction DeviceMesh permet de configurer des topologies de parallélisme multi-dimensionnel de façon déclarative.

Colossal-AI

Framework open-source qui propose une interface unifiée pour le parallélisme multi-dimensionnel. Colossal-AI se distingue par sa facilité d’utilisation : quelques lignes de configuration suffisent pour activer TP+PP+DP, avec du auto-partitionnement basé sur les contraintes matérielles.

Model parallelism en pratique : guide de configuration

Configurer le parallélisme pour un entraînement ou une inférence demande de comprendre les contraintes matérielles et de choisir la bonne combinaison.

Règles de base

Le choix de la stratégie de parallélisme dépend de la topologie réseau de votre cluster. La bande passante entre GPU dicte ce qui est faisable :

Intra-noeud (NVLink, 600-900 Go/s) : c’est le domaine du tensor parallelism. La bande passante est suffisante pour les all-reduce fréquents que le TP exige. Utilisez TP=4 ou TP=8 selon le nombre de GPU par noeud.

Inter-noeud (InfiniBand, 50-400 Go/s) : utilisez le pipeline parallelism. Les communications point-à-point entre stages sont moins exigeantes que les all-reduce du TP.

À grande échelle (1000+ GPU) : combinez les trois dimensions. Le DP absorbe le reste des GPU après que TP et PP ont couvert les besoins mémoire.

Exemple avec Megatron-LM

Pour entraîner un modèle de type GPT avec 32 GPU (4 noeuds × 8 GPU) :

python pretrain_gpt.py 
    --tensor-model-parallel-size 8 
    --pipeline-model-parallel-size 2 
    --micro-batch-size 1 
    --global-batch-size 64 
    --num-layers 48 
    --hidden-size 8192 
    --num-attention-heads 64 
    --seq-length 4096 
    --bf16

Dans cette configuration, le data parallelism est calculé automatiquement : DP = 32 / (8 × 2) = 2. Le modèle est fragmenté par tenseurs au sein de chaque noeud (TP=8), les couches sont réparties en 2 stages de pipeline (PP=2), et il y a 2 répliques data-parallèles.

Exemple avec vLLM pour l’inférence

Pour servir un modèle sur 2 noeuds de 8 GPU :

vllm serve meta-llama/Llama-3-70B 
    --tensor-parallel-size 8 
    --pipeline-parallel-size 2 
    --distributed-executor-backend ray

Le cas DeepSeek V3 : une leçon de parallélisme optimisé

L’entraînement de DeepSeek V3 est un cas d’école fascinant. L’équipe a dû composer avec des GPU H800 (version bridée des H100 pour le marché chinois) dont la bande passante NVLink est réduite. Leur solution : éviter complètement le tensor parallelism, qui est trop gourmand en communication.

La configuration retenue : 16 voies de pipeline parallelism (PP=16), 64 voies d’expert parallelism (EP=64) réparties sur 8 noeuds, et du ZeRO-1 pour le data parallelism. L’algorithme DualPipe a été spécifiquement conçu pour chevaucher la computation et la communication des experts distribués entre noeuds.

Résultat : l’entraînement complet de DeepSeek V3 (14,8 trillions de tokens) a coûté environ 5,5 millions de dollars, une fraction du coût estimé pour des modèles comparables. Cet exploit démontre qu’un parallélisme bien pensé peut compenser des limitations matérielles.

Défis et pièges courants

Le coût de la bulle de pipeline

En pipeline parallelism, les GPU au début et à la fin du pipeline sont inactifs pendant les phases de remplissage et de vidange. Plus le nombre de stages PP est élevé, plus la bulle grandit proportionnellement. La solution classique est d’augmenter le nombre de micro-batches pour amortir la bulle, mais cela augmente la mémoire des activations.

Équilibrage de charge

Si les couches n’ont pas un coût computationnel uniforme, certains GPU terminent avant d’autres et attendent. C’est particulièrement problématique pour les modèles MoE où le routage des tokens vers les experts peut être déséquilibré. DeepSeek a open-sourcé EPLB (Expert-Parallel Load Balancer) pour résoudre ce problème.

Overhead de communication

Chaque forme de parallélisme introduit de la communication inter-GPU. Le tensor parallelism est le plus exigeant (all-reduce synchrone à chaque couche), suivi du pipeline parallelism (envoi d’activations entre stages), puis du data parallelism (all-reduce des gradients en backward). Optimiser le ratio computation/communication est l’enjeu central de tout système distribué.

Problèmes de normalisation

La batch normalization pose problème en parallélisme distribué car les statistiques du batch sont locales à chaque GPU. Avec le pipeline parallelism et de petits micro-batches, les statistiques deviennent instables. La solution : utiliser la Group Normalization ou la RMSNorm, qui ne dépendent pas de la taille du batch. C’est pourquoi les LLM modernes utilisent quasi-exclusivement RMSNorm.

Checkpointing et reprise

Sauvegarder et charger un modèle distribué est complexe : chaque GPU possède un fragment différent. Le checkpoint doit capturer la topologie de parallélisme. Megatron-LM supporte le reshaping de checkpoints (conversion entre différentes configurations TP/PP), ce qui permet de reprendre un entraînement avec une topologie différente.

Évolutions et tendances

Le model parallelism continue d’évoluer rapidement. Plusieurs tendances se dessinent :

Auto-parallélisme : des systèmes comme Alpa (Google Research) cherchent à automatiser le choix de la stratégie de parallélisme. L’objectif est de prendre un modèle et un cluster en entrée et de produire automatiquement la meilleure configuration. AutoML pour le parallélisme, en quelque sorte.

Overlap maximal : la tendance initiée par DualPipe va s’accentuer. L’objectif est de recouvrir 100% de la communication par du calcul utile. Les frameworks intègrent de plus en plus de stratégies d’overlap sophistiquées entre les phases de calcul et de communication.

Spécialisation matérielle : les interconnexions entre GPU évoluent (NVLink 5.0 avec 1,8 To/s, UALink consortium). Des bandes passantes plus élevées rendent le tensor parallelism viable sur des topologies plus larges, réduisant la complexité de configuration.

Parallélisme pour l’inférence : l’inférence de LLM à grande échelle utilise de plus en plus le tensor et le pipeline parallelism. vLLM, TensorRT-LLM et d’autres moteurs d’inférence supportent nativement ces stratégies pour réduire la latence et augmenter le throughput.