Inférence MoE par lots : trier ses prompts, +17 % de débit

L'inférence MoE par lots a un coût caché que peu d'équipes mesurent : l'ordre dans lequel vous envoyez vos prompts. Le 19 octobre 2026, une équipe d'ingénieurs publie sur le blog Hugging Face une étude au titre volontairement modeste, « Sort your prompts: a free speed-up for MoE batch inference ». L'idée tient en une phrase : regrouper les prompts qui se ressemblent avant de lancer un job batch. Pas de nouveau serveur, pas de modèle modifié, pas de prédicteur à entraîner. Sur Qwen3-30B-A3B servi par vLLM, le gain mesuré atteint +17,3 % de débit de bout en bout.

Pour une équipe qui fait tourner des évaluations nocturnes, de la génération de données synthétiques ou des traitements documentaires en masse, c'est le genre d'optimisation rare : quelques lignes de Python, aucune dépendance d'infrastructure, et une facture GPU qui baisse. Encore faut-il comprendre pourquoi ça marche, et surtout quand ça ne marche pas.

Le contexte

Un modèle Mixture-of-Experts (MoE) ne mobilise pas tous ses paramètres pour chaque token. Chaque couche contient un ensemble d'« experts » (des sous-réseaux) et un routeur qui choisit, pour chaque token, quelques experts seulement. Qwen3-30B-A3B compte ainsi 128 experts par couche sur 48 couches ; gpt-oss-120b en compte 32. C'est ce qui permet à ces modèles d'être grands en capacité tout en restant raisonnables en calcul.

Le revers est moins connu. Pendant la phase de décodage (la génération token par token), le goulot d'étranglement n'est pas le calcul mais la mémoire : il faut lire les poids des experts depuis la HBM, la mémoire du GPU. Les auteurs le résument ainsi : chaque expert choisi par au moins un token du lot doit être lu depuis la HBM une fois par couche. Autrement dit, plus votre lot touche d'experts distincts, plus vous payez en bande passante, même si chaque expert ne sert qu'à un seul token.

Pourquoi l'ordre des prompts change le coût de l'inférence MoE

Des experts spécialisés par domaine

Le point de départ de l'étude est une observation sur le routage. Les auteurs ont constitué un jeu de 768 prompts répartis sur six domaines : code (MBPP), mathématiques (GSM8K), écriture créative (no_robots), français, arabe et chinois. Résultat : sur Qwen3-30B-A3B, chaque domaine concentre son trafic sur environ 32 experts favoris, soit un quart des 128 disponibles, qui reçoivent 68 à 80 % de ses décisions de routage, contre 25 % si le routage était uniforme.

Conséquence directe : un lot composé uniquement de prompts de code touche moins d'experts qu'un lot qui mélange code, maths et chinois. Les mesures le confirment. Sur Qwen3-30B-A3B, les lots mono-domaine lisent 19 à 25 % d'experts en moins par étape que les lots mélangés, pour toutes les tailles de lot de 8 à 128. Sur gpt-oss-120b, dont les experts sont moins nombreux et donc plus généralistes, l'écart tombe à 8-11 %.

Un coût linéaire, donc prévisible

Deuxième observation, côté noyau GPU : le temps passé dans une couche MoE croît linéairement avec le nombre d'experts distincts touchés. Les auteurs mesurent environ 2,9 µs par expert supplémentaire, ce qui correspond à 9,4 Mo de poids. Pris isolément, c'est minuscule. Multiplié par 48 couches et des centaines de pas de décodage par lot, ça devient une part significative du temps de génération.

Ce que montrent les benchmarks

Les tests ont été menés sur GPU AMD Instinct MI300X, avec vLLM 0.27.1 (ROCm, CUDA graphs activés), chaque prompt générant exactement 256 tokens en décodage glouton. Le scénario de référence est un ordre mélangé ; le scénario testé trie les prompts par domaine.

Sur Qwen3-30B-A3B, le gain de débit est de +13,5 % en lot de 16, +17,3 % en lot de 32, +12,6 % en lot de 64 et +11,6 % en lot de 128. Sur gpt-oss-120b, il va de +6,9 % (lot de 16) à +12,2 % (lot de 32), puis +10,6 % et +9,1 %. Le pic à 32 n'est pas expliqué en détail par l'article, mais la tendance est logique : à très grande taille de lot, même un lot homogène finit par solliciter une grande partie des experts, et la marge d'optimisation se réduit.

Sans étiquettes de domaine

Dans la vraie vie, vos prompts n'arrivent pas étiquetés « code » ou « chinois ». Les auteurs testent deux méthodes pour retrouver les groupes :

• Empreintes du routeur : après le prefill, chaque prompt dispose d'un vecteur décrivant son usage de chaque expert dans chaque couche. Un k-means sur ces vecteurs retrouve les six domaines avec 100 % de pureté et produit les mêmes économies que les vraies étiquettes. Inconvénient : il faut accéder aux décisions internes du routeur.
• Embeddings de texte : on encode les prompts avec Qwen3-Embedding-0.6B, puis on applique un k-means. Cette méthode ne demande rien au modèle MoE, s'exécute avant l'inférence et fonctionne avec n'importe quel modèle.

Sur des données conversationnelles réelles (UltraChat), le clustering par embeddings donne +5,1 à 5,5 % sur Qwen3-30B-A3B et moins de 4 % sur gpt-oss-120b. Plus modeste, mais gratuit. Avec des longueurs de sortie naturelles (arrêt sur EOS, lot de 32), le débit passe de 1 810 à 2 104 tokens par seconde, soit 16,6 % de temps réel gagné dans ce scénario.

