Спекулятивное декодирование: ускорение инференса LLM на 20–50%

Модель 70B генерирует один токен за один прямой проход (forward pass), и каждый проход перезагружает веса из видеопамяти (VRAM), вычисляет внимание (attention) для всего контекста и синхронизирует память. Между токенами GPU простаивает, ожидая разрешения последовательных зависимостей.

На H100 модель 70B генерирует один токен каждые 30–50 мс. У GPU есть вычислительная мощность для обработки нескольких токенов параллельно, но последовательная зависимость этому мешает: каждый токен зависит от предыдущего, и конвейер останавливается.

Спекулятивное декодирование разрушает это узкое место, позволяя генерировать несколько токенов за время, которое обычно требуется для генерации одного, не изменяя распределение вывода. Получаемые вами токены статистически идентичны тем, которые вы получили бы при стандартном авторегрессионном декодировании; единственная разница — скорость их получения.

В этом руководстве рассматриваются механика процесса, варианты, доступные в 2026 году, компромиссы с процентом принятия (acceptance rate), а также практическая настройка в llama.cpp, vLLM, SGLang и TensorRT-LLM.

Как работает авторегрессионное декодирование (и почему оно медленное)

Прежде чем понять спекулятивное декодирование, нужно понять авторегрессионное ограничение, которое оно обходит. Стандартная авторегрессионная генерация обрабатывает токены последовательно:

1. Выполните прямой проход через модель с текущим контекстом.
2. Выберите (sample) следующий токен из выходного распределения.
3. Добавьте токен в контекст.
4. Повторите.

Каждый шаг требует полного прямого прохода — загрузки весов из видеопамяти, вычисления внимания для всего контекста и генерации одного токена. Для модели с 70 млрд параметров это занимает примерно 30–50 мс на токен на H100. У GPU есть свободные вычислительные ресурсы — она могла бы обрабатывать больше задач параллельно, — но последовательная зависность этому мешает.

Разрыв между вычислениями и видеопамятью

Современные GPU обладают большей производительностью (FLOPs), чем требуется для генерации одного токена, поэтому реальное узкое место — пропускная способность памяти: веса должны передаваться из видеопамяти в вычислительные модули для каждого прямого прохода. При генерации по одному токену GPU большую часть времени тратит на ожидание передачи данных из памяти, а не на полезные вычисления.

Спекулятивное декодирование решает эту проблему, предоставляя GPU больше задач на одну передачу данных из памяти. Вместо одного токена за прямой проход оно генерирует K токенов, распределяя затраты памяти на несколько выходов.

Механизм «черновик — проверка» (Draft-Verify)

Спекулятивное декодирование работает в повторяющихся циклах «черновик — проверка». Быстрый механизм создания черновика предлагает K candidate-токенов — из небольшой модели-черновика (draft model), поиска n-грамм или из головы предсказания (prediction head), присоединенной к целевой модели, — а целевая модель проверяет все K за один прямой проход. Фаза черновика дешевая, обычно составляя 5–20% от времени прямого прохода целевой модели, а проверка сравнивает каждый сформированный черновик с тем, что сгенерировала бы целевая модель, принимает самый длинный совпадающий префикс и выполняет повторный выбор (resampling) от первой точки отклонения.

Проверка K токенов обходится примерно так же, как генерация одного токена авторегрессионным методом, поэтому, когда черновик правильный, вы получаете K токенов за цену одного шага проверки.

Конкретный пример

Допустим, модель-черновик предлагает 5 токенов: ["I", " like", " cooking", " and", " traveling"]. Целевая модель проверяет их за один прямой проход:

Целевая модель принимает токены 1 и 2, затем генерирует " playing" для токена 3, производя три токена за один цикл вместо трех отдельных прямых проходов. Если бы черновик был верным до токена 5, вы получили бы пять токенов за цену одной проверки — ускорение в 5 раз только для этого цикла.

Узкое место проверки

На практике проверка занимает большую часть времени выполнения — от 42% до 95% цикла, в зависимости от метода и размера модели. Прямой проход целевой модели — это узкое место, а отклоненные токены представляют собой впустую потраченные вычисления.

