Mixture of experts

Le principe du routage

Dans un réseau dense classique, chaque token traverse l'ensemble des couches et sollicite tous les paramètres. Une architecture à mélange d'experts découpe certaines couches en plusieurs sous-réseaux spécialisés et confie à un routeur le soin d'en choisir quelques-uns pour chaque token. Seuls les experts sélectionnés calculent. Le reste demeure inactif pour ce token, même s'il occupe de la mémoire sur la machine. Le gain porte donc sur le calcul, pas sur l'empreinte mémoire du modèle. Cette sélection explique pourquoi deux requêtes voisines peuvent mobiliser des experts différents.

Le routeur apprend pendant l'entraînement, en même temps que les experts. Rien ne garantit qu'il répartisse équitablement la charge : sans précautions, quelques experts accaparent les tokens et les autres restent sous-entraînés. Les équipes ajoutent donc des contraintes d'équilibrage et une capacité maximale par expert. Ce réglage influence directement la qualité finale et la stabilité de l'entraînement, souvent davantage que le nombre d'experts lui-même. C'est un point technique, mais il détermine la fiabilité du modèle livré. Un déséquilibre se repère à la charge de calcul, rarement à la qualité des réponses.

Ce que cela change à l'usage

Pour un modèle servi, l'intérêt est de disposer d'une réserve de connaissances plus large qu'un modèle dense de coût comparable. Un modèle à experts peut ainsi répondre correctement sur des domaines variés tout en restant économique à l'inférence, puisque chaque requête ne réveille qu'une partie du réseau. Plusieurs familles ouvertes reposent sur ce principe, et les grands éditeurs l'emploient sur leurs modèles les plus volumineux. Le compromis entre capacité et budget devient plus favorable. C'est ce qui explique l'écart entre la taille annoncée du modèle et son coût réel d'exploitation.

La contrepartie est mémoire : tous les experts doivent être chargés, même ceux qui ne servent pas à l'instant considéré. Un déploiement local exige donc beaucoup de mémoire vidéo par rapport au calcul réellement effectué. La latence dépend de la qualité du routage et du matériel disponible. En pratique, ce choix convient mieux à un serveur partagé entre plusieurs usages qu'à une machine individuelle, où la mémoire disponible constitue rapidement le facteur limitant. Un serveur partagé absorbe mieux cette empreinte qu'un poste de travail isolé.

Ce qu'il faut retenir pour un projet

Il n'est pas nécessaire de choisir un modèle à experts pour de bonnes performances sur une tâche étroite. Un modèle dense plus petit, affiné sur vos données, atteint souvent un résultat comparable pour un coût d'exploitation inférieur. L'arbitrage se fait sur la variété des demandes : plus elles couvrent de domaines, plus une architecture à experts a de chances d'apporter quelque chose. À l'inverse, un usage répétitif et cadré ne justifie presque jamais cette complexité. Un modèle plus petit, correctement évalué, reste souvent le choix le plus économique.

Les repères publiés par les éditeurs mélangent souvent capacité totale et calcul par token. Comparer deux modèles sur le seul nombre de paramètres annoncé conduit à des conclusions fausses. Ce qui compte pour votre budget est le coût par requête servie, mesuré sur vos cas, et la mémoire nécessaire pour loger le modèle. Une évaluation interne tranche mieux qu'une fiche technique, surtout lorsque les volumes deviennent significatifs. Le même raisonnement vaut pour la latence, qui dépend du routage autant que du matériel.