Accueil › Glossaire › Expert Parallelism

Expert Parallelism (Parallélisme d’experts)

L’expert parallelism (EP) est une stratégie de parallélisme qui distribue les experts d’un modèle Mixture of Experts (MoE) sur plusieurs GPU ou nœuds de calcul, chaque GPU hébergeant un sous-ensemble d’experts complets, tandis que les couches non-MoE (attention, embeddings) sont gérées par d’autres formes de parallélisme.

Le problème que l’expert parallelism résout est concret : un modèle MoE comme DeepSeek V3.2 (671 milliards de paramètres, 256 experts) ou Mistral Large 3 (~675 milliards de paramètres) ne tient tout simplement pas en mémoire sur un seul GPU. Même si seuls ~37 milliards de paramètres sont activés par token, l’ensemble des poids de tous les experts doit être stocké en mémoire pour le routage dynamique. L’expert parallelism résout ce problème en répartissant les experts sur plusieurs GPU : si vous avez 8 experts et 4 GPU, chaque GPU héberge 2 experts.

En 2026, l’expert parallelism est devenu un composant d’infrastructure critique. Plus de 60 % des sorties de modèles open source utilisent des architectures MoE, et tous les modèles au sommet du leaderboard Artificial Analysis (DeepSeek-R1, Kimi K2, Mistral Large 3) reposent sur l’activation sparse d’experts. NVIDIA a conçu son architecture GB200 NVL72 avec l’expert parallelism comme cas d’usage prioritaire, offrant des performances 10x supérieures à la génération H200 pour les modèles MoE.

Comment fonctionne l’expert parallelism

Le principe de base

Dans un modèle MoE, chaque couche MoE contient N experts (typiquement 8 à 256 réseaux feed-forward indépendants). L’expert parallelism assigne chaque expert à un GPU spécifique. Si vous avez 8 experts et un expert_model_parallel_size de 4, chaque GPU héberge 2 experts. Les couches non-MoE (attention, embeddings, normalisation) ne sont pas affectées par l’EP et sont gérées par le tensor parallelism ou le pipeline parallelism classique.

Quand un token est routé vers un expert situé sur un autre GPU, une communication all-to-all est nécessaire : le token est envoyé au GPU hébergeant l’expert, traité, puis le résultat est renvoyé au GPU d’origine. Cette communication all-to-all est le goulot d’étranglement principal de l’expert parallelism : Meta rapporte qu’elle contribue à 10-30 % de la latence end-to-end, selon la taille des messages (100 Ko à 2 Mo pour le décodage).

Expert parallelism vs tensor parallelism

La distinction est fondamentale. Le tensor parallelism (TP) découpe chaque expert en tranches réparties sur plusieurs GPU : chaque GPU possède une fraction de chaque expert. L’expert parallelism (EP) distribue des experts complets : chaque GPU possède certains experts en totalité. Les implications sont différentes :

DeepSeek V3.2 illustre parfaitement pourquoi l’EP est préféré au TP pour les couches MoE : avec son attention Multi-Latent (MLA) à une seule tête KV, le tensor parallelism standard ne peut pas partitionner le KV cache (il n’y a qu’une tête à partitionner). Avec TP=8, le KV cache serait dupliqué 8 fois, un gaspillage mémoire massif. L’approche DP+EP (data parallelism pour le KV cache + expert parallelism pour les experts) résout ce problème élégamment.

Le pattern de communication all-to-all

C’est le mécanisme central de l’EP. Le processus en deux phases :

Phase 1 : Dispatch. Après le routage (le routeur a sélectionné les experts pour chaque token), les tokens sont envoyés aux GPU hébergeant leurs experts assignés. Chaque GPU envoie ses tokens aux GPU appropriés et reçoit les tokens assignés à ses experts locaux.

Phase 2 : Combine. Après traitement par les experts, les résultats sont renvoyés aux GPU d’origine de chaque token, où ils sont combinés (pondérés par les scores du routeur) pour former la sortie finale de la couche MoE.

Cette communication all-to-all est le facteur limitant de l’EP. Meta explore des optimisations comme le dynamic all-to-all (envoi de sous-chunks au lieu de messages complets) et le persistent all-to-all (réduction de l’overhead CPU et de l’échange de handles mémoire). La topologie réseau (NVLink intra-nœud, InfiniBand inter-nœuds) est aussi importante que la puissance de calcul brute.

Matériel et infrastructure

NVIDIA GB200 NVL72

Le GB200 NVL72 est la plateforme matérielle conçue spécifiquement pour l’EP à grande échelle. Avec jusqu’à 72 GPU interconnectés par NVLink et NVSwitch, il permet de distribuer les experts sur un nombre beaucoup plus grand de GPU qu’auparavant. Les avantages pour le MoE sont directs : moins d’experts par GPU (réduction de la pression mémoire), plus de mémoire libre par GPU (plus d’utilisateurs concurrents et de contextes longs), et communication inter-experts quasi instantanée via NVLink. NVIDIA annonce des performances 10x supérieures au H200 pour les modèles MoE, et l’approche Wide Expert Parallelism offre un gain de débit de 1,8x par GPU.

Le rôle de l’interconnexion