Именно поэтому процент принятия так важен. Каждый отклоненный токен после первого — это впустую потраченная работа по проверке. Лучшие методы спекулятивного декодирования максимизируют ожидаемое количество принятых токенов за цикл, а не просто «сырой» процент принятия.

Математическая гарантия

Одно из самых важных свойств спекулятивного декодирования — то, что оно генерирует токены из точно такого же распределения, как и стандартная авторегрессионная выборка из целевой модели. Шаг проверки использует выборку с отклонением (rejection sampling): когда черновик предлагает токен x, целевая модель вычисляет свою вероятность p(x), а черновик вычисляет p_draft(x). Вероятность принятия составляет:

min(1, p(x) / p_draft(x))

Когда целевая модель согласна (p(x) ≥ p_draft(x)), токен всегда принимается. Когда целевая модель не согласна, токен принимается с вероятностью, пропорциональной отношению, а отклоненные токены выбираются заново из остаточного распределения:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

Эта процедура гарантирует, что выходная последовательность точно следует распределению целевой модели, поэтому спекулятивное декодирование является без потерь (lossless). Модель-черновик влияет на скорость, но не на качество — полученные вами токены статистически неотличимы от стандартного декодирования, с той же перплексией и распределением. Единственная разница — задержка.

Стратегии моделей-черновиков

Механизм черновика — это переменная, которая имеет наибольшее значение. Различные подходы имеют разные компромиссы между сложностью настройки, процентом принятия и ускорением.

Отдельные модели-черновики

Самый простой подход — загрузить меньшую модель наряду с целевой — обычно модель 1–3 млрд параметров для черновиков для целевой модели 7–70 млрд.

Плюсы:

• Концептуально понятно
• Работает с любой целевой моделью
• Модель-черновик может быть настроена, чтобы соответствовать распределению цели

Минусы:

• Требует загрузки второй модели в видеопамять (1–4 ГБ в зависимости от размера)
• Качество модели-черновика напрямую определяет процент принятия
• Черновики между семействами (например, Qwen для Llama) обычно дают низкие результаты

Практическое правило: Используйте модели из одного семейства. Gemma 2 2B хорошо работает как черновик для Gemma 2 27B. Llama 3.2 1B хорошо работает как черновик для Llama 3.1 70B. Черновики между семействами имеют тенденцию к низкому проценту принятия, поскольку распределения токенов расходятся.

Поиск совместимых моделей-черновиков

Не все небольшие модели работают как черновики для данной целевой модели. Критическим фактором является выравнивание распределений — насколько близко выходные вероятности модели-черновика совпадают с целевой.

Золотое правило: если процент принятия модели-черновика падает ниже 50%, спекулятивное декодирование может фактически замедлить процесс. Накладные расходы на запуск модели-черновика и проверку перевешивают преимущества, когда большинство предложений отклоняются.

EAGLE и EAGLE-3: Головы предсказания

EAGLE (Efficient Architecture Guided Language Model Estimation) устраняет необходимость в отдельной модели-черновике. Вместо этого он прикрепляет легкие авторегрессионные головы предсказания к внутренним слоям целевой модели.

Как работает EAGLE

EAGLE обучает головы предсказания, которые берут скрытые состояния (hidden states) из промежуточных слоев целевой модели и предсказывают будущие токены. Во время вывода:

1. Целевая модель выполняет прямой проход через свои слои.
2. На каждом слое голова EAGLE считывает скрытое состояние и предлагает токены для будущих позиций.
3. Несколько голов работают параллельно, каждая предсказывая разные будущие временные шаги.
4. Целевая модель проверяет все предложения за один проход.

Преимущество: головы EAGLE обучены специально соответствовать распределению целевой модели. Они напрямую видят внутренние представления цели, что дает им гораздо лучшее выравнивание, чем у отдельной модели-черновика.

Улучшения в EAGLE-3

EAGLE-3 (2025) улучшает подход с помощью трех ключевых изменений:

