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

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

DFlash

DFlash использует выделенную сеть предложения, обученную для конкретной целевой модели. В отличие от MTP и EAGLE-3, которые генерируют кандидатуры токенов последовательно, DFlash предсказывает целый блок будущих позиций параллельно [5].

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

Якорь занимает первую позицию в блоке, в то время как оставшиеся позиции замаскированы и предсказаны параллельно:

Блок предложения начинается с подтверждённого якорного токена, сопровождаемого замаскированными позициями:

Здесь якорь — это известный токен целевой модели, в то время как замаскированные позиции предсказаны DFlash.

Один прямой проход DFlash предсказывает все замаскированные позиции вместе:

Как EAGLE-3, DFlash сначала комбинирует скрытые состояния из нескольких слоёв целевой модели в слитое представление.

Основное различие заключается в том, как используется это слитое представление. EAGLE-3 комбинирует его с вложением семплированного токена на входе своей авторегрессивной сети предложения. DFlash вместо этого преобразует слитый контекст целевой модели в дополнительные представления Key и Value, доступные в каждом слое сети предложения.

Запросы из замаскированных позиций предложения могут, таким образом, обращать внимание как к:

• Представлениям Key и Value, полученным из целевой модели.
• Представлениям Key и Value, произведённым из блока предложения.

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

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

Здесь токен целевой модели заменяет первый отклонённый предложенный токен, в то время как оставшиеся предложенные токены отбрасываются.

Отличительной характеристикой DFlash является то, что все замаскированные позиции предсказаны вместе в одном прямом проходе сети предложения.

Это отличается от последовательного предложения:

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

DSpark

DSpark расширяет параллельное предложение двумя дополнительными механизмами:

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

DSpark использует модифицированную модель DFlash в качестве своего параллельного остова [6]. Остов выполняет главное вычисление предложения для всех позиций в одном прямом проходе, производя скрытое состояние и набор базовых логитов для каждой позиции предложения. Он, таким образом, наследует обусловливание контекста целевой модели, описанное в разделе DFlash.

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

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

DSpark применяет лёгкую головку Маркова, которая вводит зависимость между выбранными предложенными токенами. Для каждой позиции головка Маркова использует непосредственно предыдущий выбранный токен для производства небольшого смещения. Это смещение регулирует базовые логиты, произведённые параллельным остовом:

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

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

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

Целевая модель оценивает предложенную последовательность в одном проходе проверки, и предложенные токены фиксируются слева направо до первого отклонения.

Сводка методов предложения

На рисунке 3 представлен визуальный вид рядом пяти методов предложения: как выглядит компонент предложения, какую информацию целевой модели он использует и генерируются ли кандидатуры токенов последовательно или параллельно. Таблица ниже рисунка повторно излагает то же сравнение в компактной форме. Во всех пяти методах целевая модель по-прежнему оценивает предложенную последовательность в одном проходе проверки, и решение о принятии применяется слева направо до первого отклонённого предложенного токена.

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

В vLLM спекулятивное декодирование настраивается через --speculative-config. Основные различия — это название метода, требуется ли отдельная контрольная точка предложения и количество запрашиваемых кандидатур токенов. Текущий vLLM поддерживает mtp, eagle3, dflash и dspark в качестве значений метода.

Для встроенного MTP компонент предложения включен в целевую модель, поэтому поле model опускается:

vllm serve <target-model> \
  --speculative-config '{
    "method": "mtp",
    "num_speculative_tokens": <N>
  }'

Для Gemma 4 MTP, EAGLE-3, DFlash и DSpark поле model обычно указывает на контрольную точку, обученную для целевой модели:

vllm serve <target-model> \
  --speculative-config '{
    "method": "<method>",
    "model": "<matching-draft-checkpoint>",
    "num_speculative_tokens": <N>
  }'

Контрольные точки ассистента Gemma 4 используют путь MTP, даже хотя они поставляются через поле model. vLLM подключает компонент ассистента к целевой модели и позволяет ему использовать общий KV cache целевой модели.

Перед включением метода убедитесь, что:

• Установленная версия vLLM поддерживает метод и архитектуру модели.
• Контрольная точка предложения совместима с целевой моделью и методом.
• num_speculative_tokens совместим с контрольной точкой.
• Карточка модели поддерживает предполагаемое оборудование и механизм вывода.

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

