В этом материале
Пару draft и target для speculative decoding в vLLM проверяют как согласованную конфигурацию, а не выбирают только по размеру маленькой модели.
Пару draft и target для speculative decoding в vLLM проверяют как согласованную конфигурацию, а не выбирают только по размеру маленькой модели. Важны словарь, revisions, способ предложения кандидатов и стоимость их проверки. Высокий процент принятых токенов сам по себе не обещает меньшую задержку: дополнительные вычисления могут перекрыть выигрыш на конкретной нагрузке, особенно при изменении числа одновременно выполняемых запросов.
Проверьте словари и режим
В руководстве draft models описано обычное требование общего vocabulary и отдельный режим heterogeneous vocab. У последнего есть собственные ограничения sampling. Не переносите пример между версиями без проверки схемы конфигурации. Если словари различаются, несовпадение token ID нельзя исправить переименованием модели. Зафиксируйте target, draft и соответствующие tokenizer artifacts, затем убедитесь, что выбранный режим действительно предназначен для такого сочетания, а не просто принимает путь к checkpoint без немедленной ошибки.
Сохраните все параметры предложения
Схема speculative configuration определяет параметры метода, draft revision и числа speculative tokens. Их следует записывать вместе, потому что изменение количества кандидатов меняет и объем работы target при проверке. Не используйте старые разрозненные launch flags как универсальный синтаксис для текущего runtime. До нагрузочного теста сохраните эффективную конфигурацию и минимальный успешный запрос. Это позволит отличить ошибку соединения пары от плохого результата эксперимента с уже работающим speculative путем.
Пример двух профилей нагрузки
Составьте два синтетических набора: короткие однотипные продолжения и разнообразные длинные ответы. На каждом сравните target без speculation и ту же target с draft, сохранив sampling, prompts и output limits. Запишите acceptance, время ответа, TTFT и общую пропускную способность; здесь перечислены поля будущего измерения, а не готовые цифры. Если acceptance хороший, но задержка хуже, проверьте стоимость draft и проверки кандидатов. Если acceptance низкий, исследуйте соответствие draft задаче и target.
Не скрывайте стоимость ресурсов
Draft занимает память и выполняет вычисления. Даже когда обе модели используют одну GPU, их вклад в профиль следует учитывать раздельно. При изменении parallelism зафиксируйте размещение и доступную емкость для рабочих запросов. Ускорение единичной последовательности не доказывает улучшение обслуживания общей очереди. Проверяйте диапазон concurrency, соответствующий задаче, и сохраняйте одинаковое правило остановки. Разные фактические длины ответа могут создать ложное впечатление выигрыша, если сравнивать только суммарное время двух запросов.
Условия приемки пары
Приемка должна подтверждать запуск выбранного режима, ожидаемый формат ответа и отсутствие непредусмотренного fallback. Для результата сравнения задайте заранее значимые метрики и допустимые ограничения ресурсов. Сохраните revisions, engine version, параметры speculation и исходный набор запросов. Если heterogeneous vocab не поддерживает нужный sampling в проверяемой версии, это конкретная причина отказаться от сочетания, а не общий запрет на все draft models. Отдельно обозначьте, какой workload был протестирован: выводы о копировании или коротких ответах нельзя автоматически переносить на многошаговые рассуждения. Результат такой работы — проверяемая карточка пары и протокол измерения, а не обещание ускорить любую генерацию одним флагом.
Связанные материалы
Бенчмарк GPU для инференса, которому можно доверять; Скорость потока и задержка: как выбрать рабочий режим GPU.