Qu'est-ce qu'un expert dans un Mixture-of-Experts ?

Un expert est un FFN parmi plusieurs, initialisé et entraîné avec les autres. Il ne correspond pas à une compétence définie à l'avance : c'est une position dans l'architecture, dont les régularités d'activation émergent pendant l'entraînement.

Pourquoi l'équilibrage des experts est-il si important ?

Un routage déséquilibré gaspille la capacité payée et ralentit le cluster. Les experts sont répartis sur plusieurs accélérateurs, et le nœud qui reçoit le plus de tokens impose son rythme à l'ensemble du système.

Comment fonctionne le routage d'un token dans un MoE ?

Un routeur calcule un score pour chaque expert, sélectionne les top-k meilleurs, envoie le token aux experts retenus, puis recombine leurs sorties selon leurs scores. Cette décision est locale à chaque couche et indépendante pour chaque token.

Qu'est-ce que l'effondrement du routeur ?

C'est une boucle de rétroaction dans laquelle quelques experts reçoivent légèrement plus de tokens, s'entraînent davantage, puis deviennent encore plus attractifs pour le routeur. Sans contrainte supplémentaire, la loss globale ne récompense pas une utilisation équilibrée des experts.

Pourquoi les MoE récents utilisent-ils beaucoup de petits experts ?

La granularité fine augmente le nombre de combinaisons possibles entre experts activés. L'expressivité vient donc surtout de la combinatoire des mélanges, plutôt que d'une spécialisation lisible de chaque expert pris isolément.

Comment un Mixture-of-Experts gère ses experts

Pourquoi un MoE dépend moins de la spécialisation de ses experts que de sa capacité à équilibrer leur utilisation.

D’où vient le problème

Un bloc Transformer alterne deux opérations, et deux seulement.

L’attention met les tokens en relation. Chaque token regarde les autres, pondère ce qu’il y trouve, et met à jour sa représentation en fonction du contexte. C’est l’opération qui fait circuler l’information horizontalement, entre positions.

Le FFN (le réseau feed-forward) traite chaque token isolément. Il prend la représentation d’un token, la projette dans un espace beaucoup plus large, applique une non-linéarité, et reprojette. Aucune communication entre positions. C’est l’opération qui travaille verticalement, en profondeur.

Attention, FFN, attention, FFN. Soixante fois, quatre-vingts fois. C’est l’ossature répétée du Transformer.

Ces deux opérations n’ont pas le même coût. Dans un Transformer de taille courante, le FFN concentre les deux tiers des paramètres. C’est là que le modèle range l’essentiel de ce qu’il sait. Et comme il s’applique à chaque token, chaque token paie l’intégralité de cette masse.

C’est ce point de tension que le Mixture-of-Experts vient attaquer. Il ne touche pas à l’attention. Il remplace le FFN.

Qu’est-ce qu’un expert, au juste

Un expert n’est pas un module spécialisé qu’on aurait conçu, entraîné, puis inséré. C’est simplement un FFN parmi N, de structure strictement identique à ses voisins, initialisé au hasard comme eux, entraîné en même temps qu’eux.

Un mini-modèle, donc. Mais un mini-modèle dont on ne sait pas ce qu’il contient.

Ses poids sont des matrices de plusieurs millions de coefficients sans structure lisible. Aucune étiquette, aucun moyen d’ouvrir l’expert 412 et de constater qu’il « s’occupe du code Python ». On peut observer quand il s’active : des régularités émergent, souvent lexicales ou syntaxiques : mais une corrélation d’activation n’est pas une description de fonction. Et de l’autre côté, ce qu’il reçoit est le produit d’une décision prise par un routeur lui aussi appris, sur des critères que personne n’a spécifiés.

Le mot « expert » est donc trompeur, et il faut s’en méfier tout au long de ce qui suit. Il désigne une position dans une architecture, pas une compétence identifiée.

Le pari, et sa condition

Le pari du MoE tient en une phrase : découpler la capacité du coût. Construire un réseau énorme, mais n’en activer qu’une fraction pour chaque token. Un modèle de 2 800 milliards de paramètres qui n’en calcule que 50 par token.

Formulé ainsi, ça ressemble à un déjeuner gratuit. Ça n’en est pas un, et il faut poser tout de suite où se trouve la facture.

