Спекулятивное декодирование: настройка и пределы ускорения LLM

Для разработчика главный вопрос — быстрее ли поступает ответ при его типичной нагрузке. Для того, кто отвечает за сервер инференса, — сохраняется ли выигрыш при одновременных запросах и нехватке памяти. Для команды, которая пользуется внешним API, — предоставляет ли провайдер доступ к этой оптимизации и описывает ли её вообще.

Документация проверена 30 октября 2026 года: vLLM, SGLang и NVIDIA TensorRT-LLM. Команды ниже взяты из актуальной на эту дату документации. Это примеры настройки, а не результаты тестов, проведённых для статьи.

Что такое спекулятивное декодирование и как оно работает?

Недорогой механизм предлагает следующие токены, а целевая модель решает, какие из них попадут в ответ. Токен — единица текста, с которой работает модель; часто это часть слова. Целевой называют модель, поведение которой нужно сохранить.

Представьте помощника, который набрасывает предложение для придирчивого редактора. Помощник может писать наперёд, но читатель увидит текст только после проверки. Ключевой приём в том, что целевая модель оценивает предложенное продолжение целиком, без отдельного шага генерации для каждого нового токена. В описании NVIDIA за подготовкой черновика следует проверочный проход целевой модели. Документация TensorRT-LLM

На схеме буквы обозначают идентификаторы токенов. Черновая модель предлагает A B C. Допустим, при жадном декодировании, когда каждый раз выбирается наиболее вероятный следующий токен, целевая модель согласна с A B, но следующим выбирает X. В окончательный ответ попадает A B X. Продолжение, построенное после отклонённого C, тоже отбрасывается: оно опиралось на неверный префикс.

При генерации с семплированием принять токен сложнее, чем просто проверить, выбрали ли обе модели одно и то же слово. Стандартное спекулятивное семплирование учитывает вероятности целевой модели и модели, предложившей черновик. Если предложение отклоняется, применяется корректирующее распределение. Именно эта коррекция сохраняет распределение вероятностей целевой модели. В исходном алгоритме целевая модель также может выдать дополнительный токен, если принят весь черновик. Исходная статья Leviathan, Kalman и Matias

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

Что значит «без перехода на более слабую модель»?

Гарантия, которую стоит требовать, — сохранение распределения целевой модели. Это не означает одинаковый случайный ответ при каждом запуске, не устраняет ошибки целевой модели и не улучшает её рассуждения. vLLM описывает численные эффекты и влияние объединения запросов в батчи, из-за которых результаты могут различаться даже при алгоритме без потерь. Гарантии отсутствия потерь в vLLM

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

Основные варианты и документация движков

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

Отдельная черновая модель

Меньшая языковая модель генерирует токены-кандидаты, используя собственные веса. Это самый понятный вариант, но он требует загрузить и обслуживать ещё одну модель. Важны совместимость и согласованность предсказаний: меньший размер сам по себе не гарантирует пользы. Обычно vLLM предполагает общий словарь токенов, хотя в документации есть и вариант работы с разными словарями, имеющий ограничения. Черновые модели в vLLM

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

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

EAGLE — сокращение от Extrapolation Algorithm for Greater Language-model Efficiency. В этом подходе используется обученный вспомогательный модуль подготовки черновика, связанный с целевой моделью. Он опирается на её внутренние представления, чтобы предложить продолжение. Для таких обучаемых компонентов, которые часто называют головами, нужен совместимый чекпойнт. В vLLM предусмотрены отдельные конфигурации eagle и eagle3. Документация EAGLE в vLLM

Целевую модель и её чекпойнт EAGLE нужно рассматривать как совместимую пару. Совпадения семейства модели в названии чекпойнта недостаточно. В описании развёртывания фиксируйте точное семейство, ревизию модели и реализацию сервера инференса.

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

Multi-token prediction, или MTP, использует встроенную в модель способность предсказывать будущие токены. vLLM описывает этот вариант для поддерживаемых семейств моделей и приводит пример запуска без отдельного идентификатора черновой модели. У модели, в которой такой возможности нет, она не появится от установки method в mtp. Документация MTP в vLLM

