Passer au contenu principal
Un modèle Mixture of Experts (MoE) fonctionne comme un grand modèle mais n’utilise qu’une petite fraction de ses poids à chaque jeton généré. Cette séparation — capacité totale énorme, calcul par jeton réduit — est la raison pour laquelle la dernière génération de modèles frontier open-weight est passée au MoE. C’est aussi la raison pour laquelle un modèle comme DeepSeek-V3 avec 671B de paramètres totaux n’en active que 37B par jeton, tout en nécessitant suffisamment de mémoire pour contenir l’ensemble des 671B. Cette page explique le fonctionnement du routage, ce que le parallélisme d’experts implique pour le serving, et comment dimensionner le matériel pour les modèles MoE.
Last verified: 2026-10-14

​
Qu’est-ce que le Mixture of Experts

Dans un transformer dense standard, chaque jeton traverse chaque couche et active tous les paramètres à chaque passe avant. Un modèle dense de 70B utilise l’intégralité des 70B paramètres pour chaque jeton. Un modèle MoE remplace la sous-couche feed-forward de certaines couches transformer par plusieurs experts sous-réseaux en parallèle et un routeur (aussi appelé réseau de portes) qui décide quels experts traitent chaque jeton. La plupart des experts restent inactifs pour un jeton donné. Un modèle avec 256 experts peut n’en activer que 8 par jeton — environ 3% de sa capacité totale par étape. Le résultat :
  • Paramètres totaux : déterminent la mémoire nécessaire au modèle (tous les experts doivent rester chargés).
  • Paramètres actifs : déterminent le coût de calcul par jeton (seuls les experts sélectionnés s’exécutent).
C’est l’arbitrage fondamental. Le MoE vous offre la capacité de connaissance d’un très grand modèle pour le coût de calcul par jeton d’un modèle beaucoup plus petit — mais vous devez quand même payer la facture mémoire pour chaque expert, qu’il s’active ou non.

​
Comment fonctionne le routage MoE

Chaque couche MoE contient un routeur qui sélectionne quels experts traitent chaque jeton. L’approche la plus courante dans les modèles en production est le gating top-k :
  1. Le routeur calcule un score pour chaque expert en multipliant l’état caché du jeton par une matrice de poids apprise, puis applique un softmax pour produire une distribution de probabilité sur tous les experts.
  2. Les k experts avec les scores les plus élevés sont sélectionnés. Leurs sorties sont combinées en utilisant les poids normalisés par softmax comme coefficients.
  3. Tous les autres experts ne produisent aucune sortie pour ce jeton — ils sont entièrement ignorés.
La valeur de k varie selon le modèle. DeepSeek-V3 et Qwen3 utilisent k=8. gpt-oss utilise k=4. Kimi K3 utilise 16 experts routés plus 2 experts partagés par jeton.

​
Experts partagés

Certaines architectures réservent un sous-ensemble d’experts partagés qui s’activent pour chaque jeton, indépendamment des scores de routage. Les experts partagés gèrent les patterns communs (bases de la modélisation du langage, formatage) afin que les experts routés puissent se spécialiser. Qwen3-Next utilise 1 expert partagé plus 10 experts routés. Kimi K3 utilise 2 experts partagés plus 16 experts routés. DeepSeek-V3 et le MoE Qwen3 original n’utilisent pas d’experts partagés — tous les experts actifs sont sélectionnés par le routeur.

​
Équilibrage de charge

Un routeur qui envoie toujours les jetons aux mêmes quelques experts annule l’intérêt du MoE : ces experts deviennent des goulots d’étranglement tandis que les autres restent inactifs. Les modèles en production utilisent plusieurs stratégies pour maintenir une utilisation équilibrée des experts :
  • Perte auxiliaire — une pénalité à l’entraînement qui pousse le routeur vers une utilisation uniforme des experts. La plupart des premiers modèles MoE (Switch Transformer, ST-MoE) utilisent cette approche. Le coût est une légère réduction de la spécialisation : le routeur optimise l’équilibre en même temps que la qualité.
  • Équilibrage de charge sans perte auxiliaire — DeepSeek-V3 a introduit une approche basée sur des biais qui ajuste les biais de routage par expert à l’inférence. Si un expert reçoit plus de jetons que sa part cible, son biais diminue, ce qui réduit sa probabilité d’être sélectionné. Cela élimine entièrement le compromis qualité des pertes auxiliaires.
  • Stable LatentMoE — Kimi K3 utilise un mécanisme de routage latent appris qui produit des affectations d’experts plus stables entre les jetons, réduisant la variance qui cause le déséquilibre de charge dans le gating top-k standard.
