Les Modèles Mixture-of-Experts Réécrivent Discrètement l'Économie de l'IA

Lorsque Google DeepMind a publié le rapport technique de Gemini 1.5, un détail a pris de nombreux chercheurs au dépourvu : le modèle utilise une architecture Mixture-of-Experts, n'activant qu'une fraction de ses paramètres par inférence. Peu après, Mixtral 8x7B de Mistral AI a montré qu'une équipe relativement petite pouvait publier un modèle compétitif avec des architectures denses beaucoup plus grandes – pour une fraction du coût de calcul. Ces deux moments pointent vers le même changement structurel : les architectures MoE passent de la curiosité de recherche au standard de production.

Ce Que Mixture-of-Experts Fait Réellement

Un réseau neuronal dense traditionnel active tous ses paramètres sur chaque token qu'il traite. Un modèle de 70 milliards de paramètres utilise les 70 milliards – à chaque fois, pour chaque token, sans exception. Cela fait évoluer le calcul linéairement avec le nombre de paramètres, ce qui explique pourquoi l'entraînement et le service des grands modèles denses sont si coûteux.

Mixture-of-Experts brise cette équation. L'architecture divise les couches feed-forward du modèle en un ensemble de sous-réseaux "experts" – généralement entre 8 et 64. Un réseau de routage léger sélectionne ensuite lesquels de ces 2 ou 4 experts activer pour chaque token. Le reste reste inactif.

Le résultat : un modèle avec 46 milliards de paramètres totaux pourrait n'en activer que 12 milliards par token. Vous obtenez la capacité d'un modèle de 46B – sa connaissance étendue, sa surface de raisonnement – tout en payant le coût d'inférence d'un modèle de 12B. C'est la proposition économique centrale.

L'Architecture Derrière les Chiffres

Le mécanisme de routage est là où se trouve la majorité de la complexité technique. Les premières implémentations de MoE souffraient de "déséquilibre de charge" – certains experts recevaient beaucoup plus de trafic que d'autres, laissant la plupart des paramètres chroniquement sous-utilisés. Les implémentations modernes résolvent cela avec des pertes auxiliaires d'équilibrage de charge pendant l'entraînement, forçant le routeur à distribuer les tokens plus uniformément entre les experts.

Mixtral 8x7B utilise 8 experts par couche avec une stratégie de routage top-2 : chaque token sélectionne ses deux experts les mieux adaptés et leurs sorties sont combinées via une somme pondérée. Le nombre effectif de paramètres sur un token donné est d'environ 13B malgré un modèle total de 46B. Les performances du modèle sur la plupart des benchmarks suivent de près un modèle dense de 30–40B.

L'article Switch Transformer de Google a démontré que l'on pouvait passer un modèle MoE à plus d'un billion de paramètres tout en maintenant le calcul d'inférence à des niveaux gérables. On pense largement que GPT-4 utilise une architecture MoE, bien qu'OpenAI n'ait jamais confirmé les détails.

Ce Qui Change au Niveau de l'Infrastructure

Les avantages de MoE en matière de calcul viennent avec un véritable compromis : l'empreinte mémoire. Vous devez charger tous les experts en mémoire, même si seuls quelques-uns sont activés par token. Un modèle dense de 13B et un modèle MoE de 46B peuvent coûter le même nombre de FLOPs par token, mais le modèle MoE nécessite beaucoup plus de mémoire GPU pour être hébergé.

Cela façonne les exigences matérielles pour servir ces modèles. Les modèles denses tiennent proprement sur moins de GPUs ; les modèles MoE nécessitent souvent de distribuer les experts sur plusieurs dispositifs, ce qui introduit une surcharge de communication inter-dispositifs. Pour l'inférence sur un seul appareil ou les déploiements en périphérie (edge), les modèles denses ont toujours l'avantage. Pour le service API à grande échelle où de nombreuses requêtes peuvent être regroupées et les experts mis en cache en VRAM, les architectures MoE gagnent souvent en coût par token.

