DeepEP de DeepSeek : la lib open source qui optimise la communication GPU pour les modèles MoE à l'échelle

DeepEP de DeepSeek : la lib open source qui optimise la communication GPU pour les modèles MoE à l'échelle

🔎 Pourquoi DeepEP change la donne pour l'entraînement MoE

L'entraînement de modèles Mixture-of-Experts (MoE) à plusieurs centaines de milliards de paramètres bute sur un goulot d'étranglement que peu de gens évoquent : la communication inter-GPU. Les calculs vont vite, mais les transferts de données entre experts distribués sur des milliers de cartes tuent les performances.

DeepSeek vient de rendre publique l'infrastructure exacte qui permet à ses modèles de s'entraîner aussi efficacement. DeepEP, c'est 9700+ étoiles sur GitHub, une licence open source, et des optimisations qui rendent la communication MoE jusqu'à 10x plus rapide que les primitives standards.

C'est le genre de release qui déplace la ligne de départ pour tout laboratoire ou entreprise qui voulait s'attaquer à l'entraînement MoE à grande échelle mais n'avait pas les ressources de Google ou Meta.

L'essentiel

• DeepEP est une bibliothèque de communication expert-parallel (EP) open source, optimisée pour les modèles MoE à grande échelle.
• Elle accélère les opérations all-to-all dispatch/combine jusqu'à 10x par rapport aux primitives standard, avec support FP8 et kernels low-latency.
• Testée sur DeepSeek-V3 16B MoE avec PyTorch TorchTitan sur B200, elle permet un pré-entraînement 41% plus rapide en MXFP8 sans dégradation de convergence.
• Supporte CUDA et ROCm/AMD via le backend MORI, ce qui la rend portable au-delà de l'écosystème NVIDIA.
• C'est l'infrastructure qui sous-tend DeepSeek V3.1 et DeepSeek V4, désormais accessible à toute la communauté.

Outils recommandés

Qu'est-ce que l'Expert Parallelism et pourquoi c'est le goulot d'étranglement

L'Expert Parallelism (EP) consiste à distribuer les experts d'un modèle MoE sur plusieurs GPU. Plutôt que de faire tenir tous les experts sur une seule carte, on les répartit. Chaque GPU traite les tokens qui relèvent de ses experts et transmet les autres aux GPU concernés.

Le problème central : à chaque passage forward et backward, il faut un échange all-to-all massif entre tous les GPU du groupe EP. Un token produit par le GPU 0 peut devoir atterrir sur le GPU 47, et vice versa. Ces opérations all-to-all deviennent le facteur limitant bien avant le calcul matriciel lui-même.

Dans un modèle comme DeepSeek V4 Pro avec ses 88 de score global et son architecture MoE massive, la quantité de données échangées à chaque étape est colossale. Si la communication n'est pas hyper-optimisée, les GPU passent plus de temps à attendre qu'à calculer.

C'est exactement ce problème que DeepEP résout.

Architecture de DeepEP : ce qui fait la différence

DeepEP ne réinvente pas le concept d'expert parallelism. Il optimise chaque couche de la pile de communication pour le cas spécifique des modèles MoE.

Kernels low-latency dispatch et combine

Les opérations de dispatch (envoi des tokens vers les bons experts) et de combine (récupération et assemblage des résultats) sont les deux étapes clés du cycle EP. DeepEP implémente des kernels CUDA sur mesure pour ces deux opérations.

Contrairement aux appels nccl.alltoall génériques qui traitent les données comme des blocs opaques, les kernels DeepEP comprennent la structure des données MoE. Ils peuvent fusionner des opérations, réduire les copies mémoire intermédiaires et minimiser la latence par micro-batch.

Support FP8 et MXFP8

Le support de la précision FP8 est un atout majeur. En format FP8, les volumes de données transmis entre GPU sont divisés par deux par rapport à BF16, ce qui réduit directement la bande passante requise.

L'expérimentation menée par l'équipe PyTorch avec TorchTitan sur des GPU B200 a montré que l'association MXFP8 + DeepEP sur un modèle DeepSeek-V3 16B MoE donne un pré-entraînement 41% plus rapide, avec une convergence équivalente au BF16. Aucune dégradation mesurable, pas besoin de réglages fins complexes.

