La disaggregation prefill/decode sort du papier : état des lieux mai 2026

Où en était-on

Le 17 mai 2026, notre article sur la plateforme Vera Rubin posait une thèse : l’inférence LLM cesse d’être un problème GPU homogène. Le prefill prefill Phase initiale d'une inférence LLM : tous les tokens du prompt sont traités d'un coup. Intensité arithmétique élevée — le GPU sature ses Tensor Cores. C'est l'inverse du decode qui suit. est compute-bound — il sature les Tensor Cores Tensor Cores Unités matérielles spécialisées dans les multiplications de matrices à basse précision, introduites par NVIDIA avec Volta (2017). Chaque génération ajoute des formats supportés : FP16 → FP8 (Hopper) → FP6/FP4 (Blackwell). Ce sont elles qui exécutent l'essentiel du calcul d'inférence. . Le decode decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse — le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. est memory-bound — il attend la HBM HBM High Bandwidth Memory. Mémoire empilée en couches, soudée à proximité immédiate du GPU, avec une bande passante de plusieurs To/s — contre ~50 Go/s pour de la DDR5. Indispensable au-delà d'une certaine taille de modèle. . Coller les deux sur le même GPU revient à sous-utiliser le matériel sur l’une des deux phases. NVIDIA l’a reconnu au niveau silicium en intégrant un LPU Groq dédié au decode dans la plateforme Vera Rubin, et en lançant Dynamo 1.0 comme orchestrateur.

Une semaine plus tard, la thèse n’est plus une projection architecturale. Trois stacks logiciels proposent la disaggregation en production. Un challenger matériel conteste le principe même. Et le premier cycle MLPerf de l’ère disaggregation mesure ce que le logiciel pèse face au silicium. C’est cet état des lieux que cet article dresse.

Le pipeline disaggregé en un schéma

Requête Prompt utilisateur Entrée

Prefill Tensor Cores saturés, compute-bound Nœuds GPU dédiés

Transfert KV RDMA / NVLink / NIXL / MORI-IO Point critique

Decode Bande passante HBM, memory-bound Nœuds GPU ou LPU

Réponse Tokens générés Sortie

La difficulté de ce pipeline tient dans la troisième colonne. Le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. calculé par le nœud prefill doit être transféré au nœud decode avant que la génération ne commence — et ce transfert se mesure en gigaoctets par requête. Sur un modèle 70B en FP8 FP8 Format à virgule flottante 8 bits. Format de travail polyvalent pour l'inférence (et l'entraînement) sur GPU récents. Divise par 2 l'empreinte mémoire et le débit nécessaires par rapport au FP16, pour une perte de précision marginale sur la plupart des modèles. , un contexte de 8k tokens représente ~1,3 Go de KV cache (voir notre calculette détaillée). Sur un DeepSeek-R1 671B avec contexte 100k, on parle de dizaines de gigaoctets. Si le transfert est plus lent que le decode lui-même, la disaggregation dégrade la latence au lieu de l’améliorer. Chaque runtime résout ce problème différemment.

Dynamo 1.0 : l’orchestrateur en production

NVIDIA a publié Dynamo 1.0 en version production le 16 mars 2026 — le même jour que l’annonce Vera Rubin. Ce n’est pas un hasard : Dynamo est le lien logiciel entre la thèse matérielle (des siliciums spécialisés par phase) et son exécution.

Ce que Dynamo fait. C’est un framework d’orchestration d’inférence, open source (GitHub : ai-dynamo/dynamo), qui coordonne un cluster de nœuds prefill et decode. Il route les requêtes en temps réel, transfère le KV cache entre nœuds, et gère l’élasticité du pool. Son mode natif est le disaggregated serving : les nœuds prefill calculent le prompt, le KV cache est transféré via NVLink NVLink Interconnexion propriétaire NVIDIA entre GPU. NVLink 5 (Blackwell) atteint 1,8 To/s par lien ; NVLink 6 (Rubin) double à 3,6 To/s. Permet à plusieurs cartes de partager leur mémoire et de se comporter quasi comme un seul accélérateur. ou RDMA vers les nœuds decode, et la génération commence sans que le nœud prefill ne soit bloqué.

