NVIDIA a présenté SPEED-Bench — un benchmark unifié pour le speculative decoding

NVIDIA a présenté SPEED-Bench sur Hugging Face — un nouveau benchmark pour le speculative decoding, une technique d’accélération de l’inference des grands modèles de langage. Son objectif est de mesurer non pas des pics de performance en laboratoire, mais le comportement des modèles et des inference engines sur des tâches plus proches de l’exploitation réelle.

Comment fonctionne SPEED-Bench

Les auteurs partent d’un problème simple : les tests existants sont fragmentés. Certains évaluent la qualité du draft model sur des échantillons trop petits, d’autres mesurent le throughput sur des prompts courts et avec un batch size de 1, d’autres encore dépendent d’une stack spécifique qui reflète mal la production. Résultat : il est difficile de comparer entre elles les méthodes de speculative decoding. Un même algorithme peut paraître excellent sur un toy dataset et nettement moins bon sur de longs contextes ou sous forte concurrence de requêtes.

SPEED-Bench est divisé en deux parties et complété par un framework de mesure unifié. Le qualitative split comprend 880 prompts issus de 18 sources publiques, répartis en 11 catégories — de coding et math à roleplay, RAG, summarization et multilingual. Chaque catégorie contient 80 exemples, sélectionnés pour réduire la duplication sémantique et couvrir un maximum de scénarios différents. Pour cette sélection, les auteurs ont généré des embedding des candidats avec le modèle text-embedding-3-small et minimisé la similarité moyenne par paires à l’intérieur de chaque catégorie.

• Qualitative split mesure l’acceptance rate et l’acceptance length selon différents domaines
• Throughput split vérifie la vitesse sur des séquences d’entrée de 1k à 32k tokens
• Pour chaque longueur, il existe trois niveaux de difficulté : low-, mixed- et high-entropy
• Un bucket contient 1 536 prompts, ce qui permet de construire des courbes de throughput stables jusqu’à un batch size de 512
• Le framework fonctionne avec TensorRT-LLM, vLLM et SGLang

Le problème de la comparaison équitable entre engines est également traité séparément. Les différents systèmes d’inference appliquent différemment les chat templates, les BOS tokens et la tokenization, si bien qu’un même modèle peut recevoir des entrées légèrement différentes. Dans SPEED-Bench, la préparation du prompt est externalisée : les engines reçoivent des séquences déjà pretokenized. Cela réduit l’impact des différences d’implémentation et permet de comparer les algorithmes de speculative decoding eux-mêmes, plutôt que les effets secondaires du preprocessing. Le framework relève aussi une télémétrie détaillée sur la step latency, le user TPS et l’output throughput global.

Ce qu’ont montré les tests

Les premiers résultats montrent que le speculative decoding dépend fortement du type de tâche. Dans les domaines à faible entropie, comme coding et math, l’acceptance length est plus élevée : le drafter a plus de facilité à prédire les tokens suivants. Dans des tâches plus ouvertes, comme roleplay et writing, les métriques sont plus faibles. Dans les exemples de l’article, les MTP-heads natifs de Qwen3-Next donnent une acceptance length moyenne de 2,81, EAGLE3 sur GPT-OSS 120B atteint 2,25, et N-Gram sur Llama 3.3 70B atteint 1,41 ; en parallèle, N-Gram avec un batch size de 32 bascule même vers un ralentissement moyen de 0,88x au lieu d’une accélération.

Une autre conclusion concerne les optimisations agressives. Les auteurs examinent séparément le vocabulary pruning dans EAGLE3 — une technique qui réduit le coût de la projection finale. En coding et math, son effet est presque imperceptible, mais sur la longue traîne des requêtes utilisateur, en particulier dans multilingual, RAG et summarization, l’acceptance length baisse davantage. Autrement dit, une optimisation qui semble anodine sur un dataset étroit peut dégrader le comportement réel sur un ensemble de tâches plus large.

L’observation la plus pratique concerne les synthetic workloads. Dans l’industrie, il reste courant de faire tourner l’inference sur des tokens aléatoires, mais pour le speculative decoding ce mode fausse l’image. Le modèle reconnaît le bruit, répond de manière stéréotypée et augmente artificiellement l’acceptance length. Dans les mesures de SPEED-Bench, cela conduit à surestimer le throughput d’environ 23 % par rapport à des workloads réalistes. Pour les équipes, c’est un signal direct : les benchmarks synthétiques peuvent conduire à un mauvais choix de draft length, voire du schéma d’accélération tout entier.

Ce que cela signifie

SPEED-Bench est une tentative pour rapprocher l’évaluation du speculative decoding de ce qui compte réellement pour les équipes qui exploitent des LLM en production : longs contextes, batch sizes élevés, domaines variés et conditions comparables entre engines. Si le benchmark s’impose, la discussion sur l’accélération des LLM se déplacera des beaux chiffres obtenus sur des tests synthétiques vers des données reproductibles montrant précisément où l’accélération fonctionne et où elle ne fonctionne pas. Pour les équipes infra et research, c’est plus utile qu’un nouveau record sur un seul dataset pratique.