Magazine LLM Opensource · 28 October 2026

MoE open-weight en 2026 : le guide pratique du routage d’experts, ce qui change vraiment quand on passe à l’échelle

816 milliards de paramètres, 42 milliards activés par token, un million de tokens de contexte : Muse Spark Open résume à lui seul le basculement de 2026. Derrière le chiffre marketing, une mécanique de routage qui redessine le métier du praticien — serving, quantification, fine-tuning, évaluation. Voici le cadre de décision, sans mythologie.

Le basculement : pourquoi tout le monde est devenu MoE

Il y a une ironie à ouvrir ce dossier par une date. Le 15 octobre 2026, Meta a publié Muse Spark Open, présenté par AI at Meta comme « le modèle open-weight américain le plus capable à ce jour » : 816 milliards de paramètres totaux, 42 milliards actifs par token, une fenêtre de contexte d’un million de tokens, et un positionnement explicite vers le code et le travail agentique. Le lendemain, le 16 octobre, la même vague a déposé sur les serveurs non pas un mais trois modèles — 816B, 560B, 120B — et un constat gênant : la vague open-weight se heurte désormais à un mur de mémoire (the-agent-report.com). Le 7 octobre, Mistral avait déjà lâché son « Chonk », Mistral Large 4, un modèle à plus de 1 000 milliards de paramètres dont 49 milliards activés par réponse, poids prévus le 27 octobre (NeoTeo, Korben).

Autrement dit : en l’espace de dix jours d’octobre 2026, l’écosystème open-weight a produit coup sur coup des modèles à trois chiffres de milliards de paramètres, tous ou presque architecturés en mélange d’experts. La domination du MoE n’est plus une curiosité d’architecture : c’est la condition d’existence des modèles frontière ouverts. La raison est arithmétique avant d’être idéologique. Un dense de 800 milliards de paramètres coûterait, à chaque token généré, le calcul de 800 milliards de paramètres. Un MoE de 816 milliards n’en calcule que 42 — soit environ 5 % de la capacité par étape. Ce découplage entre capacité stockée et calcul par token est le seul moyen connu de faire tenir un modèle très large dans un budget d’inférence acceptable.

Le revers de la médaille est tout aussi arithmétique, et c’est là que le métier change. Tous les paramètres doivent résider en mémoire, même ceux qu’on n’active pas. Un MoE 816B en BF16, c’est de l’ordre de 1,6 To de poids à loger quelque part. C’est précisément ce « mur de mémoire » que documente la vague du 16 octobre, et c’est lui qui structure l’essentiel des décisions pratiques : quantification, parallélisme, choix de matériel. Le routage d’experts n’est pas un détail d’implémentation interne ; c’est le paramètre qui détermine si votre déploiement tient debout ou s’effondre.

Anatomie d’un routeur : ce qui se passe vraiment entre l’entrée et la sortie

Le mécanisme de base est d’une simplicité désarmante, et c’est ce qui trompe. Pour chaque token, un routeur — typiquement une matrice de poids apprise — calcule un score pour chaque expert, applique un softmax, sélectionne les k meilleurs, et combine leurs sorties de façon pondérée. Les autres experts sont ignorés pour ce token. Le consensus des sources techniques disponibles (documentation tokios, référentiels topai-tools) converge sur ce point : le top-k routing avec softmax est l’approche dominante en production, et K=2 est la valeur courante. Un modèle peut embarquer 256 experts et n’en activer que 8 par token, soit environ 3 % de la capacité mobilisée à chaque étape.

Trois variantes structurelles méritent d’être distinguées, parce qu’elles n’ont pas les mêmes conséquences opérationnelles.