Le pari ne tient que si les tokens se répartissent à peu près également entre les experts.

C’est la condition centrale, et c’est le fil rouge de cet article. Un MoE dont 5 % des experts absorbent 80 % du trafic n’est pas un grand modèle efficace : c’est un petit modèle qui traîne une immense quantité de paramètres morts. La capacité qu’on a payée n’est pas utilisée. Et : on le verra : le débit du cluster entier s’effondre par-dessus le marché.

Presque tout ce qui suit : les mécanismes de routage, les correctifs successifs, les choix d’infrastructure : découle de cette unique exigence : obtenir une répartition équilibrée, et l’obtenir tôt, avant que le déséquilibre initial ne se soit figé.

Anatomie d’une décision de routage

Dans un bloc MoE, le FFN unique est remplacé par N experts plus un routeur, typiquement une simple couche linéaire.

Pour un token de représentation cachée h :

Le routeur calcule un score par expert : s = softmax(h · W_r), un vecteur de dimension N
On sélectionne les top-k scores les plus élevés
Le token est envoyé aux k experts correspondants
Les sorties sont recombinées, pondérées par les scores normalisés

Le mécanisme tient en quatre lignes. La quasi-totalité de la difficulté est ailleurs.

Trois propriétés de cette décision conditionnent tout le reste.

Elle est dure. En pratique, seuls les experts sélectionnés travaillent sur ce token et reçoivent un signal d’apprentissage. Un expert peu choisi progresse donc moins, ce qui peut le rendre encore moins attractif.

Mécaniquement : le top-k est un argmax partiel, discret et non différentiable. On ne rétropropage pas à travers « quel expert a été choisi ». Le gradient ne remonte que par les poids de recombinaison, c’est-à-dire les scores des experts effectivement sélectionnés. Pour les autres, il n’y a rien à remonter : et c’est exactement le mécanisme par lequel un expert délaissé le reste.

Elle est locale. Chaque bloc a son propre routeur, entraîné indépendamment. Un token traversant soixante blocs prend soixante décisions sans coordination entre elles. Il n’y a pas de « chemin » cohérent à travers le réseau, pas de plan global.

Elle est par token, pas par requête. C’est la différence de fond avec le routage multi-modèles : celui de RouteLLM, des architectures Mixture-of-Agents, ou de n’importe quel dispatcher qui envoie une requête entière vers un modèle. Là-bas, une mauvaise décision ruine toute la réponse. Ici, chaque token de chaque couche fait son propre choix, et une erreur se dilue dans les dizaines de milliers d’autres. Les deux systèmes partagent le mot « routage » et à peu près rien d’autre : ne transposez pas les résultats de l’un à l’autre.

L’effondrement du routeur

Le routeur est entraîné à partir de zéro, sans aucune supervision sur ce que serait une « bonne » assignation. Le seul signal est la loss globale du modèle.

Ça crée une boucle de rétroaction vicieuse.

Au tout début de l’entraînement, par pur hasard d’initialisation, un expert reçoit légèrement plus de tokens que ses voisins. Il s’entraîne donc un peu plus. Il devient un peu meilleur. Le routeur, qui optimise la loss, lui attribue des scores un peu plus élevés. Il reçoit encore plus de tokens.

Ce phénomène porte un nom : l’effondrement du routeur, ou router collapse : et il est auto-renforçant. Il se joue dans les premiers milliers de pas, et une fois installé, il ne se défait pas : un expert non entraîné n’a aucune raison de devenir attractif.

La cause profonde est structurelle. Rien dans l’objectif d’entraînement ne récompense la diversité d’usage. La loss ne mesure que la qualité de prédiction. Un modèle qui n’utilise que 5 % de ses experts mais prédit correctement est, du point de vue de la loss, un modèle réussi.

C’est pour ça que toutes les solutions de la section suivante sont des contraintes ajoutées de l’extérieur. Aucune n’émerge de l’optimisation.

Ce que coûte le déséquilibre, et comment le mesurer

Deux coûts distincts, qui appellent des mesures différentes.

Le coût de capacité

Si une fraction des experts fait tout le travail, vous avez payé pour un modèle immense et vous en utilisez la capacité effective d’un modèle bien plus petit.

