Mixture of experts : peu de paramètres actifs, un modèle immense

Un modèle de type mixture of experts peut effectuer moins de calculs par token tout en restant immense à héberger. Le modèle de langage Kimi K3.1 Pro de Moonshot AI compte 2.8T paramètres au total, mais 104B actifs par token, selon son annonce officielle. Le plus petit de ces nombres aide à comprendre la charge de calcul ; le plus grand reste déterminant lorsqu’il faut stocker les poids.

Les nombres de paramètres et les affirmations des sources ont été vérifiés le 24 octobre 2026. Les proportions de paramètres actifs ci-dessous sont nos propres calculs : elles ne mesurent ni un gain de vitesse, ni une économie de mémoire, ni la qualité des réponses.

Qu’est-ce que le mixture of experts ?

Le mixture of experts, ou « mélange d’experts » (MoE), dote un modèle de plusieurs réseaux de traitement internes, dont seuls certains sont sélectionnés pour chaque entrée. Un paramètre est une valeur numérique apprise par le modèle. L’ensemble des paramètres stockés est couramment appelé les poids du modèle. Un token est une petite unité de texte en entrée ou en sortie, souvent un fragment de mot.

Imaginez un centre de consultation composé de nombreuses salles. À l’accueil, chaque visiteur est orienté vers les salles dont il a besoin. Seules quelques salles travaillent pour lui, mais le bâtiment les abrite toutes. Dans une couche MoE, le routeur joue le rôle de l’accueil et les experts celui des salles.

L’analogie a ses limites : ces experts sont des réseaux de calcul dont les paramètres ont été appris, pas une liste de métiers humains. Rien ne permet de supposer qu’un expert juridique, un expert en programmation et un expert comptable attendent d’être sélectionnés.

Comment fonctionne une architecture MoE ?

Le routeur sélectionne des chemins à l’intérieur du modèle, puis combine leurs résultats. Un transformer traite les relations de contexte entre les tokens. Dans les transformers MoE courants, plusieurs réseaux experts remplacent un bloc feed-forward. Ce bloc transforme la représentation numérique interne d’un token ; l’attention est un mécanisme distinct, qui lui permet d’exploiter le contexte environnant.

Le traitement se déroule ainsi :

1. La représentation courante d’un token arrive dans une couche MoE.
2. Un routeur entraîné, aussi appelé porte de sélection, attribue un score aux experts.
3. Il en retient un sous-ensemble, souvent ceux qui obtiennent les meilleurs scores. C’est le routage top-k, où k désigne le nombre d’experts sélectionnés.
4. Les experts retenus traitent cette représentation. Leurs sorties sont pondérées et combinées avant la poursuite du traitement.

Ce mécanisme intervient dans les couches MoE du modèle : les experts sélectionnés peuvent donc varier selon le token et la couche. L’explication de l’architecture par PyTorch décrit la combinaison pondérée ; l’article de recherche de Mistral montre comment les choix varient d’une couche à l’autre.

Que signifie « sparse » dans un modèle MoE ?

Un MoE est dit « sparse », ou à activation parcimonieuse, lorsque seul un sous-ensemble d’experts travaille pour un token donné. C’est à cette forme que renvoie la distinction entre paramètres totaux et actifs dans les fiches des modèles récents. Les autres experts peuvent être sollicités par d’autres tokens, y compris au sein du même lot de traitement.

Un bloc feed-forward dense applique l’intégralité de son réseau à chaque token. Les couches d’experts à activation parcimonieuse offrent davantage de capacité stockée sans faire passer chaque token par tous les experts. Les composants partagés, dont l’attention dans les exemples présentés ici, continuent de travailler.

Plusieurs experts, mais toujours un seul modèle

Le routage MoE ne consiste ni à choisir entre plusieurs modèles accessibles par API, ni à faire voter plusieurs chatbots. Le routeur et les experts sont entraînés comme les composants d’un même réseau. En général, votre application envoie une requête à ce réseau ; elle ne sélectionne pas un expert comme on choisit un produit dans un catalogue.

Pour qui développe une application, cette distinction évite une erreur de conception : choisir un modèle MoE ne donne pas accès à une équipe d’agents spécialisés que l’on pourrait piloter.