Ce qui le distingue des runtimes. Dynamo n’est pas un runtime d’inférence — il s’appuie sur TensorRT-LLM ou SGLang comme backend d’exécution. Son rôle est au-dessus : routage KV-aware, placement topologique sur le cluster, et surtout DGDR (Dynamo Graph Deployment Request), un mécanisme qui traduit des SLOs (latence cible, débit minimum) en déploiement concret sur le cluster. Là où un runtime répond à la question « comment servir ce modèle sur ce GPU », Dynamo répond à « comment répartir ce modèle sur 72 GPU pour tenir ces contraintes ».

Multimodal E/P/D. Depuis mars 2026, Dynamo étend le modèle à trois phases — Embedding, Prefill, Decode — avec un cache d’embeddings dédié. Sur des requêtes image avec Qwen3-VL-30B-A3B-Instruct en FP8 sur GB200, NVIDIA mesure +30 % de réduction du TTFT et +25 % de throughput (fait vérifié, source NVIDIA). L’extension à la vidéo est en cours : FastVideo + SGLang Diffusion génère 5 secondes de vidéo 1080p en ~4,5 secondes sur un seul B200.

Intégration Kubernetes. Le plugin K8s Inference Gateway implémente le routage KV-aware directement dans l’infrastructure Kubernetes : les requêtes qui partagent un prefix KV sont routées vers le nœud qui le détient déjà. NVIDIA mesure un TTFT 20× plus rapide et un E2E 4× plus rapide sur les requêtes à prefix commun (fait vérifié). Grove (GitHub : ai-dynamo/grove) complète le tableau avec le scheduling topology-aware pour GB300 NVL72 — il place les workloads en tenant compte de la topologie NVLink du rack.

Adoption. La liste des adopteurs confirmés au 24 mai 2026 comprend AstraZeneca, Baseten, ByteDance, CoreWeave, Crusoe, DigitalOcean, Gcore, GMI Cloud, Nebius, Meituan, Pinterest, Prime Intellect, Rednote, SoftBank Corp., Tencent Cloud, Together AI et Vultr. Intégrations cloud : AWS, Azure, GCP, OCI, Alibaba Cloud.

Le cas Baseten : les chiffres nuancés

Baseten a publié un retour d’expérience dès octobre 2025, en adopteur précoce. Le titre du billet — “How Baseten Achieved 2x Faster Inference with NVIDIA Dynamo” — résume un TTFT divisé par 2. Les mesures détaillées, signées Abu Qader, Michael Feil et Rachel Rapp, sont plus granulaires : 50 % de réduction du TTFT, 61 % d’augmentation des requêtes par seconde et 62 % d’augmentation des tokens par seconde sur Qwen3 Coder 480B avec des prompts d’environ 50k tokens. Le « 2× » s’applique au TTFT, pas au débit global. Et le claim « sans coût matériel supplémentaire » vient des réseaux sociaux, pas du billet technique.

Le chiffre de débit agrégé cité par NVIDIA — ×7 de throughput avec disaggregation + Expert Parallelism étendu sur GB200 NVL72, mesuré sur DeepSeek R1-0528 en FP4 FP4 Format à virgule flottante 4 bits — la frontière 2026 de l'inférence à haut débit. Quatre fois moins de mémoire que le FP16, mais une portée dynamique très étroite : ne tient qu'avec un scaling fin via formats à blocs (MXFP4, NVFP4). , contexte 1k/1k — provient d’un benchmark SemiAnalysis InferenceX du 3 mars 2026, relayé par NVIDIA. C’est un chiffre vendor-cited : représentatif d’un cas optimisé, pas d’un débit moyen en production.

SGLang 0.5.12 : la disaggregation native

SGLang 0.5.12 est sorti le 16 mai 2026, et c’est la première version du runtime qui traite la disaggregation prefill/decode comme un citoyen de première classe. Là où Dynamo est un orchestrateur au-dessus du runtime, SGLang intègre la mécanique dans le runtime lui-même.

