MoE en production : quand l'all-to-all dépasse la lecture des poids

Un mixture-of-experts ne supprime pas le coût, il le déplace deux fois : du calcul vers la mémoire, puis de la mémoire vers le réseau. Le second basculement a un seuil, il se calcule, et c'est lui qui décide de votre topologie.

Le chiffre qui sert d’argument

Un se vend avec un seul chiffre, et ce chiffre est un rapport. DeepSeek-V4-Pro embarque 1 600 milliards de paramètres et n’en active que 49 par token. GLM-5.2 en contient 744 et en réveille une quarantaine. Qwen3.5-397B-A17B pousse la logique plus loin encore : 512 experts par couche, dix sélectionnés à chaque token. L’argument commercial tient en une ligne, et il est séduisant. Vous payez le calcul de 49 milliards de paramètres, vous obtenez la capacité de 1 600.

Modèle	Total	Actifs	Experts routés	Top-k	Taille d'un expert
DeepSeek-V4-Pro	1,6 T	49 B	384	6	66,1 M
Kimi-K2.6	~1 T	32 B	384	8	44,0 M
GLM-5.2	744 B	~40 B	256	8	37,7 M
Qwen3.5-397B-A17B	397 B	17 B	512	10	12,6 M
DeepSeek-V3.2	671 B	37 B	256	8	44,0 M

Valeurs lues directement dans les config.json le 28 juillet 2026. La taille d'un expert est calculée à partir de ces fichiers (3 × dimension cachée × dimension intermédiaire, structure SwiGLU), non reprise d'une communication d'éditeur.

Ce rapport n’a cessé de grimper. Mixtral-8x7B ouvrait la voie fin 2023 avec un facteur 3,6 entre le total et l’actif. DeepSeek-V3 le portait à 18 un an plus tard. DeepSeek-V4-Pro atteint 32,7 aujourd’hui, Kimi K2.6 le talonne à 31,2. Autrement dit : en trente mois, la part du modèle qui travaille sur un token donné est passée de plus d’un quart à trois pour cent.

Il faut dire d’où vient cette architecture, parce que ça évite un contresens répandu. Le MoE n’a pas été inventé pour rendre le service moins cher. Il a été inventé pour l’entraînement, et les lois d’échelle sur les modèles routés le disent sans ambiguïté : à budget de calcul d’entraînement fixé, un modèle routé apprend mieux qu’un modèle dense, et l’écart se creuse quand on monte en taille. DeepSeekMoE le résume par un chiffre : avec 39,6 % du calcul, leur modèle de 16 milliards de paramètres dépasse LLaMA2 7B sur la majorité des tests. Le service, lui, hérite de la décision. Il fait avec.

Or ce rapport de 32,7 décrit l’arithmétique d’une passe avant. Il ne dit rien de ce qui traverse votre bus mémoire, et rien du tout de ce qui traverse votre réseau. Dès que le modèle ne tient plus sur un GPU, ce sont pourtant ces deux trajets qui fixent votre débit, pas le compte des multiplications.

Tout le monde ayant servi un gros MoE en production connaît le coût de communication qui vient avec. Le éparpille les experts sur les GPU, et il faut donc, à chaque couche, expédier chaque token vers les machines qui détiennent les experts qu’il a choisis, puis rapatrier les résultats. Ce trafic existe, il est mesurable, et il est cité un peu partout comme le problème du MoE.

Sauf que ce n’est pas le premier coût que vous rencontrez, et ce n’est pas toujours celui qui domine. Il existe un régime où ce trafic est négligeable, et un autre où il commande tout. La frontière entre les deux se calcule. C’est ce que fait cet article.

Premier déplacement : du calcul vers la mémoire

Commençons par le piège de vocabulaire, parce qu’il contamine presque toutes les comparaisons de coût qu’on lit sur le sujet. Paramètres activés n’est pas paramètres chargés.

Les 49 milliards de paramètres actifs de DeepSeek-V4-Pro décrivent le calcul d’un token. Ils ne décrivent pas ce que votre serveur doit héberger. Le routeur peut désigner n’importe lequel des 384 experts d’une couche, et il change d’avis à chaque token. La totalité des 1 600 milliards de paramètres doit donc être résidente, en permanence, quelque part où le GPU peut y accéder. En cela représente environ 1 600 Go, en 4 bits environ 800. Vous ne servez pas un modèle de 49 milliards de paramètres qui aurait de bonnes manières. Vous servez un modèle de 1 600 milliards dont vous ne lisez qu’une fraction à la fois.

