Accueil › Glossaire › DeepSpeed

DeepSpeed

DeepSpeed est une bibliothèque open-source développée par Microsoft Research qui optimise l’entraînement et l’inférence de modèles de deep learning à grande échelle, principalement grâce à ZeRO (Zero Redundancy Optimizer) et à ses techniques d’offloading CPU/NVMe.

Si vous entraînez ou fine-tunez un modèle de plus d’un milliard de paramètres, vous avez probablement déjà croisé DeepSpeed. La bibliothèque a été utilisée pour entraîner BLOOM (176B paramètres), Megatron-Turing NLG (530B), et des dizaines d’autres modèles de grande taille. Son innovation principale, ZeRO, élimine la redondance mémoire dans le data parallelism distribué, permettant d’entraîner des modèles jusqu’à 10x plus grands sur le même matériel.

La version courante est la 0.18.7, publiée en mars 2026, compatible avec PyTorch 2.x et les GPU NVIDIA Pascal à Blackwell, ainsi que les accélérateurs AMD et Intel.

ZeRO : le coeur de DeepSpeed

ZeRO (Zero Redundancy Optimizer) est l’innovation fondatrice de DeepSpeed, publiée en 2019 par Samyam Rajbhandari et al. Le constat de départ est simple : dans le data parallelism classique (DDP), chaque GPU stocke une copie complète du modèle, de ses gradients et des états de l’optimiseur. Pour N GPU, cela signifie N copies identiques de tout. C’est un gaspillage massif de mémoire.

ZeRO élimine cette redondance en fragmentant (sharding) les données du modèle entre les GPU au lieu de les répliquer. Il se décline en trois stages progressifs, chacun fragmentant un type de donnée supplémentaire.

ZeRO Stage 1 : fragmentation des états optimiseur

Les états de l’optimiseur (pour Adam : la moyenne mobile des gradients et la moyenne mobile des gradients au carré, soit 2 tenseurs en FP32 par paramètre) sont fragmentés entre les GPU. Chaque GPU ne stocke et ne met à jour que 1/N des états optimiseur.

L’économie est substantielle. Pour un modèle de 7B paramètres, les états Adam occupent environ 56 Go (7B × 4 octets × 2 états). Avec 8 GPU, chacun ne stocke que 7 Go d’états optimiseur au lieu de 56 Go. La communication reste identique au DDP classique (all-reduce des gradients), ce qui rend ZeRO-1 quasi-gratuit en termes de performance.

C’est le choix par défaut pour de nombreux systèmes d’entraînement. DeepSeek V3 utilise ZeRO-1 pour la composante data-parallèle de son entraînement.

ZeRO Stage 2 : + fragmentation des gradients

En plus des états optimiseur, les gradients sont fragmentés. Au lieu d’un all-reduce (qui somme puis redistribue), ZeRO-2 utilise un reduce-scatter : chaque GPU reçoit uniquement la portion de gradient dont il est responsable pour la mise à jour des poids.

L’économie mémoire est doublée par rapport à ZeRO-1 pour les gradients. Le volume total de communication est similaire au DDP classique, mais le pattern est différent (reduce-scatter + all-gather au lieu d’all-reduce).

ZeRO Stage 3 : + fragmentation des paramètres

Le stage le plus agressif : même les poids du modèle sont fragmentés. Aucun GPU ne détient la copie complète du modèle. Avant chaque forward ou backward par couche, un all-gather reconstitue temporairement les poids complets, puis ils sont libérés immédiatement après usage.

L’économie mémoire est proportionnelle au nombre de GPU : avec N GPU, chaque GPU stocke environ 1/N du modèle total (poids + gradients + états). En théorie, cela permet d’entraîner un modèle de taille quasi-illimitée en ajoutant des GPU. En pratique, l’overhead de communication (all-gather à chaque forward et backward) peut ralentir significativement l’entraînement.

ZeRO-Offload et ZeRO-Infinity

L’une des contributions les plus percutantes de DeepSpeed est l’offloading : la capacité de décharger une partie des données du modèle vers la mémoire CPU ou vers des disques NVMe, libérant la mémoire GPU pour le calcul.

ZeRO-Offload (CPU)

ZeRO-Offload combine ZeRO-2 avec le déchargement des états optimiseur et des gradients vers la CPU. L’optimiseur (Adam) est exécuté directement sur la CPU via DeepSpeedCPUAdam, une implémentation optimisée qui est 5 à 7 fois plus rapide que l’Adam standard de PyTorch sur CPU.

Résultat : un seul GPU V100 (32 Go) peut entraîner un modèle de 13B paramètres, soit 10x plus que ce que PyTorch seul permet. L’overhead est acceptable car les calculs lourds (forward, backward) restent sur GPU, seule la mise à jour des poids migre vers la CPU.

ZeRO-Infinity (NVMe)