Tri par fenêtre et parallélisme d'experts

Deux résultats intéressent directement l'industrialisation. D'abord, il n'est pas nécessaire de trier tout le corpus d'un coup : trier par blocs de 128 prompts donne +11,7 %, par blocs de 256 +14,8 %, contre +17,3 % pour le tri complet des 768 prompts. Une fenêtre de réordonnancement de 4 à 8 lots conserve l'essentiel du gain, ce qui rend la technique compatible avec un traitement en flux. Ensuite, en parallélisme d'experts sur deux GPU, le gain reste de +12,9 % en lot de 64 et +8,7 % en lot de 128.

Les limites à connaître avant de trier ses prompts

L'article est honnête sur ses angles morts, et c'est ce qui le rend utile.

Le gain réel vaut environ la moitié du gain théorique. Un modèle fondé uniquement sur les octets lus prédisait +20 à 27 % pour Qwen. L'écart vient du reste du pipeline : attention, cache KV et échantillonnage ne bénéficient pas du tri.

Les sorties changent. Réordonner modifie la composition des lots, donc les calculs numériques. Les auteurs notent que trier change les sorties à peu près autant qu'un simple remélange : 92 % de sorties identiques pour Qwen face à une base mélangée, et seulement 36 % avec des longueurs de sortie naturelles. Si vos évaluations reposent sur une reproductibilité bit à bit, il faudra figer l'ordre trié lui-même.

Ce n'est pas universel. Les modèles denses, les charges dominées par le prefill, les très grands lots, les MoE à experts peu nombreux et le serving en ligne sensible à la latence en tirent peu ou rien. Pour ce dernier cas, attendre d'avoir des requêtes similaires ajoute de la latence de file d'attente. Les auteurs placent l'usage naturel ailleurs : les jobs batch hors ligne, ou un ordonnanceur qui choisit des requêtes similaires dans sa file d'attente existante.

Enfin, la variance entre exécutions reste inférieure à 1 % pour Qwen mais monte jusqu'à 4 % pour gpt-oss : sur ce modèle, les petits gains méritent d'être mesurés plusieurs fois avant d'être annoncés.

Ce que ça change pour les équipes IA

Pour une équipe MLOps, l'intérêt de cette étude est moins le chiffre de 17 % que la méthode : elle rappelle que l'inférence MoE a un profil de coût différent des modèles denses, et que ce profil se pilote en partie depuis l'application, pas seulement depuis le serveur.

Concrètement, voici comment nous l'aborderions sur un projet client :

1. Cartographier les jobs batch. Évaluations nocturnes, génération de données synthétiques, classification de tickets, extraction documentaire : tout ce qui tourne hors ligne sur un modèle MoE est candidat. Le serving temps réel ne l'est pas.
2. Mesurer avant de trier. Le gain dépend du modèle (nombre d'experts), de la taille de lot et de l'hétérogénéité de vos données. Un corpus déjà homogène (uniquement du code, par exemple) gagnera peu. Lancez le même job en ordre mélangé et en ordre trié, plusieurs fois, et comparez tokens par seconde et temps total.
3. Commencer par les embeddings. C'est la méthode la plus simple à brancher : un petit modèle d'embedding, un k-means, un tri stable, puis la restauration de l'ordre d'origine. Le dépôt publié par les auteurs contient la capture du routage, un simulateur, un noyau Triton et les benchmarks vLLM. L'usage tient en trois lignes :

from sort_prompts import expert_friendly_order

order = expert_friendly_order(prompts, n_clusters=16)   # embed + k-means + stable argsort
outs = llm.generate([prompts[i] for i in order], sampling_params)
outs = [o for _, o in sorted(zip(order, outs))]          # restore original order

4. Traiter la reproductibilité comme une exigence explicite. Si un job sert de référence d'évaluation, versionnez l'ordre des prompts avec le jeu de données. Sinon, un gain de débit peut se payer en résultats qui bougent d'une exécution à l'autre sans que personne ne sache pourquoi.
5. Raisonner en fenêtres. Pour un pipeline en flux, une fenêtre de quelques lots suffit à récupérer la majeure partie du gain. C'est un paramètre à exposer dans votre configuration, au même titre que la taille de lot.

Sur une flotte de GPU facturée à l'heure, 10 à 15 % de débit en plus sur les jobs batch, c'est autant de temps machine libéré, obtenu sans changer de matériel ni de modèle. Et c'est une bonne occasion de remettre de l'observabilité dans des jobs batch souvent lancés à l'aveugle : tokens par seconde, temps par lot, coût par millier de requêtes.

En bref

• Pendant le décodage, un modèle MoE paie en bande passante mémoire chaque expert distinct touché par le lot.
• Trier les prompts par domaine réduit ce nombre d'experts : jusqu'à +17,3 % de débit sur Qwen3-30B-A3B et +12,2 % sur gpt-oss-120b avec vLLM sur MI300X.
• Sans étiquettes, un clustering par embeddings donne +5 % environ sur des données conversationnelles réelles, sans toucher au modèle.
• Les sorties changent comme avec un remélange, et la technique ne vaut rien pour le serving en ligne sensible à la latence.
• Pour l'inférence MoE par lots, c'est une optimisation applicative à tester en priorité sur vos jobs hors ligne.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Jan Antonin Kolar on Unsplash.