Cette fraction, justement, dépend du batch, et c’est là que la mécanique devient intéressante. À batch 1, un token traverse ses six experts et vous ne lisez que ceux-là : le trafic mémoire par token vaut à peu près les 49 milliards de paramètres activés. Servez maintenant un millier de requêtes en parallèle. Le routage n’a aucune raison de les envoyer vers les mêmes experts, et il ne le fait pas. Sur 384 experts par couche et six tirages par token, un lot de cette taille finit par toucher tout le monde. Vous relisez la quasi-totalité du modèle à chaque pas, mais vous la relisez une seule fois pour tout le lot. Le coût mémoire par token, lui, s’écroule : il vaut le poids total divisé par la taille du batch.

C’est un point qu’on peut vérifier sans instrumenter quoi que ce soit, en regardant ce qui se passe à l’autre bout du spectre matériel. Quand on décharge les experts vers la mémoire CPU pour servir un gros MoE sur une machine raisonnable, KTransformers publie ses débits de décodage.

Modèle	Paramètres actifs	Matériel	Décodage (tokens/s)
Qwen3.5-35B-A3B	3 B	4× RTX 5090	97,5
Qwen3.5-397B-A17B	17 B	4× RTX 5090	34,0
Kimi-K2.6	32 B	4× RTX 5090	29,1
DeepSeek-V4-Pro	49 B	2× RTX 5090	5,6

Relevés sur le tableau de bord public KTransformers, consulté le 28 juillet 2026. Les deux modèles Qwen3.5 partagent la même précision et le même nombre de GPU, ce qui en fait la seule comparaison réellement contrôlée du tableau.

Prenez les deux modèles de la même famille, même précision, même nombre de GPU. Leurs totaux diffèrent d’un facteur 11. Leurs paramètres actifs, d’un facteur 5,7. Leurs débits, d’un facteur 2,9. Le débit ne suit exactement aucun des deux, et les coûts fixes de chaque pas expliquent qu’il reste en deçà du rapport des actifs. Mais il en suit clairement l’échelle, et pas celle des totaux : c’est ce qui compte ici. Descendez encore la même échelle et DeepSeek-V4-Pro, avec ses 49 milliards actifs, tombe à 5,6 tokens par seconde.

Rien ne circule ici sur un réseau : tout se joue entre la DDR et le processeur. Le débit suit ce qu’il faut lire par token, et ce qu’il faut lire par token suit les paramètres actifs. Le régime est limité par la bande passante mémoire, et il se voit à l’œil nu.

Ce que l’on observe sur une station de travail vaut aussi en salle machine. Les travaux de NVIDIA sur les architectures MoE latentes le formulent sans détour : en service à faible latence, l’inférence d’un MoE est dominée par le coût de bande passante mémoire du chargement des poids. Pas par la communication.

Le premier déplacement du coût est donc là, et il n’a rien à voir avec le réseau. Le MoE vous fait économiser du calcul et vous le refacture en mémoire : en capacité d’abord, puisqu’il faut loger 1 600 Go quelque part, en bande passante ensuite, puisqu’il faut relire ces poids à chaque pas. C’est la raison pour laquelle DeepSeek-V4-Pro tient sur un nœud de huit B200 mais déborde d’un tiroir NVL4 sur GB200, où il en occupe deux. Et c’est la raison pour laquelle il ne rentre pas du tout sur huit RTX PRO 6000 de 96 Go.

Second déplacement : un trafic qui ne s’amortit jamais

Regardons maintenant ce qui traverse le réseau, et surtout comment ça se comporte quand le batch grandit.

Une couche MoE en parallélisme d’experts effectue deux collectives, et deux seulement. Le dispatch envoie l’état caché de chaque token vers les GPU qui détiennent les experts que le routeur a choisis pour lui. Le combine ramène les sorties de ces experts vers le GPU d’origine, où elles sont pondérées et recombinées. Rien d’autre ne bouge.

Le volume se calcule directement. Sur DeepSeek-V3, un état caché fait 7 168 valeurs, le routeur en sélectionne huit experts, le dispatch part en FP8 (un octet par valeur) et le combine revient en BF16 (deux octets). Un token coûte donc 8 × 7 168 × 3 octets à chaque couche, soit environ 168 Kio. Le modèle compte 58 couches MoE sur 61, ce qui porte la facture à environ 10 Mo par token pour la traversée complète.

Dix mégaoctets, ce n’est pas grand-chose. Mis en regard des 671 Go de poids du même modèle, c’est même dérisoire, et c’est précisément ce qui rend le sujet piégeux. Mais ces deux chiffres ne se comportent pas de la même façon quand la charge monte.

