vLLM Chunked Prefill: очередь длинных запросов и бюджет токенов

Что решает Chunked Prefill?

Prefill — обработка входных токенов перед генерацией ответа; decode — выдача последующих токенов. В описанном планировщике V1 сначала выделяется работа запросам, уже генерирующим ответ, а оставшиеся токены шага достаются входам. Длинный вход, не помещающийся в остаток, разбивается на части и продолжается в следующих шагах. Это планирование вычисления, а не обрезка текста или смена контекстного окна модели. s1 s2 s3

Подход полезно оценивать, когда одновременно идут длинные документы и короткие диалоги: ожидаемый результат — управляемый компромисс между ожиданием первого токена длинного запроса и плавностью выдачи ответа другим клиентам. Документация vLLM описывает потенциальное улучшение утилизации GPU, но не гарантирует ускорение именно на вашей смеси, карте или модели. s1

Маршрут выбора: задача с длинными и короткими входами → точная модель и токенизатор → совместимое железо и достаточный KV-кеш → vLLM V1 → два сравнимых прогона → решение по TTFT, ITL и ошибкам. Для первого ответа начните с гайда запуска vLLM; здесь не заявляется минимальная VRAM по размеру файла весов. s1 s7

Включать ли функцию вручную в V1?

В V1 Chunked Prefill включён по умолчанию, когда это допускает конфигурация. Поэтому перед экспериментом проверьте фактическую версию движка, опции запущенного сервера и его логи, вместо слепого добавления флага включения. Для V0 поведение отличалось; не переносите старый совет «обязательно включите флаг» на V1 без проверки. s1 s2 s4

Не путайте max_num_batched_tokens с max_model_len: первое — бюджет токенов на одну итерацию планировщика, второе — предел контекста конкретного запуска. max_num_seqs ограничивает число последовательностей в шаге. Константа 2048 в SchedulerConfig обозначена в коде как удобное значение для тестирования; при реальном запуске EngineArgs выбирает дефолт с учётом типа вызова и оборудования. Поэтому нельзя объявлять «2048 — дефолт любого vLLM-сервера» и нельзя обещать, что бюджет в 2048 исключает более длинный вход при включённом chunking. s3 s4

Как подобрать бюджет для своего потока?

По документации, меньший max_num_batched_tokens (пример автора — 2048) оставляет меньше prefill-работы рядом с decode и может улучшить ITL; больший обычно помогает TTFT, потому что больше входных токенов попадает в шаг. Значение выше 8192 в документации предлагается для throughput, особенно для небольших моделей на больших GPU, но это совет автора, не универсальная настройка и не гарантия для ограниченной памяти. При нехватке KV-кеша vLLM может вытеснять запросы и пересчитывать их, ухудшая итоговую задержку. s1

На своём уже работающем локальном сервере задайте для отдельного испытания --max-num-batched-tokens 2048, затем на том же стенде попробуйте --max-num-batched-tokens 8192; это две точки исследования, не рекомендуемая пара для всякой модели. Между сериями возвращайте исходные параметры, не меняйте одновременно max_num_seqs, аппаратную конфигурацию или длины запросов. Перед сменой параметра проверьте совместимость своей версии и настройки через vllm serve --help; не подставляйте платный удалённый API для теста. В исходном коде сервера настройка передаётся в scheduler; если Chunked Prefill выключен, документация предупреждает, что бюджет ниже max_model_len может не дать серверу стартовать. s1 s3 s4

Как провести сравнение без ложного вывода?

Подготовьте один и тот же безопасный набор: короткие вопросы и длинные входы, соответствующие вашей задаче, с известными примерными длинами в токенах именно выбранного токенизатора. Если это закрытые документы, используйте разрешённые обезличенные данные и решите заранее, какие записи остаются в локальных JSON. Зафиксируйте модель и ревизию, версию vLLM, GPU, текущие параметры KV/prefix cache, доли типов входов, число ответных токенов, одновременно запущенных клиентов и seed. Случайный dataset годится для синтетического сравнения нагрузки, но не доказывает полезность на русских договорах или качестве RAG. s5 s6

Используйте инструкцию vllm bench serve для одинаковых скорости поступления запросов --request-rate и лимита параллелизма --max-concurrency; без этих ограничений значения по умолчанию могут отправить все запросы одновременно. Отдельно измеряйте короткие и длинные входы, а затем смешанный поток: одна общая медиана скрывает ухудшение для коротких запросов. Сохраните результаты, фактические длины и число неудачных запросов для каждого режима; повторите серии. s5 s6

Смотрите TTFT (от отправки до первого потокового ответа), ITL (промежутки между потоковыми выводами), задержку всего ответа и успешность. Это показатели со стороны клиента, а не замер скорости одного GPU-ядра. При speculative decoding одна порция может содержать несколько токенов; тогда ITL и TPOT нельзя трактовать как одно и то же. Сверяйте работу очереди, KV-кеша и preemption по метрикам vLLM, прежде чем приписывать эффект только Chunked Prefill. s1 s5

Повторяющиеся префиксы могут повторно использовать prefix cache и искажать сравнение двух запусков. Поменяйте seed или перезапустите сервер/очистите кеш между сериями; явно запишите, оставался ли кеш тёплым. Зависимость от очереди проверяйте на одинаковом числе клиентских соединений и без постороннего трафика. Если фактический поток меньше заданного request rate из-за лимита concurrent-запросов, это ограничение генератора нагрузки, а не доказательство пропускной способности сервера. s5 s6

Где возникают ошибки и ограничения?

Если длинный запрос не прошёл, разделите причины: превышение контекста, нехватка KV-кеша, ошибка chat template, отказ сервера или клиентский timeout. Уменьшение бюджета шага не увеличивает предел контекста и не лечит нехватку памяти само по себе; при частых preemption документ vLLM предлагает отдельно рассмотреть параметры KV и число одновременно работающих последовательностей. s1 s3 s7

Не публикуйте API наружу ради опыта: ключ --api-key защищает не все маршруты HTTP-сервера vLLM, поэтому локальная привязка и сетевой контроль важны. Prefix cache, если он используется, создаёт отдельный риск наблюдения чужих префиксов по времени ответа в многопользовательском окружении; настройка Chunked Prefill не заменяет правила изоляции. s7 s8

Следующий шаг: запустите выбранную модель по базовому гайду vLLM, затем по протоколу нагрузки сохраните результаты двух режимов на одном наборе коротких и длинных запросов. Выбирайте бюджет по собственному TTFT, ITL, ошибкам и состоянию очереди, а не по чужой цифре throughput. s1 s5