1. Выбор слоев: Вместо прикрепления голов к каждому слою EAGLE-3 использует байесовскую оптимизацию для выбора оптимального выходного слоя, уменьшая накладные расходы.
2. Многотокенное предсказание: Каждая голова предсказывает несколько токенов одновременно, увеличивая глубину черновика без пропорционального роста затрат на вычисления.
3. Эффективность обучения: EAGLE-3 обучается на собственных данных генерации целевой модели, улучшая процент принятия для рабочих нагрузок, соответствующих обучению (in-distribution).

Проценты принятия: EAGLE-3 обычно достигает 60–80% на рабочих нагрузках, соответствующих обучению, по сравнению с 40–60% для отдельных моделей-черновиков. На рабочих нагрузках генерации кода с высокой повторяемостью процент принятия может превышать 85%.

Настройка: Для EAGLE-3 требуются заранее обученные головы для вашей целевой модели. NVIDIA предоставляет головы EAGLE-3 для нескольких популярных моделей через TensorRT-LLM и коллекцию модулей спекулятивного декодирования на HuggingFace. Сторонние реализации существуют для vLLM и SGLang.

P-EAGLE: Параллельное создание черновика (март 2026)

Основное ограничение EAGLE-3 — авторегрессионное создание черновика: каждый токен черновика зависит от предыдущего, поэтому генерация K токенов черновика требует K последовательных прямых проходов через голову черновика, и накладные расходы на черновик линейно растут с K. P-EAGLE снимает этот потолок, генерируя все K токенов черновика за один прямой проход через легкий 4-слойный черновик, обученный предсказывать до 10 токенов параллельно.

Результат: P-EAGLE обеспечивает ускорение до 1.69x по сравнению с базовым EAGLE-3 на реальных рабочих нагрузках на NVIDIA B200. Преимущество расширяется при более высоких значениях K — там, где последовательное создание черновика в EAGLE-3 становится узким местом, параллельное создание черновика в P-EAGLE не влечет дополнительных затрат.

Настройка в vLLM: Скачайте заранее обученную голову P-EAGLE с HuggingFace, установите "parallel_drafting": true в конфигурации vLLM и используйте тот же флаг --speculative-model — vLLM сделает остальное. P-EAGLE — это текущий уровень искусства (state-of-the-art) для спекулятивного декодирования на базе EAGLE, и если вы развертываете EAGLE в 2026 году, P-EAGLE — это вариант, который следует использовать.

Спекулятивное декодирование на n-граммах

Спекулятивное декодирование на n-граммах заменяет нейронный черновик сопоставлением паттернов с историей промпта. Алгоритм ищет повторяющиеся последовательности n-грамм в контексте, и когда текущая последовательность токенов совпадает с ранее увиденным паттерном, он предлагает те токены, которые следовали за этим паттерном ранее. Например, если модель уже сгенерировала def calculate_total(items): и снова встречается def calculate_total(, она знает, что следующие токены, вероятно, будут items): на основе предыдущего вхождения.

Варианты карт n-грамм (ngram-map-k, ngram-map-k4v) используют хеш-таблицы для более быстрого поиска вместо линейного сканирования, где хеш-ключ — это текущая n-грамма размера N, а значение — последовательность токенов, следовавшая за ней.

Плюсы:

• Нулевые накладные расходы по видеопамяти — нет дополнительной модели для загрузки (~16 МБ для хеш-таблицы)
• Очень быстро для повторяющихся рабочих нагрузок (редактирование кода, рефакторинг, генерация шаблонов)
• Процент принятия может достигать 90%+ на рабочих нагрузках с высокой само-похожестью (self-similarity)

Минусы:

• Бесполезно для новой генерации — если паттерн не появлялся ранее, у n-грамм нечего предложить
• Процент принятия падает до нуля на творческих или разнообразных рабочих нагрузках
• Ограниченная глубина черновика (обычно 2–4 токена на совпадение)

Лучше всего подходит для: Рефакторинга кода, заполнения шаблонов, повторяющейся документации и любых рабочих нагрузок, где модель повторно посещает похожие паттерны. Хуже всего для: творческого письма, открытого чата и задач рассуждения.

Настройка параметров