Comment le mesurer. Instrumentez le routeur sur un corpus représentatif de votre trafic réel, comptez les activations par expert, calculez l’entropie de la distribution obtenue. Le maximum théorique est log₂(N), atteint quand tous les experts sont sollicités également. Une entropie très en dessous signale un modèle qui n’utilise pas ce que vous payez. Faites-le couche par couche : l’effondrement n’est pas uniforme en profondeur.

Un corollaire souvent oublié au dimensionnement : les paramètres inactifs occupent quand même de la mémoire. Un modèle « 50 milliards actifs » ne se déploie pas comme un modèle dense de 50 milliards : il faut héberger la totalité des experts, actifs ou non.

Le coût de débit

Celui-là est brutal, et il surprend.

Les experts sont répartis sur des dizaines ou des centaines d’accélérateurs : c’est l’expert parallelism. Chaque étape implique une communication all-to-all : les tokens partent vers les GPU qui hébergent leurs experts, sont calculés, puis reviennent.

Si un GPU reçoit dix fois plus de tokens que la moyenne, tous les autres l’attendent. Le débit du cluster entier est dicté par le nœud le plus chargé. Un déséquilibre de 2× ne coûte pas 2 % de performance : il peut coûter la moitié du débit.

Comment le mesurer. Le ratio d’activation annoncé donne les FLOPs, pas la latence. Chronométrez le débit réel sur votre topologie et comparez au débit théorique dérivé du nombre de paramètres actifs. L’écart, c’est la communication.

C’est le point que les architectes sous-estiment le plus souvent. L’équilibrage de charge en MoE n’est pas d’abord une question de qualité de modèle. C’est une question de facture d’électricité.

Les solutions, et ce qu’elles coûtent

Pour la suite, une image. Imaginons un atelier de tri : des colis arrivent en continu, N postes de travail les traitent, et un contremaître décide à qui envoyer chaque colis. Le contremaître apprend sur le tas, sans consigne, en observant seulement si la production globale s’améliore.

Livré à lui-même, il envoie tout à ses trois postes préférés. Les autres regardent.

L’amende (2017)

Le principe. À la fin de chaque journée, on mesure l’écart à une répartition égale et on inflige au contremaître une amende proportionnelle. C’est la loss auxiliaire du papier fondateur de Shazeer et ses coauteurs : un terme de régularisation ajouté à la loss, qui pénalise le déséquilibre.

Ça marche. Le contremaître apprend vite à étaler.

La limite. Il a maintenant deux patrons qui lui demandent des choses contradictoires. L’un veut de la production, l’autre de l’équité. Or une répartition inégale peut être parfaitement justifiée : la distribution des tokens dans du texte réel n’a rien d’uniforme. En forçant l’uniformité, on empêche parfois le contremaître de faire le bon choix.

Et le montant de l’amende devient un hyperparamètre pénible : trop faible, effondrement ; trop fort, dégradation de la qualité. Sa valeur optimale dérive au cours de l’entraînement.

Le bac de taille fixe (2020-2021)

Le principe. On arrête de raisonner en incitations et on installe une contrainte physique : chaque poste reçoit un bac d’une contenance fixe. Quand le bac est plein, les colis suivants ne sont pas traités : ils passent directement à la sortie. C’est le capacity factor de GShard et Switch Transformer, avec son rejet de tokens : les tokens excédentaires sautent le bloc MoE et passent par la connexion résiduelle.

Ce que ça règle vraiment. Le problème de débit, et de façon décisive. Les bacs ont une taille connue à l’avance, donc les buffers ont des dimensions statiques, donc les kernels peuvent être compilés une fois pour toutes et les communications planifiées. C’est la vraie raison d’être du mécanisme, bien plus que le contrôle du déséquilibre lui-même.

La limite. Des colis ne sont pas traités. Et la taille du bac devient à son tour un paramètre à régler, avec un arbitrage direct entre gaspillage mémoire (bac trop grand) et rejet (bac trop petit).

Le pouce sur la balance (2024)

Le principe. On ne punit plus le contremaître et on ne limite plus les bacs. On truque discrètement son évaluation : chaque poste se voit attribuer un petit bonus ou malus qui s’ajoute à son score au moment du choix. Poste surchargé, malus. Poste délaissé, bonus. C’est l’équilibrage sans loss auxiliaire introduit par DeepSeek-V3 : un biais par expert, ajouté au score de routage avant la sélection top-k, ajusté par une règle heuristique en dehors de la rétropropagation.