Le trafic de poids se partage. Les 671 Go se lisent une fois par pas et servent à tous les tokens du lot, donc leur coût par token fond à mesure que le batch grandit. Le trafic , lui, appartient à chaque token en propre : l’état caché du token i n’aide en rien le token j, il doit faire le voyage pour lui-même. Doublez le batch et vous doublez exactement le volume échangé. Les 10 Mo par token ne bougent pas d’un octet.

Un coût qui s’amortit, un coût qui ne s’amortit pas. Deux courbes qui n’ont aucune raison de rester parallèles.

Le tableau se complique encore d’un second effet, celui du degré de parallélisme. Plus vous éparpillez les experts sur des GPU nombreux, plus chaque token doit adresser de destinations différentes, et plus la part du trafic qui quitte le domaine rapide pour emprunter le réseau externe augmente.

Degré EP	Dispatch	Combine
EP8	77 µs	114 µs
EP32	155 µs	273 µs
EP64	173 µs	314 µs
EP128	192 µs	369 µs
EP256	194 µs	360 µs

Noyaux basse latence de DeepEP version 1, mesurés sur H800 et ConnectX-7 400 Gb/s, configuration de production DeepSeek-V3/R1 : 128 tokens par lot, dimension cachée 7 168, top-8, dispatch en FP8 et combine en BF16.

Le combine en EP128 est environ 3,2 fois plus lent qu’en EP8, à modèle et à charge identiques. Ces chiffres viennent de la version 1 de la bibliothèque, et c’est une réserve à garder en tête : la version 2 a changé de transport, monte jusqu’à EP2048 et divise par quatre le nombre de multiprocesseurs mobilisés, mais elle a supprimé son mode basse latence à zéro SM et n’a jamais republié ses tables de latence. La version 1 reste la seule référence chiffrée disponible.

Nous avons donc, d’un côté, un coût mémoire qui décroît comme l’inverse du batch. De l’autre, un coût réseau constant par token, qui grimpe avec le nombre de GPU sur lesquels vous étalez vos experts. Ces deux courbes se croisent quelque part. Reste à savoir où.

Où les deux courbes se croisent

Le calcul tient en quatre étapes, et chacune repose sur un chiffre que nous avons déjà posé ou qui se lit dans une fiche technique. Prenons DeepSeek-V3 sur un nœud H800, la configuration pour laquelle les mesures publiques sont les plus complètes.

Premier terme, le réseau. Nous l’avons établi : environ 10 Mo par token pour traverser les 58 couches MoE, dispatch en FP8 et combine en BF16. Ce volume ne dépend pas du batch.

Deuxième terme, la mémoire. Les poids du modèle pèsent 671 Go en FP8. À grand batch, le routage les balaie tous à chaque pas, et cette lecture bénéficie à l’ensemble du lot. Ramené au token, le volume vaut donc 671 Go divisés par la taille du batch.

Troisième étape, le rapport des volumes. 671 milliards d’octets d’un côté, dix millions de l’autre. À batch 1, la mémoire déplace donc environ 67 000 fois plus d’octets que le réseau ; à batch 100, encore 670 fois plus. Appelons cette grandeur le rapport de volumes : il vaut 67 000 divisé par la taille du batch. Il faudrait un batch de 67 000 pour que les deux volumes s’égalisent, ce qui n’arrive dans aucun déploiement réel. Si l’on s’arrêtait aux volumes, l’affaire serait entendue et le réseau ne compterait jamais.

Quatrième étape, et c’est elle qui renverse le résultat : les deux trajets ne se font pas à la même vitesse. Les 671 Go se lisent depuis la , qui sur un H800 débite 3,35 To/s. Les 10 Mo, eux, franchissent l’interconnexion, et DeepEP mesure sur ce même matériel un débit all-to-all utile d’environ 50 Go/s dès que le trafic passe en entre nœuds. Notez que ce sont des débits atteints, pas des vitesses de lien affichées : c’est la seule comparaison honnête. Ce rapport de vitesses vaut environ 67 en faveur de la mémoire.

Les deux temps s’égalisent quand le rapport de volumes descend jusqu’au rapport de vitesses. Le premier vaut 67 000 divisé par le batch, le second vaut 67 : l’égalité s’obtient pour un batch d’environ mille. La coïncidence entre ces deux nombres n’a aucune signification physique, elle rend seulement le calcul agréable à poser.

Le même calcul mené sur du trafic qui ne quitte pas le domaine rapide donne un autre résultat. DeepEP mesure environ 160 Go/s en intranœud sur H800, ce qui ramène le rapport de vitesses à 21, et repousse la bascule vers un batch de trois mille.

