L'entraînement distribué en 2026 : DDP, FSDP2, DeepSpeed, Megatron et les cinq axes du parallélisme

Dès que vous avez plus d'un GPU dans une machine, un choix s'impose. Quatre stacks open source dominent aujourd'hui l'entraînement distribué — PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed et NVIDIA Megatron-Core — rejoints par TorchTitan, la nouvelle référence de l'entraînement à grande échelle en PyTorch natif. Chacun résout un problème différent. Se tromper coûte des semaines : soit le modèle ne tient pas et vous le découvrez au pas 30 avec un plantage mémoire, soit vous avez sur-dimensionné votre architecture pour une charge de travail que DDP aurait traitée avec dix fois moins d'ingénierie.

Cet article adopte le point de vue de l'acheteur et de l'architecte sur l'entraînement distribué. Il passe en revue les cinq axes de parallélisme, les quatre (désormais cinq) frameworks qui les combinent et les recettes qui fonctionnent réellement sur du matériel de classe Kentino — principalement 4× et 8× RTX 5090, 4090 et RTX Pro 6000 Blackwell sur hôtes AMD EPYC, avec PCIe Gen5 et Ethernet standard ou InfiniBand entre les nœuds. La conclusion honnête est donnée d'emblée, pour que le reste de l'article n'ait pas à la démontrer sans cesse : la plupart des clients Kentino font du fine-tuning, pas du pré-entraînement, et FSDP2 sur un seul nœud à 8 GPU couvre 90 % des besoins de fine-tuning. Megatron-Core et le parallélisme 3D ne se justifient que si vous pré-entraînez depuis zéro au-delà de l'échelle 30B, et ce club est bien plus restreint que le marketing ne le laisse croire.

Les cinq axes

Tout framework moderne d'entraînement distribué combine un sous-ensemble de ces cinq axes de parallélisme. Ce ne sont pas des alternatives — les recettes pour grands modèles en combinent trois ou quatre à la fois. Lisez la colonne communication de haut en bas : tout se joue là.

DP crie une fois par pas. TP crie deux fois par couche. PP chuchote une fois par étage. SP/CP crie une fois par bloc d'attention, mais selon une autre dimension. EP ne fait d'all-to-all que sur les couches MoE actives. Cette seule colonne décide de l'endroit où vit chaque axe — à l'intérieur d'une machine rapide, ou à travers un réseau plus lent.

Le « parallélisme 3D » évoqué dans chaque billet de blog NVIDIA, c'est DP × TP × PP. Ajoutez SP et EP et cela devient 4D ou 5D, ce qui relève plus du jeu de notation que du changement d'architecture. Ce qui compte, c'est la disposition : TP à l'intérieur du nœud (où la bande passante est bon marché), PP entre les nœuds (où elle est chère), DP par-dessus pour monter en débit. SP se glisse à côté de TP ; EP ne concerne que les MoE.

Renvois : la bande passante intra-nœud du parallélisme de tenseurs est détaillée dans K07, la pénalité NVLink contre PCIe dans N03, et le réseau inter-nœuds dans N08.

DDP — quand le modèle tient et que vous voulez juste plus de débit

PyTorch DDP (DistributedDataParallel) est la réponse la plus ancienne, la plus simple et toujours valable quand le modèle tient sur un seul GPU. Chaque rang détient une copie complète du modèle et de l'état de l'optimiseur. À chaque pas, chaque rang effectue sa propre passe avant, sa passe arrière et son calcul de gradients sur son micro-batch. Puis un unique all-reduce somme les gradients entre les rangs et tout le monde applique la même mise à jour.

DDP dans PyTorch 2.x est le même DDP qu'auparavant, avec deux améliorations à noter : un chemin static_graph=True plus robuste pour les graphes compatibles avec le compilateur, et une intégration plus étroite avec torch.compile. Le schéma de communication est inchangé — un all-reduce par pas, recouvert par la passe arrière, et une montée en charge linéaire jusqu'à ce que l'all-reduce domine.