Le mécanisme. Le GPU Staging Buffer est un buffer intermédiaire en VRAM qui accumule le KV cache côté prefill et le transfert par bloc vers le nœud decode. Le Decode Radix Cache côté decode organise le KV reçu dans un arbre radix qui permet le prefix matching — si deux requêtes partagent les mêmes 2000 premiers tokens, le cache n’est transféré qu’une fois. Trois backends de transport sont supportés : NIXL (NVIDIA), Mooncake (framework open source) et MORI-IO (AMD) — ce qui fait de SGLang le seul runtime à supporter nativement la disaggregation sur les deux écosystèmes GPU.

DeepSeek V4 day-0. SGLang 0.5.12 est le premier runtime à supporter le chemin d’inférence complet de DeepSeek V4 dès sa sortie. Ce n’est pas anodin : les modèles DeepSeek utilisent une architecture MoE (Mixture of Experts) à très grand nombre d’experts, et leur serving efficace exige Tensor Parallelism, Expert Parallelism, Context Parallelism et Data Parallel Attention simultanément. SGLang supporte TP16 sur H100 et H20.

HiSparse : l’offload proactif du KV inactif. HiSparse est un mécanisme spécifique aux modèles à attention sparse de type DeepSeek (V3.2, GLM-5.1). Au lieu d’attendre que la VRAM sature pour commencer l’offload, HiSparse identifie proactivement les entrées KV qui ne participent plus à l’attention et les déplace vers la mémoire CPU. Le gain mesuré : ×3 de throughput à 256 requêtes concurrentes, jusqu’à ×5 sur les contextes longs. La limite : il ne fonctionne que sur les modèles à attention sparse (DSA) — sur un Llama classique à attention dense, le mécanisme ne s’applique pas.

HiCache complète HiSparse en ajoutant un arbre radix unifié (UnifiedRadixTree) qui hiérarchise le KV cache entre VRAM, RAM CPU et SSD via Mooncake. C’est une extension de la logique PagedAttention à trois niveaux de stockage, pas deux.

Blackwell natif. Le backend TokenSpeed MLA est optimisé pour les Tensor Cores Blackwell avec KV cache FP8. Les kernels W4A4 MegaMoE ciblent les modèles MoE quantifiés à 4 bits, et le speculative decoding speculative decoding Technique d'accélération du decode qui utilise un petit modèle rapide (draft model) pour proposer plusieurs tokens candidats, ensuite vérifiés en un seul passage par le modèle principal. Les tokens corrects sont acceptés sans coût supplémentaire — on échange du calcul redondant contre une réduction du nombre de passes autorégressives. V2 améliore l’acceptance rate sur les modèles à MTP (Multi-Token Prediction) — DeepSeek-R1 embarque nativement une couche MTP, étendue à 3 pour le pic de performance dans Dynamo+TRT-LLM.

TensorRT-LLM 1.3 : Helix Parallelism et les connecteurs KV

TensorRT-LLM 1.3 est en cycle de pre-release rapide depuis mars 2026 — rc7 le 10 mars, rc12 le 17 avril, rc15 le 21 mai. Chaque release candidate ajoute une brique du puzzle disaggregation.

Service discovery pour disaggregated serving (rc12) : les nœuds prefill et decode se découvrent automatiquement sur le cluster, sans configuration statique. C’est le prérequis pour que Dynamo puisse router les requêtes sans registre codé en dur.

KV Cache Connector API (introduite en v1.1, affinée dans les rc de 1.3) : une API d’abstraction du transfert KV entre nœuds. Le runtime n’a pas besoin de savoir comment le KV est transféré (NVLink, RDMA, S3/Azure blob) — le connecteur s’en charge. Dynamo utilise cette API pour le offload KV vers du stockage objet, une fonctionnalité livrée en mars 2026.

Sparse Attention (rc13) : support de l’attention sparse MQA et GQA, nécessaire pour les modèles DeepSeek et les architectures à attention clairsemée.

Helix Parallelism : le rouage central

