NVIDIA представила SPEED-Bench — единый бенчмарк для спекулятивного декодирования

NVIDIA на площадке Hugging Face представила SPEED-Bench — новый бенчмарк для speculative decoding, техники ускорения вывода больших языковых моделей. Его задача — измерять не лабораторные пики производительности, а поведение моделей и inference-движков на задачах, которые ближе к реальной эксплуатации.

Как устроен SPEED-Bench Авторы исходят из простой проблемы: существующие тесты фрагментированы.

Одни оценивают качество draft-модели на слишком маленьких выборках, другие гоняют throughput на коротких промптах и batch size 1, третьи зависят от конкретного стека, который плохо отражает прод. В итоге сравнивать методы speculative decoding между собой сложно: один и тот же алгоритм может выглядеть отлично на игрушечном датасете и заметно хуже на длинных контекстах или при высокой конкуренции запросов. SPEED-Bench разбит на две части и дополнен единым фреймворком измерений.

В qualitative-сплите 880 промптов из 18 публичных источников, разложенных по 11 категориям — от coding и math до roleplay, RAG, summarization и multilingual. В каждой категории по 80 примеров, отобранных так, чтобы снизить семантическое дублирование и покрыть как можно больше разных сценариев. Для отбора авторы эмбеддили кандидатов моделью text-embedding-3-small и минимизировали среднюю попарную близость внутри категории.

• Qualitative split измеряет acceptance rate и acceptance length по разным доменам Throughput split проверяет скорость на входных последовательностях от 1k до 32k токенов Для каждой длины есть три уровня сложности: low-, mixed- и high-entropy В одном бакете 1 536 промптов, что позволяет строить стабильные кривые throughput при batch size до 512 Фреймворк умеет работать с TensorRT-LLM, vLLM и SGLang Отдельно решена проблема честного сравнения движков. Разные inference-системы по-разному применяют chat templates, BOS-токены и токенизацию, из-за чего одна и та же модель может получать слегка разные входы. В SPEED-Bench подготовка промпта вынесена наружу: движки получают уже претокенизированные последовательности. Это снижает влияние служебных различий и позволяет сравнивать сами алгоритмы speculative decoding, а не побочные эффекты препроцессинга. Фреймворк также снимает детальную телеметрию по step latency, user TPS и общему output throughput.

Что показали тесты

Первые результаты показывают, что speculative decoding сильно зависит от типа задачи. В доменах с низкой энтропией, вроде coding и math, acceptance length выше: драфтеру проще угадать следующие токены. В более открытых задачах, таких как roleplay и writing, показатели ниже.

На примерах из статьи нативные MTP-heads у Qwen3-Next дают среднюю acceptance length 2.81, EAGLE3 на GPT-OSS 120B — 2.25, а N-Gram на Llama 3.

3 70B — 1.41; при этом N-Gram на batch size 32 вообще уходит в средний slowdown до 0.88x вместо ускорения.

Ещё один вывод касается агрессивных оптимизаций. Авторы отдельно смотрят на vocabulary pruning в EAGLE3 — технику, которая снижает стоимость финальной проекции. На coding и math её эффект почти незаметен, но на длинном хвосте пользовательских запросов, особенно в multilingual, RAG и summarization, acceptance length проседает сильнее.

То есть оптимизация, которая выглядит безобидно на узком датасете, может ухудшить реальное поведение на более широком наборе задач. Самое практичное наблюдение связано с synthetic workloads. В индустрии по-прежнему популярно прогонять inference на случайных токенах, но для speculative decoding такой режим искажает картину.

Модель распознаёт шум, отвечает шаблонно и искусственно повышает acceptance length. В измерениях SPEED-Bench это приводит к завышению throughput примерно на 23% по сравнению с реалистичными workload'ами. Для команд это прямой сигнал: synthetic-бенчи могут привести к неверному выбору draft length или даже всей схемы ускорения.

Что это значит SPEED-Bench — это попытка сделать оценку speculative

decoding ближе к тому, что действительно важно для команд, которые обслуживают LLM в проде: длинные контексты, высокие batch size, разные домены и сравнимые условия между движками. Если benchmark приживётся, обсуждение ускорения LLM сместится от красивых цифр на synthetic-тестах к воспроизводимым данным о том, где именно ускорение работает, а где нет. Для infra- и research-команд это полезнее, чем очередной рекорд на одном удобном датасете.