L'implication pratique : les modèles MoE sont optimisés pour le service cloud à grande échelle, pas pour une exécution locale sur du matériel grand public. Un modèle MoE de 46B exige bien plus de 24 Go de VRAM même sous forme quantifiée, alors qu'un modèle dense de performances comparables pourrait tenir dans 16 Go.

Pourquoi Cela Redéfinit Qui Peut Construire des Modèles de Pointe

Les coûts d'entraînement sont la véritable histoire. Un modèle MoE peut égaler ou dépasser les capacités d'un modèle dense avec des budgets de FLOP d'entraînement significativement plus faibles, car l'augmentation du nombre de paramètres améliore la qualité du modèle sans nécessiter que tous ces paramètres soient calculés sur chaque échantillon.

C'est pourquoi Mistral – une équipe de moins de 20 chercheurs au moment de la sortie de Mixtral – a pu produire un modèle qui rivalisait avec Llama 2 70B de Meta. L'architecture leur a donné un effet de levier : plus de paramètres, un coût d'entraînement plus faible, un coût de service plus faible par token. Elle a réduit l'exigence de capital pour construire des modèles de pointe compétitifs.

Les laboratoires sans les budgets d'entraînement de Google ou Microsoft peuvent atteindre des niveaux de capacité plus élevés en misant sur MoE plutôt qu'en faisant évoluer des modèles denses. Ce n'est pas un égalisateur complet – les données, l'infrastructure et les talents déterminent toujours la qualité – mais il comprime de manière significative l'écart de coût entre les équipes de recherche bien financées et les équipes réduites.

Les Questions Ouvertes

La recherche sur MoE est encore loin d'être close. Le mécanisme de routage reste un domaine actif : le routage éparse appris, la fusion d'experts et les nombres dynamiques d'experts sont tous à l'étude. Il y a un travail significatif sur la question de savoir si les modèles MoE généralisent aussi bien que les modèles denses avec le même nombre de paramètres actifs, en particulier sur les tâches qui nécessitent d'intégrer des connaissances entre domaines en une seule passe avant.

Le raisonnement à contexte long est un autre domaine sous examen. Si les tokens d'un long document sont routés vers différents experts, le modèle peut ne pas maintenir un contexte cohérent aussi proprement qu'un modèle dense où tous les paramètres traitent tout ensemble. Les chercheurs testent diverses architectures d'attention-plus-expert pour résoudre ce problème.

L'efficacité de service pour les petites tailles de lots reste une faiblesse. Si vous exécutez une application mono-utilisateur avec une faible concurrence, les avantages de regroupement qui rendent MoE rentable à grande échelle disparaissent – et vous vous retrouvez avec une surcharge mémoire complète et aucune économie de calcul amortie.

Ce Qu'il Faut Surveiller

La tendance MoE s'accélère tant dans les modèles ouverts que fermés. Attendez-vous à ce que davantage de laboratoires livrent des architectures MoE comme format de publication principal, davantage d'outils pour la quantification consciente des experts qui réduit la pénalité mémoire, et davantage de recherches sur des algorithmes de routage qui améliorent la généralisation sans sacrifier l'efficacité.

Pour les praticiens qui construisent sur ces modèles via API, l'architecture est en grande partie invisible – un modèle MoE répond de la même manière qu'un modèle dense. Mais pour les équipes qui évaluent s'il faut auto-héberger ou faire du fine-tuning, le compromis mémoire-calcul est central pour la planification matérielle. Un modèle MoE de 46B et un modèle dense de 13B peuvent coûter le même prix par inférence, mais ils ont des exigences d'hébergement radicalement différentes.

MoE n'est pas une solution miracle. Mais c'est l'exemple le plus clair ces dernières années d'une innovation architecturale qui a véritablement déplacé la frontière de l'efficacité – et a changé quelles équipes pouvaient raisonnablement rivaliser dans la construction de grands modèles capables.