Helix Parallelism est la contribution la plus significative de TRT-LLM 1.3 au serving disaggregé. Son mécanisme mérite le détail, parce qu’il résout un problème que les stratégies de parallélisme existantes traitaient mal.

Le problème est le suivant. Sur un modèle MoE comme DeepSeek-R1 671B, chaque couche de transformeur se compose de deux blocs : l’attention (qui est dense — tous les paramètres participent) et le FFN (feed-forward network, qui est sparse — seuls quelques experts sont activés par token). Le Tensor Parallelism classique découpe toutes les opérations uniformément entre les GPU. Sur l’attention dense, c’est optimal — chaque GPU fait sa part. Sur le FFN sparse, c’est du gaspillage : les GPU qui hébergent des experts non activés restent inactifs, pendant que ceux qui hébergent les experts chauds saturent.

Helix résout ce déséquilibre en appliquant deux stratégies de parallélisme différentes selon le bloc. Pendant l’attention, il utilise le KV Parallelism : chaque GPU détient une partition du KV cache et calcule sa part d’attention indépendamment. Pendant le FFN, il bascule en TP (Tensor Parallelism) pour les modèles denses, ou TP×EP (Tensor Parallelism × Expert Parallelism) pour les modèles MoE. Cette commutation dynamique entre deux régimes de parallélisme au sein d’une même couche — d’où le nom Helix, qui évoque l’entrelacement — est ce qui distingue l’approche. Le papier (arXiv : 2507.07120) mesure une réduction du TTL (Time To Last token) jusqu’à 1,5× et la capacité de supporter des batches 32× plus grands sous la même contrainte de latence, sur DeepSeek-R1 sur Blackwell.

C’est une réponse logicielle au même problème que la disaggregation matérielle attaque côté silicium : adapter le régime d’exécution au profil de la charge, couche par couche.

RocketKV : la compression sans entraînement

RocketKV (arXiv : 2502.14051, ICML 2025, NVlabs) est une technique de compression KV en deux étapes intégrée dans TRT-LLM 1.3. La première étape — SnapKV++ — évicte les entrées KV qui contribuent peu à l’attention, en mesurant leur score d’importance accumulé. La seconde étape applique une attention sparse top-k hybride sur les entrées restantes. Le gain mesuré sur H100 : ×3 de speedup en decode, -31 % de consommation mémoire pic. Le point distinctif : aucun réentraînement n’est requis — la compression s’applique à l’inférence, sur un modèle existant.

Le contre-argument : Tenstorrent Galaxy Blackhole

Toutes les solutions précédentes partent d’un même postulat : la disaggregation est nécessaire parce que le GPU généraliste est structurellement sous-optimal sur l’une des deux phases. Tenstorrent conteste ce postulat.

Le 28 avril 2026, Tenstorrent a lancé Galaxy Blackhole en disponibilité générale. Le positionnement est explicite dans leur communiqué : “Other solutions require bolting together separate accelerators across fragmented infrastructure.” Leur thèse : plutôt que de fragmenter le pipeline entre des siliciums différents reliés par du réseau, on unifie compute, mémoire et réseau dans un seul système conçu pour que la bande passante interne soit si élevée que la distinction prefill/decode perd sa pertinence.

Les specs qui soutiennent la thèse. Galaxy Blackhole regroupe 32 chips Blackhole dans un seul système. La puissance de calcul atteint 23 PFLOPS en Block FP8. La mémoire est répartie en deux niveaux : 6,2 Go de SRAM à 2,9 Po/s de bande passante interne — c’est-à-dire que la SRAM seule offre une bande passante sans commune mesure avec la HBM d’un GPU classique — à titre de repère, un H100 SXM5 plafonne à ~3,35 To/s de HBM3, un B200 à ~8 To/s de HBM3E. Au-dessus, 1 To de DRAM à 16 To/s. Le réseau interne supporte jusqu’à 56 ports 800G Ethernet.