Modèles mixture of experts : lire ensemble paramètres totaux et actifs

Le nombre total de paramètres indique la taille du modèle stocké ; le nombre de paramètres actifs décrit le chemin de calcul par token annoncé par son concepteur. Aucun des deux ne constitue une spécification matérielle complète. B signifie milliard ; T signifie mille milliards.

La dernière colonne correspond au nombre de paramètres actifs divisé par le total, après arrondi. Elle décrit les chiffres publiés par chaque concepteur, pas un classement d’efficacité entre modèles. Les architectures et les conventions de comptage des paramètres peuvent différer.

Kimi K3.1 Pro : une petite fraction d’un très grand modèle

Kimi K3.1 Pro montre pourquoi le nombre de paramètres « actifs » ne peut pas servir à dimensionner l’hébergement du modèle. Une fois le total de Moonshot converti dans la même unité, on obtient 2,800B. Le calcul donne alors 104 ÷ 2,800 × 100 = 3.7%, après arrondi.

Le nombre de paramètres actifs annoncé ne représente donc qu’une petite fraction du total. Cela ne signifie pas qu’une infrastructure d’inférence peut se passer des autres poids, ni que la latence de l’API représente cette même fraction de celle d’un modèle dense. Le chemin emprunté change selon les tokens et les couches.

Dans son billet de lancement, Moonshot présente Pro comme un K3 ayant bénéficié d’un post-entraînement et emploie l’appellation arrondie « 3T-class ». Son annonce officielle donne la paire exacte 2.8T / 104B. C’est cette spécification explicite qu’il faut retenir pour interpréter la taille du modèle.

Pour une application utilisant une API, ce modèle est un candidat à évaluer. Pour un opérateur qui souhaite l’héberger, il faut d’abord vérifier sa disponibilité : à la date de vérification, Moonshot promettait l’intégralité des poids d’ici le 4 novembre 2026. Une publication promise ne fournit pas encore les fichiers nécessaires au déploiement. Notre décryptage de Kimi K3.1 Pro détaille les choix liés à cette version.

Qwen3-235B-A22B : les paramètres actifs ne remplacent pas le total

Le nom Qwen3-235B-A22B rend la distinction visible. La fiche d’origine du modèle publiée par Qwen indique 235B paramètres au total et 22B activés, avec 128 experts dont 8 activés.

Le calcul donne 22 ÷ 235 × 100 = 9.4%, après arrondi. Pour un assistant documentaire privé, ce chiffre aide à comprendre comment le modèle limite les calculs par token. Le dimensionnement de la mémoire doit malgré tout couvrir l’intégralité du checkpoint choisi ainsi que l’état des requêtes traitées.

Ne traduisez pas « 22B actifs » par « tient en mémoire comme un modèle dense de 22B ». Associez aussi chaque chiffre au checkpoint concerné : le seul nom d’une famille ne suffit pas pour choisir les fichiers de poids, la précision et la configuration d’inférence.

Mixtral 8x7B : pourquoi il ne faut pas multiplier les nombres du nom

Mixtral 8x7B possède des composants partagés : son nom n’est donc pas une multiplication à effectuer. Le billet de lancement de Mistral annonce 46.7B paramètres au total et 12.9B utilisés par token. Multiplier les nombres de son nom revient à compter les composants partagés comme s’ils appartenaient à des modèles complets distincts.

L’article de recherche de Mistral décrit des réseaux experts feed-forward associés à une attention partagée. À chaque couche, le routeur choisit 2 experts sur 8. Il ne s’agit pas de huit modèles complets et indépendants.

À partir des deux nombres publiés, on obtient 12.9 ÷ 46.7 × 100 = 27.6%, après arrondi. Sélectionner 2 experts sur 8 revient à retenir 25% des experts : le dénominateur n’est pas le même. Les composants partagés expliquent en partie pourquoi la proportion d’experts et la proportion de paramètres diffèrent.

Pour préparer un déploiement, partez du total indiqué dans la fiche et des fichiers du checkpoint réel. Ni le nom du produit ni le nombre d’experts sélectionnés ne donne l’empreinte mémoire de l’ensemble des poids.

Pourquoi moins de calculs ne garantit pas une latence plus faible