Voilà la réponse à la question du titre, et voilà surtout ce qu’elle signifie. En dessous du millier de requêtes simultanées, la lecture des poids domine tellement que le trafic all-to-all disparaît dans le bruit : votre MoE tient sa promesse, il vous fait payer 49 milliards de paramètres au lieu de 1 600 et le réseau ne vous coûte presque rien. Au-dessus, la hiérarchie s’inverse, et chaque GPU supplémentaire sur lequel vous étalez vos experts aggrave le problème au lieu de le diluer.

Reste à savoir si l’ordre de grandeur tient devant les mesures. Il tient, à condition de lire chaque mesure avec son régime, parce que les chiffres publiés vont de 20 % à 79 % et qu’ils ne parlent pas de la même chose. Les travaux sur le parallélisme sémantique mesurent jusqu’à 59,2 % de la latence des couches d’experts sur huit GPU. COMET, chez ByteDance, relève 47 % du temps d’exécution complet du modèle. Tous ces points tombent dans la zone haute, celle où le batch et l’étalement sont suffisants pour que le réseau ait pris le dessus.

Une mesure mérite qu’on s’y arrête, parce qu’elle nuance la nature du coût. UBEP, sur DeepSeek-R1 et V3.2 en décodage réparti sur 128 rangs, relève que la communication occupe environ la moitié du temps écoulé pour produire un token. Mais le matériel réseau, lui, n’est réellement occupé à transférer qu’un cinquième du temps. La différence est de l’attente : les GPU patientent qu’une dépendance se libère, ils ne transmettent pas. La distinction compte pour qui doit décider quoi acheter, parce qu’elle dit que sur cette configuration, davantage de bande passante ne réglerait qu’une partie du problème.

La mesure qui isole le mieux la variable qui nous intéresse vient pourtant de l’entraînement, et non du service. Megatron-Core rapporte que l’all-to-all consomme environ 20 % du temps quand le parallélisme d’experts reste à l’intérieur d’un domaine , contre 40 à 60 % lorsqu’il franchit les nœuds. Même modèle, même degré d’EP64, seule la topologie change, et la part du réseau double ou triple.

Et si vous voulez la démonstration par l’absurde, elle existe en production : certains fournisseurs servent DeepSeek V3 et R1 sur un unique nœud H200 ou B200. Tout le trafic reste alors sur les liens internes, l’InfiniBand ne voit rien passer, et le problème que tout le monde décrit comme intrinsèque au MoE s’évanouit. Si le MoE était par nature un problème de réseau, ce déploiement serait impossible. Il tourne.

Pourquoi la topologie décide à votre place

Le chiffre de mille tokens n’est pas une constante de la nature. Il dépend de la vitesse à laquelle vos GPU se parlent, et cette vitesse ne varie pas continûment : elle tombe d’une falaise à un endroit précis.

À l’intérieur d’un domaine NVLink, tous les GPU sont reliés par un maillage commuté. Un Hopper y dispose de 900 Go/s de lien, un Blackwell de 1,8 To/s grâce à ses dix-huit liens à 100 Go/s. Franchissez la frontière du domaine et le trafic bascule sur les cartes réseau : un ConnectX-7 offre 400 Gb/s par port, dont DeepEP tire environ 50 Go/s utiles en all-to-all.

Comparer ces deux familles de chiffres demande de la prudence, parce que les premiers sont des vitesses de lien annoncées et le dernier un débit réellement atteint. À débits atteints, seule comparaison rigoureuse, l’écart mesuré par DeepEP entre l’intérieur d’un nœud H800 et le réseau externe est d’environ 160 Go/s contre 50, soit un facteur trois. Rapportées aux vitesses de lien affichées des générations récentes, les deux grandeurs s’écartent d’un facteur supérieur à trente, mais on ne compare alors plus la même chose. Retenez le facteur trois, il suffit largement à l’argument.

Reste à savoir où passe cette frontière, et la réponse est brutalement concrète. Sur une baseboard HGX classique, le domaine s’arrête à huit GPU. Un GB200 NVL72 le porte à 72, reliés par neuf tiroirs de commutateurs pour 130 To/s agrégés, et l’architecture autorise jusqu’à 576 GPU dans un même domaine. La génération Rubin annonce 3,6 To/s par GPU et 260 To/s par NVL72 pour le second semestre 2026, chiffre constructeur qu’aucun déploiement public ne permet encore de vérifier.

Ce que cela change pour vous se formule simplement : votre degré de parallélisme d’experts ne se choisit pas dans l’absolu, il se choisit par rapport à la taille de votre domaine. DeepSeek sert son étage de décodage en EP144 réparti sur dix-huit nœuds, donc chaque all-to-all traverse forcément le réseau externe. Le même EP144 sur deux NVL72 accolés garderait la moitié du trafic à l’intérieur. Et un EP72 tenant dans un seul NVL72 n’en sortirait jamais.

