Спекулятивне декодування: досягнення прискорення інференсу LLM у 2-3 рази
Оновлено 11 грудня 2025 року
Оновлення грудня 2025: Спекулятивне декодування переходить від дослідницької стадії до виробничого стандарту. NVIDIA демонструє покращення пропускної здатності у 3,6 рази на GPU H200. vLLM та TensorRT-LLM включають нативну підтримку. Чернеткові моделі пропонують 5-8 токенів для паралельної верифікації — використовуючи потужність GPU, яка недовикористовується при генерації по одному токену. Якість виводу залишається незмінною; затримка зменшується у 2-3 рази.
Великі мовні моделі генерують текст по одному токену за раз, і кожен токен вимагає повного прямого проходу через мільярди параметрів. Послідовне вузьке місце створює затримку, яка розчаровує користувачів, що очікують відповідей, навіть коли GPU частково простоюють під час обчислень. Спекулятивне декодування усуває це вузьке місце, використовуючи малі, швидкі чернеткові моделі для пропонування декількох токенів, які більші цільові моделі верифікують паралельно, досягаючи прискорення у 2-3 рази без зміни якості виводу.¹
Техніка еволюціонувала від дослідницької цікавинки до виробничого стандарту у 2025 році. Як vLLM, так і TensorRT-LLM включають нативну підтримку спекулятивного декодування, причому NVIDIA демонструє покращення пропускної здатності у 3,6 рази на GPU H200.² Розуміння того, коли спекулятивне декодування допомагає, як обирати чернеткові моделі та які фреймворки пропонують найкращі реалізації, дозволяє організаціям драматично зменшити витрати на інференс та затримку.
Як працює спекулятивне декодування
Традиційна авторегресивна генерація виробляє токени послідовно:
- Модель отримує промпт, генерує логіти для наступного токена
- Семплювання токена з розподілу
- Додавання токена до контексту, повторення прямого проходу
- Продовження до завершення
Кожен крок вимагає обчислень повної моделі, але GPU мають набагато більшу потужність, ніж використовує генерація по одному токену. Спекулятивне декодування використовує невикористану потужність:
Чернеткова фаза: Мала, швидка модель швидко генерує K спекулятивних токенів. Чернеткова модель може видати 5-8 варіантів продовження за час, який цільова модель витрачає на один токен.
Фаза верифікації: Цільова модель обробляє всі K токенів за один паралельний прямий прохід, обчислюючи ймовірності для кожної позиції одночасно. Паралелізм GPU дозволяє верифікувати K токенів з вартістю, подібною до генерації одного.
Прийняття/відхилення: Порівняння чернеткового та цільового розподілів на кожній позиції. Прийняття токенів там, де розподіли збігаються; відхилення та пересемплювання там, де вони розходяться. Алгоритм гарантує, що вивід точно відповідає тому, що цільова модель виробила б незалежно.³
Прискорення досягається завдяки прийняттю декількох токенів за один прямий прохід цільової моделі. Якщо середній рівень прийняття чернеткової моделі становить 60% і вона пропонує 8 токенів, кожен прохід верифікації виробляє приблизно 5 токенів проти 1 без спекуляції.
Бенчмарки продуктивності
Виробничі розгортання демонструють суттєві прискорення для різних сімейств моделей:
Моделі Llama на vLLM:⁴ - Llama 3.1-70B з чернеткою 1B: прискорення у 2,31 рази - Llama 3.1-8B на одній A100: зменшення затримки в 1,8 рази - Llama 3.1-70B при низькій частоті запитів: зменшення затримки в 1,6 рази
TensorRT-LLM на H200:⁵ - Llama 3.1-405B з різними чернетковими моделями: пропускна здатність >3x - У поєднанні з квантизацією FP8: загальне покращення у 3,6 рази
SGLang з SpecForge:⁶ - Llama 4 Maverick: прискорення у 2,18 рази на MT-Bench - Llama 4 Scout: прискорення у 2,0 рази
Метод EAGLE (найкращий результат):⁷ - Приблизно 0,8 точності чернетки (80% прийняття) - Типові прискорення у 2,5-2,8 рази - Найкращий результат на лідерборді Spec-Bench
Прискорення значно варіюються залежно від характеристик навантаження. Синхронні випадки використання, чутливі до затримки, демонструють найбільші виграші. Пакетна обробка з високою пропускною здатністю виграє менше, оскільки обчислення GPU стає вузьким місцем, а не послідовна генерація.
Реалізації у фреймворках
Спекулятивне декодування у vLLM
vLLM підтримує декілька методів спекулятивного декодування, включаючи чернеткову модель, ngram-зіставлення та EAGLE:
# Увімкнення спекуляції з чернетковою моделлю
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-model meta-llama/Llama-3.2-1B-Instruct \
--num-speculative-tokens 5 \
--speculative-draft-tensor-parallel-size 1
Інтеграція EAGLE (рекомендовано):
# EAGLE досягає вищих рівнів прийняття
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-model yuhuili/EAGLE-LLaMA3.1-Instruct-70B \
--speculative-method eagle \
--num-speculative-tokens 8
Інтеграція Eagle 3 у vLLM забезпечує прискорення до 2,5 рази в різних сценаріях.⁸ Фреймворк автоматично обробляє верифікацію токенів та семплювання відхилень, підтримуючи еквівалентність виводу з неспекулятивною генерацією.
Спекулятивне декодування у TensorRT-LLM
TensorRT-LLM пропонує глибшу оптимізацію для апаратного забезпечення NVIDIA:
# Побудова движка зі спекулятивним декодуванням
trtllm-build \
--speculative_decoding_mode draft_tokens_external \
--max_draft_len 8 \
--checkpoint_dir $TARGET_CHECKPOINT \
--output_dir $ENGINE_DIR
Для конфігурації чернеткової моделі:
# Чернеткова модель з окремим движком
trtllm-build \
--checkpoint_dir $DRAFT_CHECKPOINT \
--output_dir $DRAFT_ENGINE \
--max_batch_size 256
Кастомні ядра TensorRT-LLM оптимізують як фази генерації чернетки, так і верифікації, витягуючи максимальну продуктивність з Tensor Cores та пропускної здатності пам'яті.
Інтеграція з Triton Inference Server
NVIDIA Triton Inference Server підтримує спекулятивне декодування через бекенд vLLM:⁹
model_repository/
└── speculative_llm/
├── config.pbtxt
└── 1/
└── model.py
Інтеграція з Triton дозволяє розгортання виробничого масштабу з пакетуванням запитів, збором метрик та нативним масштабуванням Kubernetes, зберігаючи переваги спекулятивного декодування.
Вибір чернеткової моделі
Якість чернеткової моделі визначає ефективність спекулятивного декодування. Погані чернеткові моделі витрачають обчислення на пропозиції, які цільова модель відхиляє.
Критерії вибору
Узгодженість архітектури: Чернеткові моделі з того ж сімейства, що й цільові, досягають вищого рівня прийняття. Llama 3.2-1B як чернетка для Llama 3.1-70B перевершує загальні малі моделі, оскільки навчальні дані та токенізація узгоджені.¹⁰
Співвідношення розмірів: Чернеткові моделі зазвичай становлять від 1/10 до 1/50 розміру цільової. Менші чернетки генерують швидше, але можуть мати нижчий рівень прийняття. Протестуйте декілька розмірів, щоб знайти оптимальне співвідношення для вашого навантаження.
Поріг рівня прийняття: Прагніть до 60%+ рівня прийняття. Нижче 50% накладні витрати на верифікацію можуть звести нанівець переваги спекуляції. Використовуйте профілювання для вимірювання фактичного рівня прийняття для ваших конкретних промптів.
Файн-тюнінг чернеткових моделей
Готові чернеткові моделі часто показують гірші результати на доменно-специфічних завданнях. Файн-тюнінг драматично покращує рівень прийняття:¹¹
# Файн-тюнінг чернеткової моделі на цільовому розподілі
from transformers import Trainer, TrainingArguments
# Генерація навчальних даних шляхом семплювання з цільової моделі
# Файн-тюнінг чернетки для відповідності вихідному розподілу цільової моделі
training_args = TrainingArguments(
output_dir="./draft_finetuned",
per_device_train_batch_size=8,
num_train_epochs=3,
learning_rate=2e-5,
)
trainer = Trainer(
model=draft_model,
args=training_args,
train_dataset=target_samples,
)
trainer.train()
Організації повідомляють про покращення рівня прийняття на 20-40% від доменно-специфічного файн-тюнінгу чернетки. Інвестиція окупається для високообсягових робочих навантажень інференсу.
SpecForge для SGLang
SpecForge надає спеціалізовану екосистему для навчання чернеткових моделей:¹²
- Нативна інтеграція з SGLang
- Оптимізовані рецепти навчання для варіантів Llama 4
- Попередньо навчені спекулятори для популярних моделей
Проект Speculators від Red Hat стандартизує спекулятивне декодування з уніфікованим форматом Hugging Face та інтеграцією vLLM, спрощуючи пошук та розгортання чернеткових моделей.¹³
Просунуті техніки
Само-спекулятивне декодування (SWIFT)
SWIFT усуває потребу в окремих чернеткових моделях шляхом адаптивного пропуску проміжних шарів цільової LLM:¹⁴
- Не потрібна допоміжна модель
- Не потрібне додаткове навчання
- Прискорення у 1,3-1,6 рази зі збереженням вихідного розподілу
Техніка працює шляхом передбачення, які шари можна пропустити, на основі впевненості у токені. Прості продовження пропускають більше шарів; складні міркування використовують повну глибину моделі.
# Концептуальна конфігурація SWIFT
config = SwiftConfig(
skip_threshold=0.8, # Пропуск шарів при впевненості > 0.8
min_layers=16, # Завжди використовувати щонайменше 16 шарів
adaptive=True # Динамічне налаштування для кожного токена
)
SWIFT підходить для сценаріїв, де підтримка окремої чернеткової моделі додає небажану складність.
Ngram-спекуляція
Для структурованих виводів або передбачуваних патернів ngram-зіставлення забезпечує спекуляцію без нейронних мереж:
# ngram-спекуляція vLLM
vllm serve meta-llama/Llama-3.1-70B-Instruct \
--speculative-model "[ngram]" \
--ngram-prompt-lookup-max 4 \
--num-speculative-tokens 4
Ngram-спекуляція ідентифікує повторювані патерни в промпті або історії генерації, пропонуючи токени на основі спостережуваних послідовностей. Підхід добре працює для генерації коду, структурованих даних та повторюваного контенту.
Medusa heads
Medusa приєднує додаткові передбачувальні голови до цільової моделі, генеруючи декілька кандидатних токенів паралельно:
# Medusa вимагає модифікації моделі
model = load_medusa_model("path/to/medusa_llama_70b")
# Додаткові голови передбачають токени на позиціях +1, +2, +3, ...
Medusa повністю усуває чернеткову модель, але вимагає модифікації моделі та перенавчання. Організації з кастомними розгортаннями моделей можуть вважати Medusa вартою уваги, незважаючи на вищу складність інтеграції.
Коли спекулятивне декодування допомагає
Спекулятивне декодування приносить найбільшу віддачу за певних умов:
Сприятливі сценарії: - Інтерактивні чат-застосунки з пріоритетом затримки - Інференс для одного користувача, де недовикористання GPU високе - Генерація довгих форм (історії, документи, код) - Робочі навантаження з передбачуваними патернами токенів
Менш сприятливі сценарії: - Пакетна обробка з високою пропускною здатністю, яка вже насичує GPU - Дуже короткі відповіді (мало токенів для спекуляції) - Високо креативна/випадкова генерація з низькими рівнями прийняття - Розгортання з обмеженою пам'яттю, де чернеткова модель не вміщується
Структура прийняття рішень:
IF (використання GPU < 50% під час генерації)
AND (середня довжина відповіді > 100 токенів)
AND (чернеткова модель вміщується в пам'ять)
→ Увімкнути спекулятивне декодування
IF (використання GPU > 80%)
OR (високий тиск на пам'ять)
→ Зосередитися на оптимізаціях пакетування замість цього
Інфраструктурні міркування
Спекулятивне декодування вводить специфічні вимоги до інфраструктури:
Накладні витрати пам'яті: Чернеткові моделі споживають додаткову пам'ять GPU. Забезпечте достатній запас: - Ваги чернеткової моделі: ~1-8 ГБ залежно від розміру - Додатковий KV-кеш для чернеткових токенів - Алокації тензорів верифікації
Патерни обчислень: Фази верифікації створюють сплескові патерни обчислень, що відрізняються від стабільної авторегресивної генерації. Моніторте варіативність використання GPU та відповідно налаштовуйте розміри пакетів.
Обслуговування чернеткової моделі: Варіанти включають: - Спільне розміщення: Чернетка працює на тих же GPU, що й цільова - Окреме: Виділений GPU для генерації чернетки - Вивантаження на CPU: Малі чернетки можуть працювати на CPU для економії пам'яті
Організації, що розгортають спекулятивне декодування в масштабі, можуть скористатися експертизою Introl у GPU-інфраструктурі для оптимальної конфігурації апаратного забезпечення та планування потужностей.
Чек-лист виробничого розгортання
Перед увімкненням спекулятивного декодування у виробництві:
1. Базові вимірювання - Виміряйте поточну затримку та пропускну здатність - Профілюйте використання GPU під час генерації - Ідентифікуйте вузькі місця (пам'ять, обчислення, комунікація)
2. Вибір чернеткової моделі - Протестуйте декілька розмірів чернеток з репрезентативними промптами - Виміряйте рівні прийняття для вашого конкретного розподілу - Розгляньте файн-тюнінг, якщо рівень прийняття нижче 60%
3. Налаштування конфігурації - Експериментуйте з num_speculative_tokens (зазвичай 4-8) - Збалансуйте рівень прийняття та накладні витрати чернетки - Профілюйте використання пам'яті з цільовими розмірами пакетів
**4. Rollo
[Контент скорочено для перекладу]