Group-limited gating algorithm

DeepSeek-V3 a introduit un algorithme de routage particulier : le group-limited gating. Au lieu d'envoyer chaque token vers les N meilleurs experts parmi tous les experts disponibles, on limite le choix à un sous-groupe. Cela réduit le nombre de destinations possibles par token.

DeepEP est spécifiquement optimisé pour ce pattern de communication. Les kernels tirent parti du fait que les destinations sont pré-contraintes pour mieux organiser les buffers et réduire la fragmentation des envois.

Portabilité : CUDA et ROCm

C'est un point souvent sous-estimé. DeepEP ne se limite pas à NVIDIA CUDA. Le support du backend MORI permet de faire tourner la même logique de communication sur des GPU AMD avec ROCm.

Pour la communauté open source, c'est stratégique. Cela signifie qu'on peut entraîner des modèles MoE de niveau DeepSeek sans être verrouillé dans l'écosystème NVIDIA, avec toute la flexibilité matérielle que cela implique.

Benchmarks : les chiffres qui parlent

Les données publiées par le blog PyTorch (juin 2025) et le site officiel deepep.org permettent de se faire une idée précise du gain.

DeepEP vs primitives All-to-All standard

Le gain de 10x sur les primitives brutes provient de la source Perplexity AI, qui a benchmarké DeepEP dans des conditions contrôlées de communication MoE. Le gain de 41% sur le pré-entraînement complet est plus conservateur car il inclut tout le pipeline (calcul, optimiseur, checkpointing), pas seulement la communication.

Convergence : FP8 vs BF16

L'étude PyTorch est claire : sur le modèle DeepSeek-V3 16B MoE, la courbe de loss en MXFP8 avec DeepEP se superpose à celle du BF16. Pas de divergence, pas de plateau prématuré. La précision réduite n'impacte pas la qualité du modèle final.

C'est un résultat important car le FP8 a longtemps été considéré trop risqué pour le pré-entraînement. DeepEP démontre que dans le contexte spécifique de la communication EP, le FP8 est non seulement sûr mais bénéfique.

DeepEP dans l'écosystème : comparaison avec Megatron et FairScale

Le paysage des frameworks d'entraînement distribué est dominé par deux noms : Megatron-LM (NVIDIA) et FairScale (Meta). DeepEP ne cherche pas à les remplacer mais à combler un vide spécifique.

Megatron-LM

Megatron implémente l'expert parallelism mais de manière relativement générique. Il utilise les primitives NCCL standard pour l'all-to-all et ne propose pas de kernels sur mesure pour le dispatch/combine MoE.

DeepEP peut d'ailleurs s'intégrer dans un pipeline Megatron en remplaçant la couche de communication EP. C'est d'ailleurs ce que l'écosystème commence à faire : garder l'ordonnancement de Megatron mais brancher DeepEP en dessous pour le transfert de tokens.

FairScale

FairScale propose des composants modulaires (FullyShardedDataParallel, sequence parallelism, etc.) mais n'a pas de spécialisation MoE poussée. Son design est orienté vers la recherche et le prototypage rapide, pas vers la performance maximale à 1000+ GPU.

DeepEP est à l'opposé : c'est du code de production, testé à l'échelle de DeepSeek V4 Pro (Max), qui vise le dernier pourcent de performance.

La position de DeepEP

DeepEP se positionne comme une bibliothèque de communication spécialisée, pas comme un framework complet. Elle fait une chose et la fait extrêmement bien : transférer des tokens entre experts MoE le plus vite possible. À intégrer dans un framework plus large plutôt qu'à utiliser seule.

Cas d'usage pratiques : qui devrait utiliser DeepEP

Entraîner un modèle MoE from scratch

Si votre équipe prévoit d'entraîner un modèle MoE de plus de 30B paramètres totaux sur un cluster de 8+ GPU, DeepEP n'est pas optionnel. Sans optimisation EP dédiée, la communication consommera 40 à 60% du temps total. Avec DeepEP, cette fraction chute drastiquement.