Ce qu’il faut retenir : l’équilibrage de charge se résout à l’entraînement, pas au serving. En tant qu’utilisateur exécutant un modèle MoE localement, vous ne configurez pas le routage — vous configurez la mémoire et le parallélisme.

​
Pourquoi la mémoire MoE évolue avec les paramètres totaux, pas les actifs

C’est le point le plus important à comprendre avant d’exécuter un modèle MoE localement. Tous les experts doivent résider en mémoire en permanence. Le routeur décide dynamiquement — par jeton, par couche — quels experts activer. Il n’y a aucun moyen de savoir à l’avance quels experts une invite donnée nécessitera, donc chaque expert doit être chargé et prêt. Swapper des experts depuis le disque à la demande est bien trop lent pour une inférence interactive. Cela signifie que la formule de mémoire de Mémoire et délestage s’applique aux paramètres totaux, pas aux actifs :
Les paramètres actifs n’affectent que le calcul par jeton (et donc la vitesse de génération), pas la mémoire.

​
Exemples détaillés

Le facteur 1.2x couvre le cache KV, les activations et la surcharge du framework pour une longueur de contexte modeste — la même formule que pour les modèles denses. Consultez Mémoire et délestage pour la dérivation complète du dimensionnement.

​
Ce que cela signifie en pratique

Un Qwen3-30B-A3B a 30.5B de paramètres totaux mais seulement 3.3B actifs. Il génère des jetons à peu près à la vitesse d’un modèle dense de 3.3B — mais il a besoin de mémoire pour l’ensemble des 30.5B. En 4 bits, cela fait environ 18 Go, ce qui tient dans un GPU de 24 Go. Un modèle dense de 30B en 4 bits aurait besoin d’environ la même mémoire mais générerait les jetons plus lentement, car il traite tous les 30B paramètres par jeton au lieu de 3.3B. À l’inverse, Kimi K3 a 2.8T de paramètres totaux et 104B actifs. Il génère des jetons à peu près à la vitesse d’un modèle dense de 104B — mais il a besoin d’environ 1.4 To de mémoire rien que pour les poids en 4 bits. Aucun matériel grand public ou prosumer ne peut contenir cela.

​
MoE vs modèles denses

L’essentiel : le MoE dissocie la capacité de connaissance du calcul par jeton. Un MoE de 671B paramètres avec 37B actifs peut égaler ou dépasser un modèle dense de 70B en qualité tout en générant des jetons à peu près à la vitesse d’un 70B — mais il a besoin de 671B de mémoire.

​
Parallélisme d’experts : servir du MoE sur plusieurs GPUs

Quand un modèle MoE ne tient pas sur un seul GPU, vous devez le distribuer. Le parallélisme d’experts est la stratégie spécifique au MoE pour y parvenir :
  • Chaque GPU détient un sous-ensemble des experts totaux. Dans un modèle de 256 experts réparti sur 8 GPUs, chaque GPU détient 32 experts.
  • Pendant la passe avant, les décisions du routeur déterminent quels jetons doivent être envoyés à quel GPU. Les jetons routés vers des experts sur le GPU 3 sont communiqués au GPU 3 pour traitement, puis les résultats reviennent.
  • Les couches non-experts (attention, embeddings) sont généralement réparties avec le parallélisme de tenseurs standard, où chaque GPU détient une tranche des matrices de poids de chaque couche.
Les runtimes de serving en production comme vLLM et TensorRT-LLM combinent le parallélisme de tenseurs pour les couches d’attention avec le parallélisme d’experts pour les couches MoE. Le résultat s’appelle le parallélisme mixte. La documentation vLLM couvre la configuration en détail ; le paramètre clé est que le parallélisme d’experts est un axe de parallélisme distinct du parallélisme de tenseurs. L’implication pratique : les modèles MoE bénéficient d’interconnexions à haut débit entre les GPUs (NVLink, InfiniBand) car les jetons doivent se déplacer entre les GPUs lors de l’étape de routage. Un cluster connecté uniquement par PCIe subira des pénalités de vitesse significatives dues à la communication inter-GPU.

​
Quels modèles open-weight utilisent le MoE

La génération actuelle de modèles frontier open-weight s’est massivement orientée vers le MoE. Voici le paysage en octobre 2026 :

​
Moins de 50B total (exécutables sur 1-2 GPUs grand public en 4 bits)

​
50B-250B total (multi-GPU ou systèmes unifiés à haute mémoire)

​
Plus de 250B total (matériel serveur requis)

Sources : fiches modèles sur HuggingFace et rapports techniques officiels liés ci-dessous.

​
Ce qu’il faut retenir pour l’inférence locale