Le routage parcimonieux réduit les calculs des experts par rapport à l’exécution d’un réseau dense de taille comparable ; il ne promet pas le temps de réponse d’un modèle dense plus petit. C’est ainsi que le MoE peut réduire le coût d’inférence par token des modèles de grande capacité, tout en conservant d’importants besoins en mémoire et en communication.

Les opérations arithmétiques ne constituent qu’une partie de l’inférence, c’est-à-dire l’exécution d’un modèle entraîné. Le serveur lit aussi les poids, exécute les composants partagés, achemine les représentations des tokens et les transfère parfois entre plusieurs dispositifs de calcul. Un nombre réduit de paramètres actifs ne fait pas disparaître ces opérations. Shazeer et ses collègues identifient la petite taille des lots par expert et la bande passante réseau comme des contraintes de performance dans l’article fondateur sur les MoE à activation parcimonieuse.

Le débit et la latence répondent à des besoins métier différents. Le débit mesure la quantité de travail que le service accomplit dans un temps donné. La latence mesure le temps d’attente d’une requête individuelle. Une file de documents traités la nuit peut bénéficier d’une configuration efficace sur de gros lots ; un assistant de support interactif doit fournir rapidement une première réponse utile.

Le traitement par lots, qui regroupe plusieurs tokens ou requêtes, peut améliorer l’utilisation du matériel. Mais chaque token peut sélectionner des experts différents : un lot peut donc solliciter une part bien plus importante du modèle qu’un token isolé. Le nombre de paramètres actifs ne correspond pas au nombre de poids auxquels le serveur accède sur l’ensemble d’un lot.

Le traitement du prompt et la génération des tokens sollicitent également le système de manière différente. Le prefill traite l’entrée ; le decode génère les tokens suivants. vLLM, un logiciel d’inférence pour modèles de langage, documente des options distinctes de communication entre experts pour un prefill à haut débit et un decode à faible latence. Notre guide de l’inférence des LLM explique ces étapes et les mesures à distinguer.

Pour choisir une API, comparez le comportement observé sur vos propres requêtes. Les deux nombres de paramètres ne disent rien sur l’intensité du regroupement en lots chez le fournisseur, la longueur de sa file d’attente ou l’adéquation de son matériel au modèle.

Les compromis concrets pour votre activité

Le MoE déplace une partie de la charge d’infrastructure : moins de calculs répétés, mais un modèle plus volumineux à conserver en mémoire et à coordonner. La question opérationnelle est de savoir si cet échange convient à votre charge de travail.

Mémoire : il faut de la place pour tous les experts

Un expert inactif pour un token ne peut pas pour autant être retiré du déploiement. Dans une configuration d’inférence habituelle où les poids résident en mémoire, l’ensemble reste chargé dans le système, même si chaque token n’en utilise qu’une partie. L’explication de PyTorch explicite cette exigence de mémoire.

Un premier calcul utile est le suivant : stockage des poids ≈ nombre total de paramètres × octets par paramètre stocké. Ce n’est qu’un point de départ : la précision peut varier selon les tenseurs, et les métadonnées des fichiers, le remplissage d’alignement, les répliques et les allocations à l’exécution augmentent l’empreinte mémoire.

Les poids ne représentent pas tout le budget mémoire. Le cache KV conserve les clés et les valeurs d’attention des tokens précédents pour les réutiliser. Un assistant documentaire qui gère des conversations plus longues ou davantage de requêtes simultanées doit aussi disposer de mémoire pour cet état supplémentaire. Notre explication du cache KV détaille cette contrainte distincte.

La quantification, qui consiste à stocker les poids avec une précision numérique réduite, peut diminuer leur empreinte mémoire. Elle ne transforme pas les paramètres totaux en paramètres actifs et ne dispense pas de valider la qualité des réponses. Le guide de la quantification des LLM aborde le choix du format et de la précision ; le mécanisme est documenté dans la présentation de la quantification par Hugging Face.

Débit : charger le modèle n’est qu’une première étape

Un modèle qui se charge correctement peut tout de même manquer vos objectifs de service. Le parallélisme des experts répartit ceux-ci entre plusieurs dispositifs de calcul, ce qui permet d’héberger un modèle plus grand que la mémoire d’un seul dispositif. Il impose aussi d’envoyer les représentations des tokens aux dispositifs qui hébergent les experts sélectionnés, puis de combiner les résultats.