Quand DDP est la bonne réponse :

• Le modèle complet + les états de l'optimiseur + les activations tiennent sur un seul GPU. Pour les optimiseurs de type Adam avec des poids maîtres FP32, la règle empirique est d'environ 16 octets par paramètre de mémoire pour le seul état entraînable (4 octets de poids, 4 octets de gradients, 8 octets d'optimiseur), plus les activations. Un modèle 8B = 128 GB d'état, ce qui ne tient sur un seul RTX Pro 6000 Blackwell (96 GB) qu'avec de la précision mixte et des poids maîtres BF16. En dessous de 8B paramètres, DDP est à l'aise sur un seul 5090 ; au-delà, regardez du côté de FSDP2.
• Vous visez le débit maximal, pas la taille maximale de modèle. DDP affiche le plus faible ratio communication/calcul de toutes les approches data-parallel, car les gradients ne sont réduits une seule fois par pas, après tout le travail local de passe arrière.
• Vous faites des rollouts d'apprentissage par renforcement, du LoRA, ou tout montage où chaque rang ne détient qu'un petit adaptateur entraînable par-dessus des poids de base gelés.

Quand DDP est le mauvais choix : le modèle ne tient pas. La solution n'est pas « réduire le batch ». La solution, c'est FSDP2.

torchrun --standalone --nproc-per-node=8 train.py

Voilà tout le lanceur. DDP est l'option par défaut ennuyeuse que tout le monde oublie, et pour la bonne charge de travail c'est ce qui tourne le plus vite.

FSDP2 — la nouvelle référence pour tout ce que DDP ne peut pas gérer

FSDP (Fully Sharded Data Parallel) répartit les paramètres du modèle, les gradients et les états de l'optimiseur sur le groupe data-parallel. Chaque GPU ne stocke que 1/N des paramètres. Pour une passe avant, le rang rassemble (all-gather) la couche dont il a besoin, effectue le calcul, puis jette les poids rassemblés. La mémoire chute d'environ un facteur N par rapport à DDP ; la communication augmente, car chaque couche est rassemblée puis rassemblée à nouveau.

L'histoire de 2025, c'est FSDP2. Le FSDP d'origine (FSDP1) regroupait les paramètres dans un unique FlatParameter, ce qui rendait pénible — voire impossible — tout raisonnement paramètre par paramètre : gel partiel, dtypes mixtes, réglages d'optimiseur par paramètre. FSDP2 a réécrit les entrailles au-dessus de DTensor : chaque tenseur reste un vrai torch.Tensor simplement découpé le long de sa dimension 0 entre les rangs. L'API publique est passée de FSDP(model, ...) à fully_shard(model, ...).

Ce que FSDP2 apporte réellement par rapport à FSDP1, d'après les benchmarks publiés et nos propres essais :

• ~7 % de mémoire GPU en moins sur Llama 2 7B à configuration identique, parce que FSDP2 évite le motif record_stream qui immobilisait la mémoire de façon pessimiste.
• ~1.5 % de débit en plus à configuration égale, et jusqu'à 50 % de débit en plus en combinaison avec torch.compile et torchao pour l'entraînement float8 sur du matériel de classe Hopper.
• Des state dicts shardés qui se chargent vite et se re-shardent proprement entre différentes dispositions de parallélisme — le format de checkpoint de FSDP1 était réputé difficile à remodeler entre entraînement et inférence.
• Le gel partiel de paramètres sans acrobaties, ce qui compte pour LoRA et l'entraînement d'adaptateurs.

FSDP1 est déprécié depuis PyTorch 2.11. Tout nouveau travail devrait utiliser fully_shard. L'ancien wrapper FullyShardedDataParallel existe encore par compatibilité, mais il est voué à disparaître.

FSDP2 expose aussi deux stratégies de sharding qui décident de l'endroit où vit le modèle :

• Full shard. Paramètres entièrement répartis sur tous les rangs (le défaut de FSDP1). Mémoire minimale, communication maximale.
• Hybrid shard. Paramètres répartis au sein d'un nœud et répliqués entre les nœuds. À l'intérieur du nœud, la communication passe par PCIe/NVLink (rapide). Entre les nœuds, seul l'all-reduce des gradients traverse le réseau lent. C'est le point d'équilibre idéal pour 2 à 4 nœuds sur Ethernet/IB 100/200 Gbps.

Quand FSDP2 est la bonne réponse (le cas Kentino le plus courant) :

• Fine-tuning de 8B à 70B sur un nœud à 8 GPU. Full shard, BF16, gradient checkpointing activé, torch.compile. Terminé.
• Fine-tuning de 70B à 405B sur 2 à 4 nœuds. Hybrid shard, avec full shard à l'intérieur de chaque nœud et réplication entre eux.
• Tout ce qui touche à LoRA / QLoRA — la gestion partielle des paramètres de FSDP2 surpasse nettement FSDP1.

from torch.distributed.fsdp import fully_shard, MixedPrecisionPolicy

mp = MixedPrecisionPolicy(param_dtype=torch.bfloat16, reduce_dtype=torch.float32)
for block in model.transformer_blocks:
    fully_shard(block, mp_policy=mp)
fully_shard(model, mp_policy=mp)

Lancé de la même manière que DDP, via torchrun. Seul le wrapper change.

DeepSpeed et les niveaux ZeRO — toujours là, mais plus la référence

DeepSpeed est la stack d'entraînement distribué de Microsoft. Sa gloire, c'est ZeRO (Zero Redundancy Optimizer), arrivé des années avant FSDP et qui a défini l'approche moderne du « tout sharder ».

ZeRO-3 est architecturalement équivalent au full shard de FSDP. Les deux résolvent le même problème avec les mêmes primitives de communication.

La réalité en 2025–2026 : FSDP2 a pris la place de DeepSpeed sur le cas d'usage des LLM denses. Natif PyTorch, sans paquet supplémentaire, intégré à torch.compile, et la même recette se porte sur Hugging Face Transformers, Accelerate et TorchTitan. Les benchmarks internes de Lightning et de Hugging Face montrent un full shard FSDP 2 à 5× plus rapide par itération que ZeRO-3 dans certains montages, même si DeepSpeed reprend du terrain sur les très gros modèles (10B+), où ses chemins d'offload CPU et NVMe restent réellement utiles.

DeepSpeed reste bon à connaître pour trois raisons :

1. L'offload ZeRO-Infinity. Si vous devez absolument affiner un modèle qui ne tient pas du tout dans la mémoire GPU agrégée — disons une base 405B sur une machine à 4× RTX Pro 6000 Blackwell — DeepSpeed peut décharger les paramètres vers la RAM CPU (bon marché, lent) puis vers le NVMe (encore moins cher, beaucoup plus lent). FSDP dispose aussi d'un offload CPU, mais le chemin NVMe de DeepSpeed est plus mature. Utile quand « j'ai une seule machine et un modèle têtu » ; pas la bonne réponse si vous pouvez louer ou acheter un second nœud.
2. Le parallélisme de séquence DeepSpeed-Ulysses. Un schéma de parallélisme de séquence économe en communication, qui utilise de l'all-to-all plutôt qu'un all-gather en anneau pour l'attention. Démontré jusqu'à des contextes de 1M de tokens sur 64 A100, et pour l'entraînement de Llama-8B avec 15M de tokens de contexte sur 32 H100 dans des travaux publiés en 2025. Si vous visez spécifiquement l'entraînement sur contexte très long, Ulysses garde une longueur d'avance sur l'implémentation context-parallel de Megatron pour certaines formes.
3. DeepSpeed-MoE. Entraînement de mixtures d'experts avec parallélisme d'experts. Peu pertinent pour le fine-tuning, très pertinent si vous pré-entraînez un MoE.

Pour l'essentiel du fine-tuning chez les clients Kentino, le bon choix est FSDP2, sauf raison précise d'aller vers DeepSpeed (contexte long, offload CPU/NVMe, pré-entraînement MoE). La dynamique de l'écosystème va sans ambiguïté vers FSDP2.

Megatron-LM, Megatron-Core, NeMo — là où vit l'artillerie lourde

Megatron est né de l'article NVIDIA sur le Transformer tensor-parallel en 2019. Aujourd'hui, la famille compte trois niveaux :

• Megatron-LM — la base de code de recherche d'origine. Toujours utilisée, toujours mise à jour.
• Megatron-Core — la version bibliothèque modulaire. Briques composables pour TP/PP/DP/EP/CP, précision mixte (FP16/BF16/FP8/FP4) et architectures de transformeurs de référence. C'est ce que vous intégrez réellement.
• NVIDIA NeMo — le framework de bout en bout bâti sur Megatron-Core. Recettes, pipelines de données, alignement, déploiement.

Megatron-Core est le framework qui l'emporte tout en haut de l'échelle, précisément parce qu'il implémente le parallélisme de tenseurs, de pipeline, de séquence, de contexte et d'experts dans un seul maillage composable. Quand vous entraînez un modèle dense de 405B sur plus de 512 GPU, vous ne pouvez pas éviter d'en combiner au moins trois, et Megatron-Core est la combinaison la plus déployée et la plus éprouvée.

Les recommandations de parallélisme Megatron pour 2026, tirées de la documentation NVIDIA elle-même, collent à la réalité matérielle :

Ce tableau explique pourquoi Megatron existe. C'est le framework dont les auteurs vivent avec les calculs de bande passante décrits dans N03 et K07, et ses recettes sont réglées pour cela.

Quand Megatron est excessif : tout fine-tuning sur un seul nœud, tout modèle qui tient dans une mémoire compatible FSDP2, toute charge de travail sans besoin de TP. La mécanique TP de Megatron est effectivement plus rapide qu'un TP maison sur PCIe, mais le TP sur PCIe reste lent — voyez les chiffres de K07. La force de Megatron s'exprime sur du matériel SXM, que Kentino ne construit pas.

Quand Megatron est la bonne réponse : pré-entraîner des modèles denses de 70B à 405B+ sur du matériel de classe NVLink loué ou possédé, ou bâtir une infrastructure d'entraînement de production pour un laboratoire de recherche. Si c'est votre cas, vous êtes probablement déjà dans l'écosystème NeMo.

TorchTitan — la nouvelle référence

TorchTitan est la référence d'entraînement à grande échelle en PyTorch natif signée Meta, acceptée à ICLR 2025 et devenue l'exemple de fait pour répondre à « à quoi doit ressembler une recette TP × PP × FSDP2 × CP en 2026 ? ». Elle n'invente aucun parallélisme — elle compose les briques déjà livrées avec PyTorch (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor) en un script d'entraînement parallèle quadridimensionnel propre, avec checkpointing shardé asynchrone, torch.compileet float8.

Pourquoi cela compte même si vous ne l'utilisez pas directement :

• C'est le parfait exemple de la façon dont FSDP2 se compose avec TP et PP sans framework tiers.
• Les mêmes API sont livrées dans PyTorch standard. Il n'y a là rien de magique.
• AMD a publié un fork TorchTitan optimisé pour ROCm fin 2025 ; le partenariat avec Lightning AI annoncé en octobre 2025 rend les recettes TorchTitan exécutables sur Lightning Studios.

Pour les clients de classe Kentino, TorchTitan est une référence à lire plus qu'un framework à déployer. Si vous faites du fine-tuning, Accelerate ou Axolotl au-dessus de FSDP2 sont plus ergonomiques. Si vous pré-entraînez à échelle modeste (8 à 64 GPU) sur du matériel standard, TorchTitan rivalise avec NeMo pour bien moins de lourdeur opérationnelle.

La matrice des frameworks

Accelerate et Axolotl ne sont pas des stratégies de parallélisme distinctes — ils encapsulent les backends ci-dessus. La plupart des clients Kentino qui font du fine-tuning finiront par utiliser Axolotl au-dessus de FSDP2 sans y penser, et c'est très bien ainsi.

Le budget de communication — pourquoi votre réseau limite le modèle

Renvoi : N08 détaille les calculs de RDMA et de lien montant ; voici la vue propre à l'entraînement.

Pour le parallélisme de données (DDP ou FSDP), la communication inter-rangs par pas est à peu près proportionnelle au nombre de paramètres (gradients à réduire). Pour le parallélisme de tenseurs, elle est proportionnelle à la taille des activations × le nombre de couches — des ordres de grandeur de plus à chaque pas.

Volume de gradients, à la louche, pour un seul pas en BF16 :

L'all-reduce de 70B à lui seul prend 5.6 secondes sur un réseau à 200 Gbps. Si votre calcul avant+arrière sur un pas dure aussi 5 secondes, vous êtes déjà limité à 50 % par la communication ; si le calcul dure 2 secondes, vous êtes inactif plus de 70 % du temps à attendre le réseau. C'est pourquoi le 100 GbE étrangle l'entraînement au-delà de 70B et qu'il vous faut du 400 GbE / NDR IB. Le calcul accélère sans cesse ; le réseau doit suivre, sinon les GPU attendent.

FSDP2 en masque une partie par recouvrement (commencer à rassembler la couche suivante pendant le calcul de la courante). Le hybrid shard en masque davantage en gardant l'all-reduce des gradients dans le réseau intra-nœud rapide et en ne réduisant que les gradients répliqués entre les nœuds. Les chiffres ci-dessus sont le pire cas pour un FSDP full shard entre nœuds, sans recouvrement.

Pour le parallélisme de tenseurs, la communication par token évolue avec la taille cachée et le nombre de couches. Les chiffres de K07 le montrent : ~80 MB par token généré pendant le décodage, ~300 GB par préremplissage sur 70B en batch 32. C'est le régime où le PCIe (50 GB/s en pratique) est environ 14× plus lent que NVLink (700+ GB/s en pratique), et où pré-entraîner un modèle dense de 70B+ sur PCIe ne fonctionne tout simplement pas à un rendement acceptable.

Recettes concrètes

Fine-tuning d'un Llama 8B, un nœud à 8 GPU — FSDP2

Matériel : 8× RTX 5090 ou 8× RTX Pro 6000 Blackwell, hôte EPYC, aucun réseau inter-nœuds nécessaire.

torchrun --standalone --nproc-per-node=8 \
  finetune.py \
    --model meta-llama/Llama-3.1-8B \
    --batch-size 1 --grad-accum 16 --seq-len 4096 \
    --bf16 --fsdp full_shard --fsdp-reshard-after-forward \
    --gradient-checkpointing --torch-compile

Attendu : ~2000 tok/s agrégés en BF16, avec de la marge pour les KV/activations ; le full shard FSDP2 sur PCIe Gen5 gère l'all-reduce des gradients à l'intérieur de la machine. C'est aussi à quoi ressemblent 90 % des travaux de fine-tuning chez Kentino.

Fine-tuning d'un Llama 70B, 2× nœuds à 8 GPU — FSDP2 hybrid shard

Matériel : 2× 8× RTX Pro 6000 Blackwell, 200 Gbps IB ou 100 GbE RoCE entre les nœuds.

torchrun --nnodes=2 --nproc-per-node=8 \
  --rdzv-backend=c10d --rdzv-endpoint=node0:29500 \
  finetune.py \
    --model meta-llama/Llama-3.3-70B \
    --batch-size 1 --grad-accum 32 --seq-len 4096 \
    --bf16 --fsdp hybrid_shard \
    --gradient-checkpointing --torch-compile \
    --activation-cpu-offload

Le hybrid shard conserve le full shard à l'intérieur de chaque nœud à 8 GPU et réplique entre les 2 nœuds. Le réseau inter-nœuds ne transporte que le reduce-scatter des gradients répliqués — environ 70 GB/pas en BF16, soit ~3 s sur de l'IB 200 Gbps. Le recouvrement en masque l'essentiel. En 100 GbE, le même pas coûte ~5–6 s et les GPU commencent à montrer du temps d'inactivité ; la recette fonctionne toujours, simplement plus lentement par époque.

Pré-entraînement d'un 405B, 8× nœuds à 8 GPU — Megatron-Core 3D

Matériel : 8× nœuds à 8 GPU NVLink/SXM, 400 Gbps NDR IB. Non construit par Kentino — pour information.

# Megatron-Core launcher (abbreviated)
torchrun --nnodes=8 --nproc-per-node=8 \
  pretrain_gpt.py \
    --tensor-model-parallel-size 8 \
    --pipeline-model-parallel-size 8 \
    --sequence-parallel \
    --context-parallel-size 1 \
    --num-layers 126 --hidden-size 16384 --num-attention-heads 128 \
    --seq-length 8192 --micro-batch-size 1 --global-batch-size 2048 \
    --bf16 --use-flash-attn --transformer-impl transformer_engine

TP=8 × PP=8 = 64 rangs par réplique ; 8 nodes × 8 GPUs = 64 GPUs au total, soit exactement une réplique. Pour passer à plusieurs répliques et augmenter le débit, multipliez par DP. C'est là que Megatron justifie son existence. Le même modèle sur FSDP2 seul passerait l'essentiel de son temps en communication inter-rangs ; la disposition 3D place la communication la plus lourde (TP) à l'intérieur du domaine NVLink.

Notre avis franc pour les clients Kentino

La plupart des clients Kentino ne pré-entraînent pas. Ils affinent des modèles de base à poids ouverts — Llama, Qwen, Mistral, parfois Gemma — sur leurs données métier, parfois en LoRA ou QLoRA, parfois en fine-tuning complet. Pour ce travail, le choix du framework est le suivant :

• Un modèle qui tient sur un seul GPU en BF16, état de l'optimiseur compris. Utilisez DDP. Répliquez les copies pour le débit.
• Un modèle qui ne tient pas sur un seul GPU mais tient en agrégé sur un nœud à 8 GPU. Utilisez le full shard FSDP2. Cela couvre les fine-tunings de 8B à 70B.
• Un modèle qui tient en agrégé sur deux nœuds à 8 GPU. Utilisez le hybrid shard FSDP2. Fine-tunings de 70B à 200B.
• Un modèle plus gros que cela, ou un pré-entraînement depuis zéro. C'est la conversation où Megatron-Core, le matériel SXM et l'IB NDR ont leur place. Nous construisons le stockage et le plan de gestion, mais les GPU sont en général loués pour cette phase.

Les 10 % de clients qui ont réellement besoin d'un entraînement multi-nœuds fortement couplé sont surtout des laboratoires de recherche dotés de programmes de pré-entraînement financés, et ils savent ce qu'il leur faut avant même d'appeler. Les 90 % restants ne devraient pas se voir vendre un cluster — mais un seul nœud à 8 GPU bien spécifié, avec l'amorce réseau nécessaire pour un second nœud plus tard, l'équipement réseau restant une ligne budgétaire de priorité P2.

---

Cet article fait partie du Kentino Wiki, une série de référence sur le calcul IA, la robotique et les systèmes qui les relient. Commentaires et corrections bienvenus à info@kentino.com.