Параметры n-грамм имеют большее значение, чем вы могли бы ожидать. Значения по умолчанию работают для кода, но текстовые рабочие нагрузки требуют корректировки:

Для текстовых рабочих нагрузок уменьшите size-n до 8–10 и увеличьте min-hits до 2. Это меняет частоту совпадений на более высокий процент принятия на каждое совпадение.

Само-спекулятивное декодирование

Само-спекулятивное декодирование (также называемое LayerSkip или self-speculation) использует собственные частичные вычисления модели в качестве черновика, поэтому отдельная модель не требуется.

Как это работает

Вместо запуска полной модели для каждого токена, само-спекулятивное декодирование запускает усеченную версию — пропуская некоторые трансформерные слои, — чтобы дешево генерировать токены черновика, а затем полная модель проверяет предложения.

Например, модель с 32 слоями может работать только с 16 слоями для черновика, а затем проверять всеми 32 слоями. Усеченный прямой проход быстрее, так как обрабатывает меньше слоев, и токены черновика выигрывают от того, что видят те же начальные слои, что и целевая модель.

Плюсы:

• Нет дополнительных весов модели для загрузки
• Естественное выравнивание с распределением цели (та же архитектура, частичные слои)
• Хорошо работает для моделей с значительной избыточностью в более глубоких слоях

Минусы:

• Требует модификации движка вывода для поддержки частичных прямых проходов
• Осложнения с кэшем KV — черновик использует частичный кэш KV, который должен быть согласован с кэшем полной модели
• Проценты принятия обычно ниже, чем у EAGLE или хорошо настроенных моделей-черновиков

Реализация в llama.cpp: PR #18471 ввел само-спекулятивное декодирование, используя историю контекста в качестве черновика. Модель повторно использует токены из собственной истории генерации для предложения продолжений, что особенно эффективно для рабочих нагрузок кода, где паттерны повторяются в пределах одного окна контекста.

MTP (Multi-Token Prediction)

MTP — это специализированная форма спекулятивного декодирования, встроенная непосредственно в некоторые контрольные точки (checkpoints) моделей. Qwen 3.6 поставляется в обоих вариантах: стандартном и с поддержкой MTP (GGUF).

В чем разница: Головы MTP встраиваются в архитектуру модели во время обучения. Модель содержит дополнительные головы предсказания, которые предлагают несколько будущих токенов за один прямой проход. Нет отдельной модели-черновика — головы MTP являются частью самой целевой модели.

Компромиссы:

• Нет модели-черновика для управления — MTP активируется с помощью --spec-type draft-mtp --spec-draft-n-max N
• Головы MTP добавляют ~1–2 ГБ накладных расходов по видеопамяти
• Лучше всего работает на архитектурах MoE (Qwen 3.6 35B-A3B), где разреженное маршрутизация сохраняет головы MTP дешевыми

Для подробных бенчмарков MTP и стандартного декодирования на Qwen 3.6 27B и 35B, см. Qwen 3.6 MTP vs Standard on 16GB GPU.

Процент принятия: что это означает на практике

Процент принятия (α) — единственный самый важный показатель производительности спекулятивного декодирования. Он определяет, получаете ли вы ускорение или платите накладные расходы.

Формула ускорения

Ожидаемое количество принятых токенов за проход проверки:

E[accepted] = α × K

Где K — количество предложенных токенов черновика за цикл. Если α = 0.7 и K = 5, вы принимаете 3.5 токена за проход — это ускорение в 3.5 раза по сравнению со стандартным декодированием (которое производит 1 токен за проход).

Процент принятия по методам

Когда процент принятия падает

Процент принятия не является постоянным в ходе генерации. Он варьируется в зависимости от:

• Позиции токена: Ранние токены склонны иметь более высокий процент принятия (больше контекста, меньше неопределенности). Поздние токены падают по мере того, как модель исследует более разнообразные продолжения.
• Тип рабочей нагрузки: Редактирование кода с повторяющимися паттернами показывает α > 80%. Открытое творческое письмо показывает α < 40%.
• Температура: Более высокая температура увеличивает расхождение между черновиком и целью, снижая принятие. Спекулятивное декодирование лучше всего работает при низкой температуре (0.0–0.7).

