La course à l’inférence ne se résume plus uniquement à « combien de tokens par seconde » une GPU peut traiter sur un prompt court. En 2026, le nouveau terrain de bataille est le contexte long : des modèles capables de lire des bases de code entières, de conserver une mémoire sur des flux agéntiques et de répondre avec une faible latence en permettant au prompt de croître jusqu’à des tailles auparavant jugées hors de portée pour la production.

Dans ce contexte, LMSYS (l’équipe derrière des développements et évaluations très suivies dans l’écosystème du serving) a publié des résultats de performance de DeepSeek fonctionnant sur du NVIDIA GB300 NVL72 (Blackwell Ultra), en le comparant avec le GB200 NVL72. La conclusion est claire : dans une utilisation à contexte long (128 000 tokens en entrée et 8 000 en sortie), le système atteint 226,2 TPS/GPU, ce qui représente 1,53× la performance du GB200 en pic. Cette avancée devient encore plus frappante lorsqu’on analyse l’expérience utilisateur et la dégradation sous contraintes de latence, deux enjeux clés pour les agents et assistants de programmation.

Une infrastructure entière comme unité de mesure (et non une GPU isolée)

Le GB300 NVL72 n’est pas une simple carte, mais un gros système en rack : 72 GPUs Blackwell Ultra combinées à 36 CPUs Grace, avec une interconnexion conçue pour faire fonctionner tout cela comme une « usine » d’inférence. NVIDIA le présente comme une plateforme conçue pour accélérer l’attention et le raisonnement en environnements exigeants, où la mémoire et la bande passante deviennent aussi cruciales que la puissance de calcul.

C’est précisément là où le contexte long bouleverse les règles : le goulet d’étranglement se déplace souvent vers le KV cache (la mémoire que le modèle utilise pour « se souvenir » du contexte pendant la génération) et la capacité de la mémoire HBM (mémoire à haut débit) qui doit supporter un volume accru de requêtes simultanées sans expulsion de l’état.

Ce qu’a mesuré LMSYS et pourquoi c’est essentiel

LMSYS a évalué DeepSeek-R1 dans un scénario typique de contexte long : une entrée massive (ISL de 128 000) et une sortie pertinente (OSL de 8 000). Pour cela, ils ont appliqué des techniques déjà considérées comme « manuelles » dans le serving moderne, mais finement ajustées pour tirer parti du hardware :

• Prefill-Decode (PD) Disaggregation : dissocier la phase de pré-remplissage (traitement du prompt) de la phase de décodage (génération des tokens) afin d’éviter qu’un seul nœud ne devienne le goulet d’étranglement.
• Chunking dynamique : diviser le pré-remplissage en blocs et chevaucher le traitement pour réduire le TTFT (Time To First Token), un indicateur reflétant la rapidité à commencer la réponse, cruciale pour une expérience fluide.
• MTP (Multi-Token Prediction) : une technique visant à améliorer la performance par utilisateur tout en maintenant le throughput global, essentielle pour obtenir des réponses rapides dans des flux agéntiques.

Les chiffres : pic, par-utilisateur et scénarios sous latence

Dans leur section « Highlights », LMSYS résume ce qui attire le plus l’attention : 226,2 TPS/GPU sur GB300 sans MTP, contre 147,9 TPS/GPU sur GB200. Avec MTP, le throughput total reste élevé, mais la véritable percée concerne la vitesse perçue par chaque utilisateur : la rapidité de chaque session.

Tableau 1 — Résultats clés (contexte long 128 000/8 000)

LMSYS signale également une autre donnée importante pour la production : lorsqu’ils égalisent les conditions de latence et ajustent des configurations comparables, GB300 offre entre 1,38× et 1,58× plus de TPS/GPU selon le scénario, avec une avantage accru dans les cas sensibles à la latence (où la dégradation est plus rapide). Par exemple, dans leur scénario « latence-}nthroughput équilibré », la progression sans MTP atteint jusqu’à 1,58×.