ZeRO-Infinity pousse le concept plus loin en offloadant également vers les disques NVMe. Cela permet d’exploiter des téraoctets de stockage SSD pour les états du modèle. Sur un seul noeud DGX avec 8 GPU, ZeRO-Infinity permet théoriquement de fine-tuner des modèles dépassant le trillion de paramètres.

L’offloading NVMe ajoute plus de latence que l’offloading CPU. C’est un outil pour les cas extrêmes où ni la mémoire GPU ni la mémoire CPU ne suffisent.

{
    "zero_optimization": {
        "stage": 3,
        "offload_optimizer": {
            "device": "nvme",
            "nvme_path": "/local_nvme"
        },
        "offload_param": {
            "device": "nvme",
            "nvme_path": "/local_nvme"
        }
    }
}

Les autres piliers de DeepSpeed

DeepSpeed ne se limite pas à ZeRO. La bibliothèque propose un ensemble complet d’optimisations pour l’entraînement et l’inférence.

Pipeline Parallelism

DeepSpeed implémente le pipeline parallelism avec le schedule 1F1B (One-Forward-One-Backward) pour minimiser les bulles. Combiné avec ZeRO, il forme le parallélisme 3D (TP de Megatron-LM × PP de DeepSpeed × DP/ZeRO). C’est cette combinaison qui a été utilisée pour entraîner BLOOM (176B paramètres) sur le cluster Jean Zay du CNRS.

Optimisations de communication

DeepSpeed propose plusieurs optimiseurs de communication compressée pour réduire le volume échangé entre GPU :

1-bit Adam : compresse les gradients en n’envoyant que le signe (1 bit par valeur), réduisant le volume de communication de 26x tout en maintenant une convergence comparable à Adam standard.

ZeRO++ : optimise ZeRO-3 avec des all-gather asynchrones et pipelinés, du quantized communication (communication en INT8 au lieu de FP16/BF16), et un hierarchical partitioning qui réduit le volume de communication inter-noeud.

Mixed Precision

DeepSpeed supporte nativement l’entraînement en FP16, BF16 et FP8. La configuration se fait via le fichier JSON DeepSpeed, avec gestion automatique du loss scaling pour FP16.

Activation Checkpointing

DeepSpeed intègre le checkpointing d’activations, qui libère la mémoire des activations après la passe forward et les recalcule pendant le backward. Cela échange du calcul contre de la mémoire, un compromis essentiel pour les grands modèles. DeepSpeed propose aussi le CMO (Contiguous Memory Optimization) pour réduire la fragmentation mémoire.

DeepSpeed-FastGen (Inférence)

DeepSpeed-FastGen est le moteur d’inférence de DeepSpeed, concurrent de vLLM et TensorRT-LLM. Il utilise la technologie Dynamic SplitFuse pour optimiser le scheduling des requêtes. En janvier 2026, FastGen a ajouté le support des modèles MoE (Mixtral), Phi-2 et Falcon, avec des kernels optimisés pour les GPU NVIDIA.

DeepSpeed-MII (Model Implementations for Inference)

MII rend l’inférence haute performance accessible en quelques lignes de code, avec des implémentations optimisées pour des milliers de modèles Hugging Face. MII promet jusqu’à 5,7x de speedup sur BLOOM 176B par rapport aux implémentations standard.

Configuration pratique de DeepSpeed

DeepSpeed se configure entièrement via un fichier JSON. C’est l’un de ses points forts : pas besoin de modifier le code du modèle pour activer les optimisations.

Configuration ZeRO-2 basique

{
    "train_batch_size": 64,
    "gradient_accumulation_steps": 4,
    "gradient_clipping": 1.0,
    "fp16": {
        "enabled": true,
        "loss_scale": 0,
        "loss_scale_window": 1000
    },
    "zero_optimization": {
        "stage": 2,
        "contiguous_gradients": true,
        "overlap_comm": true,
        "reduce_scatter": true,
        "reduce_bucket_size": 5e8,
        "allgather_bucket_size": 5e8
    }
}

Configuration ZeRO-3 avec Offload CPU

{
    "train_batch_size": 32,
    "gradient_accumulation_steps": 8,
    "bf16": {
        "enabled": true
    },
    "zero_optimization": {
        "stage": 3,
        "offload_optimizer": {
            "device": "cpu",
            "pin_memory": true
        },
        "offload_param": {
            "device": "cpu",
            "pin_memory": true
        },
        "overlap_comm": true,
        "contiguous_gradients": true,
        "sub_group_size": 1e9,
        "reduce_bucket_size": "auto",
        "stage3_prefetch_bucket_size": "auto",
        "stage3_param_persistence_threshold": "auto"
    }
}

Intégration avec PyTorch

L’intégration dans un script PyTorch existant est minimale :

import deepspeed

# Initialisation DeepSpeed (remplace DDP + optimizer)
model, optimizer, _, _ = deepspeed.initialize(
    model=model,
    model_parameters=model.parameters(),
    config="ds_config.json"
)