Les experts partagés. Certaines architectures ajoutent des experts activés pour chaque token, indépendamment du routage, afin de capturer les patterns communs à toutes les entrées. Selon la documentation tokios, Qwen3-Next utiliserait 1 expert partagé + 10 routés, et Kimi K3 deux partagés + 16 routés, tandis que DeepSeek-V3 et le MoE Qwen3 original n’en auraient pas. Ces chiffres proviennent d’une source unique non officielle et doivent être maniés avec précaution — mais le principe, lui, est solide : les experts partagés stabilisent l’apprentissage et réduisent la variance du routage, au prix d’un calcul incompressible.

Les experts fine-grained. Plutôt que 8 gros experts, on préfère souvent 64 ou 256 experts plus petits, dont on active un sous-ensemble plus large. La granularité fine améliore la spécialisation et l’équilibrage, mais multiplie les petits tenseurs — donc les communications et les noyaux de calcul inefficaces. C’est un arbitrage direct entre qualité et débit.

Le top-k dynamique. Faire varier k selon le token (plus d’experts pour une entrée ambiguë, moins pour une entrée évidente) est une piste active, mais aucune source du corpus ne fournit d’hyperparamètre publié par modèle. Restons-en au principe.

Ce tableau dit l’essentiel : le ratio d’activation tourne autour de 5 % chez les très gros modèles. C’est ce chiffre — et non le nombre total de paramètres — qui gouverne votre facture de calcul. Un 816B à 5 % n’exécute pas plus de FLOPs par token qu’un dense d’environ 42 milliards. La vraie question n’est donc pas « combien de paramètres ? » mais « combien de mémoire pour les loger, et combien de communication pour les router ? ».

Le vrai coût : mémoire, bande passante et all-to-all

C’est ici que les migrations échouent. Un dense de 42 milliards tient confortablement sur un nœud de GPU moderne en quantification 8 bits. Un MoE de 816B ne tient nulle part sur un seul nœud : il faut répartir les experts sur plusieurs GPU, ce qu’on appelle l’expert parallelism. Chaque token doit alors être envoyé, via des communications all-to-all, vers les GPU qui hébergent ses experts sélectionnés, puis ramené. Ces échanges sont le talon d’Achille du MoE : ils dépendent de l’interconnexion (NVLink intra-nœud, InfiniBand ou Ethernet inter-nœuds) et deviennent le goulot d’étranglement dès que le batch est petit ou que le routage est déséquilibré.

D’où l’importance du load balancing. Si le routeur envoie 40 % des tokens vers le même expert — un phénomène classique en début d’entraînement, et qui persiste si rien ne le corrige —, le GPU qui l’héberge sature pendant que les autres tournent à vide. On parle alors de hotspots GPU. Les parades sont de deux ordres : une perte auxiliaire qui pénalise les routages déséquilibrés pendant l’entraînement, ou des mécanismes d’équilibrage sans perte auxiliaire, plus récents. Aucune source du corpus ne documente les coefficients exacts par modèle ; retenez le principe, pas les hyperparamètres.

La conséquence pratique est immédiate : le débit d’un MoE est bien plus sensible à la charge que celui d’un dense. En régime de forte concurrence, les tokens se répartissent statistiquement sur tous les experts, les GPU se remplissent, et l’efficacité grimpe. En régime de faible batch — un utilisateur, une requête interactive —, chaque token ne mobilise que 5 % des poids mais doit quand même charger les experts concernés depuis la mémoire : on paie la bande passante mémoire sans amortir le calcul. C’est le régime où un MoE 800B+ peut perdre face à un dense 70B.

Serving : vLLM, SGLang et l’arrivée de llm-d 1.0

L’outillage a suivi. vLLM et SGLang, les deux moteurs d’inférence de référence pour les modèles ouverts, ont annoncé le 20 octobre 2026 des versions compatibles TPU, élargissant le terrain de jeu au-delà du GPU (Google Developers Blog, via note.com). Le même jour, à la PyTorch Conference North America, le projet llm-d a publié sa version 1.0, une pile d’inférence distribuée native Kubernetes, annoncée par IBM Research (IBM Newsroom). Pour un MoE à 800B+, ce n’est pas un détail : llm-d vise précisément le serving à l’échelle sur cluster, avec répartition de charge et ordonnancement conscients du matériel — exactement les problèmes que pose l’expert parallelism.