Если вы уже используете поддерживаемый чекпойнт с MTP, сначала попробуйте описанный для него способ настройки, прежде чем добавлять отдельную стороннюю черновую модель. Так придётся решать меньше вопросов совместимости, хотя производительность всё равно нужно измерять.

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

Название алгоритма и схема его исполнения — разные вещи. В актуальных примечаниях к выпуску TensorRT-LLM указано, что отдельный движок для черновой модели удалён, а сохранённые реализации размещают её внутри модели как подмодуль. Это не означает, что подход с черновой и целевой моделями исчез. Это означает, что старые инструкции по развёртыванию могут описывать схему исполнения, которой в установленной у вас версии уже нет. Примечания к выпускам TensorRT-LLM

Когда метод ускоряет генерацию, а когда — нет?

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

Принятые токены должны окупать подготовку черновика

Доля принятия — это число принятых токенов черновика, делённое на число предложенных. Сама по себе эта величина ничего не говорит о затратах на их подготовку. Более медленная черновая модель может чаще совпадать с целевой и при этом замедлять весь сервис.

Для принятия решения полезно следующее условие:

(время подготовки черновика + время проверки + время координации) ÷ число токенов, зафиксированных в ответе < базовое время декодирования одного токена

Это способ учёта затрат, а не прогноз результатов теста. Измеряйте полный раунд на своём оборудовании. В число токенов, зафиксированных в ответе, входят не только принятые предложения черновой модели, но и корректирующий или дополнительный токен целевой модели.

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

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

Возможный выигрыш зависит от размера батча

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

Параллельная проверка может задействовать вычислительные ресурсы, которые иначе простаивали бы. Но на загруженном сервере эти ресурсы уже могут обслуживать другие запросы. Поэтому снижение задержки в отдельном чате ещё не доказывает рост общей пропускной способности нагруженного API.

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

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

Нехватка памяти может свести выигрыш на нет

Черновая модель конкурирует за ограниченную память GPU. Её веса, состояние и рабочие области для проверки могут занять память, которая иначе использовалась бы для обслуживания запросов. В тот же бюджет входит KV-кэш, хранящий состояние механизма внимания для уже обработанных токенов.

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

Среди мер при нехватке памяти SGLang прямо перечисляет уменьшение резервируемой памяти, размеров захвата графов, дерева черновых токенов и числа одновременных запросов. Если ради спекулятивного декодирования приходится снижать параллелизм, это компромисс, который нужно измерить, а не бесплатная оптимизация. Устранение проблем с памятью в SGLang

Ускоряйте тот этап, на котором ждёт пользователь

Медленный ответ может означать долгое ожидание первого вывода, медленную потоковую выдачу после её начала или задержки вне модели. Спекулятивное декодирование ускоряет именно генерацию. Если приложение тратит большую часть времени на поиск документов или ожидание вызова инструмента, ускорение цикла декодирования может почти не повлиять на впечатление пользователя.

Измеряйте отдельно ожидание в очереди, prefill и decode. Prefill обрабатывает входной запрос, а decode генерирует продолжение. Эти этапы разобраны в руководстве по инференсу LLM, а в статье о токенах в секунду показано, чем скорость выдачи ответа отличается от общей пропускной способности сервиса.

Как включить спекулятивное декодирование?

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

Спекулятивное декодирование в vLLM

vLLM принимает JSON-объект через --speculative-config. В этом примере с отдельной черновой моделью целевая модель, модель для черновика и его длина взяты из документации по обслуживанию запросов:

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

Значение 5 — число предлагаемых токенов в примере, а не рекомендация оптимальной длины. Прежние отдельные флаги --speculative-model и --num-speculative-tokens в документации объявлены устаревшими. Примеры запуска vLLM

Пример со встроенным MTP из документации использует базовый чекпойнт Xiaomi MiMo:

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

Это пример с другой моделью, а не черновая модель, которую можно просто подключить к Qwen из предыдущей команды. Ограничение — поддержка чекпойнта: MTP должен быть предусмотрен в самой модели и поддерживаться вашим движком. Пример запуска MTP в vLLM

Спекулятивное декодирование в SGLang