Встроенное MTP не загружает отдельную контрольную точку предложения и может использовать общие компоненты, такие как таблица встраивания или голова выхода с целевой моделью. Gemma 4 MTP, EAGLE-3, DFlash и DSpark загружают дополнительные веса предложения, поэтому должно быть зарезервировано достаточное место в памяти GPU. Фактическая нагрузка зависит от размера компонента предложения, численной точности, конфигурации параллелизма тензора и буферов среды выполнения.

Где найти предварительно обученные модели предложения

Несколько организаций теперь публикуют предварительно обученные модели предложения на Hugging Face. Google предоставляет ассистентов MTP для Gemma 4, а Z-Lab поддерживает коллекцию контрольных точек DFlash. Red Hat AI предлагает модели предложения для EAGLE-3, DFlash и DSpark, а коллекция DeepSpec от DeepSeek предоставляет согласованные контрольные точки для всех трёх методов. LightSeek сосредоточена на моделях на основе EAGLE для Kimi, а Inferact публикует модели предложения для MiniMax и Kimi.

Экспериментальная установка и измерения

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

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

Основные показатели производительности:

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

Модели и охват экспериментов

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

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

Измерения пропускной способности

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

Основные наблюдения

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

Для gemma-4-26B-A4B-it, наибольшие измеренные соотношения пропускной способности в тестируемом диапазоне составили 2,74× и 2,62× для Gemma 4 MTP на GSM8K и MBPP соответственно, и 2,87× и 2,79× для DFlash на MATH500 и HumanEval. Измерения EAGLE-3 варьировались от 2,11× до 2,27× в четырёх наборах данных.

Для gemma-4-31B-it, измерения Gemma 4 MTP достигали 2,00× на GSM8K и 1,99× на MBPP, в то время как DFlash достигал 2,34× на MATH500 и 2,05× на HumanEval. Измерения EAGLE-3 и DSpark были также выше базового показателя в четырёх оценённых наборах данных. Предложенная длина, связанная с наибольшей измеренной пропускной способностью, варьировалась в зависимости от рабочей нагрузки.

Для Qwen3-8B, измерения DSpark варьировались от 1,15× на MATH500 до 1,63× на GSM8K. Измерения DFlash варьировались от 1,08× до 1,27×. EAGLE-3 был выше базового показателя на GSM8K, HumanEval и MBPP, в то время как его наибольшее измеренное значение MATH500 оставалось ниже базового показателя.

Для Qwen3.5-27B, Qwen3.5-122B-A10B и Qwen3.6-27B, наибольшие измеренные встроенные-MTP значения в тестируемых диапазонах были выше, чем соответствующие наибольшие значения DFlash. Наибольшее соотношение в этой группе составило 2,20× для Qwen3.5-122B-A10B на MATH500. Предложенная длина встроенного MTP, связанная с наибольшей измеренной пропускной способностью, варьировалась от N=4 до N=7, в зависимости от модели и набора данных.

Для Qwen3.6-35B-A3B, измерения DFlash варьировались от 1,77× до 2,06×, при этом наибольшее значение встречалось в N=7 для каждого из четырёх наборов данных. Измерения встроенного MTP варьировались от 1,28× до 1,49×, при этом наибольшие значения встречались в N=6. Разница от измерений Qwen3.6-27B показывает, что результаты могут варьироваться между моделями в одном семействе.

Для MiniMax-M3-MXFP8, измерения EAGLE-3 достигали 2,09× на HumanEval при N=4. Для Kimi-K2.5, измерения EAGLE-3 достигали до 2,33× и измерения DFlash достигали до 2,68×. В тестируемых диапазонах наибольшие значения EAGLE-3 обычно встречались при N=4, в то время как наибольшие значения DFlash встречались при N=7.

Во всех экспериментах предложенная длина, связанная с наибольшей измеренной пропускной способностью, не была постоянной. Для методов последовательного предложения, пропускная способность часто увеличивалась в течение первых нескольких значений N перед выходом на плато. Для DFlash и DSpark, N=7 часто было среди параметров с более высокой пропускной способностью, в то время как более крупные значения не последовательно увеличивали пропускную способность.

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

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

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

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

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

Начните с поддерживаемой конфигурации

Для встроенного MTP N=1 является консервативной начальной точкой, поскольку вводит минимальную дополнительную последовательную работу предложения:

{"method": "mtp", "num_speculative_tokens": 1}