Le raisonnement de Tenstorrent est le suivant. La raison pour laquelle le decode est memory-bound sur un GPU classique, c’est que la bande passante HBM (~8 To/s sur B200) ne suit pas le rythme du calcul. Si vous remplacez la hiérarchie GPU+HBM par une hiérarchie SRAM-first à 2,9 Po/s, l’intensité arithmétique du decode remonte suffisamment pour que le calcul redevienne le facteur limitant, pas la mémoire. Résultat : la séparation prefill/decode perd son utilité — un seul système fait les deux efficacement.

Blitz Mode concrétise cette thèse. Sur DeepSeek-R1-0528 (671B paramètres), Tenstorrent annonce : 350+ tokens/s/utilisateur en decode, TTFT sous 4 secondes sur un contexte de 100k tokens, batch sizes de 8 à 64, contexte jusqu’à 128k. Ce sont des chiffres constructeur (fait vérifié quant à leur publication, non vérifié par benchmark indépendant), mais le TTFT sous 4 secondes sur 100k tokens est un claim agressif — il signifie que le prefill lui-même est rapide malgré l’absence de Tensor Cores dédiés au sens NVIDIA du terme.

Le prix. Un système Galaxy Blackhole part d’environ 101 000 €. Un supercluster de 4 systèmes part d’environ 405 000 €. Comparé au coût d’un rack DGX GB200 NVL72 (estimations presse entre 2 et 3 M€), c’est un ordre de grandeur en dessous — mais la comparaison directe est trompeuse, car les deux systèmes ne ciblent pas la même échelle de modèle ni la même bande passante réseau inter-rack.

AMD : MORI-IO et vLLM-ATOM

AMD n’a pas de framework d’orchestration équivalent à Dynamo. Sa stratégie est de fournir les briques de transport que les runtimes tiers consomment — et de s’assurer que ses GPU sont des citoyens de première classe dans SGLang et vLLM.

MORI-IO (Modular RDMA Interface) est la bibliothèque de communication point-à-point d’AMD pour les transferts KV à faible overhead (GitHub : ROCm/mori). Ce n’est pas un runtime d’inférence : c’est une couche de transport RDMA optimisée pour les cas d’usage disaggregation — transfert de KV cache entre nœuds prefill et decode, et communication Expert Parallelism pour les modèles MoE. MORI-IO est intégré dans SGLang (comme backend de transport alternatif à NIXL) et dans vLLM. C’est la pièce qui rend la disaggregation possible sur GPU AMD, exactement comme NIXL la rend possible chez NVIDIA.

vLLM-ATOM est un plugin externe publié le 7 mai 2026, qui regroupe les optimisations kernel d’AMD pour vLLM : attention fusionnée AITER, AllReduce custom, routage MoE optimisé, support FP4 pour MI355X. AMD le décrit comme un « terrain d’essai temporaire pour les nouvelles optimisations » — les kernels stabilisés sont remontés dans le backend ROCm natif de vLLM. La logique est pragmatique : plutôt que d’attendre l’amont, AMD livre les optimisations dans un plugin qu’on installe à côté, et qui disparaîtra quand l’amont les aura absorbées.

MI350P PCIe mérite une mention. Annoncé le 7 mai 2026, c’est le premier accélérateur AMD MI350 en format PCIe Gen 5 : 144 Go de HBM3E à 4 To/s, jusqu’à 4,6 PFLOPS en MXFP4, dual-slot passif, 600 W TBP (configurable à 450 W). Ce n’est pas la même classe que le MI355X (288 Go, 8 To/s) — c’est un drop-in pour serveurs air-cooled existants, conçu pour les entreprises qui veulent entrer dans l’inférence disaggregée sans refondre leur infrastructure de refroidissement.

Ce que MLPerf v6.0 mesure

MLPerf Inference v6.0, publié le 1er avril 2026 par MLCommons, est le premier cycle de benchmarks qui reflète l’ère de la disaggregation logicielle. 24 organisations ont soumis des résultats. Cinq nouveaux benchmarks ont été ajoutés : GPT-OSS 120B, DeepSeek-R1 interactif (avec speculative decoding), DLRMv3, WAN-2.2 text-to-video, et YOLOv11 edge.