Reprenez alors le calcul de la section précédente en remplaçant les 50 Go/s par les débits d’un domaine élargi, et le batch de bascule se déplace vers le haut. C’est tout l’argument économique du NVL72, et c’est celui qui donne son enjeu à la bataille des liens rapides : 200G, ratifiée en avril 2025, vise 1 024 accélérateurs par pod avec une sémantique mémoire de type load/store, pour du matériel attendu fin 2026. Le vainqueur de cette bataille ne gagnera pas des points de benchmark. Il déplacera le seuil à partir duquel servir un MoE devient un problème de réseau. Nous avons détaillé ce duel dans notre comparaison entre le MI455X et Rubin.

Le déséquilibre, et pourquoi il frappe le prefill

Il reste un coût dont nous n’avons pas parlé, et il ne se lit sur aucune fiche technique. Le routeur ne distribue pas les tokens équitablement.

Voici ce qui se passe concrètement. À chaque couche, chaque GPU calcule les experts qu’il héberge, puis tout le monde se retrouve au combine pour recomposer les sorties. Ce rendez-vous est une barrière : la couche n’avance que lorsque le dernier GPU a terminé. Si un expert populaire reçoit trois fois plus de tokens que la moyenne, le GPU qui l’héberge met trois fois plus de temps, et tous les autres l’attendent. La latence de la couche n’est pas fixée par la charge moyenne, elle est fixée par le rang le plus chargé.

Les mesures d’UltraEP donnent l’ampleur du phénomène. En EP64, le rapport entre la charge du rang le plus sollicité et la charge moyenne va de 1,30 à 4,01 selon le modèle et le type de trafic, et leur système le ramène à 1,01. Un facteur 4 signifie que vous payez quatre GPU pour le travail d’un. Descendez au niveau de l’expert individuel plutôt qu’à celui du rang, et sur Qwen3-235B le rapport maximum sur moyenne s’étale entre 10 et 20 selon la couche et le domaine des requêtes.

Ce déséquilibre a une cause architecturale que nous avons croisée plus haut sans la nommer. La tendance du moment n’est pas seulement « plus de paramètres totaux », c’est « beaucoup de petits experts » : DeepSeek-V4-Pro aligne 384 experts de 66 M contre les 8 experts de 176 M de Mixtral. Plus les experts sont fins et nombreux, plus le routage se spécialise, et plus la distribution des charges s’écarte de l’uniforme.

On pourrait croire le problème réglé par le profilage : mesurez quels experts sont populaires, dupliquez-les sur plusieurs GPU, et l’équilibre revient. C’est exactement ce que fait , l’équilibreur de DeepSeek, et il fonctionne : à grande échelle il apporte 1,49× en et 2,54× en . Le détail est astucieux, puisqu’ajouter 32 experts redondants aux 256 d’origine libère au passage les degrés de parallélisme des puissances de deux et autorise des configurations en 12 ou en 72.

Sauf que le profilage suppose que le passé prédit le présent, et ce n’est pas le cas. ReLibra a mesuré le taux d’intersection entre les experts les plus chargés de deux micro-lots consécutifs, sur trois modèles de 30 à 235 milliards de paramètres. Ce taux reste sous 0,5 dans la plupart des configurations testées : d’un micro-lot au suivant, plus de la moitié du jeu d’experts chauds a changé. Vous équilibrez pour une distribution qui n’existe déjà plus.

Le déséquilibre ne coûte pas que du temps. Sans équilibrage, le pic de mémoire d’activation des couches MoE monte à deux fois ce qu’il serait à charge parfaitement répartie en entraînement, et onze fois en service. Ce n’est plus une question de latence, c’est une question de savoir si votre batch tient en mémoire. Vous pouvez donc perdre le débit non pas parce que vos GPU attendent, mais parce que vous avez dû réduire le batch pour éviter l’OOM.

Une dernière chose, et elle recolle à l’axe de l’article. Le prefill est la source principale de ce déséquilibre. En décodage, où le régime est limité par la mémoire, l’écart de charge côté calcul se dilue dans la latence des accès : les GPU attendaient déjà la HBM, un peu de travail en plus ne change pas grand chose. Si votre trafic est dominé par du décodage à petit batch, le déséquilibre vous coûte nettement moins cher que ce que la littérature laisse croire.

