Ce qui a changé depuis PagedAttention
L’article précédent sur le KV cache décrivait un problème de consommation mémoire : le cache croît linéairement avec le contexte et le batch, et c’est lui — pas les poids — qui sature la VRAM en premier. 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. a résolu la fragmentation, la quantification 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. a doublé la capacité, le prefix caching a éliminé les recalculs redondants. Ces trois leviers restent le socle. Mais ils traitent le KV cache comme un résidu local — un tenseur que le GPU possède, gère, et ne partage avec personne.
Ce qui s’est passé entre fin 2025 et mai 2026 dépasse ce cadre. Le KV cache a acquis sa propre quantification spécialisée, distincte de celle des poids. Il possède désormais un protocole de transfert pour migrer d’un nœud à l’autre. Il se stocke dans une hiérarchie mémoire à quatre niveaux — du 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. GPU jusqu’au stockage objet S3. Et le scheduler d’inférence prend ses décisions de routage en fonction de l’état du cache sur chaque nœud.
Le KV cache n’est plus un effet de bord. C’est l’objet central autour duquel la pile de serving se réorganise.
TurboQuant : le cache descend à ~3 bits
La quantification FP8 du KV cache — un octet par valeur au lieu de deux — était devenue un réglage par défaut en production depuis 2024. Descendre plus bas sans dégrader la qualité semblait hors de portée : le KV cache change à chaque token, contrairement aux poids qu’on calibre une fois. Les techniques de quantification agressives (4 bits, 2 bits) produisaient des artefacts mesurables sur les benchmarks de génération.
TurboQuant, publié à ICLR 2026 par Google Research et NYU (arXiv 2504.19874), résout ce problème par deux mécanismes enchaînés.
Le premier, PolarQuant, applique une rotation orthogonale aléatoire aux vecteurs K et V avant la quantification. L’idée n’est pas d’approximer les valeurs telles quelles — c’est de les transformer dans un espace où leur distribution devient quasi-gaussienne, donc mieux adaptée à une quantification uniforme. La rotation est inversible et peu coûteuse : une matrice orthogonale tirée aléatoirement, appliquée par multiplication, et défaite après le calcul d’attention. Ce qui coûterait cher en stockage (la matrice) se règle par un seed fixe — la même matrice est reconstruite à chaque appel, sans la conserver.
Le second, QJL (Quantized Johnson-Lindenstrauss), corrige le résidu de quantification par une projection aléatoire 1-bit. Au lieu de stocker l’erreur en pleine résolution, QJL la projette dans un sous-espace et ne conserve que le signe de chaque composante projetée — un bit. Le théorème de Johnson-Lindenstrauss garantit que la distance entre vecteurs est préservée avec haute probabilité dans le sous-espace projeté, ce qui suffit au calcul d’attention. Le résultat combiné : environ 3 bits par coordonnée pour une qualité indistinguable du baseline, 2,5 bits avec une dégradation marginale.
L’intégration dans vLLM 0.20 est effective depuis le 15 avril 2026 (PR #38479). Le flag CLI est --kv-cache-dtype turboquant_3bit_nc. Une extension FlashAttention 3/4 pour le 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. a suivi via PR #40092. Le blog vLLM du 11 mai 2026 publie la première étude systématique. Ce n’est plus un papier de recherche — c’est un paramètre de configuration.
RocketKV : l’éviction intelligente
TurboQuant compresse chaque valeur du cache. RocketKV (arXiv 2502.14051, NVlabs, ICML 2025) prend le problème par l’autre bout : ne pas stocker les entrées que l’attention ne regardera pas.
Le mécanisme opère en deux étages. Le premier, SnapKV++, effectue une éviction grossière : à intervalles réguliers, il évalue quels blocs du cache ont contribué le moins au score d’attention récent et les supprime. C’est un filtre passe-haut sur la pertinence temporelle — les blocs anciens et jamais consultés disparaissent. Le second étage applique une attention sparse top-k hybride sur le cache survivant : au lieu de calculer l’attention sur tous les vecteurs restants, il ne retient que les k entrées les plus pertinentes, sélectionnées par un score léger.
Le résultat mesuré sur H100 : jusqu’à 3× d’accélération du 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. , 31 % de réduction de la mémoire de pointe. L’intégration dans TensorRT-LLM comme backend d’attention sparse en fait un levier complémentaire à la quantification — TurboQuant réduit la taille de chaque entrée, RocketKV réduit le nombre d’entrées.
FlashAttention 4 : le prefill descend d’un cran
Le calcul d’attention lui-même a franchi un palier en mars 2026. FlashAttention 4 (arXiv 2603.05451, Tri Dao — Together AI) atteint 1 613 TFLOPS/s à 71 % d’utilisation sur les 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. Blackwell — 1,5 à 2× le débit de FA3 sur les longues séquences. La différence clé : FA4 est forward-only, conçu exclusivement pour l’inférence, sans le backward pass de l’entraînement. En se débarrassant de la moitié du problème, il récupère le budget registre et la bande passante L2 que le backward accaparait.
vLLM 0.20 l’utilise comme backend MLA par défaut pour le prefill sur les GPU SM90+ (Hopper et Blackwell). Le lien avec le KV cache est direct : plus le prefill est rapide, moins le temps de remplissage du cache pèse dans le TTFT — ce qui rend le prefix caching moins critique sur les séquences courtes, et encore plus précieux sur les longues.
La hiérarchie mémoire du KV cache : KVBM G1→G4
Jusqu’à 2025, le KV cache vivait en HBM ou n’existait pas. L’offloading CPU existait en prototype (vLLM, LMCache), mais sans gestion de tiers, sans politique de migration, sans stockage persistant. Le cache était un objet éphémère, détruit à la fin de la requête.
NVIDIA Dynamo 1.0, en disponibilité générale depuis le 16 mars 2026, change radicalement cette posture. Son sous-système KVBM (KV Block Manager) organise le cache dans une hiérarchie de stockage à quatre niveaux, qui emprunte sa logique aux hiérarchies mémoire des CPU — L1 / L2 / L3 / DRAM — mais à l’échelle du datacenter.
G1 — HBM GPU. Le tier chaud, celui où le cache vit pendant le calcul d’attention. Latence d’accès de l’ordre de la microseconde, bande passante de plusieurs To/s. C’est le tier que PagedAttention gère depuis 2023 — la différence est que KVBM le traite comme un étage parmi quatre au lieu du seul espace de vie du cache.
G2 — CPU RAM, potentiellement distribuée. Le cache d’une requête terminée ou interrompue migre en RAM hôte au lieu d’être détruit. Si une requête ultérieure présente le même préfixe, le cache remonte en G1 sans recalcul. Le coût : un aller-retour PCIe, de l’ordre de la milliseconde pour un bloc typique. Dynamo distribue le G2 à travers plusieurs nœuds CPU — le cache d’un préfixe n’est pas limité à la RAM locale, il est accessible depuis n’importe quel nœud du cluster.
G3 / G3.5 — SSD locaux et ICMS. Pour les caches dont la fréquence de réutilisation ne justifie plus la RAM, KVBM descend au stockage flash. Le tier G3 standard utilise des NVMe locaux ou poolés. Le tier G3.5 est une spécificité de la plateforme Vera Rubin : ICMS (Inference Context Memory Storage), un stockage flash intégré aux BlueField-4 DPU et piloté par le framework DOCA Memos. ICMS est dimensionné pour le KV cache — pas pour le stockage générique — et offre un chemin de données qui court-circuite le CPU hôte via la NIC.
G4 — Object storage distant. Le tier d’archive : S3, Azure Blob Storage. Un cache de session longue — contexte d’un agent sur plusieurs heures, historique d’un workflow RAG — persiste en G4 et se recharge à la demande. La latence d’accès se mesure en dizaines de millisecondes, mais le recalcul du préfixe aurait coûté des secondes. L’offloading G4 fait partie de la release Dynamo 1.0 de mars 2026 — ce n’est pas une fonctionnalité ajoutée après coup.
La politique de migration entre tiers est gouvernée par la fréquence de réutilisation des blocs. Un bloc référencé une seule fois descend vite vers G3/G4 ; un bloc que plusieurs requêtes partagent (system prompt, document RAG ancré) reste en G1 ou G2. C’est exactement la logique d’un cache CPU avec politique LRU étendue — mais appliquée à des blocs de dizaines de mégaoctets au lieu de lignes de 64 octets.
SGLang : HiSparse et HiCache
SGLang 0.5.12 attaque la même hiérarchie par deux systèmes distincts, chacun ciblant un segment du problème.
HiSparse s’occupe de l’offloading GPU → CPU pour les modèles qui supportent l’attention sparse — à ce jour, DeepSeek-V3.2 et GLM-5.1, qui utilisent l’architecture DSA (DeepSeek Sparse Attention). Le mécanisme est proactif : HiSparse identifie les entrées inactives du KV cache avant qu’elles ne saturent le HBM et les déplace en mémoire hôte, tout en maintenant un buffer chaud en HBM pour les entrées à haute fréquence d’accès. L’effet mesuré : plus de 3× le débit de base à 256 requêtes concurrentes, jusqu’à 5× sur les contextes longs. La première description publique date du blog LMSYS du 10 avril 2026.
HiCache est un système séparé — et plus large. Il implémente un UnifiedRadixTree avec support de l’attention glissante (Sliding Window Attention), ce qui permet de gérer des modèles à fenêtre d’attention fixe (DeepSeek V4 inclus) dans un arbre de cache partagé. L’offloading SSD passe par le Mooncake store, un moteur de transfert de cache distribué qui intervient aussi dans TensorRT-LLM. HiCache et HiSparse sont complémentaires, pas alternatifs : HiSparse gère la migration GPU↔CPU, HiCache gère la hiérarchie cache étendue jusqu’au SSD.
Connecteurs de transfert : le KV cache en transit
Dans un pipeline de serving disaggregé — où un nœud fait le prefill et un autre le decode — le KV cache doit voyager. Un modèle de 70 milliards de paramètres avec 8k tokens de contexte produit ~2,6 Go de KV cache en FP16 ; en 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). , c’est encore des centaines de mégaoctets à transférer entre nœuds avant que le decode puisse commencer. Sans un protocole optimisé, ce transfert annule le gain de la disaggregation Séparation du pipeline d'inférence en phases distinctes (prefill, decode) exécutées sur des nœuds spécialisés. Permet d'affecter du matériel compute-bound au prefill et du matériel memory-bound au decode, au lieu de faire tourner les deux sur le même GPU sous-utilisé sur l'une des deux phases. .
Trois connecteurs ont émergé en parallèle.
KV Cache Connector API (TensorRT-LLM). Introduite dans TRT-LLM v1.1 — pas v1.3, qui affine l’implémentation — cette API standardise les opérations de sérialisation, transfert et restauration du cache. La v1.3 rc12 ajoute des raccourcis pour lmcache et kvbm ; la rc15 introduit un cache_salt_id pour identifier les blocs de cache par signature plutôt que par adresse. Le KV cache devient un objet adressable, pas un buffer anonyme.
NIXL (vLLM). Le connecteur de transfert interne de vLLM, redessiné dans la version 0.21 (mai 2026) pour supporter les transferts bi-directionnels entre nœuds P (prefill) et D (decode). La v0.21 ajoute aussi le MooncakeStoreConnector pour l’offloading distribué, et le support DCP/PCP dans le connecteur d’offloading.
LMCache. Projet indépendant qui intègre CacheGen (compression du KV cache), offloading CPU, et cache distribué. Compatible avec vLLM. L’approche est complémentaire : LMCache compresse avant le transfert, ce qui réduit la bande passante inter-nœuds nécessaire.
CacheBlend (EuroSys 2025) complète le tableau par un mécanisme de réutilisation sélective : au lieu de recalculer le KV cache d’un document RAG à chaque requête, CacheBlend restaure les parties préexistantes et ne recalcule que les tokens nouveaux. Résultat mesuré : 2,2 à 3,3× de réduction du TTFT sur les charges RAG.
Le routage KV-aware : le scheduler change de critère
Tous ces mécanismes de stockage et de transfert seraient inutiles si le scheduler continuait à router les requêtes sans tenir compte de l’état du cache. C’est la dernière pièce du puzzle — et celle qui produit les gains les plus spectaculaires.
Le plugin Kubernetes Inference Gateway de Dynamo 1.0 intègre un algorithme de routage token-aware. Au lieu d’affecter une requête au nœud le moins chargé (round-robin pondéré, la norme), le routeur vérifie d’abord quels nœuds possèdent déjà le KV cache du préfixe de la requête entrante. Si un nœud en G1 ou G2 détient le cache du system prompt ou du document RAG, la requête y est envoyée directement — le prefill du préfixe est court-circuité, et le TTFT chute.
NVIDIA mesure 20× de réduction du TTFT et 4× de réduction de la latence bout-en-bout sur les charges à préfixes récurrents. Baseten, dans un déploiement Dynamo sur Qwen3 Coder 480B avec des prompts de ~50k tokens, rapporte 50 % de réduction du TTFT, 61 % de gain en requêtes par seconde, et 62 % de gain en tokens par seconde. Le titre de leur blog annonce « 2x faster inference » — c’est spécifiquement le TTFT qui est divisé par deux, pas le débit général.
Comparatif : le KV cache par runtime
| Fonctionnalité | vLLM 0.20-0.21 | SGLang 0.5.12 | TRT-LLM v1.1-1.3 | Dynamo 1.0 |
|---|---|---|---|---|
| Quantification KV FP8 | ✓ | ✓ | ✓ | ✓ (via runtime) |
| TurboQuant ~3 bits | ✓ (v0.20, PR #38479) | — | — | — |
| Attention sparse (RocketKV) | — | HiSparse (DSA) | ✓ (backend sparse) | — |
| FlashAttention 4 (prefill) | ✓ (SM90+, défaut) | — | — | — |
| Offloading CPU intelligent | ✓ (fréquence de réutilisation) | ✓ (HiSparse) | ✓ (host offloading) | G2 (KVBM) |
| Offloading SSD | — | ✓ (HiCache + Mooncake) | — | G3 / G3.5 (KVBM) |
| Offloading object storage | — | — | — | G4 (S3 / Azure Blob) |
| Transfert P/D (disaggregation) | ✓ (NIXL, bi-directionnel) | — | ✓ (KV Cache Connector API) | ✓ (KVBM + NIXL) |
| Routage KV-aware | — | — | — | ✓ (K8s Inference Gateway) |
| FlexKV (longueur variable) | ✓ (v0.17.2+, Tencent TACO) | — | — | — |
| Prefix caching automatique | ✓ | ✓ | ✓ | ✓ |
Si vous dimensionnez votre stack de serving, trois lectures se dégagent. vLLM concentre les innovations de quantification (TurboQuant, FlexKV, FA4) — c’est le runtime où le cache est le plus compressé par entrée. SGLang concentre les innovations de hiérarchie locale (HiSparse + HiCache) — c’est le runtime qui pousse le cache le plus loin hors du GPU, mais pour un sous-ensemble de modèles. Dynamo apporte la coordination au niveau cluster — KVBM + routage KV-aware — et se branche sur vLLM ou TRT-LLM comme runtime sous-jacent. TRT-LLM fournit l’API de connecteur standardisée et le backend RocketKV, mais délègue l’orchestration à Dynamo.
vLLM 0.21 et le pipeline P/D complet
La version 0.21 de vLLM (15 mai 2026) marque le moment où le KV cache devient un objet de première classe dans le pipeline disaggregé. L’intégration HMA (Heterogeneous Memory Architecture) avec le sous-système d’offloading unifie les chemins mémoire : un bloc KV suit une trajectoire G1 → CPU → retour G1 sans changement de format. Les transferts bi-directionnels entre nœuds P et D passent par le connecteur NIXL redessiné — un nœud de decode peut désormais renvoyer du cache vers un nœud de prefill, pas seulement en recevoir.
Le MooncakeStoreConnector ouvre l’offloading distribué : le cache d’un nœud P peut transiter par le store Mooncake vers un nœud D distant, sans passer par la RAM hôte du nœud P. Et le support DCP/PCP dans le connecteur d’offloading prépare le terrain pour les architectures où les nœuds de prefill et de decode ne sont pas sur le même réseau physique.
Le backend d’attention TOKENSPEED_MLA, optimisé pour les GPU Blackwell, complète le tableau en accélérant le calcul MLA (Multi-Latent Attention, l’architecture d’attention de DeepSeek V3/V4) sur le matériel le plus récent.
Le multimodal étend la hiérarchie
Dynamo 1.0 ne se limite pas au texte. Son pipeline multimodal E/P/D (Embedding / Prefill / Decode) ajoute un troisième tier de cache : l’embedding cache pour les représentations visuelles pré-calculées. Sur Qwen3-VL-30B-A3B-Instruct en FP8 sur GB200, NVIDIA mesure +30 % de réduction du TTFT et +25 % de débit sur les requêtes image — un gain qui provient entièrement du fait que l’embedding visuel, coûteux à calculer, n’est calculé qu’une fois.
La vidéo suit la même logique. FastVideo + SGLang Diffusion génère une vidéo 1080p de 5 secondes en ~4,5 s sur un seul B200 — un débit qui rend le temps-réel plausible pour la première fois sur du matériel datacenter standard.
Ce qui vient : BlueField-4 et le cache comme infrastructure réseau
La plateforme Vera Rubin inscrit le KV cache dans le silicium réseau. Le BlueField-4 DPU, annoncé au CES en janvier 2026 et attendu au second semestre 2026, intègre DOCA Memos — un framework de communication et de stockage du KV cache directement dans le DPU. Le tier G3.5 (ICMS) n’est pas un SSD que le DPU adresse : c’est du stockage flash embarqué dans la carte réseau, accessible sans traverser le CPU hôte ni le bus PCIe principal.
Le KV cache y est traité comme un objet réseau, pas comme une donnée applicative. Le DPU peut le router, le répliquer, le compresser sur le chemin de données — de la même façon qu’un switch réseau intelligent manipule des paquets sans que le CPU s’en mêle. C’est la prochaine frontière : le cache n’est plus seulement géré par le runtime, il est transporté par l’infrastructure réseau elle-même.
Le silicium se réorganise lui aussi autour du cache, et pas seulement chez NVIDIA : le TPU 8i de Google a triplé sa SRAM on-chip (384 Mo) précisément pour loger un plus gros KV cache au plus près du calcul — voir la pile TPU et ses puces 8t/8i.
MLPerf v6.0 : le cache dans les résultats officiels
Le cycle MLPerf Inference v6.0 (1ᵉʳ avril 2026) apporte une confirmation indirecte mais significative. Les soumissions NVIDIA sur B200 utilisent le KV cache en FP8 comme configuration de référence — pas en FP16, pas en FP32. C’est la première fois qu’un format de cache réduit apparaît dans les soumissions de benchmark officielles comme baseline, pas comme optimisation optionnelle. AMD, de son côté, utilise un pre-shuffled KV layout — un agencement mémoire pré-optimisé du cache pour réduire les conflits de banque HBM. Même chez les challengers, le cache est devenu un axe d’optimisation de premier plan.
Conclusion
La trajectoire du KV cache en 2026 suit celle que la mémoire cache CPU a tracée dans les années 90 : un résidu de performance devenu un sous-système à part entière, avec sa propre hiérarchie, ses propres politiques, et ses propres primitives de communication. Les prochaines étapes sont visibles. Le pre-shuffled KV layout d’AMD et la compression CacheGen de LMCache annoncent une convergence vers des formats de cache standardisés — un GGUF du KV cache, transportable entre runtimes. DOCA Memos et le BlueField-4 inscrivent le cache dans le DPU, ce qui déplace la frontière de gestion du runtime vers le réseau. Et le routage KV-aware de Dynamo pose la question suivante : si le scheduler connaît l’état du cache de chaque nœud, le prochain pas n’est-il pas un marché du cache — où un nœud qui a investi du compute dans un préfixe le vend aux nœuds qui en ont besoin, au lieu de le laisser mourir ?
Sources et méthode
TurboQuant. Hooper et al., ICLR 2026, arXiv 2504.19874. vLLM intégration : PR #38479 (15 avril 2026), PR #40092 (extension FA3/FA4). Blog vLLM « First Comprehensive Study of TurboQuant » (11 mai 2026). Les chiffres de 6× réduction mémoire et 8× accélération attention sont les claims papier, baseline FP32 — fait vérifié (papier + reproduction vLLM).
RocketKV. Zhang et al., ICML 2025, arXiv 2502.14051. 3× decode speedup et 31 % réduction mémoire de pointe sur H100 — fait vérifié (papier). Intégration TRT-LLM comme backend sparse — fait vérifié (release notes TRT-LLM).
FlashAttention 4. Dao, arXiv 2603.05451, mars 2026. 1 613 TFLOPS/s, 71 % utilisation, 1,5-2× vs FA3 — fait vérifié (papier). Backend par défaut vLLM 0.20 pour MLA prefill SM90+ — fait vérifié (release notes vLLM 0.20).
vLLM 0.20 / 0.21. Release notes : vLLM 0.20.0 (27 avril 2026), vLLM 0.21.0 (15 mai 2026). FlexKV (PR #34328, Tencent TACO) livré depuis v0.17.2, pas introduit dans v0.20 — fait vérifié. Smart CPU offloading (PR #35342) apparu dans v0.18.0 — fait vérifié.
SGLang 0.5.12 — HiSparse et HiCache. Blog LMSYS, 10 avril 2026 : HiSparse. 3-5× throughput sur 256 requêtes concurrentes (charges DSA) — fait vérifié (blog LMSYS). HiSparse et HiCache sont des systèmes distincts, non interchangeables — fait vérifié (release notes SGLang 0.5.12).
NVIDIA Dynamo 1.0 — KVBM. Blog NVIDIA Developer : Dynamo 1.0 Production Ready (16 mars 2026). Tiers G1-G4, offloading S3/Azure Blob — fait vérifié (blog officiel). Routage token-aware : 20× TTFT, 4× latence e2e — fait vérifié (blog officiel, charge à préfixes récurrents).
Baseten. Blog : How Baseten Achieved 2x Faster Inference with NVIDIA Dynamo. 50 % réduction TTFT, 61 % RPS, 62 % TPS sur Qwen3 Coder 480B (~50k tokens input). Le « 2× » est spécifiquement le TTFT — fait vérifié (blog Baseten, mai 2026).
TensorRT-LLM — KV Cache Connector API. Introduite dans TRT-LLM v1.1, pas v1.3 — fait vérifié (release notes v1.1). v1.3 rc12 : raccourcis lmcache/kvbm ; rc15 : cache_salt_id — fait vérifié (changelogs GitHub).
BlueField-4 et DOCA Memos. Annonce CES janvier 2026. ICMS (Inference Context Memory Storage) et DOCA Memos — fait vérifié (communiqué NVIDIA CES 2026). Disponibilité H2 2026 — fait vérifié (roadmap officielle).
CacheBlend. EuroSys 2025. 2,2-3,3× réduction TTFT sur charges RAG — fait vérifié (papier EuroSys).
MLPerf v6.0. 1ᵉʳ avril 2026. FP8 KV cache dans soumissions NVIDIA B200, pre-shuffled KV layout AMD — fait vérifié (résultats MLPerf publics).
Multimodal Dynamo. +30 % TTFT, +25 % throughput sur Qwen3-VL-30B/GB200 (requêtes image) — fait vérifié (blog NVIDIA Dynamo). FastVideo 1080p 5s en ~4,5s sur un B200 — fait vérifié (démo NVIDIA).
Taux de conversion indicatif : 1 USD ≈ 0,92 EUR (mi-2026). Aucune valeur monétaire n’apparaît dans cet article.
