vLLM speculative decoding: draft-модель и проверка ускорения

Когда спекулятивное декодирование имеет смысл?

Для локального сервера с длинной генерацией ответов важна не только скорость обработки входа, но и время между новыми токенами. В speculative decoding вспомогательный механизм предлагает следующие токены, а целевая модель проверяет предложение; принятые токены позволяют уменьшить число последовательных шагов генерации. Разработчики vLLM описывают пользу прежде всего для ограниченной пропускной способностью памяти нагрузки при низком или среднем QPS. Это условие для проверки, а не обещание ускорения вашего сервера s1.

Начните с обычного ответа выбранной модели в vLLM. Путь решения: задача и набор запросов → подходящая target-модель → доступное железо и запас памяти для неё и draft-модели → vLLM → сопоставимые ответы и задержки. Ни размер файлов весов, ни показанное авторами тестовое железо не дают универсального минимума RAM/VRAM. Размещение обеих моделей и фактический расход нужно проверять для своих конфигураций, а не объявлять заранее s1s2.

Не путайте этот механизм с prefix caching: там повторно используются KV-блоки общего начала запросов, здесь сокращается последовательная работа над ответом. Оба механизма могут влиять на эксперимент; прогретый общий префикс и разная очередь запросов испортят сравнение режимов, если их не контролировать s1s7.

Как выбрать target, draft и режим без лишнего обещания?

У vLLM есть несколько методов: отдельная draft-модель, EAGLE, MTP, n-gram и другие. Не применяйте одни и те же параметры ко всем методам. В online-примере авторов target Qwen/Qwen3-4B-Thinking-2507 и draft Qwen/Qwen3-0.6B, method: draft_model, num_speculative_tokens: 5; это пара из документации, а не независимо проверенная Modelium совместимость на вашей версии или оборудовании. Сначала проверьте наличие обеих ревизий, условия использования весов и совместимость токенизаторов; при ошибке старта не подменяйте draft случайным checkpoint другого семейства s1s2s8.

По умолчанию vLLM требует общий словарь для target и draft. В закреплённой схеме есть опция use_heterogeneous_vocab, позволяющая пересечение токенов при разных словарях, но для неё документация ограничивает вероятностное draft-семплирование. Это не универсальная гарантия совместимости любой пары. Качество подсказок draft определяет долю принимаемых токенов, а расходы на дополнительную модель могут свести выигрыш на нет; сравнивайте результат, а не одно название метода s1s2s8.

Если не хочется загружать отдельную draft-модель, документация показывает method: ngram с предложениями из повторяющихся фрагментов входа, num_speculative_tokens и границами prompt_lookup_min/prompt_lookup_max. У такого пути другая стоимость и иной характер попаданий; он уместен как отдельный кандидат, не как контрольная серия для оценки именно draft-пары. MTP/EAGLE требуют собственной совместимости и не являются бесплатным переключателем для произвольной модели s1s3.

Как запустить безопасный тестовый сервер?

На изолированном стенде подготовьте установленный vLLM версии, совместимой с закреплённой документацией, обе доступные модели и достаточно ресурсов по фактической конфигурации. Сначала поднимите target-модель без speculative config и добейтесь содержательного ответа от /v1/chat/completions; адрес и идентификатор модели сверяйте по ответу своего сервера. API привязывайте к 127.0.0.1, если не нужен удалённый доступ; продакшен-доступ и защита иных маршрутов требуют отдельной проверки s2s6.

Для второй серии формат команды по документации: vllm serve Qwen/Qwen3-4B-Thinking-2507 --host 127.0.0.1 --port 8000 --seed 42 --max-model-len 2048 --speculative-config '{"model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5,"method":"draft_model"}' --per-request-spec-decode-metrics summary. Это редакционно собранный шаблон из авторского online-примера и описанного флага метрик, не команда, которую запустил Modelium. Выберите подходящие вам лимит контекста, нагрузку и параметры размещения; подтверждайте включённый режим по логам и реальному ответу. --speculative-config принимает один JSON-объект, прежние отдельные --speculative-model и --num-speculative-tokens в документации помечены устаревшими. tensor_parallel_size не является ключом speculative config: для draft там предусмотрен draft_tensor_parallel_size s1s2s4.

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

Как сравнить скорость и правильность на одинаковых запросах?

Сохраните ревизии vLLM и обеих моделей, GPU/CPU, занятость памяти, шаблон чата, контекст, sampling, число параллельных клиентов, набор запросов и порядок серий. Проведите контроль без speculative config и эксперимент с ним на одинаковой target-модели и одинаковых входах. Отдельно проверяйте ответ модели и ошибки; HTTP 200 и высокий acceptance сами по себе не означают подходящий ответ. Для детерминированного режима сравните выходы на повторяемых входах, но не обещайте побайтного равенства: авторы указывают влияние численной точности и нестабильности logprobs s1s7.

Для каждого режима считайте успешные запросы, TTFT (время до первого токена), TPOT (время на выходной токен без первого) и полную задержку. Не используйте ITL как единственную метрику выигрыша: при speculative decoding один сетевой фрагмент может содержать сразу несколько принятых токенов, и ITL не добавляет нулевые интервалы между ними. vllm bench serve измеряет эти задержки на стороне клиента; повторение на прогретом сервере может ложно улучшить результат из-за общего prefix cache. Контролируйте cache-состояние рестартом или методикой без reuse, держите порядок и входы воспроизводимыми; инструкция по bench serve раскрывает протокол s7.

На /metrics доступны серверные временные ряды. Экспериментальный --per-request-spec-decode-metrics summary добавляет metrics.speculative_decoding для одиночной последовательности (n=1): draft_acceptance_rate — принятые draft-токены / предложенные draft-токены; mean_acceptance_length — 1 + принятые draft-токены / число шагов проверки. При none сбор отключён, для n>1 значение отсутствует, а формат экспериментален. Не перепутайте долю принятия draft-токенов с долей корректных ответов или приростом скорости; агрегированные счётчики /metrics охватывают и другие запросы стенда s4s5.

Почему старт или выигрыш может не получиться?

• Сервер не стартует с draft: проверьте существование checkpoint, словарь, поддерживаемую пару и поля --speculative-config; не вставляйте tensor_parallel_size внутрь JSON и не маскируйте несовместимость специальным параметром без понимания ограничения s1s2s8.
• Задержка выросла: отдельная draft-модель расходует память и время; на иной QPS, коротком ответе и при дорогой проверке выигрыш не задан документацией. Замерьте текущую нагрузку против контроля и при необходимости откажитесь от режима s1s7.
• Принятие есть, но ответы вызывают сомнения: посмотрите конкретные ответы, семплирование, ошибки и условия теста. Теоретическая и алгоритмическая lossless-цель в документации не означает, что произвольные прогоны всегда выдадут одинаковые строки; численная точность и batch size могут изменить logprobs s1s4.
• Показатели расходятся: per-request acceptance относится только к отдельному n=1, а /metrics агрегирует серверные запросы; ITL и TPOT считают разные события. Проверьте единицы, границы интервала, внешний трафик и состояние prefix cache s4s5s7.

Что сохранить перед решением о внедрении?

Основной следующий шаг — сопоставимый тест vLLM bench serve на своём железе: две конфигурации, один набор обезличенных запросов, равные условия, корректные ответы, TTFT/TPOT, общая задержка и acceptance. Выбирайте draft только если ваша нагрузка показывает полезный выигрыш без неприемлемых ограничений по памяти, стабильности и качеству результата. Modelium не проводил такой тест и не сообщает собственного коэффициента ускорения s1s4s7.