L’avantage est décisif. La loss n’est plus polluée. Le contremaître n’a plus deux patrons : il continue d’optimiser la seule production, et l’équilibrage se joue à côté, dans le réglage de la balance. C’est ce qui en a fait le paradigme dominant.

La limite. On n’a pas supprimé le réglage, on l’a déplacé. Il reste à décider à quelle vitesse on ajuste le pouce. Trop lentement, le déséquilibre s’installe avant d’être corrigé. Trop vite, le routage oscille : un poste devient attractif, se surcharge, est pénalisé, se vide, redevient attractif : et l’entraînement devient instable.

Chaque génération a donc réglé le problème de la précédente en déplaçant l’hyperparamètre plutôt qu’en le supprimant. C’est exactement le point où l’étude de cas reprendra.

Beaucoup de petits plutôt que quelques gros

Reste une question de dimensionnement : combien d’experts ?

La réponse de la pratique est spectaculaire. Les premiers MoE grand public en avaient huit et en activaient deux. Les modèles récents en ont plusieurs centaines et en activent une quinzaine. Le ratio d’activation est passé de 25 % à moins de 2 %.

Modèle	Experts routés	Activés	Ratio
Mixtral 8×7B	8	2	25 %
DeepSeek-V3	256	8	~3 %
Kimi K2	384	8	~2 %
Kimi K3	896	16	<2 %

Pourquoi cette course ? Pas pour avoir davantage de spécialités. Pour avoir davantage de recettes.

Reprenons la cuisine. Un MoE à huit gros experts, c’est une carte de huit plats tout préparés dont on choisit deux. Le nombre de menus possibles est vite épuisé, et si aucun des huit plats ne correspond exactement à ce qu’on veut, tant pis.

Un MoE à neuf cents petits experts, c’est un garde-manger de neuf cents ingrédients dont on en combine seize. Aucun ingrédient pris isolément ne constitue un plat : mais le nombre de recettes réalisables devient astronomique. À budget de paramètres constant, on n’a pas ajouté de capacité : on a ajouté de la finesse d’assemblage.

C’est le point conceptuel important, et il éclaire rétrospectivement ce qu’on disait sur la nature d’un expert. L’expressivité vient de la combinatoire, pas de la spécialisation individuelle. Un expert n’a pas besoin d’incarner quoi que ce soit d’identifiable. Il suffit que les mélanges soient discriminants.

Le nombre d’activés augmente lui aussi : de deux à seize. Logique : avec des ingrédients plus petits, il en faut plus pour composer un plat complet. On échange de la taille contre du nombre.

Et le prix est celui de la section précédente. Plus le garde-manger est grand, plus il est probable qu’on pioche toujours dans le même rayon. Chaque saut de granularité doit s’accompagner d’un progrès sur l’équilibrage, sinon il ne tient pas. C’est le fil rouge, encore une fois.

Les experts partagés

Un raffinement introduit par DeepSeekMoE et largement repris depuis : mélanger deux catégories dans le même bloc.

Un expert partagé traite tous les tokens, sans passer par le routeur. Toujours actif. Les experts routés sont sélectionnés par top-k comme décrit plus haut.

Pourquoi ? Parce que dans un MoE pur, chaque expert doit réapprendre les compétences génériques : la syntaxe de base, les régularités de surface, tout ce qui est nécessaire quel que soit le contenu. Cette redondance est un gaspillage massif : la même connaissance dupliquée des centaines de fois.

L’expert partagé factorise ce socle commun. Les routés sont alors libres de n’encoder que du différentiel. Pour reprendre l’atelier : un poste traite tous les colis pour les opérations de base, les autres n’interviennent que sur ce qui dépasse.

C’est aussi un filet de sécurité. Même si le routage se dégrade, l’expert partagé continue de traiter chaque token. La qualité chute, le modèle ne s’effondre pas.

Ce que ça implique côté infrastructure

Trois contraintes qui découlent du mécanisme et qu’aucune modélisation ne contourne.

L’all-to-all domine. À chaque bloc, les tokens partent vers les GPU hébergeant leurs experts et reviennent. Communication tous-vers-tous, gourmande en bande passante, répétée à chaque couche. D’où l’importance des domaines d’interconnexion rapides : mieux vaut que l’échange reste à l’intérieur d’un groupe d’accélérateurs étroitement couplés.

