MoE (Mixture of Experts)
MoE est l’acronyme de Mixture of Experts, une architecture de réseau de neurones où seuls quelques sous-réseaux spécialisés (les « experts ») sont activés pour chaque token, permettant de construire des modèles massifs à coût d’inférence réduit.
- Signifie
- Mixture of Experts
- Aussi écrit
- MoE, SMoE (Sparse MoE), Sparse Mixture of Experts
- Catégorie
- Architecture de modèle / Technique de calcul conditionnel
- Opposé
- Modèle dense (tous les paramètres actifs à chaque token)
- Ratio typique
- 3 % à 25 % des paramètres activés par token
- Adoption 2026
- Plus de 60 % des nouveaux modèles open-source utilisent le MoE ; 100 % du top 10 open-source sur Artificial Analysis
Que signifie MoE exactement ?
MoE (prononcé « mo-é » ou épelé « M-O-E ») désigne une architecture dans laquelle un LLM est divisé en sous-réseaux spécialisés appelés « experts ». Un routeur (ou gating network) décide, pour chaque token traité, quels experts activer parmi l’ensemble disponible. Les experts non sélectionnés restent inactifs, ce qui signifie que le modèle utilise seulement une fraction de ses paramètres totaux à chaque instant.
C’est cette propriété de sparsité qui rend le MoE fondamentalement différent d’un modèle dense. Un modèle dense active 100 % de ses paramètres pour chaque token. Un modèle MoE peut n’en activer que 3 à 25 %, tout en conservant la capacité de stockage d’un modèle bien plus large.
Pour les mécanismes internes détaillés (routeur, top-K, load balancing, perte auxiliaire), consultez la page dédiée : Mixture of Experts.
Paramètres actifs vs. paramètres totaux : la distinction fondamentale
La première chose à maîtriser pour comprendre les fiches techniques des modèles MoE est la différence entre paramètres totaux et paramètres actifs.
Paramètres totaux. C’est l’ensemble des poids du modèle, incluant tous les experts. C’est cette valeur qui détermine la mémoire GPU nécessaire pour charger le modèle. Un modèle de 671 milliards de paramètres totaux nécessite des centaines de Go de VRAM, même si seule une fraction est utilisée par token.
Paramètres actifs. C’est le nombre de paramètres effectivement utilisés pour traiter un token donné. C’est cette valeur qui détermine le coût de calcul (FLOPs) et la vitesse d’inférence. Un modèle avec 37 milliards de paramètres actifs se comporte, en termes de vitesse, comme un modèle dense de 37 milliards.
Exemple concret : DeepSeek V3 avec 671B paramètres totaux et 37B actifs. Sa qualité de réponse rivalise avec GPT-4 (dense, estimé à ~1 800B paramètres). Son coût d’inférence en FLOPs est celui d’un modèle dense de ~37B. Le ratio qualité/coût est donc spectaculaire.
Panorama complet des modèles MoE en 2026
Le paysage MoE a explosé. Voici le tableau le plus complet des modèles MoE déployés ou disponibles, classés par paramètres totaux.
| Modèle | Créateur | Params totaux | Params actifs | Experts (routés) | Top-K | Licence |
|---|---|---|---|---|---|---|
| Switch-C | 1 571B | Variable | 128 | 1 | Apache 2.0 | |
| GLaM | 1 200B | ~97B | 64 | 2 | Non public | |
| Kimi K2 | Moonshot AI | 1 000B | 32B | Variable | Variable | Open-weight |
| Ling-1T | InclusionAI | 1 000B | ~50B | Variable | Variable | Open-weight |
| GLM-5 | Zhipu AI | 745B | 44B | Variable | Variable | Open-weight |
| Mistral Large 3 | Mistral AI | 675B | ~41B | Variable | Variable | Apache 2.0 |
| DeepSeek V3/V3.2 | DeepSeek | 671B | 37B | 256 + 1 partagé | 8 | MIT |
| DeepSeek-R1 | DeepSeek | 671B | 37B | 256 + 1 partagé | 8 | MIT |
| Qwen3-Coder-480B | Alibaba | 480B | 35B | 160 | 8 | Open-weight |
| Trinity-Large-Preview | Arcee AI | 400B | 13B | 256 | 4 | Apache 2.0 |
| Qwen3.5-397B | Alibaba | 397B | ~17B | Variable | Variable | Open-weight |
| GLM-4.5 | Zhipu AI | 355B | Variable | Variable | Variable | Open-weight |
| Grok-1 | xAI | 314B | ~78B | 8 | 2 | Apache 2.0 |
| MiMo-V2-Flash | Xiaomi | 309B | 15B | Variable | Variable | Open-weight |
| MiniMax M2.5 | MiniMax | 230B | 10B | Variable | Variable | Open-weight |
| Step 3.5 Flash | StepFun | 196B | 11B | Variable | Variable | Open-weight |
| Mixtral 8x22B | Mistral AI | 141B | 39B | 8 | 2 | Apache 2.0 |
| DBRX | Databricks | 132B | 36B | 16 | 4 | Open |
| GLM-4.5-Air | Zhipu AI | 106B | 12B | Variable | Variable | Open-weight |
| Qwen3-Next 80B | Alibaba | 80B | 3B | Variable | Variable | Open-weight |
| Mixtral 8x7B | Mistral AI | 46,7B | 12,9B | 8 | 2 | Apache 2.0 |
Tendances clés du MoE en 2026
Des ratios actif/total de plus en plus extrêmes
La tendance la plus marquante est la chute du ratio paramètres actifs / paramètres totaux. Mixtral 8x7B (2023) activait 27 % de ses paramètres. Qwen3-Next 80B (2025) n’en active que 3,7 %. MiniMax M2.5 descend à 4,3 %. Trinity-Large-Preview est à 3,3 %. Cela signifie des modèles de plus en plus capables pour un coût d’inférence de plus en plus faible.
Plus d’experts, plus petits
Les architectures récentes abandonnent le schéma classique « 8 gros experts, top-2 » (Mixtral, Grok-1) au profit de dizaines voire centaines de petits experts. DeepSeek V3 utilise 256 experts routés. Trinity-Large-Preview en utilise également 256 avec un routage top-4. Cette segmentation fine augmente la flexibilité des combinaisons et améliore la spécialisation de chaque expert.
Experts partagés et couches denses initiales
Deux innovations architecturales se généralisent. Les experts partagés (toujours actifs, indépendamment du routage) captent les connaissances communes et évitent la redondance entre experts routés. Les couches denses initiales (2 à 3 couches FFN standard avant les blocs MoE) stabilisent l’apprentissage des premières représentations syntaxiques et sémantiques. GLM-4.5 et DeepSeek V3 utilisent ces deux techniques.
Architecture dominante des modèles frontier
Le basculement est net : plus de 60 % des modèles open-source publiés en 2026 utilisent le MoE. Quasiment tous les modèles frontier (DeepSeek V3/R1, Mistral Large 3, Qwen3.5, GLM-5, Kimi K2) sont MoE. L’exception notable reste Anthropic, dont les modèles Claude restent denses.
Quand choisir un modèle MoE ?
Vous devriez choisir un MoE quand…
Vous cherchez la meilleure qualité pour un budget de calcul donné. C’est le scénario roi du MoE. Pour le coût d’inférence d’un modèle de ~37B paramètres (DeepSeek V3), vous obtenez la qualité d’un modèle frontier. L’écart de prix est saisissant : une tâche complexe qui coûte 15 $ avec GPT-5 coûte environ 0,50 $ avec DeepSeek V3.
Vos données sont multi-domaines. Le MoE excelle sur des entrées diversifiées (code, texte, maths, multilingue) car les experts se spécialisent naturellement sur différents patterns. C’est pourquoi les chatbots généralistes et les assistants de code bénéficient particulièrement du MoE.
Vous avez accès à une infrastructure multi-GPU. Le MoE tire parti de l’expert parallelism, où différents experts sont hébergés sur différents GPU. Si votre infrastructure le permet, vous obtenez un parallélisme naturel et efficace.
Vous devriez préférer un modèle dense quand…
Votre mémoire GPU est limitée. Un modèle MoE de 671B paramètres nécessite des centaines de Go de VRAM, même si seuls 37B sont actifs. Si vous ne disposez que d’un ou deux GPU grand public, un modèle dense de 7B à 70B sera plus adapté.
La simplicité de déploiement prime. Les modèles denses se déploient avec un model parallelism standard, sans la complexité additionnelle du routage inter-GPU et de l’équilibrage de charge.
Vous travaillez à petite échelle. En dessous de ~30B paramètres, le MoE apporte peu d’avantages. Le surcoût du routeur et la complexité supplémentaire ne se justifient pas quand un modèle dense de taille comparable fait le travail.
La latence ultra-faible est critique. Les décisions de routage ajoutent un overhead (faible mais non nul), et les communications inter-GPU des architectures distribuées ajoutent de la latence. Pour des applications temps-réel extrêmement sensibles, un modèle dense optimisé peut être préférable.
Comment lire la fiche technique d’un modèle MoE
Quand vous évaluez un modèle MoE, voici les chiffres clés à repérer et ce qu’ils signifient concrètement :
| Métrique | Ce qu’elle indique | Exemple (DeepSeek V3) |
|---|---|---|
| Paramètres totaux | Mémoire GPU nécessaire, capacité théorique du modèle | 671B |
| Paramètres actifs | Coût de calcul réel par token, vitesse d’inférence | 37B |
| Nombre d’experts (routés) | Granularité de la spécialisation | 256 |
| Experts partagés | Connaissances communes toujours activées | 1 |
| Top-K | Nombre d’experts activés par token (impacte coût et qualité) | 8 |
| Ratio actif/total | Efficacité de la sparsité (plus bas = plus efficient) | 5,5 % |
| Fenêtre de contexte | Longueur max de texte traitable | 128K tokens |
Impact du MoE sur les prix API
L’architecture MoE a un impact direct sur la tarification des API d’inférence. Puisque le coût de calcul est proportionnel aux paramètres actifs (pas totaux), les modèles MoE offrent un rapport qualité/prix nettement supérieur aux modèles denses équivalents.
| Modèle | Architecture | Prix input ($/M tokens) | Prix output ($/M tokens) | Qualité relative |
|---|---|---|---|---|
| DeepSeek V3.2 | MoE 671B/37B | ≈ 0,28 $ | ≈ 0,42 $ | Frontier |
| Mistral Large 3 | MoE 675B/41B | ≈ 0,50 $ | ≈ 1,50 $ | Frontier |
| Claude Opus 4.6 | Dense | 5,00 $ | 25,00 $ | Frontier |
| GPT-5.4 | Probablement MoE | 2,50 $ | 15,00 $ | Frontier |
| MiniMax M2.5 | MoE 230B/10B | ≈ 0,12 $ | ≈ 1,20 $ | Quasi-frontier |
Le contraste est frappant. Les modèles MoE open-source de DeepSeek et Mistral offrent une qualité frontier à un prix 10 à 60 fois inférieur aux modèles propriétaires. C’est le résultat direct de l’efficacité computationnelle du MoE : moins de FLOPs par token signifie moins de GPU nécessaires, donc un coût moindre facturé à l’utilisateur.
MoE et matériel : ce que ça change
Le MoE impose des contraintes hardware spécifiques qui diffèrent des modèles denses :
Mémoire : tous les experts sont chargés. Même si seuls 37B de paramètres sont actifs, les 671B doivent résider en mémoire. C’est le paramètre totaux qui détermine la VRAM nécessaire, pas les paramètres actifs. D’où l’importance de la quantification pour réduire l’empreinte.
Bande passante mémoire : le vrai goulot. À chaque token, les poids des experts sélectionnés doivent être lus depuis la mémoire. Si les experts changent souvent (ce qui est courant), la bande passante mémoire devient le facteur limitant, pas la puissance de calcul. C’est pourquoi NVIDIA met l’accent sur la bande passante HBM de ses GPU Blackwell.
Interconnexion réseau : critique en multi-GPU. En expert parallelism, les tokens doivent voyager entre GPU pour atteindre l’expert sélectionné. La vitesse de l’interconnexion (NVLink, InfiniBand) impacte directement la latence et le throughput.
Résultat concret : NVIDIA GB200 NVL72 (Blackwell) offre une accélération 10× et un coût par token divisé par 10 pour les modèles MoE par rapport à la génération H200. Le format NVFP4 réduit encore l’empreinte mémoire tout en maintenant la précision.
Exécuter un modèle MoE en local
Si vous souhaitez utiliser un modèle MoE en local, voici les options réalistes classées par taille :
Mixtral 8x7B (46,7B paramètres). Avec une quantification 4-bit (GPTQ, AWQ, ou GGUF), l’empreinte tombe à environ 25 Go. Un GPU RTX 4090 (24 Go) peut le faire tourner, mais de manière serrée. Deux GPU de 24 Go offrent un confort suffisant. C’est le MoE local le plus accessible.
Qwen3-Next 80B (80B paramètres, 3B actifs). Environ 40-50 Go en 4-bit. Nécessite au minimum 2 GPU de 24 Go. L’inférence est très rapide grâce aux seulement 3B paramètres actifs par token.
DBRX (132B paramètres). Environ 70 Go en 4-bit. Nécessite 3 à 4 GPU de 24 Go ou un GPU A100/H100 de 80 Go.
DeepSeek V3 (671B paramètres). Même en 4-bit, l’empreinte dépasse 350 Go. Hors de portée d’un setup grand public. Requiert un cluster multi-GPU professionnel.
MoE : vocabulaire associé
L’écosystème MoE a son propre jargon. Voici les termes que vous rencontrerez le plus souvent :
| Terme | Signification | Page glossaire |
|---|---|---|
| Sparse Model | Modèle où seuls certains paramètres sont activés par entrée | sparse-model |
| Dense Model | Modèle où tous les paramètres sont activés (opposé du MoE) | dense-model |
| Routage / Routing | Mécanisme de sélection des experts pour chaque token | mixture-of-experts-routing |
| Load Balancing | Équilibrage de la charge entre experts pour éviter les goulots | load-balancing-moe |
| Capacity Factor | Limite maximale de tokens qu’un expert peut recevoir | capacity-factor |
| Auxiliary Loss | Perte additionnelle pour encourager un routage équilibré | auxiliary-loss |
| Expert Parallelism | Distribution des experts sur différents GPU | expert-parallelism |
| Token Dropping | Tokens ignorés quand un expert est surchargé | (couvert dans mixture-of-experts) |
MoE vs. autres approches d’efficacité
Le MoE n’est pas la seule technique pour rendre les modèles plus efficients. Voici comment il se positionne par rapport aux alternatives :
MoE vs. Distillation. La distillation crée un petit modèle qui imite un grand. Le MoE garde la grande taille mais réduit le calcul effectif. Les deux sont complémentaires : on peut entraîner un grand MoE puis le distiller en un modèle dense plus petit pour le déploiement.
MoE vs. Quantification. La quantification réduit la précision des poids (32-bit → 4-bit) pour diminuer la mémoire et accélérer les calculs. Le MoE réduit le nombre de paramètres activés. Les deux sont combinables et complémentaires : un MoE quantifié en 4-bit cumule les gains.
MoE vs. Pruning. Le pruning supprime définitivement des paramètres non essentiels. Le MoE conserve tous les paramètres mais n’en active qu’une partie conditionnellement. Le MoE est plus flexible car tous les experts restent disponibles selon le contexte.
MoE vs. Speculative decoding. Le speculative decoding accélère l’inférence en prédisant plusieurs tokens simultanément avec un petit modèle. Il s’applique indépendamment du MoE et les deux peuvent être combinés. Together AI utilise d’ailleurs le speculative decoding sur des modèles MoE pour maximiser le throughput.
Verdict
MoE n’est plus une option architecturale parmi d’autres : c’est le standard de facto pour les modèles frontier open-source en 2026. La combinaison de modèles massifs (600B à 1T+ paramètres) avec une inférence abordable (seulement 10 à 50B paramètres actifs) a créé un nouveau paradigme où la qualité frontier est accessible à une fraction du coût des modèles propriétaires.
Pour les développeurs et les entreprises, la conséquence pratique est claire : si vous utilisez une API, privilégiez les modèles MoE pour maximiser le rapport qualité/prix (DeepSeek V3, Mistral Large 3). Si vous déployez en local, évaluez d’abord votre budget VRAM (c’est la taille totale, pas active, qui compte). Et si vous entraînez vos propres modèles, le MoE est le chemin le plus efficient vers la performance à grande échelle.
Questions fréquentes sur le MoE
MoE et SMoE, est-ce la même chose ?
Presque. MoE (Mixture of Experts) est le terme général. SMoE (Sparse Mixture of Experts) précise qu’on parle d’un MoE où seul un sous-ensemble d’experts est activé par token. En pratique, dans le contexte des LLM, quand quelqu’un dit « MoE », il parle quasiment toujours d’un Sparse MoE. Le MoE dense (où tous les experts sont activés avec des pondérations différentes) existe en théorie mais n’est pas utilisé pour les grands modèles de langage car il ne procure pas de gain computationnel.
Pourquoi les modèles Claude d’Anthropic n’utilisent-ils pas le MoE ?
Anthropic n’a pas communiqué publiquement les raisons architecturales derrière le choix de rester dense pour Claude. Plusieurs hypothèses circulent : les modèles denses sont plus simples à entraîner et à déployer, l’alignement (Constitutional AI) pourrait être plus complexe à implémenter avec des experts spécialisés, et Anthropic pourrait miser sur des avantages en termes de stabilité et de prédictibilité. Cela dit, la compétitivité de Claude Opus 4.6 face aux modèles MoE prouve qu’un modèle dense bien optimisé reste très performant.
Un modèle MoE de 671B est-il meilleur qu’un modèle dense de 671B ?
Pas nécessairement en qualité brute. Un modèle dense de 671B (s’il pouvait être entraîné et déployé efficacement) aurait potentiellement une qualité supérieure car chaque paramètre contribue à chaque token. L’avantage du MoE est l’efficacité : il offre une qualité proche de celle d’un modèle dense de même taille totale, mais à un coût de calcul drastiquement réduit (celui d’un modèle 10 à 30× plus petit). Le MoE ne promet pas d’être « meilleur » mais d’être « presque aussi bon pour beaucoup moins cher ».
Combien de GPU faut-il pour un modèle MoE en production ?
Cela dépend du modèle et du throughput souhaité. Mixtral 8x7B tourne sur 2 GPU A100 (80 Go). DeepSeek V3 nécessite un cluster sérieux : au minimum 8 GPU H100 pour un service basique. Pour un throughput de production élevé, NVIDIA recommande des systèmes NVL72 (72 GPU Blackwell), qui réduisent le coût par token d’un facteur 10× par rapport aux systèmes H200. La règle : divisez les paramètres totaux (en Go) par la VRAM de vos GPU pour estimer le nombre minimum.
Le MoE va-t-il remplacer tous les modèles denses ?
Non. Les modèles denses conservent leur place pour les petites et moyennes tailles (≤70B), les déploiements edge/embarqués où la mémoire est contrainte, et les cas où la simplicité de déploiement prime. LLaMA, les Ministral de Mistral et les petits Qwen restent denses. Le MoE domine au-delà de ~100B paramètres, là où l’efficacité computationnelle devient critique. La coexistence des deux architectures est le scénario le plus probable à moyen terme.