Как сообщает vLLM Blog, в DSpark появилась функция enable_adaptive_verification, включённая в PR #47808. Она регулирует объём проверяемого черновика в зависимости от текущей нагрузки и вероятности принятия каждого токена. Руководитель инфраструктуры может выбирать между фиксированным и адаптивным бюджетом. При высоком параллелизме adaptive verification сокращает проверку позиций с низкой вероятностью, а при меньшем выгоднее использовать более длинный черновик.
Механизм оценивает вероятность прохождения проверки для каждого чернового токена, затем рассчитывает вероятность сохранения последовательности на каждой позиции. Общий бюджет B распределяется между запросами с наибольшими значениями. В результате более поздняя позиция запроса с высокой уверенностью может оказаться приоритетнее первой позиции запроса с низкой уверенностью. Размер бюджета определяется по ожидаемому числу токенов на единицу времени шага. Для расчёта используется профилированная таблица затрат в микросекундах.
Авторы отмечают, что фиксированное значение num_speculative_tokens подходит не для всех уровней параллелизма. Когда меняются нагрузка и доля принятия, соотношение полезных и отклонённых токенов тоже становится другим. На DeepSeek-V4-Pro-0813 последний токен в блоке из семи черновых токенов проходит проверку менее чем в 10% случаев, первый более чем в 70%. При num_speculative_tokens: 7 спекулятивное декодирование сохраняет преимущества вплоть до параллелизма 256.
Ключевые факты
На DeepSeek-V4-Pro-0813 последний токен в блоке из 7 черновых токенов проходит проверку менее чем в 10% случаев, первый, более чем в 70%.
При блоке из 7 черновых токенов преимущества спекулятивного декодирования сохраняются вплоть до параллелизма 256.
Размер бюджета проверки рассчитывается на CPU, а позиции между запросами распределяются на GPU по актуальным оценкам уверенности.
Реализация выбора позиций написана на PyTorch и преобразуется в Triton через torch.compile.
Вопросы и ответы
- При какой нагрузке спекулятивное декодирование сохраняет выгоду?
При num_speculative_tokens: 7 преимущество сохраняется вплоть до параллелизма 256. При меньшем параллелизме более длинный черновик даёт больше выгоды.
- Почему нельзя просто задать фиксированное число черновых токенов?
Вероятность принятия резко снижается внутри блока: на DeepSeek-V4-Pro-0813 первый из 7 токенов принимается более чем в 70% случаев, последний, менее чем в 10%. Поэтому DSpark направляет бюджет на позиции с максимальной вероятностью сохранить последовательность.
- Как это встроено в вычислительный контур?
Размер бюджета B рассчитывается на CPU по профилированной таблице затрат в микросекундах, пока GPU обрабатывает предыдущий шаг. Распределение позиций выполняется на GPU, а код на PyTorch преобразуется в Triton через torch.compile; функция enable_adaptive_verification вошла в PR #47808.
Контекст по теме
- Исследователи описали правила вызова LLM в потоковых системах через модель оценки риска16 июля 2026 г.
- Пекинский университет и DeepSeek открыли код фреймворка DSpark для ускорения инференса больших языковых моделей27 июня 2026 г.
- Фреймворк ICT предлагает новый подход к оптимизации рассуждений LLM через анализ распределений токенов19 июня 2026 г.
- Метод SEVRA предлагает выборочную проверку рассуждений для экономии вычислений у языковых моделей19 июня 2026 г.