В актуальном примере SGLang для планировщика с перекрытием операций приведена пара отдельных моделей Qwen — целевая и черновая:

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

Текущая реализация с перекрытием операций требует --speculative-eagle-topk 1. Более широкое дерево, скопированное из другого примера, с ней несовместимо. Используйте настройки планировщика и подготовки черновика в том сочетании, которое приведено в документации. Пример SGLang с планировщиком с перекрытием операций

Для меняющихся нагрузок SGLang отдельно описывает адаптивное спекулятивное декодирование в поддерживаемых конфигурациях EAGLE. Изучите требования этой функции, прежде чем рассчитывать, что глубина черновика будет подстраиваться сама. Адаптивное спекулятивное декодирование в SGLang

Настройка TensorRT-LLM

TensorRT-LLM принимает параметры спекулятивного декодирования через конфигурацию YAML. Сохраните её в файле speculative.yaml:

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

Длина черновика и чекпойнт взяты из примера настройки спекулятивного декодирования NVIDIA. Запустите соответствующую целевую модель через описанный в документации CLI сервера:

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

Проверяйте не только название конфигурации, но и поколение чекпойнта. NVIDIA описывает Eagle как псевдоним Eagle3 для совместимости, однако чекпойнты более ранних поколений EAGLE с этой реализацией несовместимы. Ограничения TensorRT-LLM по чекпойнтам

Если вы выбираете не только метод спекулятивного декодирования, но и сам движок инференса, обратитесь к более широкому сравнению vLLM и SGLang. Хорошая черновая модель не компенсирует отсутствие другой функции движка, которая нужна вашему приложению.

Есть ли польза для команд, работающих через внешний API?

Да, если провайдер описывает и включает эту оптимизацию. Доступные настройки зависят от сервиса. Чтобы получить выигрыш от оптимизации инференса у провайдера, необязательно владеть GPU.

Fireworks AI, провайдер облачного инференса, указывает в документации, что на выделенных развёртываниях для большинства поддерживаемых моделей предусмотрены черновые модели по умолчанию. Если черновой модели по умолчанию нет, спекулятивное декодирование на основе модели не используется, пока его не настроят отдельно. Конфигурацией инференса в serverless управляет Fireworks, поэтому наличие флагов для выделенных развёртываний не доказывает, что спекулятивное декодирование работает на каждом serverless-эндпоинте. Документация Fireworks по развёртыванию

Для сценария, в котором файл генерируется заново с небольшими правками, Fireworks также описывает Predicted Outputs: ожидаемый текст передаётся в поле запроса prediction. Заранее известный текст становится другим источником предложений и может использоваться вместе со спекулятивным декодированием на основе модели. Это полезно, когда большая часть ответа уже известна, а не при открытом вопросе. Predicted Outputs в Fireworks

Если вы используете другой внешний API, сначала найдите подтверждение в его собственной документации, а уже затем заявляйте о таком преимуществе или добавляйте настройку. Одна лишь совместимость API ничего не говорит о том, какая черновая модель работает за ним и есть ли она вообще.

Какие обещания преувеличены?

Спекулятивное декодирование улучшает работу сервера при определённых условиях, а не гарантирует универсальное ускорение. Здесь нет обещаний конкретного коэффициента ускорения: результат для другой целевой модели, другого черновика, GPU и состава трафика не описывает ваш сервис.

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

Самая дорогая ошибка — выдавать результат на почти свободном сервере за показатель производительности в рабочей среде. Ассистент для кода может ощущаться быстрее у разработчика, а общий сервер при этом будет выдерживать меньше одновременных сессий. Определите, что вы оптимизируете: задержку ответа, устойчивую пропускную способность или оба показателя. Явно закрепите это в критериях внедрения.

Что сделать на следующей неделе?

Разработчикам стоит проверить совместимый механизм подготовки черновика, если узкое место — декодирование. Тем, кто эксплуатирует сервер, нужен подтверждённый выигрыш под рабочей нагрузкой. Командам, использующим внешний API, стоит начать с настроек, которые действительно описывает провайдер.

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

Частые вопросы разработчиков

Подпишитесь на рассылку, чтобы получать практические руководства по созданию и эксплуатации систем ИИ.