Un mot d’honnêteté pour finir : tout ce que nous venons de citer porte sur DeepSeek-V3, Qwen3-235B, GLM-4.5 et Mixtral. Personne n’a publié de mesure de déséquilibre sur DeepSeek-V4, GLM-5.2, Kimi K2.6 ou Qwen3.5-397B, c’est-à-dire précisément les modèles à 384 et 512 experts où le phénomène devrait être le plus marqué. Nous décrivons une tendance sur la génération précédente, et nous extrapolons.

Ce qui rend la disaggregation obligatoire

Tout ce qui précède converge vers une conclusion d’architecture, et il se trouve qu’une contrainte logicielle très concrète l’impose de toute façon.

Les deux familles de noyaux de DeepEP ne servent pas le même régime. Les noyaux normaux visent le débit et acceptent d’occuper des multiprocesseurs ; les noyaux basse latence passent en RDMA pur pour les petits lots du décodage. Ces deux modes ne coexistent pas dans un même groupe de communication. Vous ne pouvez donc pas servir prefill et décodage dans la même instance sans sacrifier l’un des deux. La n’est pas une optimisation que l’on ajoute quand on a le temps : c’est la conséquence directe du fait que les deux phases vivent dans des régimes opposés. Nous avions suivi sa sortie du papier vers la production dans un précédent dossier.

Le déploiement de référence le montre. DeepSeek sépare un étage de prefill en EP32 sur quatre nœuds, avec neuf experts routés et un partagé par GPU, d’un étage de décodage en EP144 sur dix-huit nœuds, avec deux experts routés et un partagé par GPU. Sur une journée de fin février 2025, l’ensemble a mobilisé 278 nœuds au pic et 226,75 en moyenne, pour un coût quotidien estimé à environ 80 100 euros au tarif de deux dollars par GPU-heure. SGLang a reproduit l’architecture sur 96 H100 et publie 22 282 tokens par seconde et par nœud en décodage, pour 0,184 euro par million de tokens de sortie, soit environ le cinquième du tarif de l’API officielle.

Le recouvrement calcul-communication obéit à la même logique de régime, et c’est peut-être la démonstration la plus nette de tout l’article. Le two-batch overlap de SGLang consiste à découper le lot en deux pour masquer la communication de l’un derrière le calcul de l’autre. À batch 256, il donne 25,5 % de débit supplémentaire en décodage. À batch 32, il en retire 27 %. La même optimisation, sur le même code, améliore ou dégrade selon le seul paramètre dont nous parlons depuis le début. En dessous de 64 à 128 tokens par device, il n’y a rien à recouvrir : la communication n’est pas le goulot, et découper le lot ne fait que diviser le travail utile.

Pour qui règle un serveur, voici où ça se joue.

Ce que vous réglez	vLLM	SGLang
Activer le parallélisme d'experts	--enable-expert-parallel	--ep
Choisir le transport	--all2all-backend	--moe-a2a-backend
Régime du transport	deepep_high_throughput ou deepep_low_latency	--deepep-mode normal ou low_latency
Recouvrement calcul-communication	--enable-dbo	--enable-single-batch-overlap
Équilibrage des experts	--enable-eplb	--enable-eplb

vLLM signale que ces options restent expérimentales et que leurs noms peuvent changer. Côté SGLang, une limite documentée surprend beaucoup de monde en production : avec DeepEP, Mooncake, NIXL-EP ou MORI, le degré de parallélisme d'experts doit égaler le degré tensoriel.

La dernière ligne du tableau des régimes est la traduction en ligne de commande de tout ce paragraphe : en disaggregation, l’instance de prefill tourne en mode normal et celle de décodage en mode basse latence. Ces réglages remontent d’un cran quand une couche d’orchestration s’en mêle, sujet que nous avons traité à part avec Infera, Dynamo et llm-d.

Un avertissement pour finir : le parallélisme d’experts à grande échelle a un seuil de rentabilité. Sur un modèle modeste avec peu d’experts, le surcoût de communication l’emporte sur le gain de chargement des poids, et étaler davantage vous ralentit. NVIDIA le dit dans sa propre documentation. Ce mode ne se déploie pas parce qu’on en a les moyens, il se déploie quand le régime le justifie.

La sparsité finit toujours par ressortir

Un rapport de 32,7 entre paramètres totaux et paramètres actifs ne reste pas sagement dans la fiche du modèle. Il ressurgit à des endroits qu’on n’attend pas, et il vaut la peine de finir par deux d’entre eux.

