Le MoE à 513 experts¶
98,2 % des paramètres du modèle sont ici. Et 3,94 % seulement sont lus par jeton.
La configuration¶
"num_experts": 512,
"num_experts_per_tok": 10,
"moe_intermediate_size": 2048,
"shared_expert_intermediate_size": 2048,
"router_aux_loss_coef": 0.001,
"hidden_act": "silu"
512 experts routés, plus un expert partagé — d'où « 513 » dans le titre de ce chapitre. La carte de modèle dit « 11 activated per token (10 routed + 1 shared) ».
Un expert, en détail¶
Chaque expert est un réseau SwiGLU à trois matrices :
| Matrice | Dimensions | Paramètres |
|---|---|---|
| \(W_{\text{gate}}\) | \(8\,192 \times 2\,048\) | 16 777 216 |
| \(W_{\text{up}}\) | \(8\,192 \times 2\,048\) | 16 777 216 |
| \(W_{\text{down}}\) | \(2\,048 \times 8\,192\) | 16 777 216 |
| Total | 50 331 648 |
Soit 50,33 M de paramètres par expert.
Pourquoi SwiGLU plutôt qu'un simple ReLU
La branche \(W_{\text{gate}}\) passée dans silu module multiplicativement la
branche \(W_{\text{up}}\). Cette porte donne au réseau la capacité d'annuler
sélectivement des dimensions, ce qu'une activation simple ne permet pas.
C'est devenu le standard depuis 2022, à un coût de 50 % de paramètres supplémentaires par rapport à un réseau à deux matrices.
Des experts étroits et nombreux¶
Une dimension intermédiaire de 2 048 pour une dimension cachée de 8 192, c'est un rapport de \(0{,}25\). Dans un Transformer dense classique, ce rapport est de 4 — soit seize fois plus large.
L'école de conception est claire : beaucoup d'experts très étroits.
| Modèle | Experts | Dim. intermédiaire | Actifs |
|---|---|---|---|
| Mixtral 8×7B | 8 | 14 336 | 2 |
| DeepSeek-V3 | 256 | 2 048 | 8 |
| Kimi K3 | 384 | — | 8 |
| Qwen3.8-Max | 512 | 2 048 | 10 |
L'argument en faveur des experts étroits
Avec 8 experts larges, chacun doit couvrir un huitième de tout le langage — il reste généraliste. Avec 512 experts étroits, chacun peut se spécialiser finement, et la combinaison de 10 d'entre eux offre \(\binom{512}{10} \approx 3 \times 10^{20}\) configurations distinctes.
C'est une capacité de spécialisation combinatoire qu'un petit nombre d'experts ne peut pas atteindre.
L'argument contre
Plus d'experts, c'est plus de communication entre GPU au moment du routage, et un équilibrage plus difficile. C'est aussi un risque d'experts sous-entraînés : avec 512 experts et 10 tirés par jeton, chaque expert ne voit qu'environ 2 % des jetons.
Le routeur¶
Une seule matrice, \(8\,192 \times 512\), soit 4,19 M de paramètres — 0,016 % du bloc.
Quatre millions de paramètres décident de l'usage de 25,8 milliards. C'est le point de levier le plus extrême du modèle — et le plus fragile.
L'expert partagé¶
En plus des 10 sélectionnés, un expert traite tous les jetons sans passer par le routeur.
Sa fonction : absorber ce qui est utile à tout le monde. Sans lui, les 512 experts spécialisés devraient chacun réapprendre la syntaxe de base, la ponctuation, les régularités morphologiques — un gaspillage de capacité multiplié par 512.
Avec lui, les experts routés peuvent consacrer leurs 50 M de paramètres à ce qui les distingue.
L'équilibrage¶
"router_aux_loss_coef": 0.001
Sans contrainte, le routage s'effondre : un expert légèrement meilleur reçoit plus de jetons, s'entraîne davantage, devient encore meilleur. Au bout de quelques milliers d'étapes, quelques dizaines d'experts captent tout et les autres sont des paramètres morts.
La parade classique est une perte auxiliaire pénalisant les distributions déséquilibrées, ajoutée à l'objectif avec un coefficient. Ici : 0,001.
Un coefficient faible
0,001 est une valeur basse. Deux lectures possibles :
- Qwen dispose d'un mécanisme complémentaire — beaucoup d'équipes ont adopté depuis 2024 des corrections de biais sans perte auxiliaire, qui ajustent directement les scores du routeur ;
- ou l'équipe accepte un déséquilibre modéré, jugeant que la perte auxiliaire dégrade la qualité plus qu'elle n'apporte.
config.json ne permet pas de trancher, et aucune documentation ne le dit.
L'enjeu n'est pas seulement la qualité. En production, les 512 experts d'une couche sont répartis sur des dizaines de GPU. Un expert qui reçoit trois fois plus de jetons que la moyenne fait attendre tous les autres GPU. Un MoE déséquilibré est proportionnellement plus lent.
Le décompte¶
Par couche :
| Composant | Calcul | Paramètres |
|---|---|---|
| 512 experts routés | \(512 \times 50{,}33\) M | 25 769 803 776 |
| 1 expert partagé | \(3 \times 8\,192 \times 2\,048\) | 50 331 648 |
| routeur | \(8\,192 \times 512\) | 4 194 304 |
| Total | 25 824 329 728 |
Sur 92 couches :
98,2 % des 2,42 T du modèle.
Actifs par jeton :
| Composant | Paramètres |
|---|---|
| 10 experts routés | 503 316 480 |
| 1 expert partagé | 50 331 648 |
| routeur | 4 194 304 |
| Par couche | 557 842 432 |
| × 92 couches | 51,32 G |
Un facteur 46 entre ce qui est stocké et ce qui est calculé.
Ce que cela impose au matériel¶
Le MoE ne réduit pas la mémoire
N'importe quel jeton peut demander n'importe lequel des 512 experts. Il faut donc que les 2,376 T de paramètres d'experts soient chargés et accessibles, en permanence.
D'où les 4,89 To de poids, et les dizaines de GPU. Voir Exécuter les poids.
Et un second coût, moins visible : le routage impose une communication all-to-all entre les GPU à chaque couche. Les jetons doivent être envoyés vers le GPU qui héberge leur expert, puis les résultats rapatriés. Quatre-vingt-douze fois par passe avant.
C'est une des raisons pour lesquelles la vitesse mesurée — 47 jetons/s — reste modeste malgré 3,94 % d'activation.
À retenir¶
Ce chapitre en cinq points
- 512 experts routés + 1 partagé, chacun un SwiGLU de 50,33 M de paramètres.
- Les blocs MoE totalisent 2,376 T — 98,2 % du modèle — mais 51,32 G actifs, soit un facteur 46.
- Le choix d'écoles est celui d'experts nombreux et étroits (dim. 2 048), pour une spécialisation combinatoire maximale.
- Un routeur de 4,19 M de paramètres décide de l'usage de 25,8 G par couche.
- Le MoE réduit le calcul, jamais la mémoire, et ajoute un coût de communication entre GPU.
Chapitre suivant : La prédiction multi-jetons — la couche cachée que le calcul a permis de débusquer.