Les formes statiques valent de l’or. Si la taille des buffers dépend de la répartition observée, il faut réallouer et parfois recompiler à chaque pas. Fixer les tailles à la compilation permet des kernels optimisés une fois pour toutes.

Le CPU doit rester hors du chemin critique. Si le GPU attend une décision de l’hôte à chaque bloc MoE, la latence de cette boucle domine tout le reste. Les implémentations sérieuses gardent le dispatch entièrement sur l’accélérateur.

Étude de cas : Kimi K3

Kimi K3, publié par Moonshot AI le 16 juillet 2026, est le premier modèle ouvert de la classe 3T. Il pousse tout ce qui précède à un niveau inédit et propose une réponse originale au problème d’équilibrage.

896 experts, dont 16 activés par token. Environ 50 milliards de paramètres actifs sur 2 800, soit un ratio d’activation sous 2 %. Le bloc s’appelle Stable LatentMoE, et le schéma d’architecture publié fait apparaître les deux catégories décrites plus haut : experts partagés et experts routés. C’est un doublement de granularité par rapport à Kimi K2, un quadruplement par rapport à DeepSeek-V3.

À ce niveau de sparsité, Moonshot le dit explicitement, le routage et l’optimisation deviennent des enjeux de premier ordre. Leur réponse s’appelle Quantile Balancing : l’allocation des experts est dérivée directement des quantiles des scores du routeur, ce qui élimine les mises à jour heuristiques et un hyperparamètre d’équilibrage sensible.

Reprenons l’atelier une dernière fois. Le pouce sur la balance raisonnait en valeur absolue : « ce poste est trop chargé, retirons 0,05 à son score ». D’où la question insoluble de savoir combien retirer, et à quelle vitesse : une quantité dont la bonne valeur dépend de l’échelle des scores, qui elle-même dérive pendant l’entraînement.

Raisonner en quantiles, c’est cesser de noter les postes pour les classer. On ne demande plus « quel est le score de ce poste » mais « où se situe-t-il dans le classement du jour ». L’allocation découle de cette position.

L’avantage est l’invariance d’échelle. Un rang ne change pas si tous les scores sont multipliés par deux. Toute la sensibilité qui rendait le réglage délicat disparaît, parce que la grandeur manipulée est normalisée par construction. Il n’y a plus de bonne valeur à trouver : la distribution empirique fournit sa propre référence à chaque pas.

La leçon dépasse largement le MoE : quand un hyperparamètre est structurellement pénible à régler, il vaut souvent mieux changer la grandeur manipulée que perfectionner le réglage. Passer de la valeur au rang supprime le problème plutôt que de l’optimiser.

Le rapport technique n’est pas encore paru : il accompagnera les poids, annoncés pour le 27 juillet 2026. Ce qui précède s’appuie sur le blog de lancement, qui donne le principe et non l’algorithme ; l’interprétation en termes de rang est la mienne. La sortie des poids permettra aussi de mesurer directement la distribution d’usage des 896 experts, ce qui est le test le plus honnête de la promesse.

Ouverture : 896 boîtes noires

Cet article a passé son temps à contourner une question qu’il faut bien finir par nommer.

On sait construire un MoE. On sait diagnostiquer son effondrement, on sait l’équilibrer, on sait le faire tenir sur un cluster. Ce qu’on ne sait pas, c’est ce qu’il y a dedans.

Un expert reste ce qu’on a posé au début : un mini-modèle dont les poids ne sont pas lisibles et dont on ne peut pas caractériser ce qu’il traite. Multiplier par 896 ne change rien à l’affaire, sinon qu’on a maintenant 896 boîtes noires au lieu d’une, plus un routeur qui décide entre elles selon des critères que personne n’a spécifiés.

Ce n’est pas un vide de curiosité, c’est un vide d’outillage. On mesure des distributions d’activation : combien de fois chaque expert est sollicité : mais une distribution n’est pas une interprétation. Savoir que l’expert 412 reçoit 0,11 % du trafic ne dit rien de ce qu’il fait.