Ces transferts font des interconnexions, les liaisons entre dispositifs, un élément de la conception du service d’inférence. Une capacité répartie sur des machines mal reliées n’équivaut pas à la même capacité sur un système bien interconnecté. C’est une conséquence directe du schéma de communication décrit dans l’implémentation du parallélisme des experts de PyTorch.

Pour un assistant interne peu sollicité, le problème concret est une capacité fixe sous-utilisée. Pour un service de traitement par lots très sollicité, il peut s’agir d’alimenter suffisamment les experts en travail. Le nombre de paramètres actifs ne permet, à lui seul, de prédire aucun de ces deux résultats.

Routage : les experts les plus sollicités peuvent devenir des goulets d’étranglement

Un routeur entraîné ne garantit pas une utilisation parfaitement équilibrée du matériel. L’analyse du routage de Mixtral par NVIDIA a montré qu’un trafic concentré sur un sujet pouvait déséquilibrer la charge entre experts. Certains processus de calcul terminent tôt, tandis que d’autres restent occupés.

C’est pourquoi une démonstration sur des tâches variées ne suffit pas pour un service qui traite principalement des contrats ou du code. Évaluez cette concentration de requêtes, en tenant compte des plus lentes, plutôt que de vous fier uniquement à une moyenne.

Le logiciel d’inférence peut compenser ces déséquilibres, mais cette compensation a elle aussi un coût en mémoire. vLLM documente l’équilibrage de charge par des copies redondantes d’experts et précise que ces copies supplémentaires consomment de la mémoire GPU qui pourrait autrement accueillir du cache KV. Si les poids remplissent exactement la mémoire disponible, il peut rester trop peu de place pour une configuration d’inférence efficace.

Choisir un LLM MoE : API ou hébergement autonome ?

Les développeurs qui utilisent une API doivent évaluer le service rendu ; les opérateurs qui hébergent le modèle doivent aussi évaluer le déploiement complet. Tous ont besoin de réponses acceptables, mais seuls les seconds gèrent directement l’emplacement des experts.

Pour les développeurs qui passent par une API, l’architecture apporte un contexte utile, pas une raison de changer de modèle. Évaluez des tâches représentatives, le respect des consignes, l’utilisation d’outils lorsqu’elle est pertinente, le délai jusqu’au premier token et la durée totale au niveau de simultanéité attendu. Consignez les tentatives échouées et les relances. L’efficacité de l’inférence chez le fournisseur ne détermine ni votre facture ni le travail nécessaire pour obtenir un résultat acceptable.

Pour les opérateurs qui hébergent eux-mêmes le modèle, partez du checkpoint exact disponible au téléchargement, de sa licence et d’une implémentation d’inférence compatible. Évaluez ensuite la précision des poids, la mémoire nécessaire au modèle complet, la marge pour le cache, les connexions entre dispositifs et les performances en charge. Notre guide des modèles à poids ouverts distingue l’accès aux fichiers des droits et responsabilités liés à leur exploitation.

Pour les acheteurs responsables d’un engagement de service, la question est de savoir si le modèle candidat accomplit un travail validé dans le délai de réponse cible, sur l’infrastructure prévue. « Des milliers de milliards de paramètres au total, des milliards actifs » décrit une architecture, pas une garantie de niveau de service.

1. 1

   Définir la charge de travail avant de comparer les modèles

   Utilisez des requêtes représentatives assorties de critères d’acceptation clairs. Distinguez les usages interactifs des traitements en file d’attente, et incluez les entrées longues ainsi que les sujets récurrents que votre application traite réellement.

2. 2

   Évaluer le mode d’exploitation prévu

   Pour une API, testez le fournisseur et le point d’accès envisagés. Pour un hébergement autonome, consignez le checkpoint exact, la précision, l’environnement d’exécution et le matériel. Un autre mode d’inférence donne un autre résultat opérationnel.

3. 3

   Tester ensemble la capacité et la qualité

   Augmentez le nombre de traitements simultanés tout en surveillant la mémoire utilisée, le temps d’attente, la qualité des réponses et les échecs. Une réponse isolée rapide ne démontre pas un débit utile ; un débit élevé ne démontre pas non plus une latence interactive acceptable.

