Polydesk-logotype
Polydesk.ai — Header

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.

MoE — Fiche rapide
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.

Règle de pouce pour comparer Quand vous évaluez la performance d’un modèle MoE, comparez-le à un modèle dense ayant un nombre de paramètres totaux proche de ses paramètres totaux (pas actifs). Quand vous évaluez son coût d’inférence et sa vitesse, comparez-le à un modèle dense ayant un nombre de paramètres proche de ses paramètres actifs. C’est précisément cette asymétrie qui fait l’intérêt du MoE.

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 Google 1 571B Variable 128 1 Apache 2.0
GLaM Google 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
Les modèles propriétaires probablement MoE GPT-4, GPT-5.x (OpenAI) et Gemini (Google) sont largement soupçonnés d’utiliser des architectures MoE, mais leurs créateurs n’ont pas confirmé officiellement. Les modèles Claude d’Anthropic sont, eux, confirmés comme denses. L’architecture exacte de Grok 2 et ultérieurs n’a pas été rendue publique non plus.

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
Attention aux annonces marketing Certains communiqués mettent en avant les paramètres totaux pour impressionner (« modèle à 1 000 milliards de paramètres ! ») sans préciser les paramètres actifs. Un modèle de 1T paramètres avec 3B actifs n’est pas comparable en qualité à un modèle dense de 1T paramètres. Le chiffre pertinent pour la qualité est la capacité totale combinée au nombre de paramètres actifs, pas l’un ou l’autre isolément.

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.

Le meilleur rapport qualité/accessibilité en local Pour une utilisation locale avec un ou deux GPU grand public, Mixtral 8x7B reste le choix le plus équilibré. Pour ceux ayant accès à 2-4 GPU de 24 Go, Qwen3-Next 80B offre un ratio performances/coût exceptionnel grâce à ses seulement 3B paramètres actifs pour 80B de capacité totale.

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.

Polydesk.ai — Footer