Критический порог: Если ваш эффективный процент принятия (α × K) падает ниже 1.0, спекулятивное декодирование медленнее стандартного. Накладные расходы на черновик плюс время проверки превышают стоимость одного шага авторегрессионного генерации.

Спекулятивное декодирование в производстве: что происходит на самом деле

Научные статьи сообщают об ускорении в 2–4 раза, но производственные бенчмарки рассказывают более нюансированную историю — ускорение уменьшается с размером батча, проверка доминирует во времени цикла, и ни один метод не выигрывает во всех рабочих нагрузках.

Результаты SpecDecode-Bench (2026)

Системная оценка пяти вариантов SD (n-gram, EAGLE, EAGLE-3, Draft-Model, MTP) на vLLM для четырех моделей и шести рабочих нагрузок выявила:

1. SD работает, но ускорение уменьшается с размером батча. При размере батча 1 EAGLE достигает до 1.96x на Llama-3-70B. К размеру батча 128 это падает до 1.21x. Система становится ограниченной по вычислениям при высокой конкурентности, и у GPU остается меньше свободного ресурса для спекулирования.

2. Проверка доминирует во времени выполнения (42–95%). Прямой проход целевой модели — узкое место. Сокращение впустую потраченных проверок на отклоненные токены — самый перспективный путь для улучшения.

3. Ни один метод не выигрывает везде. EAGLE-3 — лучший универсальный выбор. Методы модели-черновика excel (превосходят), когда целевая модель велика (70B+). n-gram оптимальна для редактирования кода и задач с высоким перекрытием.

4. Анализ оракула выявляет разрыв. Теоретический верхний предел для комбинированных стратегий n-gram + EAGLE достигает ~4.9x на рабочих нагрузках редактирования кода, но текущие реализации достигают 2–3x. Есть пространство для оптимизации.

Ожидаемое ускорение на практике

Эффект размера батча критически важен. При малых батчах у GPU есть свободные вычислительные ресурсы для спекулирования. При больших батчах система уже насыщена, и спекулятивное декодирование добавляет накладные расходы без пропорциональной пользы.

Мониторинг в производстве

Вы должны отслеживать процент принятия в производстве. Падение процента принятия сигнализирует о том, что ваша модель-черновик расходится с целевой — либо потому, что изменилась рабочая нагрузка, либо потому, что модель-черновик нуждается в переобучении.

Ключевые метрики для мониторинга:

• Процент принятия на запрос (должен быть стабильным около вашего базового уровня)
• Токены в секунду со спекулятивным декодированием и без него (фактическое ускорение)
• Время проверки в процентах от времени цикла (должно быть 42–95%)
• Время прямого прохода модели-черновика (должно быть < 20% времени целевой модели)

Если ваш процент принятия падает ниже 40%, отключите спекулятивное декодирование для этого запроса. Накладные расходы того не стоят.

Практическая настройка

Выбор движка так же важен, как и стратегия черновика — см. Ollama vs vLLM vs LM Studio and other local runtimes для того, как каждый рантайм обрабатывает батчинг, совместимость API и пропускную способность, прежде чем вы выберете путь спекулятивного декодирования.

llama.cpp

Для общей настройки сервера и загрузки GGUF начните с llama.cpp quickstart; флаги ниже добавляют спекулятивное декодирование поверх.

llama.cpp поддерживает несколько методов спекулятивного декодирования через флаг --spec-type:

# Модель-черновик (отдельная)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Обязательно: --parallel 1 для спекулятивного декодирования

# n-gram
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-gram (настройка для текстовой нагрузки)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Само-спекулятивное (рабочие нагрузки кода)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Критические флаги:

• --parallel 1 — Спекулятивное декодирование в llama.cpp требует режима одного батча. Это текущее ограничение.
• --spec-draft-n-max — Количество токенов черновика за цикл. Начните с 3–5; более высокие значения увеличивают давление на видеопамять.
• --spec-ngram-simple-size-n — Длина n-граммы для поиска. Значение по умолчанию 12 хорошо работает для кода; уменьшите до 8 для текста.

