veilletech.frCe qui se passe
NVIDIA publie une comparaison entre architectures denses et Mixture-of-Experts (MoE) écrite du point de vue de celui qui sert le modèle, pas de celui qui l'entraîne. Le fil conducteur est un constat : le nombre de paramètres affiché sur une fiche de modèle ne prédit plus ni le débit, ni la VRAM nécessaire, ni le coût.
Le mécanisme
Dans un modèle dense, tous les paramètres participent à chaque token : les 27 ou 31 milliards passent par un unique bloc feed-forward (FFN) par couche de décodage.
Un MoE remplace ce bloc unique par plusieurs FFN — 8, 64, parfois 128 — qu'on
appelle experts. Un réseau de routage placé devant attribue chaque token aux
top-k experts les mieux notés ; les autres sont sautés pour ce token, à cette
couche. Trois précisions qui évitent les contresens :
- le routage est refait à chaque couche. Un token n'est pas assigné une fois pour toutes ;
- l'attention reste dense. Quand une fiche annonce « 3 B de paramètres actifs », ce chiffre inclut les poids d'attention et d'embedding, plus les FFN sélectionnés ;
- les experts ne se spécialisent pas par sujet, mais plutôt par motifs syntaxiques et types de tokens (ponctuation, nombres).
Le point à retenir : mémoire et calcul se séparent
Dans un modèle dense, coût d'hébergement et coût d'inférence évoluent ensemble. Le MoE rompt ce lien :
- la mémoire suit le total — tous les experts doivent résider en VRAM ;
- le calcul suit les actifs — un expert au repos ne coûte rien à exécuter.
À batch 1, le décodage est limité par la mémoire plutôt que par le calcul, et le MoE excelle : il lit moins d'octets de poids par token.
Les chiffres
Relevé Artificial Analysis, entrée de 10 K tokens, 31 août 2026 :
| Modèle | Architecture | Total | Actifs | VRAM BF16 | VRAM 4 bits | Indice | Débit | $/M sortie |
|---|---|---|---|---|---|---|---|---|
| Gemma 4 31B | dense | 31 B | 31 B | ~61 Go | ~16 Go | 30 | 36,9 – 222,4 t/s | 0,40 $ |
| Qwen3.8-27B | dense | 27 B | 27 B | ~56 Go | ~14 Go | 52 | 46,8 t/s | 3,00 $ |
| Nemotron 3.5 Lightning | MoE + Mamba-2 | 30 B | 3 B | ~60 Go | ~20 Go | 24 | 235,7 – 494,2 t/s | 0,22 $ |
| Mistral Small 4 | MoE | 119 B | 6 B | ~121 Go FP8 (4×H100) | ~71 Go | 20 | 147,3 t/s | 0,60 $ |
Lightning va 4 à 5 fois plus vite que Qwen3.8-27B pour un quatorzième du prix, et score moins de la moitié à l'indice de capacité générale. Ce qui est le bon arbitrage pour une couche d'exécution agentique enchaînant des étapes bien spécifiées à volume — et le mauvais quand une seule passe de raisonnement décide du résultat.
À noter : les deux modèles à ~30 B occupent la même VRAM. La question n'est pas combien de gigaoctets, mais ce qu'on en obtient : de la capacité côté dense, du débit côté MoE. Et Lightning cumule d'autres effets que la seule sparsité — ses couches Mamba-2 portent un état récurrent de taille constante au lieu d'un cache KV qui grossit, et il utilise le décodage spéculatif.
Les limites
- Concurrence. L'avantage de débit tient à l'échelle, mais l'écart de latence face à un modèle dense bien optimisé se resserre : à gros batch, l'ensemble des tokens finit par solliciter la plupart des experts.
- Cache KV. Tous les experts occupant la mémoire simultanément, il reste moins de place pour le cache d'attention qu'avec un dense de taille comparable.
- Fine-tuning. Un réglage fin complet peut déséquilibrer le routeur — certains experts deviennent surreprésentés, d'autres cessent d'être appelés. LoRA/PEFT, ou le simple gel du routeur, évitent le problème.
À retenir
Le choix ne se joue pas sur une préférence d'architecture mais sur une contrainte de déploiement : budget mémoire, profil de concurrence, projet de fine-tuning. Si vous êtes sensible à la latence à forte concurrence, l'article conseille de mesurer les deux plutôt que de trancher sur le papier.