C'est particulièrement pertinent pour les équipes qui travaillent sur des architectures similaires à Qwen3.6-27B ou Qwen3.5-122B-A10B, qui utilisent aussi des architectures MoE avec un petit nombre de paramètres actifs.

Fine-tuner un grand MoE existant

Le fine-tuning distribué de modèles comme DeepSeek V4 Pro ou Kimi K2.6 nécessite aussi de l'expert parallelism si le modèle ne tient pas sur un seul nœud. DeepEP accélère les échanges lors des passes forward/backward de fine-tuning, pas seulement lors du pré-entraînement.

Recherche sur le routage d'experts

Les chercheurs qui expérimentent avec de nouveaux algorithmes de gating (top-k variable, routage basé sur le bruit, expert choice) ont besoin d'une infrastructure de communication fiable et rapide. DeepEP fournit cette base sans que les chercheurs aient à réécrire les kernels de bas niveau.

Runs en local pour le prototypage

Pour le prototypage initial à petite échelle, on peut utiliser des LLM locaux avec Ollama ou LM Studio. Mais dès qu'on passe à l'entraînement ou au fine-tuning distribué, DeepEP devient pertinent. La guide d'installation LLM local reste la première étape pour comprendre les modèles MoE avant de passer à l'échelle.

Intégration technique : comment utiliser DeepEP concrètement

L'intégration la plus documentée est avec PyTorch et TorchTitan. Le blog PyTorch détaille les étapes pour configurer un run DeepSeek-V3 16B MoE avec MXFP8 et DeepEP sur des B200.

Prérequis

• Cluster multi-GPU avec interconnect InfiniBand ou NVLink (la latence réseau devient le facteur limitant avec des kernels aussi optimisés).
• PyTorch compilé avec support CUDA ou ROCm.
• DeepEP cloné depuis le repo GitHub officiel et compilé.

Configuration type

DeepEP s'intègre au niveau de la couche MoE. Au lieu d'appeler torch.distributed.all_to_all pour le dispatch et le combine, on appelle les fonctions DeepEP qui gèrent le formatage des tenseurs, la quantification FP8 optionnelle, et l'envoi via les kernels optimisés.

Le group-limited gating de DeepSeek-V3 doit être activé dans la config du modèle pour que DeepEP tire pleinement parti de ses optimisations. Sans cette contrainte de groupe, les gains sont moindres car les patterns de communication sont moins prévisibles.

Monitoring

DeepEP expose des métriques de communication (volume transféré, temps par opération, utilisation de la bande passante) qui permettent de vérifier que le EP n'est pas le goulot. Si les métriques montrent que le temps de communication dépasse 20% du temps de calcul, c'est que le scaling EP a atteint ses limites pour la configuration donnée.

Impact sur la démocratisation de l'entraînement MoE

Jusqu'à récemment, seuls quelques acteurs (Google avec GShard/Megatron, Meta avec les premiers modèles MoE internes) maîtrisaient l'entraînement MoE à très grande échelle. Les kernels de communication étaient des secrets industriels.

DeepSeek change la donne en publiant exactement la même bibliothèque qu'il utilise en production. Le message est clair : la performance MoE n'est pas un art mystérieux réservé à quelques-uns, c'est de l'ingénierie que n'importe qui peut reproduire.

Pour les meilleurs LLM open source, cela signifie que la prochaine génération de modèles MoE ne viendra pas seulement de DeepSeek ou Alibaba. Des laboratoires universitaires, des startups, des communautés open source peuvent maintenant accéder au même niveau d'optimisation infrastructurelle.

La publication de DeepEP sous licence MIT (comme DeepSeek V3.1) s'inscrit dans cette stratégie de démocratisation par l'infrastructure.

Limites et considérations

DeepEP n'est pas une solution magique. Il y a des prérequis et des limites à comprendre.

Seuil de rentabilité

Sur un cluster de 2 à 4 GPU, l'overhead d'installation et de configuration de DeepEP n'en vaut probablement pas la peine. Les gains deviennent significatifs à partir de 8 GPU en EP, et spectaculaires à 64+ GPU.

Dépendance au hardware