Concrètement, trois chantiers dominent le déploiement d’un MoE 800B+ en 2026 :

1. La quantification. Le BF16 est prohibitif en mémoire pour 816B. Le NVFP4 (format 4 bits de NVIDIA) est explicitement cité dans les guides de déploiement de Muse Spark Open sur SageMaker JumpStart (ireadcustomer.com). Mais quantifier agressivement un MoE n’est pas neutre : les experts rares, peu sollicités, tolèrent mal une quantification à 4 bits, et le routeur lui-même — qui décide de tout — est sensible. La dégradation ne se voit pas sur un benchmark agrégé ; elle se voit sur les domaines de niche.
2. Le KV cache et le contexte long. Un contexte d’un million de tokens fait exploser le cache d’attention. Aleph Alpha recommande d’ailleurs, pour Kolibri-1, une fenêtre de production d’environ 262 144 tokens alors que le maximum est de 1 048 576 — un aveu que le contexte maximal n’est pas le contexte raisonnable. Sur un MoE, le KV cache pèse d’autant plus lourd que la mémoire est déjà saturée par les poids.
3. Le matériel. Muse Spark Open est présenté comme tournant sur des Mac Studio équipés d’Apple M5 Ultra — un positionnement desktop/edge qui dit quelque chose : à 42 milliards d’actifs, un MoE peut descendre sur du matériel local à mémoire unifiée, là où un dense équivalent peinerait.

Fine-tuning : ce qu’on gèle, ce qu’on cible

C’est le point où les praticiens se cassent les dents, et où la documentation publique reste la plus mince. Sur un MoE, la question n’est pas seulement « quel module adapter ? » mais « quel expert adapter ? ». Trois stratégies coexistent :

• LoRA sur les couches d’attention uniquement, en gelant intégralement les experts et le routeur. C’est le choix conservateur : on adapte le style, le format, la langue, sans toucher à la spécialisation. Risque faible, gain limité sur les tâches de domaine pointu.
• LoRA sur les experts, en ciblant les experts les plus sollicités pour un domaine donné. Plus puissant, mais il faut d’abord identifier ces experts — ce qui suppose de logger le routage, donc d’instrumenter le serving. Et l’on risque de déséquilibrer davantage un routeur déjà fragile.
• LoRA sur le routeur, pour réorienter la sélection d’experts vers un domaine. Théoriquement élégant, pratiquement délicat : le routeur est un composant à très faible paramétrage mais à effet global, et le perturber dégrade tout le reste.

Les pratiques émergentes — élagage d’experts (expert pruning) pour ne garder que ceux utiles à un domaine, distillation vers un dense plus petit — sont séduisantes sur le papier. Mais aucune source du corpus ne documente de retour d’expérience publié sur DeepSeek, Qwen ou Kimi en la matière, ni de benchmark d’outils (PEFT, Unsloth, Axolotl) spécifique aux MoE 800B+. Prudence donc : sur ce terrain, l’état de l’art public est en retard sur la pratique des équipes.

Évaluation : pourquoi les benchmarks agrégés vous mentiront

Voici le piège le plus coûteux. Un MoE est, par construction, un ensemble de spécialistes. Un score MMLU de 88 % peut cacher un excellent expert de mathématiques et un expert de droit lamentable — simplement parce que le routeur envoie peu de tokens juridiques vers l’expert concerné, ou parce que cet expert a été sous-entraîné. Les benchmarks agrégés moyennent cette hétérogénéité et la masquent.