После подтверждения корректности и стабильности, развёртывание большими значениями, такими как 2, 3, 4, 5, 6 и 7.

В наших измерениях, установка встроенного MTP, связанная с наибольшей измеренной пропускной способностью, варьировалась в зависимости от целевой модели и рабочей нагрузки. Для Qwen3.5-27B, наибольшая измеренная пропускная способность встречалась при N=5 для GSM8K и MATH500, N=4 для HumanEval и MBPP, и N=3 для MT-Bench. Для Qwen3.5-122B-A10B, наибольшая измеренная пропускная способность в четырёх указанных наборах данных рассуждений и кода встречалась при N=7.

Измерения Qwen3.6 также показывают, что эта установка может варьироваться между моделями в одном семействе. Для Qwen3.6-27B, наибольшие измеренные значения встречались при N=4 или N=5, в то время как пропускная способность для протестированных конфигураций Qwen3.6-35B-A3B увеличивалась до N=6.

Для Gemma 4 MTP и EAGLE-3, увеличение N также добавляет последовательную работу предложения. Короткое развёртывание, таким образом, полезно даже когда контрольная точка предоставляет рекомендуемую конфигурацию. В наших экспериментах Gemma 4 и EAGLE-3, измеренная пропускная способность обычно увеличивалась в течение первых нескольких значений N перед выходом на плато.

Для DFlash, начните с предложенных длин, рекомендуемых или поддерживаемых контрольной точкой предложения. Многие контрольные точки DFlash обучены с фиксированным размером блока. Например, когда:

block_size = 16

максимальная предложенная длина, как правило:

num_speculative_tokens = 15

потому что первая позиция — это подтверждённый якорный токен, а оставшиеся 15 позиций — кандидатуры предложения.

Это максимальная поддерживаемая предложенная длина, необязательно параметр с наибольшей пропускной способностью. На практике полезно протестировать меньшие значения, такие как:

N = 3, 7, 11, 15

Во всех экспериментах DFlash, N=7 часто было среди параметров с более высокой пропускной способностью. Для некоторых рабочих нагрузок, наибольшая измеренная пропускная способность встречалась при N=11.

Для DSpark, num_speculative_tokens устанавливает количество кандидатур токенов, генерируемых в каждом спекулятивном раунде. В наших экспериментах vLLM, полная настроенная предложение была отправлена для проверки целевой моделью, поэтому значения, такие как N=3 и N=7, должны быть сравнены с использованием комплексной пропускной способности.

Мониторинг поведения принятия

Соответствующие сигналы для мониторинга включают:

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

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

Согласуйте развёртывание с рабочей нагрузкой

Различные рабочие нагрузки могут произвести различные паттерны принятия.

В нашем измерениях GSM8K и MATH500, средние или большие предложенные длины часто связывались с более высокой измеренной пропускной способностью в тестируемых диапазонах. Для встроенного MTP на Qwen3.5-122B-A10B, измеренная пропускная способность увеличивалась до N=7. Для DFlash, более высокие измеренные значения часто встречались при N=7 или N=11.

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

Пример рабочего процесса настройки

1. Начните с конфигурации, поддерживаемой или рекомендуемой для контрольной точки.

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

3. Запишите пропускную способность, среднюю принятую длину и коэффициенты принятия.

4. Развёртывание нескольких меньших и больших предложенных длин.

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

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

Обучение спекулятора для новой целевой модели

Это руководство не охватывает обучение спекулятора в глубине. Следующий рабочий процесс суммирует практические соображения из указанных ресурсов vLLM Speculators и DeepSpec [13], [14] и [15].

Типичный рабочий процесс:

1. Подготовка представительных подсказок.
2. Генерирование ответов с целевой моделью.
3. Выбор режима генерирования скрытого состояния.
4. Сбор требуемых скрытых состояний целевой модели.
5. Обучение спекулятора.
6. Проверка принятия и пропускной способности обслуживания.

Подготовка представительных подсказок

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

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

Выбор способа получения скрытых состояний

Спекулятор получает внутренние скрытые состояния от целевой модели во время обучения. Рабочий процесс vLLM Speculators поддерживает три способа их предоставления:

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

Сбор информации целевой модели

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

Собираемая информация зависит от метода:

