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

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

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

Chunked prefill позволяет обрабатывать длинный вход частями вместо единственного большого куска. Руководство по оптимизации vLLM описывает приоритет decode и влияние token budget на компромисс задержек. Этот бюджет относится к работе шага scheduler, а не к максимальному контексту отдельного запроса. Поэтому увеличение лимита не является способом разрешить более длинный пользовательский диалог. Сначала уточните задачу: ускорить поступающие длинные запросы или защитить интервалы выдачи уже активных ответов.

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

Сохраните ограничения последовательностей, контекста, output и состояние кэшей. Актуальные scheduler параметры проверяйте в справочнике 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 при инференсе; Continuous batching: почему несколько запросов меняют ценность GPU.