Le MoE change la signification des chiffres sur une fiche modèle :
  • Paramètres actifs : indiquent la vitesse de génération du modèle. Un MoE de 671B avec 37B actifs génère à peu près à la vitesse de 37B.
  • Paramètres totaux : indiquent la mémoire nécessaire au modèle. Ce même MoE de 671B a besoin de 671B de VRAM, pas 37B.
  • Nombre d’experts et routage : sont des détails d’architecture qui affectent la qualité et l’efficacité de l’entraînement, mais en tant qu’utilisateur d’inférence locale, vous ne les configurez pas — vous configurez la mémoire et le parallélisme.
Quand vous voyez un modèle MoE annoncé comme “2.4T paramètres, 95B actifs”, lisez : “génère à la vitesse de 95B, a besoin de 2.4T de mémoire.” Dimensionnez votre matériel pour le total, profitez de la vitesse du nombre actif. Utilisez le guide d’adéquation modèle-GPU pour vérifier si un modèle MoE spécifique et une quantification donnée tiennent sur votre matériel avant de télécharger.

​
Approfondir

Memory and offloading

La formule complète de dimensionnement, y compris les octets par paramètre par précision et les mécanismes de délestage.

Quantization

Réduisez les octets par paramètre pour modifier l’équation mémoire des modèles MoE et denses.

How inference works

Pourquoi le décodage est limité par la bande passante mémoire et comment les paramètres actifs affectent la vitesse de génération.

Model serving and scaling

Stratégies de parallélisme, serving multi-GPU, et comment les runtimes distribuent les modèles.

​
Modèles utilisant le MoE

Kimi K3

2.8T total, 104B actifs, 896 experts avec routage Stable LatentMoE.

DeepSeek

V3/R1 à 671B/37B, V4.1-Flash à 552B avec activation asymétrique 8B/16B.

Qwen3

Niveaux MoE 30B-A3B et 235B-A22B, 128 experts avec routage top-8.

Qwen3.8

Flagship 2.4T avec 95B actifs, 512 experts, 10 routés + 1 partagé.

GLM-5.3

753B total, ~40B actifs, MoE avec contexte 1M.

gpt-oss

20b (32 experts) et 120b (128 experts), routage top-4, Apache 2.0.

​
Une fois que ça tient et que ça tourne

Charger un modèle MoE sur votre matériel est la première étape. Une fois qu’il répond aux requêtes sur localhost, l’étape suivante est d’y accéder depuis n’importe où.

Give it a stable endpoint

Tokios ne choisit, n’héberge ni n’affine le modèle — une fois qu’il tourne localement, Tokios le transforme en un endpoint stable et authentifié que vous pouvez appeler de n’importe où.

​
Questions fréquentes

Le routeur sélectionne des experts différents pour chaque jeton, donc chaque expert doit être accessible. À tout moment, seuls k experts s’activent, mais le jeton suivant pourrait nécessiter un ensemble complètement différent. Cela signifie que tous les poids des experts doivent rester en mémoire (VRAM ou RAM) en permanence — vous dimensionnez par les paramètres totaux, pas les paramètres actifs.
Calculez : paramètres totaux × octets par poids. En 4 bits (le plancher de quantification native pour la plupart des modèles MoE), c’est total_params × 0.5 GB. Ajoutez 20% pour le cache KV et la surcharge. Si ce nombre tient dans votre VRAM + RAM combinées, le modèle se charge. S’il ne tient pas, aucune optimisation ne change cela — il vous faut plus de mémoire ou un modèle plus petit.
Les experts partagés sont actifs sur chaque jeton — ils gèrent les tâches communes comme la modélisation du langage. Les experts routés sont sélectionnés par jeton par le réseau de portes. DeepSeek-V3 utilise 256 experts routés avec 8 actifs et pas d’experts partagés. Kimi K3 utilise 896 experts avec 16 routés + 2 partagés. Qwen3.8 utilise 512 experts avec 10 routés + 1 partagé.
Seulement les petits. Qwen3-30B-A3B (30.5B total, ~18 Go en 4 bits) tient dans un GPU de 24 Go. gpt-oss-20b (21B total, ~13 Go en 4 bits) tient aussi. Tout ce qui dépasse ~50B de paramètres totaux nécessite soit du serving multi-GPU (vLLM, SGLang avec parallélisme d’experts), soit un système à mémoire unifiée élevée (Mac Studio, DGX Spark) avec délestage CPU.
Le parallélisme d’experts répartit les couches d’experts sur plusieurs GPUs — le GPU 0 détient les experts 0-63, le GPU 1 détient les experts 64-127, etc. Chaque GPU calcule les sorties de ses experts et elles sont combinées via une communication all-to-all. Vous en avez besoin quand les poids totaux des experts ne tiennent pas sur un seul GPU. vLLM et SGLang le supportent tous les deux ; consultez le guide d’optimisation vLLM pour la configuration.

​
Sources