Aller au contenu

Le Mixture-of-Experts

Comment un modèle peut contenir 2,4 billions de paramètres et n'en calculer que 95 milliards à chaque jeton.


Le point de départ

Dans un Transformer classique, l'essentiel des paramètres se trouve dans le réseau dense qui suit l'attention à chaque couche. Ce réseau applique la même transformation à chaque jeton, avec les mêmes poids.

C'est un gâchis. Le traitement utile pour un jeton de code Python n'a probablement pas grand-chose à voir avec celui d'un jeton de poésie chinoise, et pourtant les deux traversent exactement les mêmes matrices.


L'idée

Remplacer le réseau dense unique par plusieurs réseaux plus petits — les experts — et ne faire passer chaque jeton que par quelques-uns d'entre eux.

                            ┌──→ expert 1    ┐
                            ├──→ expert 2    │
   jeton ──→ ROUTEUR ───────┼──→ …           ├──→ somme pondérée ──→ sortie
                            ├──→ expert 511  │
                            └──→ expert 512  ┘

              seuls 10 experts sur 512 sont réellement évalués

Le routeur est un simple produit matriciel suivi d'un tri : il attribue un score à chacun des 512 experts et retient les \(k\) meilleurs.

\[ \text{scores} = \operatorname{softmax}(W_r \, \mathbf{x}) \qquad \mathcal{T} = \operatorname{top\text{-}k}(\text{scores}) \]
Symbole Signification Valeur pour Qwen3.8-Max
\(\mathbf{x}\) vecteur du jeton dimension 8 192
\(W_r\) matrice du routeur \(512 \times 8\,192\)
\(k\) nombre d'experts retenus 10
\(\mathcal{T}\) ensemble des experts sélectionnés 10 indices

La sortie est la somme des sorties des experts choisis, pondérée par leurs scores :

\[ \mathbf{y} = \sum_{i \in \mathcal{T}} g_i \cdot \operatorname{Expert}_i(\mathbf{x}) \]

Les chiffres de Qwen3.8-Max

"num_experts": 512,
"num_experts_per_tok": 10,
"moe_intermediate_size": 2048,
"shared_expert_intermediate_size": 2048

Chaque expert est un petit réseau SwiGLU à trois matrices — gate, up, down — de dimension \(8\,192 \times 2\,048\) :

\[ 3 \times 8\,192 \times 2\,048 = 50\,331\,648 \approx 50{,}3 \text{ M de paramètres} \]

Par couche :

Composant Paramètres
512 experts routés 25,77 G
1 expert partagé 50,3 M
routeur 4,19 M
total du bloc MoE 25,82 G

Multiplié par 92 couches : 2,376 billions de paramètres — soit 98 % du modèle entier.

Mais par jeton, seuls 11 experts sont évalués (10 routés + 1 partagé) :

\[ 11 \times 50{,}3\ \text{M} = 553{,}6\ \text{M par couche} \quad\Longrightarrow\quad 50{,}9\ \text{G sur 92 couches} \]

Le résultat

2,376 T de paramètres stockés, 50,9 G calculés. Un facteur de 46,6.

C'est toute la thèse du MoE : acheter de la capacité de mémorisation sans payer le calcul correspondant.


L'expert partagé

Notez la ligne shared_expert_intermediate_size. En plus des 10 experts sélectionnés, un expert partagé traite tous les jetons, sans routage.

Sa raison d'être : certaines transformations sont utiles à tout le monde — normaliser, gérer la syntaxe de base, traiter la ponctuation. Sans expert partagé, chaque expert routé doit réapprendre ces compétences communes, ce qui gaspille de la capacité.

Avec un expert partagé, les 512 experts routés peuvent se spécialiser davantage.


Le problème de l'équilibrage

Rien ne garantit que le routeur répartisse équitablement les jetons. Sans contrainte, il apparaît un phénomène d'emballement : un expert légèrement meilleur reçoit plus de jetons, s'entraîne donc plus, devient encore meilleur, et finit par tout capter. Des centaines d'experts restent alors inutilisés — des paramètres payés et jamais appris.

La parade standard est une perte auxiliaire d'équilibrage ajoutée à l'objectif d'entraînement, qui pénalise les distributions déséquilibrées. config.json la mentionne :

"router_aux_loss_coef": 0.001

Un coefficient faible : l'équilibrage est une correction douce, pas une contrainte forte.

L'équilibrage n'est pas qu'une question de qualité

En production, les 512 experts d'une couche sont répartis sur des dizaines de GPU. Si un expert reçoit trois fois plus de jetons que la moyenne, le GPU qui l'héberge devient le goulet d'étranglement et tous les autres l'attendent.

Un MoE mal équilibré n'est pas seulement moins bon : il est proportionnellement plus lent.


Ce que le MoE ne résout pas

Le calcul baisse, la mémoire non

Les 512 experts doivent être chargés et accessibles. Un jeton peut demander n'importe lequel d'entre eux, et deux jetons consécutifs peuvent en demander des différents.

Il faut donc les 4,89 To en mémoire haute vitesse — d'où les dizaines de GPU nécessaires. Voir Exécuter les poids.

C'est le renversement du problème classique : un modèle dense est limité par le calcul, un très grand MoE est limité par la bande passante mémoire et par la communication entre GPU lors du routage.


Densité d'intelligence

Le rapport entre paramètres totaux et paramètres actifs est une signature d'école :

Modèle Total Actifs Part activée
Mixtral 8×7B (2023) 47 G 13 G 27,7 %
DeepSeek-V3 (2024) 671 G 37 G 5,5 %
Kimi K3 2 780 G 104 G 3,7 %
Qwen3.8-Max 2 420 G 95 G 3,94 %

La tendance de 2024-2026 est claire : les modèles deviennent de plus en plus creux. On empile des experts sans augmenter le coût par jeton.


À retenir

Ce chapitre en cinq points

  1. Le MoE remplace le réseau dense par 512 experts, dont 10 sont choisis par jeton par un routeur.
  2. Un expert partagé traite tous les jetons et absorbe les compétences communes.
  3. Dans Qwen3.8-Max, les blocs MoE représentent 98 % des paramètres mais 53 % du calcul par jeton.
  4. L'équilibrage du routage est un problème de qualité et de vitesse.
  5. Le MoE réduit le calcul, pas la mémoire : les 4,89 To doivent rester chargés.

Chapitre suivant : Le cache clé-valeur et le contexte long — où l'on calcule ce que coûte vraiment un million de jetons.