# Boucle d'entraînement
for batch in dataloader:
    loss = model(batch)
    model.backward(loss)    # Remplace loss.backward()
    model.step()            # Remplace optimizer.step()

Lancement avec le launcher DeepSpeed :

deepspeed --num_gpus=8 train.py --deepspeed_config ds_config.json

Intégration avec Hugging Face

Le Hugging Face Trainer supporte DeepSpeed nativement. Il suffit de passer le fichier de configuration :

from transformers import TrainingArguments

training_args = TrainingArguments(
    output_dir="./output",
    deepspeed="ds_config.json",
    bf16=True,
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,
)

Hugging Face Accelerate offre une alternative encore plus simple avec la commande accelerate config qui génère la configuration DeepSpeed interactivement.

DeepSpeed ZeRO vs PyTorch FSDP

ZeRO-3 et PyTorch FSDP sont fonctionnellement équivalents : tous deux fragmentent les poids, gradients et états optimiseur entre les GPU. Les différences sont dans l’implémentation et l’écosystème.

Notre verdict : pour le fine-tuning de modèles Hugging Face, DeepSpeed reste très populaire grâce à son intégration mature avec le Trainer. Pour le pré-entraînement à grande échelle avec parallélisme multi-dimensionnel, FSDP combiné avec Megatron-LM (via Megatron-FSDP) gagne du terrain. Si vous avez besoin d’offloading NVMe ou de communication compressée, DeepSpeed n’a pas d’équivalent côté PyTorch natif.

Modèles entraînés avec DeepSpeed

DeepSpeed a un historique impressionnant de modèles de référence :

Roadmap Q1 2026

Le roadmap officiel de DeepSpeed pour Q1 2026, publié sur GitHub, mentionne plusieurs axes de développement :

Support TPU. DeepSpeed travaille à supporter les TPU de Google, ce qui élargirait considérablement son écosystème matériel.

SuperOffloading pour MoE. Une nouvelle technique d’offloading optimisée pour les architectures Mixture of Experts, présentée à ASPLOS 2026 sous le nom de « SuperOffload ». L’objectif est de tirer parti des « superchips » (comme le NVIDIA Grace Hopper) qui combinent CPU et GPU sur le même die avec une bande passante mémoire unifiée.

Architectures émergentes. Adaptation aux nouvelles architectures de modèles qui sortent du paradigme Transformer classique.

Tuning de performance DeepSpeed

Obtenir les meilleures performances avec DeepSpeed demande d’ajuster plusieurs paramètres clés dans la configuration JSON.

Taille des buckets de communication

Les paramètres reduce_bucket_size et allgather_bucket_size contrôlent la granularité des opérations collectives. Des buckets trop petits augmentent la latence (trop d’opérations séparées), des buckets trop grands augmentent la mémoire de pointe. La valeur par défaut (5e8, soit 500M éléments = ~1 Go en FP16) est un bon point de départ. Réduisez si vous manquez de mémoire, augmentez si votre bande passante réseau le permet.

Overlap de communication

Le paramètre overlap_comm: true permet de chevaucher la communication (reduce-scatter/all-gather) avec le calcul du backward. C’est essentiel pour masquer la latence réseau. Activez-le systématiquement sauf si vous observez des instabilités de convergence (rare).

Prefetching ZeRO-3

En ZeRO-3, stage3_prefetch_bucket_size contrôle combien de paramètres sont pré-chargés (all-gather) avant leur utilisation effective. Un prefetch agressif réduit les temps d’attente mais consomme plus de mémoire. La valeur « auto » laisse DeepSpeed optimiser automatiquement ce paramètre en fonction de la mémoire disponible.

Pin memory pour l’offload

Quand vous utilisez l’offloading CPU, activez toujours pin_memory: true. La mémoire « pinned » (page-locked) permet des transferts CPU-GPU plus rapides car elle ne peut pas être swappée par l’OS. Le coût est une réduction de la mémoire CPU disponible pour d’autres tâches, mais le gain de performance est systématiquement positif pour l’entraînement.

Limites et pièges courants

Debugging complexe

DeepSpeed ajoute une couche d’abstraction qui rend le debugging plus difficile. Les erreurs de mémoire, de communication ou de convergence peuvent être obscurcies par la machinerie interne de ZeRO. Le mode JSON « boîte noire » peut être frustrant quand un paramètre mal configuré provoque un comportement inattendu.

Compatibilité matérielle

DeepSpeed est principalement optimisé pour les GPU NVIDIA avec CUDA. Le support AMD (ROCm), Intel XPU et d’autres accélérateurs existe mais reste moins mature. Certains ops JIT-compiled peuvent échouer sur des configurations matérielles non testées.

ZeRO-3 n’est pas gratuit

Le stage 3 ajoute un volume de communication considérable. Sur des petits modèles (< 10B paramètres) avec des interconnexions lentes, ZeRO-3 peut être plus lent que le DDP classique avec un modèle plus petit ou quantizé. Mesurez toujours le throughput réel avant de valider une configuration.