Частые ошибки:

• Забыли --parallel 1 — сервер будет молча игнорировать спекулятивное декодирование.
• Использование моделей-черновиков между семействами — проценты принятия обрушаются, отрицая любое ускорение.
• Установка --spec-draft-n-max слишком высоко — каждый дополнительный токен черновика стоит видеопамяти для буфера черновика. Эффект убывающей отдачи наступает примерно на уровне 5–8.

vLLM

vLLM quickstart охватывает базовое развертывание; флаги ниже включают спекулятивное декодирование на существующем сервере vLLM.

vLLM поддерживает спекулятивное декодирование через флаги --speculative-model и --speculative-num-steps:

# Модель-черновик
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (параллельное создание черновика)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-gram
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

Спекулятивное декодирование в vLLM интегрировано с непрерывным батчингом, поэтому оно работает под нагрузкой конкурентных задач. Планировщик обрабатывает несколько слотов токенов в рамках одного прямого прохода, а менеджер памяти управляет кэшем KV как для модели-черновика, так и для целевой модели.

SGLang

SGLang поддерживает спекулятивное декодирование через флаг --speculative-algorithm:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

Архитектура RadixAttention в SGLang хорошо сочетается со спекулятивным декодированием, поскольку кэширование префиксов снижает стоимость проверки — целевая модель повторно использует кэшированное внимание для общих префиксов, что делает каждый проход проверки дешевле, чем «холодный» прямой проход.

TensorRT-LLM

TensorRT-LLM предоставляет спекулятивное декодирование производственного уровня с Triton Inference Server. Настройка более сложная, но обеспечивает лучшую производительность на оборудовании NVIDIA:

1. Постройте движок TensorRT как для целевой, так и для модели-черновика.
2. Настройте репозиторий моделей с model.yaml, указывающим конфигурацию спекулятивного декодирования.
3. Запустите Triton с LLM API / PyTorch backend.

TensorRT-LLM поддерживает как варианты модели-черновика, так и EAGLE-3. Для рабочих нагрузок генерации кода TensorRT-LLM со спекулятивным декодированием n-gram продемонстрировал снижение задержки на 2–3x в производственных развертываниях.

Когда использовать спекулятивное декодирование

Используйте, когда

• Большие целевые модели (7B+): Накладные расходы механизма черновика распределяются по вычислениям цели. Спекулятивное декодирование блистает, когда целевая модель медленная — чем больше цель, тем ценнее ускорение.
• Рабочие нагрузки с низкой температурой: Спекулятивное декодирование лучше всего работает при температуре 0.0–0.7, где распределение целевой модели концентрировано, и у черновика есть лучший шанс совпадения.
• Интерактивные приложения: Рабочие нагрузки, чувствительные к задержкам (чат, автодополнение кода, вызовы инструментов агента), выигрывают больше всего. Пакетная обработка, при которой вы уже насыщаете GPU, выигрывает меньше.
• Генерация и редактирование кода: Высокая повторяемость паттернов кода делает n-gram и само-спекулятивное декодирование особенно эффективными.

Пропускайте, когда

• Маленькие целевые модели (< 3B): Накладные расходы модели-черновика приближаются ко времени прямого прохода цели. Ускорение маргинальное или отрицательное.
• Выборка с высокой температурой: При температуре > 0.7 распределение целевой модели слишком широкое, чтобы черновик мог надеяться на совпадение.
• Творческое письмо и открытая генерация: Низкие проценты принятия на новом содержимом делают накладные расходы неразумными.
• Большие размеры батчей (> 32): Система становится ограниченной по вычислениям, и спекулятивное декодирование добавляет накладные расходы без пропорциональной пользы. SpecDecode-Bench показывает падение ускорения с 1.96x до 1.21x при изменении размера батча с 1 на 128.

Комбинирование методов

Продвинутые установки комбинируют несколько стратегий спекулятивного декодирования. Анализ оракула SpecDecode-Bench показал, что адаптивное комбинирование n-gram и EAGLE может продвинуть ускорение до 4.9x на рабочих нагрузках редактирования кода.