• EAGLE-3 использует скрытые состояния из выбранных слоёв целевой модели для авторегрессивного предложения. [4]
• DFlash использует особенности целевой модели для обучения сети, которая предсказывает блок будущих позиций параллельно. [16]
• DSpark добавляет лёгкие последовательные и головки уверенности к сети предложения в стиле DFlash. [6]
• Обучение MTP настраивает собственный компонент MTP целевой модели и, таким образом, требует целевую модель, которая уже содержит совместимые слои MTP. [13]

Обучение и проверка спекулятора

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

После обучения, проверьте контрольную точку и обслуживайте её вместе с целевой моделью в vLLM. Потери обучения одни недостаточны для оценки результата; важные измерения — это принятая длина, коэффициент принятия, задержка предложения, использование памяти GPU и комплексная пропускная способность обслуживания. Руководство vLLM Speculators охватывает полный путь от подготовки данных и извлечения скрытого состояния до проверки контрольной точки и обслуживания.

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

Итоговая сводка

Эта статья исследовала спекулятивное декодирование в vLLM как подход предложения-проверки для обслуживания LLM. Компонент предложения выдвигает кандидатуры возможных будущих токенов, а целевая модель оценивает предложение перед фиксацией каких-либо токенов.

Рассмотрены пять подходов к предложению: встроенное MTP, Gemma 4 MTP, EAGLE-3, DFlash и DSpark. Они различаются в основном в том, как используют информацию от целевой модели и генерируются ли кандидатуры токенов последовательно, параллельно или через комбинацию параллельного предсказания и лёгкой последовательной коррекции.

Эксперименты охватывали выбранные модели Gemma, Qwen, MiniMax и Kimi на AMD Instinct™ MI300X и MI355X GPU с использованием платформы программного обеспечения ROCm™. Измеренная пропускная способность варьировалась на разных целевых моделях, контрольных точках предложения, рабочих нагрузках, предложенных длинах и конфигурациях обслуживания.

Во всех протестированных конфигурациях, некоторые параметры произвели меньшие изменения или пропускную способность ниже базового показателя без спекуляции, в то время как несколько комбинаций целевой-рабочей нагрузки произвели соотношения пропускной способности выше 2×. Примеры на верхнем конце наблюдаемого диапазона включают 2,87× для DFlash на gemma-4-26B-A4B-it, 2,83× для Gemma 4 MTP на той же целевой модели и 2,68× для DFlash на Kimi-K2.5.

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

Будущая работа

Будущие бенчмарки могли бы включать несвязанные подходы, такие как спекуляция на основе n-грамм и суффиксное декодирование, особенно для рабочих нагрузок с повторяющимися паттернами токенов, такие как редактирование кода и агентские циклы.

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

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

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

Ссылки

1. Документация vLLM, "Speculative Decoding" https://docs.vllm.ai/en/latest/features/speculative_decoding/
2. Документация vLLM, "MTP Speculative Decoding" https://docs.vllm.ai/en/latest/features/speculative_decoding/mtp/
3. Блог Google Developers, "Multi-token prediction in Gemma 4" https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/
4. Статья EAGLE-3, "Scaling up Inference Acceleration of Large Language Models via Training-Time Test" https://arxiv.org/pdf/2503.01840
5. Z-Lab, "DFlash" репозиторий GitHub https://github.com/z-lab/dflash
6. Статья DSpark, препринт arXiv https://arxiv.org/pdf/2607.05147
7. Google, коллекция "Gemma 4" на Hugging Face https://huggingface.co/collections/google/gemma-4
8. Коллекция модели LightSeek Foundation на Hugging Face https://huggingface.co/lightseekorg/models
9. Red Hat AI, коллекция "Speculator Models" на Hugging Face https://huggingface.co/collections/RedHatAI/speculator-models
10. Z-Lab, коллекция "DFlash" на Hugging Face https://huggingface.co/collections/z-lab/dflash
11. DeepSeek-AI, коллекция "DeepSpec" на Hugging Face https://huggingface.co/collections/deepseek-ai/deepspec
12. Коллекция модели Inferact на Hugging Face https://huggingface.co/Inferact/models
13. Документация vLLM Speculators, "Training a Speculator" https://docs.vllm.ai/projects/speculators/en/latest/user_guide/tutorials/train/
14. Проект vLLM, репозиторий "Speculators" GitHub https://github.com/vllm-project/speculators
15. DeepSeek-AI, репозиторий "DeepSpec" GitHub https://github.com/deepseek-ai/DeepSpec
16. Статья DFlash, препринт arXiv https://arxiv.org/pdf/2602.06036