Le collectif ne coûte pas seulement ses octets
Dans un MoE Mixture-of-Experts. Architecture où le réseau est découpé en de nombreux « experts » dont un routeur n'active qu'un petit sous-ensemble par token. Le calcul par token suit le nombre de paramètres actifs ; la mémoire, elle, suit le nombre total, car tous les experts doivent rester résidents en VRAM, prêts à être sollicités. Approfondir dans le glossaire , le routeur choisit quelques experts pour chaque token. Le modèle économise du calcul parce qu’il n’active pas tous ses paramètres, mais les poids de tous les experts doivent résider quelque part. Le parallélisme d'experts Mode de découpage d'un MoE où chaque GPU héberge un sous-ensemble des experts, au lieu de recevoir une tranche de chaque matrice comme en parallélisme tensoriel. Le token doit donc voyager jusqu'aux GPU qui détiennent les experts choisis pour lui : la communication devient un all-to-all et non un all-reduce. Souvent abrégé EP. place un sous-ensemble d’experts sur chaque GPU. Les tokens voyagent alors vers les cartes qui possèdent leurs experts, puis les sorties reviennent.
Ce trajet produit deux collectifs all-to-all Collective où chaque rang envoie une donnée distincte à chaque autre rang. Dans une couche MoE en parallélisme d'experts, elle survient deux fois : le dispatch expédie l'état caché de chaque token vers les GPU de ses experts, le combine rapatrie les sorties. Son volume est proportionnel au nombre de tokens, donc il ne s'amortit pas avec la taille du lot. par couche MoE : un dispatch, un combine. Le volume transporté suit le nombre de tokens. Notre analyse du seuil réseau des MoE montre pourquoi ce trafic peut rester secondaire face à la lecture des poids à petit batch. DWDP attaque un autre coût : le rendez-vous.
Dans une exécution qui combine attention data-parallel et experts répartis, chaque rang traite des requêtes différentes. Leurs longueurs, leurs touches de cache et les experts choisis divergent. Un rang termine sa couche avant les autres, mais le collectif suivant l’oblige à attendre le plus lent. Le papier NVIDIA mesure environ 12 % de synchronisation avec un coefficient de variation de 20 % sur les longueurs par rang dans son cas DeepSeek-R1. Le blog TensorRT-LLM associé publie environ 10 % sur une configuration voisine. Cette différence de chiffre entre deux versions de la même étude interdit de le traiter comme une constante ; le mécanisme, lui, ne dépend pas de la valeur exacte.
Réduire la taille des messages ne supprime pas ce rendez-vous. Équilibrer les experts peut rapprocher les temps, sans aligner les longueurs de requêtes ni les touches de cache. DWDP pose donc une question plus radicale : que se passe-t-il si aucun rang n’a besoin d’attendre les tokens des autres ?
Le renversement : attirer les experts vers chaque rang
DWDP signifie Distributed Weight Data Parallelism. L’attention reste en parallélisme de données : chaque GPU conserve son lot de requêtes. Les poids d’attention sont répliqués ; les poids des experts, qui dominent la taille d’un grand MoE, sont répartis entre les GPU du groupe. Lorsqu’un rang approche une couche MoE, il dispose de ses experts locaux et attire depuis ses pairs les experts manquants pour cette couche. Il calcule ensuite tous les experts requis par ses tokens, localement, sans dispatch ni combine.
La copie utilise cudaMemcpyAsync et les moteurs de copie plutôt que les SM. Deux buffers alternent : l’un nourrit la couche courante pendant que l’autre reçoit la suivante. Au démarrage d’un pas, le runtime amorce les premières couches ; en régime établi, la fin du calcul d’une couche déclenche le prochain préchargement. SGLang construit une vue d’adresse virtuelle composite avec CUDA VMM. TensorRT-LLM échange des handles CUDA IPC au lancement, puis conserve les pointeurs vers les tenseurs distants.
Le système ne réplique pas durablement tous les experts sur tous les GPU. Chaque rang garde son placement local et un buffer pour les experts distants de la couche en approche. C’est ce détail qui rend la mémoire possible. Répliquer le MoE complet transformerait DWDP en simple parallélisme de données et supprimerait son intérêt de capacité.
Pourquoi déplacer plus peut coûter moins
Le modèle roofline Modèle qui borne la performance atteignable par deux plafonds : la puissance de calcul et la bande passante mémoire. Le rapport entre les deux définit une intensité arithmétique de bascule, en dessous de laquelle un noyau est limité par la mémoire et laisse ses unités de calcul inutilisées, au-dessus de laquelle il est limité par le calcul. publié avec TensorRT-LLM compare deux temps par couche. T_compute est la fenêtre de calcul disponible pour masquer la copie. T_prefetch est le temps nécessaire pour attirer les poids distants. Tant que le premier reste sous le second, le rang finit par attendre son buffer. Lorsqu’il le dépasse, la copie sort du chemin critique.
| Longueur d'entrée | T calcul / T préchargement | Temps DEP / temps DWDP |
|---|---|---|
| 1 024 tokens | 0,19 | 0,10 |
| 8 192 tokens | 0,62 | 0,73 |
| 16 384 tokens | 1,52 | 1,27 |
| 32 768 tokens | 4,77 | 1,17 |
À 1K, DWDP est dix fois plus lent dans ce modèle analytique : la copie dépasse largement le calcul. À 16K, la fenêtre devient assez grande et DWDP passe devant de 27 %. À 32K, le préchargement est mieux caché, mais le gain retombe à 17 %. Une fois que le calcul domine les deux stratégies, supprimer le collectif retranche une fraction plus petite du total. Le bénéfice n’augmente donc pas avec le contexte de façon monotone.
Le seuil de 16K n’est pas universel. Le tableau fixe un batch de 1, DeepSeek-R1, GB200 et le découpage étudié. Augmenter le batch agrandit la fenêtre de calcul et peut rendre DWDP rentable avec des prompts plus courts. Passer de NVLink Interconnexion propriétaire NVIDIA entre GPU. NVLink 5 (Blackwell) atteint 1,8 To/s bidirectionnels par GPU ; NVLink 6 (Rubin) double à 3,6 To/s. Avec NVSwitch, elle accélère les échanges GPU-GPU et les collectifs ; les mémoires restent physiquement distribuées et un accès distant n'a pas le coût de la HBM locale. Approfondir dans le glossaire à une interconnexion plus lente déplace le seuil dans l’autre sens, voire supprime le régime gagnant.
Le 1,92× de SGLang : juste, mais prefill-only
SGLang 0.5.17, publié le 8 août 2026, intègre DWDP comme fonctionnalité de prefill Phase initiale d'une inférence LLM : les tokens du prompt sont traités en parallèle pour construire l'état du contexte. Cette réutilisation augmente l'intensité arithmétique et peut rendre la phase limitée par le calcul ; le régime exact dépend du modèle, du batch, du contexte et du backend. Approfondir dans le glossaire en développement initial. Le PR fusionné décrit quatre B200 et gpt-oss-120b. DEP4, la base, combine quatre rangs d’experts et un all-gather ; DWDP4 précharge les poids par P2P. MNT désigne le nombre maximal de tokens traités dans une passe, ISL la longueur d’entrée.
| MNT | ISL 4K | ISL 8K | ISL 16K | ISL 32K |
|---|---|---|---|---|
| 16K | 1,16× | 1,37× | 1,18× | non publié |
| 32K | 1,30× | 1,45× | 1,48× | 1,92× |
À saturation, avec 128 requêtes concurrentes et 8K d’entrée, SGLang publie 506 000 tokens/s contre 329 000, soit 1,54×. Ces nombres valident l’implémentation et le régime long. Ils ne mesurent ni la génération, ni la file d’attente, ni le temps jusqu’au premier token perçu par un utilisateur. Transformer « 1,92× prefill-only » en « un MoE 1,92× plus rapide » effacerait trois quarts du protocole.
Le profil TensorRT-LLM montre où part le gain
Sur quatre GB200, DeepSeek-R1, 8K d’entrée et 32 768 tokens maximaux par passe, TensorRT-LLM décompose une itération de contexte. DEP paie 126,74 µs de communication et 161,85 µs de synchronisation. DWDP les retire du chemin critique et lance 429 µs de copie P2P en recouvrement.
| Catégorie | DEP4 | DWDP4 |
|---|---|---|
| Attention | 269,67 µs | 320,56 µs |
| Grouped GEMM | 342,40 µs | 337,42 µs |
| Communication critique | 126,74 µs | 0 µs |
| Synchronisation | 161,85 µs | 0 µs |
| Copie P2P recouverte | 0 µs | 429,00 µs |
| Itération | 1 319,85 µs | 1 131,58 µs |
Retirer communication et synchronisation promettait 21,86 % de réduction brute. Le gain réalisé est 14,26 %. L’attention passe de 269,67 à 320,56 µs et d’autres noyaux ralentissent aussi. Les moteurs de copie n’occupent pas les SM, mais le trafic traverse le réseau sur puce, le cache L2 et la DRAM des GPU source et destination. Copie et calcul se disputent la hiérarchie mémoire. L’analyse NVIDIA identifie aussi une baisse de fréquence induite par la limite de puissance pendant ce recouvrement.
Un autre conflit apparaît lorsque plusieurs rangs attirent simultanément des experts depuis le même GPU source. Le moteur de copie sérialise ces demandes many-to-one. NVIDIA teste un découpage des transferts en tranches de 1 Mo distribuées à tour de rôle et mesure 8 % supplémentaires dans un cas à fenêtre courte. Le blog précise que cette atténuation n’est pas intégrée au chemin produit actuel. Citer ses 8 % comme performance disponible serait prématuré.
Le débit par GPU gagne pendant que le TTFT perd
Le test de bout en bout est le contrôle adversarial décisif. TensorRT-LLM sépare le prefill et le decode Phase de génération autorégressive d'un LLM : un token est produit à la fois en relisant les poids et l'état de contexte utile. À faible batch, ce trafic peut limiter le decode par la bande passante mémoire. Sa part dans le coût total dépend toutefois des longueurs d'entrée et de sortie, du batching et de la réutilisation du cache. Approfondir dans le glossaire sur des serveurs distincts, garde le serveur de génération fixe et applique DWDP au contexte. Le protocole utilise DeepSeek-R1 NVFP4, 8K tokens d’entrée, 1K de sortie et compare des points de frontière de Pareto à débit utilisateur voisin.
| Débit utilisateur | Gain débit/GPU | TTFT base | TTFT DWDP |
|---|---|---|---|
| 20 à 30 tokens/s | 1,10× | 2 538 ms | 8 314 ms |
| 40 à 50 tokens/s | 1,08× | 1 919 ms | 7 012 ms |
| 60 à 70 tokens/s | 1,12× | 965 ms | 1 640 ms |
| 80 à 90 tokens/s | 1,06× | 1 669 ms | 2 280 ms |
| 170 à 180 tokens/s | 0,97× | 494 ms | 660 ms |
Dans la plage 20 à 100 tokens/s/utilisateur, le papier résume le gain moyen de débit de sortie par GPU à 8,8 %. Le tableau révèle ce que cette moyenne ne dit pas. Les points DWDP emploient moins de GPU de contexte, abaissent leur capacité de service agrégée et dégradent l’accord de débit entre contexte et génération. À 20-30 tokens/s, le TTFT médian passe de 2,5 à 8,3 secondes. À très haut débit utilisateur, DWDP perd même 3 % par GPU.
Ce n’est pas une réfutation de DWDP. C’est une réfutation du choix de métrique unique. Un opérateur qui paie par GPU peut accepter un premier token plus tardif pour servir le même débit avec moins de contexte. Un produit interactif soumis à un SLO Service Level Objective. Cible de qualité de service qu'un système se donne, par exemple un temps jusqu'au premier token sous 500 ms au 99e percentile. À distinguer du SLA, qui est l'engagement contractuel opposable : en inférence LLM, les SLO abondent et les SLA de latence sont quasi inexistants. de TTFT peut refuser exactement ce point. Latence contre latence explique pourquoi débit, TTFT et fluidité de génération ne se remplacent pas.
Le domaine de validité est étroit et utile
Prefill long ou batch assez grand. C’est le cœur du régime gagnant. Le calcul de la couche courante couvre le poids distant de la suivante. Des prompts RAG longs, l’ingestion de documents et un serveur de contexte chargé correspondent au mécanisme.
Service prefill/decode désagrégé. TensorRT-LLM n’active le chemin produit que sur le serveur de contexte. SGLang recommande aussi le mode prefill désagrégé. La disaggregation en production isole précisément la phase où la fenêtre de calcul existe.
Fabric P2P rapide dans le nœud. Le papier vise GB200 NVL72 ; SGLang mesure quatre B200 reliés par NVLink. TensorRT-LLM utilise des handles CUDA IPC qui ne couvrent pas le multi-nœud. Un cluster PCIe ou RDMA n’hérite pas de ces gains par simple configuration.
Decode court ou faible batch. Le pari se retourne. Peu de tokens donnent peu de calcul par couche, tandis que les poids à attirer gardent leur taille. Le tableau roofline place DWDP derrière DEP à 1K et 8K en batch 1.
Chemin logiciel contraint. Au moment de la publication, TensorRT-LLM demande le backend MoE CuteDSL avec NVFP4, TP égal à 1 dans le groupe, le lancement MPI désagrégé, FC2 fused-finalize, sans overlap scheduler ni EPLB sur ce chemin. SGLang qualifie sa propre intégration de développement initial. Ce sont des limites de déploiement, pas des notes de bas de page.
Conclusion
DWDP ne découvre pas que les poids sont petits. Il découvre qu’un gros transfert anticipé peut coûter moins qu’un petit transfert synchronisé. Cette inversion devient possible lorsque le prefill fournit une fenêtre de calcul, que NVLink transporte les experts avant leur usage et que chaque rang avance sans attendre le plus lent.
Le résultat dépasse une optimisation de kernel : c’est un changement de contrat entre données et modèle. Le parallélisme d’experts fixe les poids et déplace les requêtes. DWDP fixe les requêtes et fait circuler une couche de poids. Aucun des deux contrats n’est supérieur hors contexte. Le premier convient quand déplacer les tokens reste bon marché ; le second quand les barrières coûtent plus que les octets cachables.
La prochaine étape crédible n’est pas un nouveau record prefill-only. C’est une politique qui choisit le contrat par régime, prédit le temps de copie, protège le TTFT et retombe vers l’all-to-all lorsque la fenêtre se referme. Tant que cette décision reste manuelle et liée à un fabric NVLink, DWDP est un outil spécialisé. C’est aussi la raison pour laquelle il mérite d’être compris maintenant.
Sources et méthode
Le mécanisme et les résultats TensorRT-LLM viennent du papier NVIDIA DWDP: Distributed Weight Data Parallelism for High-Performance LLM Inference on NVL72 et du blog technique TensorRT-LLM avec protocole reproductible. Le blog publie le roofline, le profil par kernel, les contraintes de code, les points bout en bout et les fichiers examples/dwdp/ nécessaires à la reproduction.
Les résultats SGLang viennent de la release 0.5.17 et du PR #29778, fusionné le 21 juillet 2026. Le PR identifie le code comme développement initial, décrit CUDA VMM et le double buffer, puis publie les gains prefill-only sur quatre B200. Nous conservons cette qualification.
Les chiffres SGLang et TensorRT-LLM sont présentés dans des tableaux séparés parce qu’ils changent de modèle, matériel exact, runtime, dataset et métrique. Aucune moyenne ni comparaison directe n’est calculée. Le 1,92× est un maximum prefill-only SGLang ; le 8,8 % est une synthèse de service TensorRT-LLM dans la plage 20 à 100 tokens/s/utilisateur.
Nous n’avons trouvé aucune réplication indépendante de ces résultats DWDP au moment de la publication. Les deux implémentations remontent au même concept NVIDIA et les mesures sont produites par leurs équipes de développement. Les mécanismes sont inspectables et les scripts TensorRT-LLM sont fournis, mais la généralisation à un autre MoE, un autre fabric ou un autre profil de requêtes reste une hypothèse à tester.
