Jusqu'en 2023, un modèle de N paramètres coûtait environ 2N opérations par token généré. Le nombre de paramètres était une mesure directe du travail, et la comparaison entre modèles se faisait dessus.
Depuis la généralisation du Mixture-of-Experts, c'est faux. Un modèle annoncé à 2 800 milliards de paramètres n'en active que 104 par token, soit 3,7 %. Le seul chiffre qui informe sur le coût est celui des paramètres actifs, et il n'est pas toujours mis en avant.
Ce que fait un Mixture-of-Experts
Dans un modèle classique, chaque token traverse l'intégralité du réseau. Or sur une entrée donnée, la quasi-totalité de la partie qui stocke les connaissances s'active pour une contribution négligeable.
On remplace un gros bloc de connaissances par N blocs plus petits, les experts, et un petit réseau appelé routeur choisit lesquels activer pour chaque token. Typiquement 8 experts sur 256.
Jusqu'en 2023, la règle était simple : un modèle dense de N paramètres coûtait environ 2N FLOP par token produit. Le nombre de paramètres mesurait donc directement le travail, et deux modèles se comparaient sur cette seule ligne.
L'architecture à experts a cassé ce lien. Le calcul par token suit désormais les paramètres actifs, pas le total annoncé. Le mécanisme est décrit à l'étape 4 du trajet d'une requête.
Le calcul par token chute, mais tous les experts doivent rester chargés en mémoire, puisqu'on ne sait pas à l'avance lesquels le routeur va choisir. Le MoE calcule moins, mais il faut tout charger en mémoire.
Un token traverse ce nombre de paramètres, sur l'ensemble du réseau, attention comprise. Ni la taille d'un expert, ni les paramètres actifs d'une seule couche.
C'est le seul chiffre qui prédit le coût de calcul d'une inférence. À réclamer systématiquement, à côté du total.
Piège de vocabulaire à connaître : 8 × 7 milliards ne font pas 56 milliards. Le modèle Mixtral 8x7B pèse 47 milliards de paramètres, parce que les couches d'attention sont partagées entre les experts et que seuls les blocs de connaissances sont dupliqués. Un document qui écrit 56 se trompe dès la première ligne.
La tendance, en chiffres
| Modèle | Date | Total | Actifs par token | Ratio |
|---|---|---|---|---|
| Mixtral 8x7B | janv. 2024 | 47 Md | 13 Md | 27,7 % |
| Grok-1 | mars 2024 | 314 Md | 25 % des poids | 25 % |
| DeepSeek-V3 | déc. 2024 | 671 Md | 37 Md | 5,5 % |
| Llama 4 Maverick | avril 2025 | 400 Md | 17 Md | 4,3 % |
| Qwen3-235B-A22B | mai 2025 | 235 Md | 22 Md | 9,4 % |
| Kimi K2 | juil. 2025 | 1 000 Md | 32 Md | 3,2 % |
| gpt-oss-120b | août 2025 | 117 Md | 5,1 Md | 4,4 % |
| DeepSeek-V4-Pro | avril 2026 | 1 600 Md | 49 Md | 3,1 % |
| Kimi K3 | août 2026 | 2 800 Md | 104 Md | 3,7 % |
De 25 à 28 % en 2024 à 3 à 5 % en 2026, pendant que les totaux passaient de 47 milliards à 2 800 milliards. Le calcul par token stagne. La masse de poids à héberger, elle, explose.
Deux modèles à ne pas citer faute de données : Grok 3 et Grok 4, dont aucun compte de paramètres n'a été publié. Et une confusion fréquente à éviter : DeepSeek-R2 n'existe pas, la lignée passe de R1 à V3 puis V4, plusieurs agrégateurs l'inventent.
Le gain, mesuré par un régulateur
La meilleure mesure indépendante disponible vient du PEReN, pour l'Arcep, publiée en mai 2026. Protocole : 22 modèles ouverts de 3 à 123 milliards de paramètres, mesures sur le supercalculateur Jean Zay, cas d'usage grand public.
| Levier | Gain moyen mesuré |
|---|---|
| Architecture MoE contre dense, à paramètres équivalents | −45 % |
| Quantification 8 ou 4 bits | −39 % |
| Mode raisonnement activé | +92 %, jusqu'à +849 % sur du code |
Limites assumées par les auteurs, à citer avec le chiffre : modèles ouverts uniquement, aucun modèle au-delà de 125 milliards de paramètres, et consommation des GPU seule, alors que les processeurs représentent environ un tiers du total.
La conclusion du régulateur vaut d'être reprise telle quelle en clientèle : limiter la consommation n'implique pas nécessairement un compromis sur la performance, et des modèles sobres égalent de gros modèles sur des cas d'usage donnés.
Le prix payé ailleurs
Le MoE réduit le calcul, pas la mémoire à provisionner. Les communications commerciales passent ce point sous silence.
Le rapport technique de DeepSeek-V3 le dit sans détour : l'unité minimale de déploiement en phase de génération est de 320 GPU, pour un modèle qui n'active que 37 milliards de paramètres par token. Un modèle classique de 37 milliards tiendrait sur un à deux accélérateurs.
En production réelle, l'entreprise a publié 24 heures de mesures : une moyenne de 1 814 GPU H800 en permanence, pour 87 072 dollars d'infrastructure par jour, servant 608 milliards de tokens d'entrée et 168 milliards de tokens de sortie.
La nuance qui évite de se faire retourner en réunion : « il faut 320 GPU pour charger le modèle » est faux. Des moteurs d'inférence ouverts le servent sur 8 accélérateurs H200 en précision réduite. Les 320 GPU sont l'unité que DeepSeek déploie pour atteindre son objectif de latence et de débit, un arbitrage d'exploitation lié à la latence visée, pas une contrainte de mémoire.
Et c'est la quantification, pas le MoE, qui fait tenir un gros modèle sur peu de matériel : Llama 4 Scout tient sur un seul H100 en 4 bits, gpt-oss-120b sur 80 Go grâce à un format 4 bits post-entraîné. Sans compression agressive, aucun des deux ne tient.
Question
Un éditeur compare deux modèles : un dense de 70 milliards de paramètres et un MoE de 671 milliards dont 37 actifs. Que pouvez-vous conclure sur le coût d'inférence ?
Choisissez une réponse pour voir l'explication.
Ce qui manque pour comparer
Voici l'arbitrage tel qu'on voudrait pouvoir le formuler : le MoE divise l'énergie par token par X et multiplie le parc nécessaire par Y, l'empreinte de fabrication allouée à chaque requête en découle.
Les deux moitiés existent séparément, personne ne les a reliées. Aucune source ne publie de mise en regard chiffrée du gain énergétique et du surcoût matériel rapportés à la même unité. Pour le combler il faudrait une analyse de cycle de vie de serveur appliquée à une flotte MoE avec allocation par requête, et ce travail n'a pas été fait.
On devine l'ordre de grandeur du terme manquant à partir des seules données constructeur disponibles, publiées en juillet 2025 : une carte de huit accélérateurs H100 porte 1 312 kgCO2e de fabrication, dont 42 % de mémoire, et la génération suivante 2 274 kgCO2e dont 49 % de mémoire.
La mémoire est donc le premier poste de fabrication, devant la puce de calcul elle-même. Or le MoE déplace justement la charge du calcul vers la mémoire. Ça rend l'absence de chiffrage gênante, pas anecdotique. Présentez-le comme un raisonnement, jamais comme un résultat mesuré.
FAQ
Le nombre de paramètres d'un modèle indique-t-il son coût ?
Plus depuis la généralisation du Mixture-of-Experts. Un modèle peut annoncer 2 800 milliards de paramètres et n'en activer que 104 par token, soit 3,7 %. Le calcul d'inférence suit les paramètres actifs, pas le total. Sans le couple total et actifs, un chiffre de taille induit systématiquement en erreur, dans le sens de la surestimation.
Qu'est-ce que les paramètres actifs d'un modèle ?
Le nombre de paramètres réellement traversés par chaque token, sur l'ensemble du réseau, attention comprise. Sur DeepSeek-V3, 8 experts routés sur 256 sont activés par couche, ce qui donne 37 milliards de paramètres actifs sur 671 milliards au total. C'est la seule valeur qui prédit le coût de calcul d'une inférence.
Un modèle Mixture-of-Experts consomme-t-il moins qu'un modèle dense ?
Moins de calcul par token, oui. L'étude du PEReN pour l'Arcep, publiée en mai 2026 sur 22 modèles ouverts mesurés sur le supercalculateur Jean Zay, chiffre le gain à 45 % en moyenne à paramètres équivalents. Mais l'architecture ne réduit pas la mémoire à provisionner, puisque tous les experts doivent rester chargés, ce qui augmente le parc matériel nécessaire.
Pourquoi Mixtral 8x7B pèse-t-il 47 milliards de paramètres et non 56 ?
Parce que seuls les blocs de connaissances sont dupliqués entre les experts. Les couches d'attention, elles, sont partagées et ne sont comptées qu'une fois. Multiplier le nombre d'experts par la taille annoncée d'un expert donne donc un résultat faux, et c'est une erreur fréquente dans les comparatifs.
Faut-il vraiment 320 GPU pour faire tourner DeepSeek-V3 ?
Non. Ce chiffre est l'unité minimale de déploiement en phase de génération publiée par DeepSeek pour atteindre ses objectifs de latence et de débit, avec de la redondance d'experts. Des moteurs d'inférence ouverts servent le même modèle sur 8 accélérateurs H200 en précision réduite. C'est un arbitrage d'exploitation, lié à la latence visée.