Le résultat le plus frappant n’est pas un chiffre matériel — c’est un chiffre logiciel. NVIDIA a amélioré son score DeepSeek-R1 de 2,7× par rapport à sa propre soumission antérieure. Le matériel n’a pas changé : 288 GPU, 4 racks GB300 NVL72. Le gain vient de l’orchestration — Dynamo, disaggregation, Expert Parallelism, speculative decoding étendu (MTP passé de 1 à 3 couches). Résultat : 2,5 M tokens/s. Ce 2,7× est à interpréter avec précision : c’est vs la soumission NVIDIA antérieure, pas vs l’ensemble du champ MLPerf v5.1. Il montre que le logiciel pèse autant que le silicium sur du matériel déjà déployé.

AMD MI355X. Le score phare est 100 282 tokens/s sur Llama 2 70B Server — 3,1× par rapport au MI325X. En multinode (11 nœuds, 87 MI355X), AMD atteint 1 042 110 tokens/s en Offline et 1 016 380 tokens/s en Server. Ces chiffres valident la compétitivité du MI355X en débit brut, même si l’écosystème logiciel AMD reste un cran derrière en maturité d’orchestration.

NVIDIA Blackwell Ultra atteint 2,5 M tokens/s sur DeepSeek-R1 avec 288 GPU répartis sur 4 racks GB300 NVL72 — le score absolu le plus élevé du cycle. Le fait que ce score provienne en grande partie de gains logiciels sur du matériel existant est le signal le plus important de ce cycle MLPerf : investir dans l’orchestration rapporte autant qu’investir dans le silicium.

Comparatif des implémentations

Critère	Dynamo 1.0	SGLang 0.5.12	TRT-LLM 1.3	Tenstorrent Galaxy
Rôle	Orchestrateur cluster	Runtime natif	Runtime + kernels	Système intégré
Disaggregation	Native (E/P/D)	Native (P/D)	Via Service Discovery + KV Connector	Non applicable (unifiée)
Transport KV	NVLink, RDMA, S3/Azure blob	NIXL, Mooncake, MORI-IO	KV Cache Connector API	SRAM interne (2,9 Po/s)
GPU supportés	NVIDIA (GB200, GB300)	NVIDIA + AMD (H100, H20, MI355X)	NVIDIA uniquement	Blackhole (RISC-V Tensix)
Parallélisme avancé	Wide EP, TP, KV-aware routing	TP, EP, CP, DPA	Helix (KV-P + TP×EP)	Interne 32 chips
Optimisation KV	KVBM offload S3, prefix caching	HiSparse, HiCache, Radix Cache	RocketKV, Sparse Attention	SRAM-first (6,2 Go)
Kubernetes	Inference Gateway + Grove	Non	Non	Non
Open source	Oui (ai-dynamo/dynamo)	Oui (sgl-project/sglang)	Oui (NVIDIA/TensorRT-LLM)	Non
Prix d'entrée	GPU cloud (~2-3 €/h H100)	GPU cloud (~2-3 €/h H100)	GPU NVIDIA uniquement	~101 000 € (système)

Comment choisir

La matrice de décision dépend de trois variables : votre parc matériel existant, votre contrainte dominante (latence ou débit), et votre tolérance à la complexité opérationnelle.

Vous avez un parc NVIDIA existant et vous servez des modèles MoE à forte concurrence. Dynamo + TRT-LLM est le chemin le plus direct. Dynamo orchestre la disaggregation, TRT-LLM fournit le débit maximal par nœud avec Helix Parallelism, et le plugin Kubernetes gère le scaling. Le coût opérationnel est réel — une couche de plus à maintenir — mais les gains mesurés (×7 throughput sur le benchmark NVIDIA, ×2 TTFT chez Baseten) justifient l’investissement sur les charges à forte concurrence.

Vous voulez la disaggregation sans verrouillage matériel. SGLang 0.5.12 est le seul runtime qui supporte la disaggregation nativement sur NVIDIA et AMD, via NIXL et MORI-IO respectivement. Si vous prévoyez un parc mixte ou une migration future vers AMD, c’est le choix le plus défendable. HiSparse est un levier puissant si vous servez des modèles DeepSeek.