C’est le terrain des approches qui cherchent à caractériser l’espace interne d’un modèle plutôt que ses seules sorties : identifier des directions porteuses de sens dans l’espace latent, repérer des structures qui se maintiennent d’une couche à l’autre, comprendre ce qui est mis en commun entre modules et ce qui reste local. Les travaux sur les espaces de représentation partagés et les architectures d’espace de travail global posent précisément cette question : comment une information devient disponible pour l’ensemble d’un système plutôt que de rester confinée dans un module.

Un MoE est un terrain d’application naturel. C’est un système explicitement modulaire, avec une frontière nette entre modules, un mécanisme de sélection observable, et un flux résiduel qui joue le rôle de canal commun. Presque un banc d’essai.

Kimi K3 rend la chose concrète pour la première fois à cette échelle : 896 experts, poids ouverts, et une communauté qui pourra enfin regarder.

Ce sera une autre question : non plus comment équilibrer les experts, mais comment comprendre ce qu’ils apprennent réellement.

En résumé

Un MoE remplace le FFN du bloc Transformer, pas l’attention. C’est là que sont les deux tiers des paramètres.
Un expert est un mini-modèle opaque : on peut observer quand il s’active, pas décrire ce qu’il fait.
Le pari : découpler capacité et coût : ne tient que si les tokens se répartissent également. Tout le reste en découle.
La décision de routage est dure, locale et par token. Rien à voir avec le routage inter-modèles, malgré le vocabulaire partagé.
L’effondrement du routeur est auto-renforçant et se joue tôt. Rien dans la loss ne le prévient : toutes les solutions sont des contraintes externes.
Le déséquilibre coûte de la capacité et du débit : en expert parallelism, le nœud le plus chargé dicte le rythme du cluster entier.
L’expressivité vient de la combinatoire : beaucoup de petits ingrédients valent mieux que quelques gros plats.
L’apport de Kimi K3 est Quantile Balancing : classer plutôt que noter, pour supprimer un hyperparamètre au lieu de le régler.

Ressources

Les origines

Jacobs, Jordan, Nowlan & Hinton (1991), Adaptive Mixtures of Local Experts, Neural Computation 3(1) : l’idée fondatrice, trente ans avant les Transformers.
Jordan & Jacobs (1994), Hierarchical Mixtures of Experts and the EM Algorithm, Neural Computation 6(2) : la version hiérarchique.
Vaswani et al. (2017), Attention Is All You Need : arXiv
.03762. L’alternance attention / FFN dont il est question en introduction.

Le MoE sparse et son équilibrage

Shazeer et al. (2017), Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer : arXiv
.06538. Le papier fondateur, et la loss auxiliaire.
Lepikhin et al. (2020), GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding : arXiv
.16668. Facteur de capacité et sharding automatique.
Fedus, Zoph & Shazeer (2021), Switch Transformers : arXiv
.03961. Le top-1 poussé jusqu’au bout, et le rejet de tokens assumé.
Zoph et al. (2022), ST-MoE: Designing Stable and Transferable Sparse Expert Models : arXiv
.08906. Sur l’instabilité d’entraînement, encore le meilleur point d’entrée.
Wang, Gao, Zhao, Sun & Dai (2024), Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts : arXiv
.15664. Le « pouce sur la balance » : biais par expert, sans gradient d’interférence.

Granularité et experts partagés

Dai et al. (2024), DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models : arXiv
.06066. Segmentation fine et isolation des experts partagés : les deux idées reprises depuis par à peu près tout le monde.
Jiang et al. (2024), Mixtral of Experts : arXiv
.04088. Le MoE à huit gros experts, avec une analyse du routage qui vaut la lecture.
DeepSeek-AI (2024), DeepSeek-V3 Technical Report : arXiv
.19437. 671 milliards de paramètres, 37 activés, et l’équilibrage sans loss auxiliaire en production.

Vues d’ensemble

Fedus, Dean & Zoph (2022), A Review of Sparse Expert Models in Deep Learning : arXiv
.01667.
Cai et al. (2024), A Survey on Mixture of Experts : arXiv
.06204.

Vers l’ouverture

Probing Semantic Routing in Large Mixture-of-Expert Models : arXiv
.10928. La question posée frontalement : le routage encode-t-il de la sémantique, ou seulement de la surface ?

Kimi K3

Blog de lancement de Kimi K3 (16 juillet 2026) : source de tous les chiffres et des noms de mécanismes cités ici. Le rapport technique et les poids sont annoncés pour le 27 juillet 2026.