# Chunked prefill в vLLM: как подобрать бюджет токенов для смешанного потока

Бюджет токенов chunked prefill в vLLM подбирают по смешанному потоку новых длинных промптов и уже генерирующих запросов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-chunked-prefill-token-budget/
Language: ru

Бюджет токенов chunked prefill в vLLM подбирают по смешанному потоку новых длинных промптов и уже генерирующих запросов. Малое время до первого токена и ровная выдача следующих токенов — разные цели. Изменяйте `max_num_batched_tokens` на фиксированном наборе, измеряя TTFT и ITL отдельно. Единственный средний показатель throughput не показывает, какой группе запросов стало хуже после настройки.

## Что меняется в шаге scheduler

Chunked prefill позволяет обрабатывать длинный вход частями вместо единственного большого куска. [Руководство по оптимизации vLLM](https://docs.vllm.ai/en/stable/configuration/optimization/) описывает приоритет decode и влияние token budget на компромисс задержек. Этот бюджет относится к работе шага scheduler, а не к максимальному контексту отдельного запроса. Поэтому увеличение лимита не является способом разрешить более длинный пользовательский диалог. Сначала уточните задачу: ускорить поступающие длинные запросы или защитить интервалы выдачи уже активных ответов.

## Зафиксируйте остальные пределы

Сохраните ограничения последовательностей, контекста, output и состояние кэшей. Актуальные scheduler параметры проверяйте в [справочнике serve](https://docs.vllm.ai/en/stable/cli/serve/). Если одновременно увеличить concurrency, вывод и token budget, результат будет нельзя связать с chunked prefill. Также записывайте состав входов: серия коротких вопросов и поток длинных документов создают разные условия. Контрольный запуск должен использовать те же тексты и те же правила остановки, иначе изменится объем фактически выполняемой вычислительной работы.

## Пример смешанной серии

Подготовьте одну группу коротких разговорных запросов и другую с длинными документами. Подавайте их вместе по заранее сохраненному расписанию, а не вручную по одному. Для каждой конфигурации сформируйте таблицу: TTFT коротких, TTFT длинных, ITL активных ответов и суммарный completed throughput. Значения заполняются только фактическим измерением. Такая разбивка позволяет увидеть ситуацию, когда общий throughput почти не изменился, но длинные prefill заметно ухудшили отзывчивость короткого диалога или наоборот.

## Как читать развилку результата

Если TTFT длинных запросов хуже, но ITL стабильнее, выбранный бюджет может сильнее защищать decode. Если длинные входы проходят быстрее, а интервалы текущих ответов растут, проверьте объем prefill в scheduler шагах. Эти интерпретации следует подтверждать профилем, а не выводить из одной цифры. Отдельно исследуйте хвосты распределения: редкий крупный запрос способен создать ухудшение, которое исчезает в среднем. Не считайте низкую загрузку одной GPU достаточным основанием для повышения любого лимита.

## Приемочный артефакт настройки

Сохраните dataset, расписание подачи, конфигурацию и результаты по группам, включая холодную и прогретую серии, если обе важны. Заранее задайте допустимый компромисс для пользовательского сценария и отмечайте отклоненные варианты. Выбранный бюджет следует считать настройкой конкретной нагрузки, а не универсальным оптимумом модели. При изменении длины документов или доли параллельных ответов эксперимент нужно повторить. В итоговом протоколе отделите scheduler budget от admission backlog: первое определяет выполнение принятой работы, второе ограничивает ее накопление. Это предотвращает попытку исправить длинную очередь только увеличением размера вычислительного шага и помогает увидеть, какой именно механизм изменялся между сравниваемыми запусками.

## Связанные материалы

[Prefill и decode: какую работу выполняет ваш GPU при инференсе](/ru/journal/llm-prefill-decode/); [Continuous batching: почему несколько запросов меняют ценность GPU](/ru/journal/continuous-batching/).