Nous avons expliqué dans notre article sur le mélange d'experts pourquoi les modèles géants n'activent qu'une fraction d'eux-mêmes. Voici l'autre moitié de l'histoire : pourquoi les modèles conçus pour tourner chez vous font souvent le choix inverse, et pourquoi ce n'est pas un retard mais une décision.
Rappel rapide des deux approches
Un modèle dense utilise l'intégralité de ses paramètres pour chaque token produit. Trente milliards de paramètres signifie trente milliards de calculs, à chaque fois.
Un modèle en mélange d'experts découpe une partie du réseau en sous-ensembles spécialisés, et un routeur n'en convoque que quelques-uns. Deux mille milliards de paramètres dont quarante actifs signifie qu'on paie le calcul de quarante milliards seulement.
Pourquoi les gros modèles choisissent le mélange
La raison est économique. À l'échelle d'un service qui traite des milliards de requêtes, le coût de calcul par requête est la variable qui décide de la viabilité, comme nous l'expliquions dans notre article sur les deux coûts de l'IA.
Le mélange d'experts offre un compromis remarquable : les connaissances d'un modèle géant pour le coût de calcul d'un modèle moyen. Sans cette architecture, les modèles à plusieurs milliers de milliards de paramètres seraient probablement inexploitables commercialement.
Pourquoi les modèles locaux choisissent souvent le dense
Voici le point contre-intuitif, et il tient à une distinction que nous avons déjà signalée : le mélange économise le calcul, pas la mémoire.
Puisqu'on ne sait pas à l'avance quels experts le routeur va convoquer, l'ensemble doit rester disponible. Un modèle de deux mille milliards de paramètres occupe donc la place de deux mille milliards de paramètres, même s'il n'en fait travailler que quarante.
Or pour quelqu'un qui fait tourner un modèle sur une carte graphique unique, la contrainte n'est pas le calcul mais la mémoire disponible. Dans ce contexte, un modèle dense de trente milliards de paramètres, correctement compressé selon les techniques décrites dans notre article sur la quantization, tient. Un modèle en mélange de taille totale équivalente à ses paramètres actifs n'existerait pas.
Un modèle dense a un comportement plus prévisible. Toutes ses parties travaillent à chaque fois, donc sa vitesse et sa consommation varient peu d'une requête à l'autre. Un modèle en mélange peut voir ses performances fluctuer selon les experts sollicités, et le routeur lui-même peut se tromper. Pour un usage local, où l'on veut de la régularité plutôt que la performance maximale, cette prévisibilité compte.
Comment choisir en pratique
La règle est simple.
Si vous passez par une API, l'architecture ne vous concerne pas. Ce qui compte est le prix par tâche accomplie et la qualité sur vos cas. Le fournisseur absorbe les contraintes techniques.
Si vous hébergez vous-même, regardez la taille totale, pas le nombre de paramètres actifs. C'est elle qui détermine si le modèle tient dans votre mémoire. Un modèle annoncé avec quarante milliards actifs peut être totalement hors de portée si son total dépasse le téraoctet, comme nous l'avons vu avec les poids de Kimi K3.
Ce qu'il faut retenir
Ces deux architectures ne s'opposent pas comme l'ancien et le moderne : elles répondent à deux contraintes différentes.
Le mélange d'experts optimise le calcul, ce qui compte quand on sert des millions d'utilisateurs. Le dense optimise la mémoire et la prévisibilité, ce qui compte quand on fait tourner un modèle sur une machine unique.
Cette divergence explique d'ailleurs quelque chose d'intéressant sur l'état du secteur : il ne construit plus un seul type de modèle. Il construit des modèles pour des serveurs et des modèles pour des machines personnelles, et ces deux lignées commencent à diverger techniquement. C'est le signe d'un marché qui se segmente, donc qui mûrit.