Formation distribuée en 2026 : DDP, FSDP2, DeepSpeed, Megatron et les cinq axes du parallélisme

Dès lors que vous disposez de plusieurs GPU, un choix s'impose. Quatre solutions open source dominent aujourd'hui l'entraînement distribué : PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed ​​et NVIDIA Megatron-Core, auxquelles s'ajoute TorchTitan, la nouvelle référence pour l'entraînement à grande échelle en PyTorch natif. Chacune de ces solutions répond à un besoin spécifique. Un mauvais choix peut entraîner une perte de semaines : soit le modèle est inadapté et vous vous en apercevez à la 30e étape suite à une erreur de mémoire insuffisante, soit vous avez surdimensionné votre solution pour une charge de travail que DDP aurait gérée en dix fois moins de temps.

Cet article présente le point de vue des acheteurs et des architectes sur l'entraînement distribué. Il explore les cinq axes de parallélisme, les quatre (désormais cinq) frameworks qui les combinent, et les solutions qui fonctionnent réellement sur du matériel de type Kentino — principalement des configurations 4× et 8× RTX 5090, 4090 et RTX Pro 6000 Blackwell sur des hôtes AMD EPYC, avec PCIe Gen5 et Ethernet standard ou InfiniBand entre les nœuds. L'essentiel est dit d'emblée : la plupart des clients Kentino effectuent un fine-tuning, et non un pré-entraînement, et FSDP2 sur un seul nœud 8 GPU couvre 90 % des besoins de fine-tuning. Le parallélisme Megatron-Core et 3D n'est vraiment pertinent que pour le pré-entraînement à partir de zéro au-delà de 30 milliards de modèles, ce qui représente un public bien plus restreint que ne le laisse entendre le marketing.

Les cinq axes

Chaque framework moderne d'entraînement distribué utilise un sous-ensemble des cinq mêmes axes de parallélisme. Il ne s'agit pas d'alternatives : les méthodes pour grands modèles combinent trois ou quatre axes simultanément. Consultez la section « Communication » ; c'est là que réside l'essentiel.

DP crie une fois par étape. TP crie deux fois par étape. couchePP émet un signal chuchoté une fois par étape. SP/CP émet un signal sonore une fois par bloc d'attention, mais selon une dimension différente. EP agit sur l'ensemble des couches uniquement sur les couches actives MoE. Cette unique colonne détermine la position de chaque axe : à l'intérieur d'une boîte rapide ou à travers un tissu plus lent.

Le « parallélisme 3D » qui revient sans cesse dans les articles de blog d'NVIDIA est… DP × TP × PPAjoutez SP et EP et on passe à une architecture 4D ou 5D, ce qui relève davantage d'une question de notation que d'un véritable changement d'architecture. L'important, c'est l'agencement : TP à l'intérieur du nœud (où la bande passante est bon marché), PP entre les nœuds (où la bande passante est chère), et DP au-dessus pour augmenter le débit. SP s'intègre aux côtés de TP ; EP ne concerne que MoE.

Références croisées : la bande passante intra-nœud parallèle tensorielle est décompressée dans K07, la pénalité NVLink par rapport à PCIe dans N03, et le tissu inter-nœud dans N08.

DDP — lorsque le modèle convient et que vous souhaitez simplement un débit plus élevé

PyTorch DDP (DistributedDataParallel) est la solution la plus ancienne, la plus simple et toujours valable lorsque le modèle tient sur un seul GPU. Chaque nœud de calcul contient une copie complète du modèle et de l'état de l'optimiseur. À chaque étape, chaque nœud effectue ses propres calculs de propagation avant, arrière et de gradient sur son propre micro-lot. Ensuite, une seule opération de réduction (all-reduce) somme les gradients de tous les nœuds et la même mise à jour est appliquée à tous.

Le DDP dans PyTorch 2.x reste le même qu'auparavant, avec deux améliorations notables : une version plus robuste static_graph=True voie vers des graphes compatibles avec les compilateurs et une intégration plus étroite avec torch.compileLe schéma de communication reste inchangé : une réduction globale par étape, chevauchement avec la rétrogradation, mise à l'échelle linéaire jusqu'à ce que la réduction globale devienne dominante.

Quand DDP est la bonne réponse :

