💬 NLP

MoE-Prism: Disentangling Monolithic Experts for Elastic MoE Services via Model-System Co-Designs

MoE-Prism est un cadre de co-conception modèle-système qui permet l'élasticité du calcul au niveau de la requête dans le service de Mixture-of-Experts (MoE) en décomposant les experts monolithiques en sous-experts granulaires et en implémentant un runtime $k$ -aware, améliorant ainsi considérablement le débit et réduisant la latence pour les charges de travail hétérogènes.

Auteurs originaux : Xinfeng Xia, Xiaofeng Hou, Jiacheng Liu, Wenfeng Wang, Mingxuan Zhang, Peng Tang, Chao Li, Minyi Guo

Publié 2026-08-11

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Xinfeng Xia, Xiaofeng Hou, Jiacheng Liu, Wenfeng Wang, Mingxuan Zhang, Peng Tang, Chao Li, Minyi Guo

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous dirigez une bibliothèque massive et super intelligente où les livres ne sont pas écrits par des humains, mais par un cerveau numérique géant appelé Modèle de Langage Étendu (LLM). Ces cerveaux deviennent de plus en plus grands et intelligents chaque jour, mais ils sont aussi incroyablement gourmands en électricité et en puissance informatique. Pour les rendre plus rapides et moins coûteux à exploiter, des scientifiques ont inventé une astuce ingénieuse appelée « Mixture-of-Experts » (MoE - Mélange d'Experts). Considérez un modèle MoE non pas comme un seul cerveau géant, mais comme une équipe de nombreux spécialistes plus petits travaillant ensemble. Lorsque vous posez une question, le système ne réveille pas toute l'équipe ; il fait simplement appel à quelques experts spécifiques qui sont les plus compétents sur ce sujet. C'est comme demander à un bibliothécaire de n'aller chercher des livres que dans la section « Science-Fiction » plutôt que de déplacer toute la bibliothèque jusqu'à votre bureau.

Cependant, il y a un bémol. Actuellement, ces systèmes sont un peu rigides. Que vous posiez une question simple comme « Quel temps fait-il ? » ou une question complexe comme « Analysez ce contrat juridique de 50 pages », le système réveille souvent exactement le même nombre d'experts. C'est comme embaucher toute une équipe de construction pour accrocher un simple cadre, ou envoyer un seul stagiaire pour construire un gratte-ciel. Cela gaspille de l'énergie pour les tâches faciles et ne donne pas assez de puissance pour les tâches difficiles. La grande question que se posent les chercheurs est la suivante : pouvons-nous rendre ces équipes d'IA plus flexibles, en nous permettant de moduler à la hausse ou à la baisse le nombre d'experts en fonction de la difficulté réelle de la tâche, tout en maintenant la rapidité et l'efficacité du système ?

C'est précisément ce que les chercheurs derrière MOE-PRISM ont cherché à résoudre. Ils ont réalisé que, si l'idée de « moduler » les experts semble excellente, la technologie actuelle est trop maladroite pour le faire de manière fluide. Ils ont découvert que le système existant traite chaque expert comme une brique géante et indivisible — on ne peut pas utiliser une demi-brique. Si vous avez besoin d'un peu moins de puissance, vous devez retirer un expert entier, ce qui constitue un saut énorme qui gâche souvent la qualité de la réponse. De plus, lorsque le système tente de gérer de nombreuses requêtes à la fois (comme une bibliothèque très fréquentée), il a tendance à toutes les regrouper et à utiliser le réglage le plus élevé pour tout le monde, gaspillant ainsi de l'énergie pour les tâches faciles juste pour maintenir la taille du lot (batch size).

Pour corriger cela, l'équipe a construit un nouveau cadre appelé MOE-PRISM. Ils ont abordé le problème sous deux angles : le « modèle » (le cerveau lui-même) et le « système » (le gestionnaire de la bibliothèque).

D'abord, du côté du modèle, ils ont inventé un moyen de briser ces « briques d'experts » géantes en morceaux plus fins et plus petits. Imaginez prendre un gros bloc de fromage lourd et le couper en petits cubes. Ils ont fait cela en observant comment les neurones internes de l'IA (les minuscules unités de traitement à l'intérieur d'un expert) s'activent lorsqu'elle travaille. Ils ont remarqué que pour n'importe quelle tâche donnée, seul un sous-ensemble spécifique de ces neurones est réellement important. Ils ont donc découpé les experts en « sous-experts » plus petits qui regroupent ces neurones importants. Cela permet au système de choisir, par exemple, 12,5 sous-experts au lieu d'être contraint de choisir entre 12 ou 13 experts entiers. Cela leur donne un « curseur » beaucoup plus précis pour contrôler la quantité de puissance de calcul utilisée, sans avoir besoin de réentraîner l'IA entière à partir de zéro.

Ensuite, du côté du système, ils ont créé un « gestionnaire » plus intelligent pour la bibliothèque. Au lieu de simplement jeter toutes les requêtes dans un grand tas et d'utiliser le réglage le plus élevé pour tout le monde, ce nouveau gestionnaire regroupe les requêtes qui nécessitent des quantités de puissance similaires. Si un groupe de questions faciles arrive, elles sont traitées ensemble avec un réglage de faible puissance. Si un groupe de questions difficiles arrive, elles reçoivent leur propre groupe de haute puissance. Cela empêche le système de gaspiller de l'énergie en sur-servant les tâches faciles juste pour maintenir le lot complet. Ils ont également construit un « contrôleur de trafic » spécial qui gère efficacement les graphiques informatiques (graphiques CUDA), garantissant que même avec tous ces réglages différents, le système ne soit pas ralenti par des problèmes de mémoire.

Lorsqu'ils ont testé MOE-PRISM sur trois modèles d'IA populaires, les résultats ont été prometteurs. Ils ont constaté qu'en utilisant ces experts plus fins et cette planification plus intelligente, ils pouvaient augmenter le nombre de « réglages de puissance » disponibles par 4 fois. Dans leurs tests, cela a conduit à une amélioration de 33,9 % du nombre de requêtes que le système peut traiter simultanément (débit) pour les tâches hors ligne. Pour les tâches en ligne, où la vitesse est critique, cela a réduit le temps nécessaire pour obtenir le premier mot d'une réponse (Time-to-First-Token) lors de la gestion de charges de travail mixtes.

L'article suggère que cette approche ne permet pas seulement d'économiser de l'argent sur l'électricité ; elle rend l'IA plus adaptable. Elle prouve que vous pouvez avoir un modèle d'IA unique qui est « élastique », capable d'étirer sa puissance de calcul pour les tâches difficiles et de la réduire pour les tâches faciles, le tout sans se ruiner ni ralentir. Bien que les tests actuels aient été effectués sur des configurations spécifiques avec deux cartes graphiques, les résultats indiquent que ce « remodelage » de la structure interne de l'IA et cette « réflexion » sur la manière de planifier son travail pourraient constituer une étape majeure vers une IA plus efficace et flexible dans le monde réel.

Résumé Technique : MOE-PRISM

1. Énoncé du Problème

Les architectures Mixture-of-Experts (MoE) sont devenues centrales pour les grands modèles de langage (LLM) afin d'augmenter la capacité sans augmenter proportionnellement la charge de calcul. Cependant, les systèmes de service MoE existants exécutent généralement toutes les requêtes sous une configuration de routage fixe (un top- $k$ statique), échouant ainsi à exploiter l'hétérogénéité des exigences de calcul entre les différentes requêtes. Bien que certaines approches parviennent à une « élasticité de calcul au niveau de la requête » en cascade de plusieurs modèles ou en utilisant des mécanismes de sortie anticipée (early-exit), ces méthodes introduisent des coûts de mémoire/déploiement importants ou nécessitent des changements architecturaux et un entraînement spécialisés.

Le papier identifie deux lacunes primaires empêchant une élasticité efficace au niveau de la requête au sein d'une seule instance MoE :

Unités de Routage à Grain Grossier : Le routage MoE natif traite les experts entiers comme des unités indivisibles. Réduire le budget de routage $k$ d'une unité supprime un expert entier, provoquant une chute discrète et brutale de la qualité du modèle et limitant les points de fonctionnement disponibles dans l'espace d'échange entre qualité et calcul.
Batching Hétérogène Inefficace : Les systèmes de service comme vLLM utilisent le batching continu. Lorsque des requêtes avec des budgets de routage différents sont mélangées, le système exécute généralement le batch au $k$ maximum demandé pour garantir la qualité, ce qui entraîne un « sur-service » (over-serving) et un gaspillage de calcul. Inversement, diviser les batches pour préserver les budgets fragmente l'exécution, réduisant ainsi le débit (throughput).

2. Méthodologie : MOE-PRISM

MOE-PRISM est un cadre de support modèle et système conçu pour permettre l'élasticité de calcul au niveau de la requête au sein d'une seule instance de service MoE. Il répond au problème via deux composants co-conçus :

A. Moteur de Refactorisation de Modèle (Côté Modèle)

Ce composant transforme le modèle pour exposer un spectre plus dense de points de fonctionnement de routage sans nécessiter de réentraînement de bout en bout.

Décomposition d'Experts : Le moteur profile les activations neuronales intermédiaires sur des données de calibration. Il observe que la masse d'activation au sein d'un expert est concentrée dans des sous-ensembles de neurones dépendants des tokens.
Partitionnement de Sous-Experts : En utilisant un solveur d'optimisation de partition (initialisation gloutonne suivie par recuit simulé), chaque expert monolithique est découpé en $N$ sous-experts plus fins et disjoints. Le partitionnement vise à regrouper les neurones qui co-activent à travers les tokens, garantissant que le saut d'un sous-expert minimise la perte de qualité.
Reconstruction de la Porte (Gating) : Le système reconstruit l'interface de routage pour les nouveaux sous-experts via deux voies :
1. Proxy sans Entraînement : Un mécanisme de sélection hiérarchique qui utilise les statistiques de co-activation pour scorer les sous-experts, permettant un déploiement immédiat.
2. Fine-Tuning de la Porte Uniquement : Une adaptation à faible coût où seuls les poids du routeur sont affinés (le reste du modèle étant gelé) pour s'aligner avec l'espace étendu des sous-experts, maximisant la fidélité.

B. Runtime de Service Sensible au $k$ (Côté Système)

Ce composant gère efficacement l'exécution de budgets de routage hétérogènes.

Planificateur de Service Sensible au $k$ :
- Hors-ligne (Orienté Débit) : Utilise une séparation temporelle via un batching par paliers de qualité. Les requêtes sont triées par leur budget de routage ( $k$ ) et regroupées en paliers. Le planificateur décide de dispatcher un batch résiduel immédiatement ou de le fusionner avec le palier suivant selon une heuristique de débit locale, minimant le sur-service tout en maintenant la complétude du batch.
- En Ligne (Sensible à la Latence) : Utilise une séparation spatiale via un routage par voies (lanes). Les rangs de parallélisme de données (DP) sont partitionnés en voies « bas- $k$ » et « haut- $k$ » avec une frontière souple et adaptative. Cela empêche le mélange de budgets très différents dans le même flux d'exécution tout en évitant un partitionnement rigide qui pourrait causer des accumulations de files d'attente.
Exécuteur de Graphe Segmenté : Pour gérer l'augmentation des états de routage sans faire exploser l'utilisation de la mémoire des CUDA Graphs, l'exécuteur divise le bloc Transformer à la frontière Attention-MoE.
- Segments d'Attention : Partagés entre les différentes valeurs de $k$ (insensibles au routage).
- Segments MoE : Spécialisés par le budget de routage $k$ (sensibles au routage).
- Cette conception permet au système de conserver l'efficacité des CUDA Graphs tout en supportant une exécution de $k$ dynamique.

3. Contributions Clés

Méthode de Refactorisation de Modèle : Une technique pour décomposer les experts monolithiques en sous-experts et reconstruire le réseau de porte, permettant à un seul modèle d'exposer des points de fonctionnement de routage plus denses. Elle supporte le déploiement sans entraînement et le fine-tuning optionnel de la porte uniquement.
Runtime de Service Sensible au $k$ : Une extension de vLLM qui combine un ordonnancement conscient du budget (séparation temporelle et spatiale) avec une exécution efficace de $k$ dynamique via un exécuteur de graphe segmenté.
Intégration Système et Évaluation : Intégration complète dans vLLM et évaluation sur trois modèles MoE représentatifs (OLMoE, DeepSeek-V2-Lite, Qwen3), démontrant une élasticité pratique.

4. Résultats Expérimentaux

Les auteurs ont évalué MOE-PRISM sur trois modèles en utilisant le framework vLLM sur des GPU A100, RTX A6000 et H800.

Débit (Hors-ligne) : MOE-PRISM a amélioré le débit d'inférence hors-ligne jusqu'à 33,9 % par rapport aux bases de référence. Les gains proviennent à la fois de la capacité d'exécuter un $k$ plus faible (via la refactorisation) et de la capacité du scheduler à grouper les requêtes similaires pour éviter le sur-service.
Latence (En Ligne) : Sous des charges de travail hétérogènes, MOE-PRISM a réduit le Temps de Premier Token (TTFT), particulièrement lors de charges élevées où les bases de référence souffrent de délais de file d'attente et de latence de queue.
Précision : La refactorisation du modèle a largement préservé la précision des modèles originaux. Dans certains cas (ex: OLMoE et Qwen3 à des budgets plus bas), les modèles refactorisés ont atteint une perplexité ou une précision sur les tâches en aval légèrement meilleure, suggérant que la nouvelle structure supporte une sélection d'experts efficace sous contrainte de calcul.
Études d'Ablation :
- Refactorisation : A confirmé que la décomposition à grain fin réduit significativement le dépassement du budget de routage par rapport à l'arrondi à grain grossier.
- Graphe Segmenté : A montré que l'exécuteur réduit l'utilisation de la mémoire du graphe d'environ 84 % (comparé à une approche standard sensible au $k$ ) avec une pénalité de débit négligeable (<0,2 %).
- Ordonnancement (Scheduling) : A démontré que l'exécution de $k$ dynamique seule est insuffisante ; un ordonnancement explicite est requis pour prévenir l'interférence entre les $k$ et réaliser des gains de performance de bout en bout.

5. Signification et Revendications

Le papier affirme que MOE-PRISM démontre la faisabilité pratique de l'élasticité de calcul au niveau de la requête dans le service MoE. En traitant le top- $k$ de routage comme un bouton de contrôle au runtime plutôt que comme un paramètre architectural fixe, le système peut :

Servir des requêtes avec des exigences de qualité/calcul variables au sein d'une seule instance de modèle déployée.
Traduire des budgets de routage hétérogènes en améliorations tangibles de la latence et du débit de bout en bout.
Éviter les coûts de mémoire et de déploiement associés à la cascade de plusieurs modèles.

Les auteurs notent une limite : l'évaluation est actuellement restreinte à des bancs d'essai à deux GPU, ce qui représente l'environnement minimal non trivial pour valider le mécanisme central. Ils ne prétendent pas une scalabilité immédiate vers des clusters massifs sans ingénierie supplémentaire, mais les résultats établissent les principes fondamentaux de co-conception modèle-système pour un service MoE élastique.