Les experts concentrent 95 à 97 % des poids d’un MoE moderne. La conséquence tient en une phrase : tout le monde quantifie les experts, et rien d’autre. Kimi K2.6 est distribué en INT4 avec exclusion explicite de l’attention, des experts partagés et de la tête de sortie. DeepSeek-V4 porte dans sa configuration un champ expert_dtype en FP4, distinct de la FP8 globale du reste du modèle. Les checkpoints NVFP4 publiés par NVIDIA pour V4-Pro mettent les experts en NVFP4 et gardent l’attention et les couches denses en FP8. La précision a cessé d’être une propriété du modèle pour devenir une propriété de chaque composant, et c’est la structure du MoE qui l’a imposé.

Le second endroit est plus inattendu. Dans llama.cpp, un lot déclenche le prefill sur GPU à partir de 32 tokens. Dans ik_llama.cpp, quand les experts sont déchargés vers la mémoire CPU, ce seuil devient 32 multiplié par le nombre d’experts totaux et divisé par le nombre d’experts actifs, soit 2 048 tokens pour un modèle en top-6 sur 384. Ce facteur est exactement le rapport de du modèle. Quelqu’un a bien écrit cette formule, évidemment. Mais il ne l’a pas choisie : c’est la seule valeur qui rende l’arbitrage juste, et la géométrie du MoE ressort donc telle quelle dans une constante de runtime.

Reste une piste que personne n’a encore chiffrée, et qui pourrait déplacer le problème du déséquilibre plutôt que le corriger. DeepSeek-V4 fige le routage de trois de ses couches : les indices d’experts n’y sont plus produits par un réseau appris mais lus dans une table gelée, indexée par le token d’entrée. Sur ces couches, la charge de chaque expert devient une fonction déterministe de la distribution des tokens. Elle reste inégale, puisque quelques tokens du vocabulaire reviennent des milliers de fois plus souvent que les autres. Mais elle est connue à l’avance et invariante dans le temps, ce qui signifie qu’un placement optimal se calcule hors ligne, une fois, et ne se périme jamais. Fini le profilage qui court après une distribution déjà changée.

Aucune mesure publique ne dit ce que cette idée rapporte, ni sur combien de couches elle reste compatible avec la qualité du modèle. Si elle tient, elle règle par construction ce que trois années d’équilibreurs tentent de corriger au runtime. C’est la question que nous aimerions voir mesurée avant la prochaine génération.

Sources et méthode

Les montants en dollars sont convertis en euros au taux indicatif de 1 USD = 0,92 EUR (mi-2026). Les chiffres de performance sont rapportés avec leur régime (prefill, décodage ou entraînement), leur taille de lot et leur domaine d’interconnexion, faute de quoi ils ne sont pas comparables entre eux.

Faits vérifiés

Architectures des modèles. Fichiers config.json lus directement sur HuggingFace le 28 juillet 2026 pour DeepSeek-V4-Pro, DeepSeek-V4-Flash, GLM-5.2, Qwen3.5-397B-A17B et Kimi-K2.6. Les tailles d’expert sont calculées à partir de ces fichiers, non reprises d’une communication d’éditeur. Configuration minimale de Kimi-K2.6 : guide de déploiement Moonshot publié dans le dépôt du modèle.

Communication et parallélisme d’experts. Dépôts DeepEP (tables de latence et de débit de la version 1, mesurées sur H800 et ConnectX-7 400 Gb/s), EPLB, LPLB et profile-data. Fractions de communication mesurées : UBEP (arXiv 2607.06202), parallélisme sémantique et spéculatif (arXiv 2503.04398), COMET (arXiv 2502.19811), Lina (arXiv 2210.17223), Megatron-Core (arXiv 2603.07685) pour la comparaison entre domaine NVLink et réseau externe en entraînement.

Déploiements et débits. open-infra-index pour la configuration EP32 en prefill et EP144 en décodage, le nombre de nœuds et le coût quotidien. Billet SGLang du 5 mai 2025 sur le service à grande échelle en parallélisme d’experts (96 H100, EP72 en décodage, two-batch overlap, gains EPLB) et billet du 20 juillet 2025 sur Kimi K2. Documentation vLLM sur le déploiement en parallélisme d’experts et billets techniques de décembre 2025 et février 2026. Documentation SGLang. Blogs techniques TensorRT-LLM et publication NVIDIA du 20 octobre 2025 sur le parallélisme d’experts à grande échelle sur NVL72, y compris le seuil de rentabilité.

Interconnexion. Architectures de référence NVIDIA et page d’architecture Blackwell pour NVLink 4 et 5, la taille des domaines et les débits agrégés du NVL72. Fiche technique ConnectX-7. Spécification UALink 200G 1.0, ratifiée le 8 avril 2025.