La bonne pratique 2026 consiste à évaluer par domaine et par régime de routage : mesurer non seulement la qualité, mais la distribution des experts activés sur votre corpus cible. Si 80 % de vos tokens métier partent vers deux experts, vous avez un problème de capacité ou de déséquilibre, et vos scores globaux ne le diront pas. C’est aussi ce qui rend les comparaisons inter-modèles trompeuses : un dense 70B offre une qualité homogène, un MoE 816B offre une qualité en dents de scie dont la moyenne est supérieure mais la variance bien plus grande.

Le cadre de décision : quand le MoE gagne, quand il perd

Résumons en un tableau de régimes, sans chiffres inventés — les ordres de grandeur dépendent trop du matériel et de la quantification.

La règle empirique qui se dégage : le MoE gagne quand vous pouvez mutualiser la charge et que votre tâche ressemble à celle pour laquelle le modèle a été entraîné. Il perd quand vous avez besoin d’une latence prévisible sur petit batch, d’une qualité homogène sur un domaine étroit, ou d’un déploiement contraint en mémoire.

Les pièges de migration, eux, sont bien identifiés : déséquilibre d’experts non détecté (instrumentez le routage dès le premier jour), hotspots GPU sur un cluster mal dimensionné en interconnexion, et dégradation silencieuse en quantification 4 bits sur les experts rares. Ajoutez-en un quatrième, spécifique à 2026 : le mur de mémoire. Trois modèles majeurs publiés le même jour, et pas assez de VRAM sur le marché pour tous les servir confortablement — c’est le vrai sujet de l’année.

Perspectives : vers des MoE plus petits, ou plus intelligents ?

Deux trajectoires se dessinent. La première est celle de la démesure assumée : Mistral Large 4 et ses 1 000 milliards de paramètres, Muse Spark Open et ses 816 milliards, avec des ratios d’activation qui restent sagement autour de 5 %. La seconde est celle de la sobriété : Aleph Alpha Kolibri-1, 78,1 milliards de paramètres dont 3,46 milliards actifs, licence Apache 2.0, contexte d’un million de tokens, publié le 3 octobre 2026 — la démonstration qu’un MoE bien proportionné peut viser l’usage professionnel sans exiger un datacenter. Entre les deux, la question n’est plus « quel est le plus gros ? » mais « quel est le plus adapté à mon régime de charge ? ». C’est moins spectaculaire, et c’est probablement le signe que la technologie est devenue adulte.

Sources

• AI at Meta — annonce de Muse Spark Open (X)
• Meta Releases Muse Spark Open: 816B Open-Weight MoE With 1M Context — MarkTechPost (15 oct. 2026)
• Meta lance Muse Spark Open : MoE de 816 milliards, contexte 1M — iaexpertos.net (16 oct. 2026)
• Meta Muse Spark Open: 816B MoE & 1M Context Guide — ireadcustomer.com (16 oct. 2026)
• 816B, 560B, 120B en un jour : la vague open-weight se heurte à un mur de mémoire — the-agent-report.com (16 oct. 2026)
• How to Use Muse Spark Open: A Practical Guide — Hugging Face (16 oct. 2026)
• llm-d 1.0 Advances Open, Cost-Efficient AI Inference for Production Scale — IBM Newsroom (20 oct. 2026)
• vLLM et SGLang sur TPU — Google Developers Blog, via note.com (20-21 oct. 2026)
• Mistral Large 4, le modèle à 1 000 milliards de paramètres — Korben (7 oct. 2026)
• Sortie de Mistral Large 4 : aperçu API et poids — NeoTeo (7 oct. 2026)
• Open-Weight LLMs 2026: DeepSeek, Qwen, Kimi, GLM, Llama — wavect.io
• The Best Open-Source and Open-Weight LLMs in 2026 — ZenMux
• Open-Weights LLM Release History and Timeline — hidekazu-konishi.com
• Documentation technique tokios (routage top-k, experts partagés, DeepSeek-V3 671B/37B) et référentiels topai-tools — sources tierces uniques, à recouper.

Article recherché et rédigé automatiquement · Magazine Electrosens