• Le modèle complet, les états de l'optimiseur et les activations tiennent sur un seul GPU. Pour les optimiseurs de type Adam sur des poids maîtres FP32, la règle générale est la suivante : environ 16 octets par paramètre La mémoire allouée à l'état entraînable (4 octets pour les poids, 4 octets pour les gradients, 8 octets pour l'optimiseur) plus les activations est de 128 Go. Un modèle de 8 milliards de paramètres nécessite 128 Go d'état, ce qui tient sur une seule RTX Pro 6000 Blackwell (96 Go) avec une précision mixte et les poids maîtres BF16. En dessous de 8 milliards de paramètres, DDP est compatible avec une seule 5090 ; au-delà, il est préférable d'utiliser FSDP2.
• Vous recherchez un débit maximal, pas une taille de modèle maximale. La méthode DDP présente le rapport communication/calcul le plus faible de toutes les approches de traitement parallèle des données, car les gradients sont réduits. une fois par étape, après tout le travail de rétroaction local.
• Vous effectuez des déploiements d'apprentissage par renforcement, LoRA, ou toute autre configuration où chaque rang contient un petit adaptateur entraînable en plus de poids de base figés.

Lorsque DDP est erroné : le modèle ne convient pas. La solution n’est pas de réduire la taille des lots. La solution est FSDP2.

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

Voilà pour le lanceur. DDP est le pilote par défaut, certes peu attrayant, mais souvent oublié, et pour une charge de travail appropriée, c'est le plus rapide.

FSDP2 — la nouvelle solution par défaut 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 l'ensemble du groupe de traitement parallèle des données. Chaque GPU stocke les données. 1/N des paramètres. Pour effectuer une passe avant, le nœud de classement rassemble tous les poids de la couche dont il a besoin, lance le calcul et supprime les poids rassemblés. La mémoire est réduite d'un facteur N environ par rapport à DDP ; la communication augmente car chaque couche est rassemblée et re-rassemblée.

L'histoire de 2025 est FSDP2Le FSDP original (FSDP1) regroupait les paramètres en un seul FlatParameterce qui rendait le raisonnement sur le comportement par paramètre (gel partiel, types de données mixtes, paramètres d'optimisation spécifiques à chaque paramètre) difficile, voire impossible. FSDP2 a réécrit le fonctionnement interne en s'appuyant sur DTensor : chaque tenseur reste un tenseur réel. torch.Tensor qui se trouve être fragmentée le long de sa dimension 0 à travers les rangs. L'API destinée à l'utilisateur a été modifiée. FSDP(model, ...) à fully_shard(model, ...).

D'après les benchmarks publiés et nos propres tests, voici ce que FSDP2 apporte réellement de plus que FSDP1 :

• ~7% de mémoire GPU en moins sur Llama 2 7B avec la même configuration, car FSDP2 évite le record_stream Un schéma qui ancrait la mémoire de manière pessimiste.
• Gain de débit d'environ 1.5 % à parité, et jusqu'à Accélération du débit de 50 % lorsqu'il est combiné avec torch.compile et torchao Formation float8 sur du matériel de classe Hopper.
• Dictionnaires d'état partitionnés qui se chargent rapidement et se repartitionnent proprement avec différentes configurations de parallélisme — le format de point de contrôle FSDP1 était notoirement difficile à remodeler entre l'entraînement et l'inférence.
• Gel partiel des paramètres sans acrobatiesce qui est important pour LoRA et la formation des adaptateurs.

FSDP1 est obsolète depuis PyTorch 2.11Les nouveaux travaux devraient utiliser fully_shard. L'ancien FullyShardedDataParallel Le wrapper existe toujours pour des raisons de compatibilité, mais il est en cours de suppression.

FSDP2 expose également deux stratégies de partitionnement qui déterminent où réside le modèle :

• Fragment complet. Paramètres entièrement répartis sur tous les rangs (paramètre par défaut de FSDP1). Mémoire minimale, communication maximale.
• Fragment hybride. Paramètres fragmentés dans les un nœud et répliquées Entre les nœuds, la communication s'effectue via PCIe/NVLink (rapide). Au sein d'un nœud, seule la réduction du gradient emprunte le réseau Ethernet/IB (plus lent). Cette configuration est optimale pour 2 à 4 nœuds sur un réseau Ethernet/IB 100/200 Gbit/s.

Lorsque FSDP2 est la bonne réponse (cas modal de Kentino) :