Déséquilibre d’experts. UltraEP (arXiv 2606.04101, version 3 du 18 juin 2026) pour les rapports de charge inter-rang et par expert, et pour le constat que le prefill en est la source principale. ReLibra (arXiv 2605.08639) pour l’instabilité du jeu d’experts chauds entre micro-lots. Libra (ICLR 2026, dépôt SNU-ARC/Libra) pour l’aggravation du déséquilibre sur les générations récentes. MoETuner (arXiv 2502.06643) et ReaLB (arXiv 2604.19503) en corroboration.

Régime mémoire. Tableau de bord KTransformers consulté le 28 juillet 2026 et dépôt kvcache-ai/ktransformers. Travaux NVIDIA Nemotron sur les architectures MoE latentes (arXiv 2601.18089) pour la domination du chargement des poids en service à faible latence. Analyse Tensor Economics du 2 septembre 2025 pour le service de DeepSeek sur un unique nœud.

Motivation d’entraînement du MoE. Clark et al., lois d’échelle unifiées pour les modèles routés, ICML 2022 (arXiv 2202.01169). Krajewski, Ludziejewski et al., lois d’échelle pour les MoE à grain fin, ICML 2024 (arXiv 2402.07871). DeepSeekMoE (arXiv 2401.06066).

Estimations crédibles

Le volume all-to-all d’environ 10 Mo par token est un calcul direct à partir de paramètres vérifiés (8 experts sélectionnés, état caché de 7 168 valeurs, dispatch en FP8 et combine en BF16, 58 couches MoE), et non une mesure.

Le batch de bascule d’environ mille en RDMA et trois mille en NVLink est une estimation menée à partir de ces volumes et des débits atteints mesurés par DeepEP sur H800, corrigés par la bande passante HBM3 de 3,35 To/s. Elle suppose des experts saturés, une communication non recouverte par du calcul, et un routage touchant l’ensemble des experts à grand batch. Chacune de ces hypothèses prise en défaut repousse la bascule vers le haut.

Les empreintes mémoire par précision sont calculées par multiplication du nombre total de paramètres par le nombre d’octets, hors cache clé-valeur et hors tampons d’exécution.

Le contraste entre le domaine NVLink et le réseau externe est donné à débits atteints (environ 160 Go/s contre 50 Go/s, mesurés par DeepEP sur H800), et non en rapportant une vitesse de lien annoncée à un débit mesuré. Le rapport supérieur à trente que l’on croise ailleurs compare ces deux natures de grandeur et n’est pas exploitable tel quel.

Le coût quotidien d’environ 80 100 euros repose sur l’hypothèse de deux dollars par GPU-heure retenue par DeepSeek, convertie au taux ci-dessus.

Hypothèses

Le lien entre la granularité croissante des experts (beaucoup de petits experts plutôt que peu de gros) et l’aggravation du déséquilibre est un raisonnement, pas une mesure. La corrélation est cohérente avec les données de Libra et d’UltraEP, mais aucune étude ne l’isole comme variable.

Le bénéfice d’équilibrage attendu du routage hash figé de DeepSeek-V4 est un raisonnement à partir de la structure déclarée dans la configuration du modèle. Aucune mesure publique n’existe.

Ce que nous n’avons pas pu établir

Aucune source primaire de DeepSeek ni de NVIDIA ne publie de fraction chiffrée de communication d’un pas de décodage avec sa configuration complète. Les meilleures approximations disponibles viennent de tiers.

Aucune mesure de déséquilibre d’experts n’a été publiée sur la génération de 2026 (DeepSeek-V4, GLM-5.2, Kimi K2.6, Qwen3.5-397B), précisément les modèles où le phénomène devrait être le plus marqué. Les mesures citées portent sur DeepSeek-V3, Qwen3-235B, GLM-4.5 et Mixtral.

Les chiffres de production publiés par DeepSeek (débits par nœud, coût, proportion de tokens servis par le cache) sont auto-rapportés et n’ont fait l’objet d’aucun audit indépendant. Nous ne reprenons ni la marge de 545 % avancée dans le même document, qui suppose que la totalité des tokens serait facturée au tarif le plus élevé, ni le coût d’entraînement de 5,576 millions de dollars, qui ne couvre que la campagne finale.

Les chiffres de Mixtral-8x7B cités en introduction et dans la section sur le déséquilibre proviennent de l’architecture publiée par Mistral et sont arithmétiquement cohérents, mais leur config.json n’a pas été relu lors de cette campagne de vérification.

La version 2 de DeepEP n’a pas republié ses tables de latence après avoir changé de transport et supprimé son mode basse latence sans occupation de multiprocesseurs. Les chiffres cités sont donc ceux de la version 1.

MoE : à partir de quel batch le réseau prend-il le dessus ?