Vous partez de zéro et la latence par utilisateur est votre métrique-clé. Tenstorrent Galaxy Blackhole mérite l’évaluation. Le TTFT sous 4 secondes sur 100k tokens et les 350+ tokens/s/utilisateur en decode sont des claims agressifs, mais le prix d’entrée (~101 000 € par système) et l’absence de complexité de transfert KV sont des arguments réels. La contrepartie : un écosystème logiciel jeune, pas de Kubernetes natif, et un verrouillage à l’architecture Tensix.

Vous servez principalement des modèles denses (Llama, Mistral) à batch modéré. La disaggregation n’est probablement pas votre priorité immédiate. Un runtime classique bien configuré — vLLM avec PagedAttention PagedAttention Algorithme introduit par vLLM qui gère le KV cache comme la mémoire virtuelle d'un système d'exploitation — par pages, sans exiger un bloc contigu par requête. Élimine la fragmentation interne et externe, permet de servir 2 à 4× plus de requêtes concurrentes sur la même VRAM. et prefix caching — couvre la majorité de ces cas. La disaggregation paie surtout sur les modèles MoE à très grande concurrence ou les contextes longs.

Conclusion

Le logiciel a rattrapé le matériel en trois mois. La thèse posée par Vera Rubin — l’inférence éclate en phases spécialisées — est désormais implémentable sans attendre le silicium Rubin. Dynamo, SGLang et TRT-LLM permettent de disaggréger sur du matériel Blackwell ou Hopper existant, et les gains mesurés (MLPerf v6.0 : ×2,7 logiciel pur) montrent que l’orchestration est devenue un levier au moins aussi puissant que le passage à la génération silicium suivante.

La prochaine frontière n’est pas la disaggregation elle-même — c’est son automatisation. Les trois runtimes exigent encore un dimensionnement manuel du ratio prefill/decode, une configuration explicite du transport KV, et une topologie réseau pensée pour le cas d’usage. DGDR de Dynamo esquisse la direction : traduire un SLO en déploiement, sans que l’opérateur ne touche au routage. Quand cette boucle sera fermée — un SLO entre, un cluster configuré sort — la disaggregation cessera d’être une technique de spécialiste pour devenir un mode de déploiement par défaut.

L’autre question ouverte est celle du quatrième tier. Vera Rubin a posé trois tiers : prefill GPU, decode LPU, orchestration CPU. Le KV cache — dont le transfert est le goulot de la disaggregation — pourrait justifier un tier de stockage dédié, exactement ce que le Rubin CPX annulé devait être. Si les transferts KV restent le facteur limitant à l’échelle, ce tier réapparaîtra — sous une forme ou une autre — dans la plateforme Feynman 2028.

Sources et méthode

Cet article s’appuie sur un dossier de recherche arrêté au 24 mai 2026. Étiquettes : fait vérifié = source primaire citable ; estimation crédible = cohérent mais non vérifié indépendamment ; hypothèse = raisonnement sans mesure.

Dynamo 1.0

• NVIDIA Developer Blog — NVIDIA Dynamo 1.0 Production Ready : developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/ — 16 mars 2026 (fait vérifié). Chiffres E/P/D multimodal, Kubernetes Inference Gateway, FastVideo.
• GitHub : ai-dynamo/dynamo — open source (fait vérifié).
• GitHub : ai-dynamo/grove — Grove API pour scheduling topology-aware GB300 NVL72 (fait vérifié).
• SemiAnalysis InferenceX — benchmark ×7 throughput sur GB200 NVL72 avec DeepSeek R1-0528 FP4 (vendor-cited, relayé par NVIDIA).
• Baseten — “How Baseten Achieved 2x Faster Inference with NVIDIA Dynamo” : baseten.co/blog/how-baseten-achieved-2x-faster-inference-with-nvidia-dynamo/ — 16 octobre 2025, Abu Qader, Michael Feil, Rachel Rapp. TTFT -50 %, +61 % RPS, +62 % TPS sur Qwen3 Coder 480B (fait vérifié). Le claim « 2× » s’applique au TTFT. Le claim « sans coût matériel supplémentaire » provient des réseaux sociaux, pas du billet technique (nuance éditoriale).