La topologie réseau est critique pour l’EP. La hiérarchie typique : NVLink (900 Go/s entre GPU sur le même nœud), InfiniBand (400-800 Gb/s entre nœuds). La communication all-to-all de l’EP est particulièrement sensible à la latence réseau. FasterMoE (2022) a introduit un gate topology-aware qui sélectionne les experts en tenant compte de la latence réseau, obtenant un speedup de 17x dans les configurations distribuées. MegaScale-MoE (EuroSys 2026) combine expert parallelism avec compression de communication FP8 pour réduire les volumes de données échangés.

Frameworks et mise en œuvre

DeepSpeed-MoE

DeepSpeed-MoE (DeepSpeed) est le framework le plus utilisé pour l’entraînement MoE. Il gère la distribution des experts via le paramètre ep_size, la communication all-to-all, et les optimisations de mémoire. DeepSpeed-MoE combine expert parallelism avec data parallelism et tensor parallelism dans des configurations N-D paramétrables.

Megatron-LM (NVIDIA)

Megatron-LM (maintenant Megatron Bridge) offre un support natif de l’EP avec les paramètres expert_model_parallel_size et expert_tensor_parallel_size (pour appliquer du TP à l’intérieur de chaque expert). L’optimisation DeepEP améliore les performances sur les GPU Ampere et Hopper. Le framework gère le token dropping et le capacity factor pour le load balancing.

vLLM et TensorRT-LLM (inférence)

Pour l’inférence, vLLM et TensorRT-LLM offrent un support natif de l’EP avec le flag –enable-expert-parallel. vLLM supporte le déploiement combinant Data Parallel attention avec Expert Parallel MoE layers. Les deux frameworks ont ajouté des optimisations spécifiques MoE en 2025, notamment l’intégration FlashInfer avec autotuning de kernels MoE pour adapter les performances à la taille des batches et aux longueurs de séquences.

NVIDIA Dynamo

Le framework Dynamo orchestre le serving désagrégé : les tâches de prefill et de decode sont assignées à des GPU différents, permettant au decode de tourner avec un EP large pendant que le prefill utilise des stratégies de parallélisme mieux adaptées à son profil de charge.

Parallélisme hybride N-D

En production, l’expert parallelism n’est jamais utilisé seul. Il est combiné avec d’autres formes de parallélisme dans des configurations N-D :

DP + EP (Data Parallelism + Expert Parallelism). Le data parallelism partitionne les requêtes/batches entre les GPU, l’EP distribue les experts. Chaque GPU traite un sous-ensemble de requêtes avec un sous-ensemble d’experts. C’est la configuration recommandée pour DeepSeek V3.2 en inférence.

TP + EP (Tensor Parallelism + Expert Parallelism). Le TP gère les couches non-MoE (attention), l’EP gère les couches MoE. Cette combinaison exploite les forces de chaque approche.

PP + EP (Pipeline Parallelism + Expert Parallelism). Le PP distribue les couches du modèle en séquence sur les GPU, l’EP distribue les experts à l’intérieur de chaque étage. Utile pour les déploiements multi-nœuds.

Configuration N-D complète. Meta déploie des configurations combinant CP (Context Parallelism), PP, EP, TP entre les nœuds, avec DP séparé. MegaScale-MoE montre que la stratégie SP+EP (Sequence Parallelism + Expert Parallelism) surpasse TP+TP de 14,9 % à 32,9 % en MFU (Model FLOPs Utilization).

Défis et optimisations

Latence de communication. Le all-to-all contribue à 10-30 % de la latence. Les solutions : compression FP8 des communications (MegaScale-MoE), routage topology-aware (FasterMoE), NVLink Switch pour calcul direct dans le réseau (GB200 NVL72).

Mémoire. Même avec l’EP, la mémoire reste la contrainte principale. DeepSeek-R1 complet nécessite 13 719 Go/s de bande passante mémoire. Des techniques comme le Dynamic Gating (réduction des placeholders) et l’offloading CPU (SE-MoE) atténuent la pression mémoire.

Load balancing. Si le routage est déséquilibré, certains GPU hébergeant des experts populaires sont surchargés tandis que d’autres sont sous-utilisés. Les pertes auxiliaires et le capacity factor sont les mécanismes standard de régulation.

Complexité opérationnelle. Le déploiement multi-GPU avec EP demande des compétences spécialisées en systèmes distribués. Les frameworks modernes (vLLM, TensorRT-LLM) simplifient la configuration, mais le debugging reste complexe. Pour les organisations sans expertise interne, les services managés (AWS, CoreWeave, Lambda) offrent une alternative.

Verdict

L’expert parallelism est la stratégie de parallélisme qui a rendu possible le déploiement de modèles MoE à des centaines de milliards de paramètres en production. Sans EP, des modèles comme Mistral Large 3, DeepSeek V3.2 ou Grok ne pourraient tout simplement pas être servis. L’architecture NVIDIA GB200 NVL72, conçue avec l’EP comme priorité, confirme que c’est un pilier durable de l’infrastructure IA.

Pour les praticiens : si vous déployez un modèle MoE (Mixtral, DeepSeek, Mistral Large), l’EP via vLLM ou TensorRT-LLM est le chemin le plus direct. Si vous entraînez un modèle MoE, DeepSpeed-MoE ou Megatron-LM fournissent l’infrastructure nécessaire. Dans tous les cas, la topologie réseau (NVLink, InfiniBand) est aussi importante que la puissance GPU brute.