Mixture-of-Experts (MoE) à grande échelle

Un modèle Mixture-of-Experts (MoE) répond à une question simple : peut-on multiplier le nombre de paramètres d'un réseau sans multiplier d'autant le coût de calcul par token ? La réponse est oui, et elle repose sur la parcimonie (sparsity) : plutôt qu'un seul gros réseau dense activé à chaque passage, on dispose de plusieurs sous-réseaux — les experts — dont un routeur n'active qu'une poignée pour chaque token. C'est ce découplage entre paramètres totaux et paramètres actifs qui a permis de franchir le cap du trillion de paramètres. Cet article explique le mécanisme, ses pièges (équilibrage de charge, effondrement d'experts, abandon de tokens) et son passage à l'échelle.

Le point de départ : la couche dense FFN

Dans un Transformer classique, chaque bloc alterne une couche d'attention et un réseau feed-forward (FFN) — typiquement deux projections linéaires séparées par une non-linéarité. Ce FFN représente souvent les deux tiers des paramètres d'un bloc, et surtout : tous ses paramètres sont activés pour chaque token. Doubler la taille du FFN double le coût de calcul (FLOPs) de chaque token traité. La capacité du modèle et son coût d'inférence sont donc rigidement couplés.

L'idée du MoE est de briser ce couplage. On remplace l'unique FFN dense par un ensemble de N FFN indépendants (les experts) plus un petit réseau de routage. Pour un token donné, on n'évalue que k experts sur N (avec k très petit, souvent 1 ou 2). Le modèle peut alors contenir des centaines de milliards de paramètres tout en n'en activant qu'une fraction par token.

Formellement, une couche FFN dense calcule y = W_2 · σ(W_1 · x) pour chaque token x. Une couche MoE calcule y = Σ_{i ∈ top-k} g_i · FFN_i(x), où g_i est le poids de gating de l'expert i et où la somme ne porte que sur les k experts sélectionnés. Les N − k autres experts ne sont jamais évalués pour ce token : leur calcul est purement nul, pas seulement faible.

Figure : dense vs épars. À gauche, un FFN unique traite chaque token avec tous ses paramètres ; à droite, le routeur dirige chaque token vers le top-k d'experts, la plupart restant inactifs.

Paramètres totaux vs paramètres actifs

C'est la métrique fondamentale du MoE. Un modèle est décrit par deux chiffres :

• les paramètres totaux : tout ce qui doit être stocké en mémoire (tous les experts) ;
• les paramètres actifs : ce qui participe réellement au calcul d'un token (attention + experts sélectionnés).

Mixtral 8x7B illustre parfaitement l'écart : il dispose de 8 experts par couche, route chaque token vers 2 d'entre eux, totalise ~47 milliards de paramètres mais n'en active que ~13 milliards par token. On obtient donc la qualité d'un grand modèle pour le coût de calcul d'un modèle bien plus petit — au prix d'une empreinte mémoire élevée (il faut charger les 47 G).

Règle mnémotechnique : les paramètres totaux gouvernent la mémoire (VRAM), les paramètres actifs gouvernent le calcul (latence, FLOPs). Un MoE optimise le second sans contrainte sur le premier.

Un calcul d'enveloppe

Prenons un bloc dont le FFN dense ferait 0,5 G de paramètres. Avec 8 experts on stocke 8 × 0,5 = 4 G de paramètres d'experts par couche, mais en top-2 on n'en calcule que 2 × 0,5 = 1 G par token. Sur 32 couches, cela donne 128 G stockés contre 32 G calculés côté FFN. À cela s'ajoutent les couches partagées (attention, embeddings) qui, elles, comptent dans les deux totaux. Le ratio actifs/totaux qui en résulte — souvent < 10 % — est exactement ce que le MoE cherche à minimiser sans perdre en qualité.

Un peu d'histoire

L'idée n'est pas neuve : le « mélange d'experts » remonte aux années 1990 (Jacobs, Jordan, Hinton), où l'on entraînait plusieurs réseaux spécialisés et un gating pour les pondérer. Sa résurrection moderne tient à deux travaux clés :

• le Sparsely-Gated MoE (Shazeer et al., 2017) qui introduit le routage top-k pour des couches à des milliers d'experts dans un LSTM ;
• le Switch Transformer (Fedus, Zoph, Shazeer, 2021) qui simplifie au top-1, l'intègre au Transformer et démontre la mise à l'échelle au trillion.

Depuis, la lignée s'est densifiée : GShard, GLaM, ST-MoE, Mixtral, DeepSeekMoE/V3, et l'adoption dans des modèles de production grand public. Le fil conducteur historique est constant : à chaque étape, on cherche à rendre la couche éparse à la fois plus stable à entraîner et moins coûteuse à communiquer entre accélérateurs.

Le routeur (gating network)

Le cœur du MoE est le routeur, aussi appelé gating network. C'est une simple couche linéaire : elle projette le vecteur caché du token sur N logits (un par expert), applique un softmax, et on retient les k plus élevés.

import torch
import torch.nn.functional as F

def top_k_router(x, W_gate, k=2):
    # x : (tokens, d_model) ; W_gate : (d_model, n_experts)
    logits = x @ W_gate                      # scores bruts par expert
    probs = F.softmax(logits, dim=-1)        # distribution sur les experts
    topk_w, topk_idx = probs.topk(k, dim=-1) # k meilleurs experts + poids
    topk_w = topk_w / topk_w.sum(-1, keepdim=True)  # renormalisation
    return topk_idx, topk_w  # à qui envoyer le token, avec quelle pondération

La sortie de la couche est la somme pondérée des sorties des experts sélectionnés, les poids venant du softmax du routeur. Ce routeur est appris conjointement avec le reste du modèle — rien ne lui impose a priori une spécialisation thématique ; la spécialisation, si elle émerge, le fait par l'optimisation.

Détail important : le softmax peut être pris avant ou après le top-k. GShard et Mixtral normalisent les poids des k experts retenus (comme ci-dessus). DeepSeek-V3, lui, remplace le softmax par une sigmoïde par expert, puis normalise les scores des experts sélectionnés — ce qui découple le score d'un expert de celui des autres et facilite l'ajout d'un biais d'équilibrage (voir plus bas).

Figure : le routage top-2. Les scores classent les experts ; les deux meilleurs sont retenus, le facteur de capacité borne le nombre de tokens par expert, et la perte auxiliaire combat l'effondrement.

Top-1, top-2 : combien d'experts par token ?

Le nombre k d'experts activés est un levier majeur.

• Top-1 (Switch Transformer) : un seul expert par token. C'est le choix le plus parcimonieux, qui minimise le calcul et la communication. Les auteurs du Switch Transformer ont montré qu'au-delà de la simplification, le top-1 donne de meilleures performances à budget de calcul fixé, et ont mené l'approche jusqu'à 1,6 trillion de paramètres répartis sur 2 048 experts (modèle Switch-C).
• Top-2 (GLaM, Mixtral) : deux experts par token. Le surcoût est modéré mais le gradient est plus riche (le routeur reçoit plus de signal), ce qui stabilise souvent l'apprentissage. GLaM, avec 1,2 trillion de paramètres totaux sur 64 experts par couche, n'active qu'environ 97 milliards de paramètres (8 %) par prédiction, et a égalé GPT-3 avec un tiers de l'énergie d'entraînement.

Plus k est grand, plus on se rapproche d'un comportement dense (au plus coûteux) ; plus k est petit, plus on est parcimonieux (au plus instable à router). Le compromis classique est top-1 ou top-2. Les architectures à experts fins (DeepSeek-V3) repoussent k plus haut (8) mais avec des experts beaucoup plus petits, ce qui combine richesse de combinaison et parcimonie de calcul.

Variantes de routage

Le routage « token choisit l'expert » (top-k côté token) n'est pas la seule option. Plusieurs variantes existent :

• Expert choice : on inverse la décision — chaque expert choisit ses C meilleurs tokens. L'équilibrage est alors garanti par construction (chaque expert reçoit exactement C tokens), au prix qu'un token peut être pris par zéro ou plusieurs experts.
• Routage par bloc/hash : on assigne les tokens par une fonction fixe (hash) plutôt qu'apprise — surprenamment compétitif et trivialement équilibré.
• Soft MoE : on combine tous les experts via des poids continus sur des « slots » de tokens, ce qui évite la décision dure (et l'abandon) au prix de la pure parcimonie.

Le choix dépend de l'objectif : garantie d'équilibre, qualité, ou parcimonie maximale. En pré-entraînement causal (décodeur), l'expert choice est délicat car un expert ne peut pas « regarder » l'ensemble de la séquence sans fuir d'information du futur ; le routage côté token reste donc dominant pour les LLM génératifs.

Le problème central : l'équilibrage de charge

Si on laisse le routeur libre, un cercle vicieux s'installe. Quelques experts, légèrement meilleurs au départ, reçoivent plus de tokens, donc plus de gradient, donc s'améliorent davantage, donc attirent encore plus de tokens. C'est l'effondrement d'experts (expert collapse) : une poignée d'experts fait tout le travail, les autres ne sont jamais entraînés. La capacité « gratuite » du modèle est gaspillée.

La parade historique est une perte auxiliaire d'équilibrage, ajoutée à la perte principale. Sa forme dans le Switch Transformer est :

L_aux = α · N · Σ_i ( f_i · P_i )

où N est le nombre d'experts, f_i la fraction de tokens réellement routés vers l'expert i dans le batch, et P_i la probabilité moyenne que le routeur attribue à l'expert i. Cette perte est minimale quand la charge est uniforme. Le coefficient α (typiquement ~0,01) dose la pression : trop faible, l'équilibrage ne prend pas ; trop fort, il dégrade la qualité du modèle en forçant un routage artificiel. On y ajoute souvent une router z-loss (ST-MoE) qui pénalise les logits trop grands pour stabiliser numériquement le softmax.

Intuitivement, f_i (un comptage, non différentiable) sert de pondération, et P_i (différentiable) porte le gradient : minimiser le produit pousse le routeur à baisser la probabilité des experts déjà surchargés. C'est un signal doux, qui n'impose rien token par token mais corrige la tendance globale.

Concrètement, l'instabilité d'entraînement des MoE vient de plusieurs sources :

• des logits de routeur qui explosent et saturent le softmax (d'où la z-loss) ;
• des gradients discontinus : un changement infime de score peut faire basculer un token d'un expert à l'autre, rendant la surface de perte rugueuse ;
• une précision numérique sensible : on calcule souvent le routeur en float32 même quand le reste est en bfloat16 (selective precision du Switch Transformer).

Ces correctifs (z-loss, calcul du routeur en haute précision, bruit de routage à l'entraînement) sont ce qui sépare un MoE qui converge d'un MoE qui diverge.

L'alternative récente : équilibrage sans perte auxiliaire

DeepSeek-V3 a popularisé une approche auxiliary-loss-free. Plutôt qu'une perte qui interfère avec le gradient principal, on ajoute à chaque expert un biais dynamique b_i appliqué uniquement au calcul du top-k (à la sélection), pas à la pondération finale g_i. À chaque étape, on observe la charge : un expert surchargé voit son biais diminuer (il devient moins attractif), un expert sous-utilisé voit son biais augmenter, par pas γ. L'équilibre s'auto-régule sans polluer l'objectif d'apprentissage — ce qui évite la dégradation de qualité qu'une perte auxiliaire trop forte provoquait.

# pseudo-code d'ajustement du biais (par étape)
charge_i = nombre de tokens routés vers l'expert i
moyenne  = total_tokens · k / N
pour chaque expert i :
    si charge_i > moyenne :  b_i = b_i − γ   # rendre i moins attractif
    si charge_i < moyenne :  b_i = b_i + γ   # rendre i plus attractif
# la sélection utilise (s_i + b_i) ; la pondération finale utilise s_i seul

Cette astuce sépare proprement les deux rôles : s_i + b_i décide qui est activé (et donc l'équilibrage), tandis que s_i seul décide du poids de la contribution, préservant le signal d'apprentissage non biaisé. DeepSeek-V3 conserve toutefois une perte d'équilibrage de séquence de très faible coefficient en garde-fou.

Facteur de capacité et abandon de tokens

En pratique (et surtout en parallélisme matériel), chaque expert a une capacité bornée : un nombre maximal de tokens qu'il peut traiter par batch. Elle se calcule ainsi :

capacité = (tokens_par_batch / nombre_experts) × facteur_de_capacité

Le facteur de capacité (typiquement 1,0 à 1,25) offre une marge au-dessus de la répartition parfaitement uniforme. Si un expert reçoit plus de tokens que sa capacité, le surplus est abandonné (token dropping) : ces tokens sautent la couche d'expert (ils passent par la connexion résiduelle sans transformation). Un facteur trop bas augmente les abandons (perte d'information) ; trop haut, il gonfle le calcul et la mémoire réservés. Le Switch Transformer montre qu'un bon équilibrage permet de fonctionner à faible facteur (1,0–1,25) avec un taux d'abandon souvent inférieur à 1 %, sans impact mesurable sur la qualité.

Pourquoi une capacité fixe plutôt que dynamique ? Parce que le matériel veut des tenseurs de forme statique : on pré-alloue un buffer de taille capacité × d_model par expert, ce qui rend le all-to-all et le calcul prévisibles. Le revers est qu'un déséquilibre se paie soit en abandons (buffer trop petit), soit en gaspillage (buffer trop grand, rempli de zéros). C'est tout l'enjeu du couple capacité × équilibrage.

Parallélisme d'experts et coût mémoire

À l'échelle du trillion, les experts ne tiennent pas sur un seul accélérateur. On recourt au parallélisme d'experts (expert parallelism) : les experts sont répartis sur plusieurs GPU/TPU, et chaque token est envoyé (all-to-all) vers le ou les GPU hébergeant ses experts, puis sa sortie est renvoyée. Les couches non-MoE (attention, embeddings) sont, elles, répliquées comme en parallélisme de données. On combine en général ce parallélisme d'experts avec le parallélisme de données, de tenseur et de pipeline.

Le talon d'Achille du MoE est ici : la communication all-to-all est coûteuse et sensible au déséquilibre (un expert surchargé devient un goulot). C'est précisément pourquoi capacité et équilibrage sont si critiques — ils bornent et lissent ce trafic réseau. Un cas particulièrement coûteux est l'envoi de tokens entre nœuds (inter-node) : la bande passante inter-nœud est bien plus faible qu'intra-nœud, d'où des stratégies de routage limité aux nœuds (node-limited routing) qui plafonnent le nombre de nœuds distincts qu'un token peut atteindre (DeepSeek-V3 borne à 4 nœuds), réduisant drastiquement le trafic inter-nœud.

Les différentes formes de parallélisme se combinent et se cumulent :

• Données : chaque réplique voit un morceau différent du batch ; couches non-MoE répliquées.
• Tenseur : une même couche est découpée entre plusieurs accélérateurs.
• Pipeline : les couches successives sont réparties par étages.
• Experts : les experts d'une couche MoE vivent sur des accélérateurs distincts, reliés par all-to-all.

Le choix d'un placement (combien d'experts par accélérateur, quel degré de chaque parallélisme) gouverne directement le volume de communication et le taux d'occupation du matériel. Mal calibré, le réseau devient le facteur limitant bien avant le calcul. Les implémentations performantes recouvrent d'ailleurs le calcul des experts avec la communication all-to-all (double buffering, micro-batches) pour masquer la latence réseau derrière le calcul utile.

Experts fins et experts partagés (DeepSeekMoE)

DeepSeek-V3 affine encore l'architecture avec deux idées :

• Experts à grain fin (fine-grained) : au lieu de N gros experts, on en crée m·N plus petits (dimension cachée divisée par m) et on en active m fois plus. À calcul constant, cela démultiplie les combinaisons possibles d'experts, ce qui favorise une spécialisation plus précise des connaissances.
• Experts partagés (shared) : un ou quelques experts sont toujours activés pour tous les tokens. Ils absorbent les connaissances communes (grammaire, structure générale), évitant que chaque expert routé n'ait à les réapprendre. DeepSeek-V3 combine 1 expert partagé et 256 experts routés par couche, avec 8 experts routés actifs par token.

L'intérêt de ces deux idées est cumulatif : les experts partagés stabilisent la base de connaissances, pendant que les experts fins multiplient la diversité de spécialisation sans coût de calcul supplémentaire. Le nombre de combinaisons d'experts possibles explose : choisir 8 experts parmi 256 offre un nombre astronomique de routages distincts, là où 2 parmi 8 (Mixtral) n'en offre que 28. DeepSeek-V3 atteint ainsi 671 milliards de paramètres totaux pour seulement ~37 milliards activés par token.

Que « font » réellement les experts ?

Une intuition trompeuse veut que chaque expert se spécialise sur un thème lisible (« l'expert du droit », « l'expert du code »). En pratique, l'analyse de Mixtral montre que la spécialisation est surtout syntaxique et positionnelle plutôt que sémantique de haut niveau : un même expert traite souvent des tokens de même nature grammaticale, et le routage est fortement corrélé d'une couche à l'autre. Autrement dit, les experts ne sont pas des modules thématiques mais des routines apprises, et il ne faut pas sur-interpréter leur rôle.

Token "def"  -> experts {3, 7}
Token "("    -> experts {3, 1}
Token "x"    -> experts {5, 7}
# motif corrélé entre couches, faible alignement sémantique évident

Une conséquence pratique : on ne peut pas « élaguer » un expert en pariant qu'il est inutile pour un domaine donné, car son rôle est diffus et réparti. La compression d'un MoE passe plutôt par la quantification ou la fusion d'experts que par la suppression sélective.

Le défi du service en inférence

Un MoE est plus rapide à calculer qu'un dense équivalent en qualité, mais bien plus difficile à servir efficacement :

• Empreinte mémoire : il faut charger tous les experts en VRAM (Mixtral : ~47 G), même si seuls quelques-uns servent à chaque token. La mémoire suit les paramètres totaux, pas actifs.
• Routage par token, par couche : à chaque couche MoE, des tokens différents d'une même séquence partent vers des experts différents. Le motif d'activation est dynamique et imprévisible, ce qui complique le batching et l'utilisation régulière des accélérateurs.
• Déséquilibre en production : la distribution réelle des requêtes peut surcharger certains experts, créant des points chauds que l'entraînement n'avait pas anticipés.

Des techniques atténuent cela : expert parallelism dédié au service, déchargement (offloading) des experts rares vers une mémoire moins coûteuse (CPU/NVMe), quantification agressive des poids d'experts, et regroupement des tokens par expert avant exécution (grouped GEMM). La phase de prefill (beaucoup de tokens en parallèle) tend à bien remplir les experts, tandis que le decode (un token à la fois) souffre le plus du déséquilibre — d'où l'intérêt d'un batching dynamique qui agrège les tokens de plusieurs requêtes.

Surveiller un MoE en production

Quelques signaux à instrumenter pour garder un MoE sain :

• Taux d'abandon de tokens (drop rate) par expert et par couche : un pic révèle un déséquilibre ou un facteur de capacité trop bas.
• Entropie du routage : une entropie qui s'effondre signale une concentration sur quelques experts (collapse en cours).
• Charge par expert : la distribution doit rester proche de l'uniforme ; les points chauds persistants méritent ajustement.
• Latence all-to-all : à surveiller à part, car elle peut dominer la latence totale en service distribué.

Ces métriques, simples à logguer, évitent les dérives silencieuses qui dégradent la qualité sans erreur visible.

Avantages et inconvénients face au dense

Pour le MoE :

• meilleur rapport qualité/FLOPs : plus de capacité à coût de calcul égal ;
• entraînement plus rapide à qualité cible (jusqu'à ~7× de speedup de pré-entraînement rapporté par le Switch Transformer) ;
• inférence à faible latence par rapport à un dense de qualité équivalente.

Contre le MoE :

• empreinte mémoire massive (tous les experts résident en VRAM) ;
• complexité d'ingénierie (routage, communication all-to-all, équilibrage) ;
• service en inférence plus délicat (motifs dynamiques, batching) ;
• tendance au surapprentissage et fine-tuning plus capricieux que pour un dense.

Quelques chiffres repères

Pour fixer les ordres de grandeur des modèles cités :

• Switch-C : ~1,6 T paramètres totaux, 2 048 experts, routage top-1.
• GLaM : ~1,2 T totaux, 64 experts/couche, top-2, ~97 G actifs (8 %).
• Mixtral 8x7B : ~47 G totaux, 8 experts, top-2, ~13 G actifs.
• DeepSeek-V3 : ~671 G totaux, 256 experts routés + 1 partagé, ~37 G actifs.

Le fil rouge est constant : le ratio actifs/totaux tombe sous 10 %, ce qui résume toute la promesse économique du MoE.

Quand préférer un dense, quand préférer un MoE

Le MoE n'est pas universellement supérieur. Quelques repères de décision :

• Mémoire contrainte (un seul GPU, edge) : un dense est souvent plus simple et plus efficace, car le MoE force à charger tous les experts.
• Budget de calcul d'entraînement contraint, qualité maximale visée : le MoE excelle, en offrant plus de capacité à FLOPs égaux.
• Tâches très orientées connaissance (questions factuelles, multilingue) : le MoE brille, sa capacité supplémentaire stocke davantage de faits.
• Tâches de raisonnement pur et fine-tuning léger : un dense reste parfois plus robuste et moins sujet au surapprentissage.
• Service à haut débit avec parallélisme disponible : le MoE est viable si l'infrastructure supporte le all-to-all et le placement d'experts.

Checklist pratique pour entraîner et servir un MoE

Avant de lancer un entraînement ou une mise en service, vérifier point par point :

• Choix de k : top-1 pour la parcimonie maximale, top-2 pour un gradient plus stable, top-8 fins pour la diversité de combinaison.
• Stratégie d'équilibrage : perte auxiliaire (α ~0,01) ou biais dynamique sans perte (DeepSeek-V3), avec une garde-fou de faible coefficient.
• Stabilisation : router z-loss activée, routeur en float32, éventuel bruit de routage à l'entraînement.
• Facteur de capacité : départ à 1,0–1,25 ; surveiller le drop rate et ajuster.
• Placement : degré de parallélisme d'experts vs données/tenseur/pipeline ; activer le node-limited routing si l'inter-nœud domine.
• Recouvrement : calcul des experts masqué derrière la communication all-to-all.
• Service : VRAM dimensionnée sur les paramètres totaux, batching dynamique pour le decode, quantification/offloading des experts si nécessaire.
• Observabilité : drop rate, entropie de routage, charge par expert et latence all-to-all logués dès le jour 1.

En résumé

Le MoE découple capacité et calcul : un routeur dirige chaque token vers quelques experts seulement, de sorte que le nombre de paramètres totaux peut exploser pendant que les paramètres actifs restent modestes. Tout l'art consiste à équilibrer la charge — par perte auxiliaire ou biais dynamique — pour éviter l'effondrement d'experts, à régler facteur de capacité et abandon de tokens, et à distribuer les experts sur le matériel sans étrangler le réseau. De Switch Transformer à DeepSeek-V3, c'est cette mécanique qui rend l'échelle du trillion de paramètres économiquement viable.