SGLang 0.5.12

• GitHub release : sgl-project/sglang v0.5.12 — 16 mai 2026 (fait vérifié).
• PD disaggregation avec GPU Staging Buffer, Decode Radix Cache, backends NIXL/Mooncake/MORI-IO (fait vérifié).
• HiSparse : ×3 throughput à 256 concurrents, jusqu’à ×5 en long contexte (fait vérifié, limité aux modèles DSA — DeepSeek-V3.2, GLM-5.1).
• HiCache : UnifiedRadixTree, offload SSD via Mooncake (fait vérifié).
• DeepSeek V4 day-0, TP16 H100/H20 (fait vérifié).

TensorRT-LLM 1.3

• Releases : rc7 (10 mars) → rc15 (21 mai 2026), pre-release (fait vérifié).
• Helix Parallelism : arXiv 2507.07120 — KV Parallelism (attention) + TP×EP (FFN), 1,5× TTL, 32× batch à latence constante sur DeepSeek-R1/Blackwell (fait vérifié).
• RocketKV : arXiv 2502.14051, ICML 2025 (NVlabs) — ×3 decode speedup, -31 % mémoire pic sur H100 (fait vérifié).
• Service discovery (rc12), KV Cache Connector API (v1.1+), Sparse Attention MQA/GQA (rc13) (fait vérifié).

Tenstorrent Galaxy Blackhole

• Tenstorrent Newsroom — GA : 28 avril 2026 : tenstorrent.com/newsroom/ (fait vérifié).
• Specs : 32 chips Blackhole, 23 PFLOPS Block FP8, 6,2 Go SRAM (2,9 Po/s), 1 To DRAM (16 To/s), 56× 800G Ethernet (fait vérifié).
• Blitz Mode : 350+ tokens/s/utilisateur decode, TTFT sous 4 s sur 100k contexte, DeepSeek-R1-0528 671B, batch 8-64, contexte jusqu’à 128k (fait vérifié — publication constructeur, non vérifié par benchmark indépendant).
• Prix : système à partir de 110 000 $ (~101 000 €), supercluster 4 systèmes à partir de 440 000 $ (~405 000 €) (fait vérifié).

AMD

• ROCm Blog — vLLM-ATOM plugin : rocm.blogs.amd.com — 7 mai 2026 (fait vérifié).
• MORI-IO (Modular RDMA Interface) : github.com/ROCm/mori — bibliothèque RDMA pour transfert KV et EP sur GPU AMD (fait vérifié).
• MI350P PCIe : AMD blog 7 mai 2026 — 144 Go HBM3E, 4 To/s, 4,6 PFLOPS MXFP4, dual-slot PCIe Gen 5, 600 W TBP (fait vérifié).

MLPerf Inference v6.0

• MLCommons — MLPerf Inference v6.0 Results : mlcommons.org/2026/04/mlperf-inference-v6-0-results/ — 1er avril 2026 (fait vérifié).
• NVIDIA : 2,5 M tokens/s DeepSeek-R1, 288 GPU, 4× GB300 NVL72 (fait vérifié). Le ×2,7 est vs la soumission NVIDIA antérieure, pas vs l’ensemble du champ v5.1 (clarification éditoriale).
• AMD MI355X : 100 282 tokens/s Llama 2 70B Server (×3,1 vs MI325X), 1 042 110 tokens/s Offline / 1 016 380 Server sur 11 nœuds / 87 MI355X (fait vérifié).

Speculative decoding

• EAGLE-3 / SpecForge : arXiv 2603.18567, mars 2026. Plage mesurée : 3,27×–4,79× sur HumanEval (LLaMA-3.3-70B-Instruct, temp=0) (fait vérifié).
• P-EAGLE (AWS) : 13 mars 2026, PR principal #32887. 1,55× à c=1, 1,05× à c=64 sur MT-Bench/GPT-OSS-20B (fait vérifié).

Conversion monétaire

Taux indicatif : 1 USD = 0,92 EUR (mi-2026).