Идея состоит в том, чтобы использовать n-gram для паттернов, которые появлялись ранее (где принятие высокое, а накладные расходы близки к нулю), и переключаться на EAGLE для новых токенов. На практике это требует поддержки движком спекулирования несколькими методами — vLLM и TensorRT-LLM имеют экспериментальную поддержку, но производственные реализации все еще созревают.

Пока самым практическим комбинированием является MTP + n-gram в llama.cpp. MTP обрабатывает нейронное спекулирование, а n-gram ловит повторяющиеся паттерны, которые MTP пропускает. На Qwen 3 27B это комбинирование достигает 120 токенов/сек по сравнению со 67 токенов/сек в стандартном режиме — ускорение в 1.8x.

Соображения по стоимости

Спекулятивное декодирование обменивает вычисления на задержку. Общие вычисления на токен примерно такие же — вы просто делаете больше работы параллельно, а не последовательно.

Влияние на стоимость GPU:

• Задержка одиночных запросов улучшается на 20–50%, что важно для интерактивных приложений.
• Пропускная способность (токены/сек по многим запросам) улучшается меньше — GPU уже насыщена при больших размерах батчей.
• Использование видеопамяти увеличивается на размер модели-черновика (1–4 ГБ для отдельных черновиков, минимально для n-gram/EAGLE).

Облачный вывод: При цене $2–4/час за H100, спекулятивное декодирование снижает задержку на запрос без увеличения стоимости на токен. Для пакетной обработки, где вы уже насыщаете GPU, выгода в стоимости минимальна — вы платите за то же время GPU в любом случае.

Когда спекулятивное декодирование экономит деньги: Интерактивные приложения, где вы взимаете плату за запрос и хотите сократить время до первого токена. Ускорение в 2x означает, что ваши пользователи ждут вдвое меньше, и вы можете обслуживать больше запросов в секунду на том же оборудовании.

Когда нет: Пакетная обработка, где вы уже максимизируете использование GPU. Дополнительные вычисления от спекулятивного декодирования не увеличивают пропускную способность — они просто изменяют профиль задержки.

Что дальше

Спекулятивное декодирование созревает от научной новинки до производственного стандарта. Фронтир движется за пределы текущих ограничений:

• Параллельная генерация на уровне модели: Спекулятивное декодирование продвигает несколько токенов за прямой проход на уровне вывода, не трогая распределение вывода. Языковые модели диффузии делают структурно другую ставку, генерируя несколько токенов за прямой проход как часть самой архитектуры модели. См. что приходит после LLMs для того, как это сравнивается с подходом «черновик — проверка» выше, и с моделями пространства состояний и JEPA-моделями мира на другом конце пост-трансформерного ландшафта.

• Спекулятивное спекулятивное декодирование (SSD): Параллелизует этапы создания черновика и проверки на отдельном оборудовании. Модель-черновик работает асинхронно, предвосхищая несколько вероятных результатов проверки. Ранние результаты показывают ускорение до 2x по сравнению с оптимизированным спекулятивным декодированием и 5x по сравнению с авторегрессионным декодированием. Пока не готово к производству, но направление ясно.

• SpecSA (Sparse Speculative Verification): Комбинирует спекулятивное декодирование с динамическим разреженным вниманием. Превращает разреженное внимание в рабочую нагрузку, ориентированную на проверку, достигая до 3.49x пропускной способности от начала до конца по сравнению с авторегрессионным разреженным декодированием. Актуально для моделей с длинным контекстом, где разреженное внимание уже используется.

• Адаптивное спекулирование: Автоматическое переключение между n-gram, EAGLE и методами модели-черновика на основе характеристик рабочей нагрузки. Анализ оракула показывает значительный неиспользованный потенциал — текущие реализации достигают 2–3x, но теоретический предел составляет 4.9x.

• Мультимодальное спекулятивное декодирование: Расширение «черновик — проверка» для моделей «видение-язык» и генерации видео. Ранние обзоры показывают, что те же принципы применимы, но стратегии проверки нуждаются в адаптации для нетекстовых модальностей.

Рамка принятия решений