• Réglage fin de 8B à 70B sur un nœud à 8 GPU. Shard complet, BF16, point de contrôle de gradient activé. torch.compile. Terminé.
• Ajustement fin de 70B à 405B sur 2 à 4 nœuds. Fragment hybride avec un fragment complet dans chaque nœud, répliqué sur l'ensemble des nœuds.
• Tout ce qui concerne LoRA / QLoRA — la gestion partielle des paramètres de FSDP2 surpasse nettement celle de FSDP1 sur ce point.

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 torchrunSeul l'enveloppe change.

DeepSpeed ​​et les niveaux ZeRO — toujours disponibles, mais plus par défaut

DeepSpeed ​​est la plateforme d'entraînement distribué de Microsoft. Sa principale caractéristique était… Zéro (Zero Redundancy Optimizer), apparu des années avant FSDP et qui a défini l'approche moderne du partitionnement intégral.

Du point de vue architectural, ZeRO-3 est équivalent à FSDP full-shard. Ils résolvent le même problème avec les mêmes primitives de communication.

La réalité en 2025-2026 : FSDP2 a détrôné DeepSpeed ​​sur le cas d'utilisation LLM dense. PyTorch natif, sans paquet supplémentaire, intégré avec torch.compileLa même recette est utilisée par Hugging Face Transformers, Accelerate et TorchTitan. Des tests internes de Lightning et Hugging Face montrent que le traitement complet des partitions par FSDP est 2 à 5 fois plus rapide par itération que ZeRO-3 dans certaines configurations, bien que DeepSpeed ​​prenne l'avantage sur les très grands modèles (plus de 10 milliards d'octets) où ses techniques de déchargement du processeur et du NVMe restent réellement efficaces.

DeepSpeed ​​mérite d'être connu pour trois raisons :

1. Déchargement ZeRO-Infinity. Si vous devez optimiser un modèle qui ne tient pas dans la mémoire GPU totale (par exemple, un modèle de base 405 octets sur une configuration Blackwell 4 × RTX Pro 6000), DeepSpeed ​​peut décharger les paramètres sur la RAM du processeur (économique, mais lente) et sur un SSD NVMe (encore moins cher, mais beaucoup plus lent). FSDP propose également le déchargement sur le processeur, mais la solution NVMe de DeepSpeed ​​est plus aboutie. Utile si vous ne disposez que d'une seule machine et d'un modèle complexe ; à éviter si vous pouvez louer ou acheter un second nœud.
2. Parallélisme de séquence DeepSpeed-Ulysses. Un schéma de parallélisation séquentielle économe en communication, utilisant une approche « tous à tous » plutôt qu'une approche « rassemblement en anneau » pour la gestion de l'attention. Il a été démontré qu'il pouvait gérer des contextes allant jusqu'à 1 million de jetons sur 64 A100, et que Llama-8B pouvait être entraîné avec 15 millions de jetons de contexte sur 32 H100 (article publié en 2025). Si votre objectif principal est l'entraînement sur des contextes très longs, Ulysses reste supérieur à l'implémentation de parallélisation contextuelle de Megatron pour certaines formes.
3. DeepSpeed-MoE. Formation mixte avec formation parallèle d'experts. Moins pertinent pour le réglage fin, très pertinent pour la préformation des responsables de formation.

Pour la plupart des réglages fins effectués par les clients de Kentino, FSDP2 est la solution idéale, sauf raison particulière justifiant l'utilisation de DeepSpeed ​​(contexte long, déchargement CPU/NVMe, pré-entraînement MoE). L'écosystème penche clairement en faveur de FSDP2.

Megatron-LM, Megatron-Core, NeMo — là où vit le fer lourd

Megatron a vu le jour en 2019 sous la forme d'un article de NVIDIA sur les Transformers parallèles tensoriels. Aujourd'hui, cette famille d'architectures comprend trois couches :

• Mégatron-LM — le code source de recherche original. Toujours utilisé ; toujours mis à jour.
• Megatron-Core — la version bibliothèque modulaire. Des blocs de construction composables pour les architectures TP/PP/DP/EP/CP, de précision mixte (FP16/BF16/FP8/FP4) et de transformateurs de référence. L'élément à intégrer.
• Nvidia NeMo — le cadre de bout en bout construit sur Megatron-Core. Recettes, pipelines de données, alignement, déploiement.

Megatron-Core est le framework qui l'emporte au plus haut niveau, notamment grâce à son implémentation Parallélisme tensoriel, parallélisme de pipeline, parallélisme de séquence, parallélisme de contexte et parallélisme d'experts dans un maillage composable. Lorsque vous entraînez un modèle dense de 405 milliards de données 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 testée.

Les recommandations de parallélisme de Megatron pour 2026, issues de la documentation de NVIDIA, correspondent à la réalité matérielle :

Ce tableau explique la raison d'être de Megatron. Il s'agit du framework dont les auteurs utilisent les calculs de bande passante que nous décrivons dans N03 et K07et ses recettes sont adaptées à cet usage.

Dans quels cas Megatron se révèle surdimensionné : pour tout réglage fin sur un seul nœud, tout modèle compatible avec la mémoire FSDP2, et toute charge de travail ne nécessitant pas de TP. Le mécanisme TP de Megatron est certes plus rapide qu'une solution TP maison sur PCIe, mais cette dernière reste lente (voir les résultats du K07). Le point fort de Megatron réside dans sa compatibilité avec le matériel SXM, non fabriqué par Kentino.

Megatron s'avère particulièrement utile pour le pré-entraînement de modèles denses de 70 à 405 milliards de données (voire plus) sur du matériel NVLink loué ou possédé, ou pour la mise en place d'une infrastructure d'entraînement de production pour un laboratoire de recherche. Si tel est votre cas, vous utilisez probablement déjà l'écosystème NeMo.

TorchTitan — la nouvelle référence

TorchTitan est la référence de Meta pour l'entraînement à grande échelle natif de PyTorch, acceptée à ICLR 2025 et désormais l'exemple de facto de « à quoi devrait ressembler une recette TP × PP × FSDP2 × CP en 2026 ? » Il n'invente pas de nouveau parallélisme ; il compose les éléments de base que PyTorch fournit déjà (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor) dans un script d'entraînement parallèle propre à quatre dimensions avec point de contrôle asynchrone fragmenté, torch.compileet float8.

Pourquoi c'est important même si vous ne l'utilisez pas directement :

• Il est de la exemple canonique de la manière dont FSDP2 se compose avec TP et PP sans framework tiers.
• Les mêmes API sont fournies avec PyTorch standard. Il n'y a rien de magique.
• AMD a livré une version optimisée de TorchTitan pour ROCm fin 2025 ; le partenariat Lightning AI annoncé en octobre 2025 rend les recettes TorchTitan exécutables sur Lightning Studios.

Pour les clients utilisant des technologies comme Kentino, TorchTitan est davantage une ressource de référence qu'un framework à déployer. Pour le réglage fin, Accelerate ou Axolotl sur FSDP2 offrent une meilleure ergonomie. En revanche, pour le pré-entraînement à une échelle modeste (8 à 64 GPU) sur du matériel standard, TorchTitan est compétitif avec NeMo et beaucoup moins gourmand en ressources.

La matrice du cadre

Accelerate et Axolotl ne sont pas des stratégies de parallélisme distinctes ; elles encapsulent les processus backend mentionnés ci-dessus. La plupart des clients Kentino effectuant un réglage fin utiliseront Axolotl plutôt que FSDP2 sans même s'en rendre compte, et c'est tout à fait normal.

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

Références croisées: N08 Ce document présente en détail les calculs RDMA et de liaison montante ; il s'agit du point de vue spécifique à la formation.

Pour le traitement parallèle des données (DDP ou FSDP), la communication inter-rangs par étape est approximativement proportionnelle à nombre de paramètres (gradients à réduire). Pour le parallélisme tensoriel, il est proportionnel à taille d'activation × nombre de couches — des ordres de grandeur plus importants à chaque étape.

Volume de gradient approximatif pour une seule étape à BF16 :

L'opération de réduction complète de 70 octets prend à elle seule 5.6 secondes sur une infrastructure de 200 Gbit/s. Si le calcul aller-retour en une étape prend également 5 secondes, votre réseau est déjà limité à 50 % par la communication ; s'il prend 2 secondes, il est inactif à plus de 70 %. C'est pourquoi 100 GbE saturent l'entraînement 70B+ et que vous avez besoin de 400 GbE / NDR IB. La puissance de calcul ne cesse d'augmenter ; le réseau doit suivre le rythme, sinon les GPU resteront inactifs.

FSDP2 masque une partie de ce problème grâce au chevauchement (début de la collecte de la couche suivante pendant le calcul de la couche actuelle). Le shard hybride en masque davantage en conservant le pente Tout est réduit au sein du réseau intra-nœud rapide, seuls les gradients répliqués entre les nœuds étant réduits. Les valeurs ci-dessus correspondent au pire cas pour un FSDP complet sur l'ensemble des nœuds, sans chevauchement.

Pour le traitement parallèle de tenseurs, la communication par jeton est proportionnelle à la taille de la couche cachée et au nombre de couches. Les nombres dans K07 Explication : ~80 Mo par jeton généré lors du décodage, ~300 Go par préremplissage sur 70 octets au lot 32. C’est dans ce régime que PCIe (50 Go/s réalistes) est environ 14 fois plus lent que NVLink (plus de 700 Go/s réalistes), et que le préentraînement d’un modèle dense de plus de 70 octets sur PCIe ne fonctionne tout simplement pas avec une efficacité acceptable.

De vraies recettes

Optimisation fine de 8B Llama, 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

Performances attendues : environ 2 2000 tok/s agrégés à BF16, compatible avec les KV/activations. Le FSDP90 complet sur PCIe Gen5 gère la réduction globale du gradient en interne. C’est également le type de tâches d’optimisation les plus courantes chez Kentino.

Optimisation fine de 70 milliards de Llama, 2 nœuds de 8 GPU — shard hybride FSDP2

Matériel : 2× 8× RTX Pro 6000 Blackwell, IB 200 Gbps ou RoCE 100 GbE 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 shard hybride conserve l'intégralité du shard dans chaque nœud à 8 GPU et le réplique entre les deux nœuds. L'infrastructure inter-nœuds ne transporte que la partie réduite des gradients répliqués (environ 70 Go/étape à BF16, soit environ 3 s avec IB à 200 Gbit/s). Le chevauchement masque la majeure partie de cette quantité. À 100 Gbit/s, la même étape prend environ 5 à 6 s et les GPU commencent à afficher un temps d'inactivité ; le processus reste fonctionnel, mais plus lent par époque.

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

Configuration matérielle : 8 nœuds NVLink/SXM à 8 GPU, IB NDR 400 Gbit/s. 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, une seule réplique. Pour passer à plusieurs répliques et obtenir un débit plus élevé, multipliez par DPC’est là que Megatron justifie son utilisation. Le même modèle, sous FSDP2 uniquement, consacrerait la majeure partie de son temps à la communication inter-rangs ; la configuration 3D place la communication la plus intensive (TP) au sein du domaine NVLink.

Avis honnête des clients de Kentino

La plupart des clients de Kentino n'effectuent pas de pré-entraînement. Ils peaufinent des modèles de base à poids ouverts (Llama, Qwen, Mistral, parfois Gemma) sur leurs données de domaine, occasionnellement avec LoRA ou QLoRA, et parfois par un réglage fin complet. Pour ce travail, le choix du framework est le suivant :

• Un modèle qui tient sur un GPU sous BF16, avec l'état de l'optimiseur. Utilisez DDP. Répliquez les copies pour augmenter le débit.
• Un modèle qui ne tient pas sur un seul GPU mais qui tient globalement sur un nœud à 8 GPU. Utilisez le partitionnement complet FSDP2. Cela couvre les réglages fins de 8 à 70 octets.
• Un modèle qui s'adapte globalement à deux nœuds de 8 GPU. Utiliser un shard hybride FSDP2. Ajustements fins de 70 à 200 octets.
• Un modèle plus grand, ou un préentraînement à partir de zéro. C'est dans ce contexte que Megatron-Core, le matériel SXM et NDR IB ont toute leur place. Nous construirons le plan de stockage et de gestion, mais les GPU sont généralement loués pour cette phase.

Les 10 % de clients qui ont réellement besoin d'une formation multi-nœuds étroitement couplée sont principalement des laboratoires de recherche disposant de programmes de pré-formation financés, et ils savent précisément ce dont ils ont besoin avant de nous contacter. Pour les 90 % restants, il ne faut pas vendre un cluster ; il convient de leur vendre un nœud 8 GPU performant, avec l'infrastructure réseau adéquate pour un futur second nœud, et de considérer l'équipement réseau comme un poste de dépense supplémentaire.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.