Les kernels optimisés sont conçus pour des GPU modernes (A100, H100, B200). Sur du matériel plus ancien ou des GPU grand public, les gains seront réduits car les kernels exploitent des fonctionnalités matérielles spécifiques (Tensor Cores, NVLink, réseaux FP8).

Couverture des cas d'usage

DeepEP est optimisé pour le pattern de communication spécifique de DeepSeek-V3/V4 (group-limited gating, top-k routing). Pour des architectures MoE très différentes (expert choice, routage basé sur la séquence entière), une partie des optimisations pourrait ne pas s'appliquer directement.

Maturité

Malgré les 9700+ étoiles, c'est un projet relativement jeune. La documentation est technique et assume une bonne compréhension du parallélisme distribué. Il n'y a pas de tutoriel pas-à-pas pour débutants.

❌ Erreurs courantes

Erreur 1 : Confondre DeepEP avec un framework d'entraînement complet

DeepEP ne fait pas l'optimiseur, le data loading, le checkpointing, ni le tensor parallelism. C'est un composant de communication EP à intégrer dans un framework existant (TorchTitan, Megatron, ou votre propre pipeline). L'utiliser seul ne sert à rien.

Erreur 2 : Activer DeepEP sur un cluster sous-dimensionné en réseau

Si vos GPU sont reliés par du Ethernet standard sans InfiniBand ni NVLink, les kernels optimisés de DeepEP ne pourront pas exprimer leur plein potentiel. Le réseau deviendra le goulot avant la communication elle-même. Vérifiez votre interconnect avant d'investir du temps dans l'intégration.

Erreur 3 : Utiliser FP8 sans vérifier la convergence

L'étude PyTorch montre que MXFP8 fonctionne sans dégradation sur DeepSeek-V3 16B MoE. Ça ne signifie pas que c'est garanti pour n'importe quel modèle MoE. Testez toujours la convergence en FP8 vs BF16 sur votre cas spécifique avant de commiter un long run de pré-entraînement.

Erreur 4 : Ignorer le group-limited gating

DeepEP est optimisé pour le group-limited gating algorithm. Si vous utilisez un routage top-k standard sans contrainte de groupe, vous perdez une partie des optimisations. Assurez-vous que l'architecture de votre modèle est compatible avec les hypothèses de DeepEP.

❓ Questions fréquentes

DeepEP remplace-t-il NCCL ?

Non. DeepEP s'appuie sur NCCL pour le transport réseau sous-jacent. Ce qu'il remplace, ce sont les appels all_to_all génériques par des kernels sur mesure qui formatent et optimisent les données avant l'envoi NCCL.

DeepEP fonctionne-t-il avec des modèles non-MoE ?

Non, ce n'est pas son usage prévu. DeepEP est spécifiquement conçu pour les patterns de communication des modèles Mixture-of-Experts. Pour du tensor parallelism ou du data parallelism pur, utilisez les outils standards.

Quel est le nombre minimum de GPU pour tirer profit de DeepEP ?

En pratique, 8 GPU en configuration EP. En dessous, l'overhead d'intégration dépasse les gains. Les benchmarks significatifs sont tous à 64+ GPU.

DeepEP supporte-t-il l'inférence ou uniquement l'entraînement ?

Les kernels dispatch/combine servent aux deux. Mais les optimisations sont principalement pensées pour l'entraînement (où la communication est répétitive et le volume massif). Pour l'inférence, d'autres optimisations (batch continu, KV cache sharing) sont souvent plus pertinentes.

Peut-on utiliser DeepEP avec des GPU AMD ?

Oui, via le backend MORI qui supporte ROCm. C'est l'un des atouts de DeepEP par rapport aux solutions NVIDIA-only.

✅ Conclusion

DeepEP est le composant d'infrastructure que la communauté open source attendait pour compétitionner sérieusement sur l'entraînement MoE à grande échelle. En publiant la même bibliothèque qui propulse DeepSeek V4, DeepSeek ne se contente pas de partager du code : il redistribue les cartes du jeu de l'IA open source. Si vous envisagez un projet MoE sérieux, DeepEP est désormais le point de départ obligatoire de votre pile technique.