4. 4

   Changer seulement si la charge réelle justifie le choix

   Adoptez le modèle candidat lorsque le travail validé et le respect des exigences opérationnelles progressent ensemble. Conservez le modèle actuel si ces gains n’apparaissent pas. Reportez l’hébergement autonome tant que les fichiers de poids requis ou une solution de déploiement compatible restent indisponibles.

Un développeur dont l’API actuelle répond aux exigences de qualité et de temps de réponse n’a rien à changer du seul fait de l’étiquette architecturale. En revanche, un opérateur qui a dimensionné son déploiement à partir des paramètres actifs doit revoir son plan dès maintenant.

Quelles promesses autour du MoE sont exagérées ?

L’exagération consiste à promettre tous les avantages d’un très grand modèle avec toutes les caractéristiques d’exploitation d’un petit. L’activation parcimonieuse permet de dissocier utilement la capacité du modèle de la charge de calcul, mais sous certaines conditions.

Les experts ne sont pas nécessairement des spécialistes d’un domaine. L’analyse de Mixtral par Mistral a révélé des schémas de routage qui ne séparent pas nettement les disciplines académiques. Un réseau expert entraîné n’est pas un spécialiste qualifié, et sa sélection par le routeur n’explique pas pourquoi une réponse serait correcte.

Un plus grand nombre total de paramètres ne prouve pas que les réponses sont meilleures. Une proportion active plus faible ne prouve pas davantage la supériorité d’un modèle. L’entraînement, l’architecture et la tâche comptent tous. Le tableau ci-dessus explique les tailles annoncées ; il ne constitue volontairement pas un classement de qualité.

Une proportion active plus faible ne se traduit pas par une réduction équivalente du prix ou du temps de traitement. À elle seule, elle ne dit rien sur les tarifs du fournisseur, l’attente en file, les transferts réseau ou le nombre de tokens que votre tâche nécessite de générer.

Quel article de recherche est à l’origine de ce mécanisme MoE ?

L’article de Shazeer et al., publié en 2017, a formalisé une couche MoE à sélection parcimonieuse devenue une référence : elle augmentait la capacité du modèle sans accroissement proportionnel des calculs. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer est la source de référence pour ce mécanisme. Ses développements sur l’équilibrage de charge et les performances distribuées rappellent aussi que les compromis opérationnels faisaient partie du concept dès le départ.

Les questions pratiques sur les modèles MoE

Qu’est-ce que le mixture of experts dans un LLM ?

C’est une façon de construire un grand modèle de langage avec plusieurs réseaux experts internes et un routeur entraîné. Dans un MoE à activation parcimonieuse, chaque token utilise uniquement les experts sélectionnés à chaque couche MoE. L’application continue d’appeler un seul modèle.

GPT-4 est-il un modèle mixture of experts ?

Le rapport technique de GPT-4 ne divulgue pas davantage de détails sur l’architecture, notamment la taille du modèle. Il ne fournit pas de décompte des paramètres MoE vérifié par le concepteur : les chiffres issus de rumeurs ne doivent donc pas servir de données de déploiement.

Que change le fine-tuning d’un modèle mixture of experts ?

Le fine-tuning adapte le comportement appris d’un modèle ; il ne supprime pas les exigences d’hébergement de l’ensemble de ses poids. Évaluez la qualité du modèle adapté sur vos tâches et son comportement de routage sous un trafic représentatif. Le guide MoE de Hugging Face aborde les enjeux particuliers de surapprentissage et d’équilibrage.

Préparer votre prochain choix de déploiement

Dès lundi, joignez une fiche d’inférence à chaque modèle présélectionné. Consignez les nombres de paramètres totaux et actifs annoncés par le concepteur, leur source et le checkpoint exact ou le point d’accès API. Pour un accès hébergé, ajoutez les résultats sur vos tâches et les mesures de latence. Pour un hébergement autonome, ajoutez l’empreinte mémoire complète des poids, la réserve pour le cache et les performances sous le trafic attendu. Cette fiche est plus utile qu’un classement fondé sur le plus gros chiffre mis en avant.

Pour comprendre concrètement l’infrastructure derrière les produits d’IA, abonnez-vous à la newsletter.