Tableau 2 — Gains sous contraintes de latence (scénarios représentatifs)

Pourquoi GB300 est en tête : plus de mémoire pour plus de sessions actives

Dans le contexte long, ce qui limite le système n’est plus tant la « puissance brute » de calcul, mais plutôt le nombre de requêtes simultanées qu’il peut maintenir en mémoire sans rétractation (retraction). LMSYS souligne explicitement ce point : GB300 possède 1,5× plus de HBM (288 GB contre 192 GB), ce qui lui permet d’augmenter le batch de décodage et de gérer une plus grande concurrence avec moins de pénalisation.

Autrement dit : ce n’est pas uniquement une question de rapidité, mais aussi de résilience face au trafic intensif, où le contexte ne peut pas toujours tenir dans un espace étroit.

TTFT : la durée jusqu’au premier token s’améliore aussi

Le prefill de 128 000 tokens est souvent le moment où beaucoup d’assistants deviennent lents ou « se figent ». Pour y remédier, LMSYS emploie le chunking et affiche un meilleur cas avec 32 000 tokens en chunks dynamiques, atteignant ainsi 8,6 secondes de TTFT. Sans cette technique, le TTFT dépasse 15 secondes sur les deux systèmes, ce qui explique pourquoi ces méthodes sont devenues indispensables dans les déploiements sérieux.

Tableau 3 — TTFT lors d’un pré-remplissage long (128 000 tokens)

L’évident : énergie, coûts et le « prix du rack »

La comparaison GB300 vs GB200 se concentre sur la performance, mais le marché s’intéresse aussi au coût total : énergie, amortissement et déploiement. Deux narratifs parallèles émergent :

• NVIDIA affirme, en s’appuyant sur des données de SemiAnalysis InferenceX et analyses tierces, que GB300 peut offrir jusqu’à 50× plus de throughput par mégawatt et jusqu’à 35× moins coûteux par token par rapport à Hopper dans certains scénarios, tout en préconisant une meilleure économie pour les longues sessions.
• Mais, même dans les milieux spécialisés applaudissant cette montée en performance, la prudence demeure : il n’y a pas encore de chiffres publics complets sur le TCO comparé entre GB300 et GB200 dans tous les cas de figure, et le déploiement d’un rack de cette envergure reste un coût important.

En résumé, les données de LMSYS indiquent que Blackwell Ultra s’impose dans le domaine de l’agent long contexte et faible latence, mais la discussion sur le coût réel se jouera davantage sur les chiffres concrets de facture et la disponibilité que sur des graphiques.

Questions fréquentes

Que signifie “contexte long 128 000/8 000” dans l’inférence de modèles comme DeepSeek ?
Cela indique que le système peut traiter des entrées allant jusqu’à 128 000 tokens et générer des sorties jusqu’à 8 000 tokens, ce qui correspond à un usage courant dans les assistants de programmation lisant beaucoup de code avant de répondre.

Qu’est-ce que le PD Disaggregation (Prefill-Decode) et comment améliore-t-il la performance ?
Il s’agit d’une architecture qui divise le traitement du prompt (pré-remplissage) de celui de la génération de tokens (décodage) dans des nœuds séparés, réduisant ainsi les goulets d’étranglement pour permettre une meilleure scalabilité et une latence plus faible.

Quels bénéfices apporte MTP (Multi-Token Prediction) en contexte de production ?
Selon LMSYS, MTP augmente significativement la performance par utilisateur (TPS/User) tout en maintenant le throughput global, rendant chaque session plus réactive sans saturer le système.

Pourquoi la mémoire HBM est-elle si critique dans le contexte long ?
Parce que le cache KV grandit avec le contexte, et s’il ne peut pas tout contenir, le système doit rétracter ou expulser du mémoire, dégradant latence et throughput. Plus de HBM permet une gestion plus efficace de cette mémoire, offrant une meilleure résilience à forte charge.

via wccftech