Mixture of Experts (MoE) est l’astuce architecturale qui a bris\u00e9 les lois de scaling. Au lieu d’activer chaque param\u00e8tre pour chaque token, les mod\u00e8les MoE routent chaque input vers un petit sous-ensemble de r\u00e9seaux d’\u00ab experts \u00bb sp\u00e9cialis\u00e9s. Le r\u00e9sultat : un mod\u00e8le de 30B param\u00e8tres qui n’utilise que 3B param\u00e8tres par forward pass. M\u00eame qualit\u00e9. Une fraction du calcul.<\/p>\n
Les transformers denses traditionnels sont gaspilleurs. Chaque token traverse chaque param\u00e8tre, ind\u00e9pendamment du fait que ces param\u00e8tres sont pertinents. MoE fait basculer cela en introduisant un r\u00e9seau routeur<\/strong> \u2014 un petit m\u00e9canisme de gating qui d\u00e9cide quels experts g\u00e8rent chaque token.<\/p>\n Pense \u00e0 un h\u00f4pital. Un mod\u00e8le dense envoie chaque patient \u00e0 chaque sp\u00e9cialiste. Un mod\u00e8le MoE a une infirmi\u00e8re de triage qui route les patients aux bons m\u00e9decins. L’h\u00f4pital a le m\u00eame personnel total, mais chaque patient ne voit que les pertinents.<\/p>\n Le routeur utilise typiquement une fonction de gating bas\u00e9e sur softmax qui produit une distribution sparse \u2014 s\u00e9lectionnant les top-k experts (g\u00e9n\u00e9ralement 2) parmi un pool de 8, 16, ou m\u00eame 64 experts. Cela signifie qu’\u00e0 tout moment, seule une petite fraction des param\u00e8tres du mod\u00e8le est active.<\/p>\n C’est l\u00e0 que \u00e7a devient int\u00e9ressant. Un mod\u00e8le MoE de 30B avec 3B param\u00e8tres actifs surpasse syst\u00e9matiquement un mod\u00e8le dense de 7B, m\u00eame si tous deux utilisent \u00e0 peu pr\u00e8s le m\u00eame calcul par token. La raison est la capacit\u00e9<\/strong>.<\/p>\n Le mod\u00e8le MoE stocke plus de connaissances sur ses 30B param\u00e8tres totaux. Diff\u00e9rents experts se sp\u00e9cialisent dans diff\u00e9rents domaines \u2014 l’un pourrait g\u00e9rer le code, un autre les math\u00e9matiques, un autre l’\u00e9criture cr\u00e9ative. Quand un token de code arrive, l’expert code s’active. Quand un token de po\u00e9sie arrive, l’expert po\u00e9sie s’illumine. Le mod\u00e8le a plus de connaissances sans payer le co\u00fbt computationnel complet.<\/p>\n Mixtral 8x7B a prouv\u00e9 ceci \u00e0 l’\u00e9chelle. Avec 46,7B param\u00e8tres totaux mais seulement 12,9B actifs, il a \u00e9gal\u00e9 ou d\u00e9pass\u00e9 Llama 2 70B sur la plupart des benchmarks tout en \u00e9tant dramatiquement moins cher \u00e0 faire tourner. DeepSeek-V2 l’a pouss\u00e9 plus loin avec 236B param\u00e8tres totaux et seulement 21B actifs.<\/p>\n MoE n’est pas un repas gratuit. Plusieurs probl\u00e8mes d’engineering le rendent plus difficile que les mod\u00e8les denses :<\/p>\n L’\u00e9quilibrage de charge<\/strong> est le plus gros probl\u00e8me. Sans r\u00e9gularisation soign\u00e9e, le routeur tend \u00e0 s’effondrer \u2014 envoyer tous les tokens \u00e0 un ou deux experts \u00ab favoris \u00bb tandis que d’autres restent inactifs. Cela d\u00e9fait compl\u00e8tement le but. Les chercheurs ajoutent des fonctions de perte auxiliaire pour encourager un routage \u00e9quilibr\u00e9, mais r\u00e9gler cela est un art.<\/p>\n L’empreinte m\u00e9moire<\/strong> est l’autre pi\u00e8ge. Un mod\u00e8le MoE de 30B a 30B param\u00e8tres en m\u00e9moire, m\u00eame si seulement 3B sont actifs par token. Tu as besoin de suffisamment de VRAM pour tenir le mod\u00e8le complet, ce qui peut \u00eatre surprenant si tu es habitu\u00e9 \u00e0 dimensionner l’infrastructure bas\u00e9 sur les comptes de param\u00e8tres actifs.<\/p>\n Les frais g\u00e9n\u00e9raux de communication<\/strong> en environnements distribu\u00e9s sont r\u00e9els. Quand les experts vivent sur diff\u00e9rents GPUs, router des tokens entre eux introduit de la latence. Les strat\u00e9gies de parall\u00e9lisme d’experts aident, mais les co\u00fbts networking sont non-triviales.<\/p>\n Chaque grand lab a adopt\u00e9 MoE. Mixtral, DeepSeek, Qwen, Grok \u2014 ils utilisent tous une variante. La tendance est claire : les comptes de param\u00e8tres totaux augmentent tandis que les comptes de param\u00e8tres actifs restent g\u00e9rables.<\/p>\n Le sweet spot en 2026 semble \u00eatre des mod\u00e8les avec 30-60B param\u00e8tres totaux et 3-8B actifs. Ceux-ci tournent sur du hardware grand public (avec quantisation), tiennent sur des GPUs simples pour l’inf\u00e9rence, et livrent une performance qui aurait demand\u00e9 des mod\u00e8les denses 70B+ il y a un an.<\/p>\n Le fine-tuning des mod\u00e8les MoE ajoute un autre pli. Les adaptateurs LoRA fonctionnent, mais tu dois d\u00e9cider : adapter les couches partag\u00e9es, les experts, ou le routeur ? Chaque choix produit des r\u00e9sultats diff\u00e9rents. Le consensus \u00e9mergent est d’adapter les couches d’attention partag\u00e9es plus un sous-ensemble d’experts pertinents pour ton domaine.<\/p>\n La fronti\u00e8re se d\u00e9place vers la s\u00e9lection d’experts dynamique<\/strong> \u2014 des mod\u00e8les qui peuvent activer plus d’experts pour les probl\u00e8mes difficiles et moins pour les faciles. Cette approche de calcul adaptatif signifie que le mod\u00e8le d\u00e9pense plus de ressources o\u00f9 elles comptent.<\/p>\n Une autre direction prometteuse est la fusion et l’\u00e9lagage d’experts<\/strong> post-training. Si deux experts finissent par apprendre des choses similaires, fusionne-les. Si un expert s’active rarement, supprime-le. Cela cr\u00e9e des mod\u00e8les MoE plus petits et plus efficaces sans retraining.<\/p>\n MoE n’est pas juste un choix d’architecture. C’est un changement fondamental dans la fa\u00e7on dont nous pensons au scaling de mod\u00e8les. La question n’est plus \u00ab combien de param\u00e8tres ? \u00bb. C’est \u00ab combien de param\u00e8tres par token ? \u00bb. Cette distinction change tout sur le co\u00fbt, le d\u00e9ploiement, et l’accessibilit\u00e9.<\/p>\nPourquoi 30B avec 3B actifs surpasse 7B dense<\/h2>\n
Les d\u00e9fis d’engineering<\/h2>\n
Le paysage MoE actuel<\/h2>\n
Ce qui vient ensuite<\/h2>\n