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

Источник: https://modelium.tech/zhurnal/vllm-chunked-prefill/

Chunked Prefill позволяет vLLM делить обработку длинного входа на части и планировать её вместе с генерацией уже начатых ответов. В V1 функция обычно включена, а `max_num_batched_tokens` ограничивает число токенов за шаг планировщика, не длину всей модели. Меньший бюджет может помочь задержке между токенами, больший — времени до первого токена; проверять нужно на одинаковой нагрузке и своей модели.

**Проверено по документации и исходному коду vLLM на Git-коммите **`**ced6857**`**, 30 сентября 2026 года.** Это инструкция для собственного стенда, а не результаты испытания Modelium: сервер, веса и тест здесь не запускались. [s1](#src-s1) [s3](#src-s3)

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

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

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

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

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

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

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

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

По документации, меньший `max_num_batched_tokens` (пример автора — 2048) оставляет меньше prefill-работы рядом с decode и может улучшить ITL; больший обычно помогает TTFT, потому что больше входных токенов попадает в шаг. Значение выше 8192 в документации предлагается для throughput, особенно для небольших моделей на больших GPU, но это **совет автора, не универсальная настройка** и не гарантия для ограниченной памяти. При нехватке KV-кеша vLLM может вытеснять запросы и пересчитывать их, ухудшая итоговую задержку. [s1](#src-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](#src-s1) [s3](#src-s3) [s4](#src-s4)

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

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

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

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

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

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

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

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

**Следующий шаг:** запустите выбранную модель по [базовому гайду vLLM](/zhurnal/vllm/), затем по [протоколу нагрузки](/zhurnal/vllm-bench-serve/) сохраните результаты двух режимов на одном наборе коротких и длинных запросов. Выбирайте бюджет по собственному TTFT, ITL, ошибкам и состоянию очереди, а не по чужой цифре throughput. [s1](#src-s1) [s5](#src-s5)

## Источники

1. [vLLM v0.30.0 — Optimization and Tuning](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/configuration/optimization.md) — получено 2026-09-30
2. [vLLM v0.30.0 — V1 user guide](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/usage/v1_guide.md) — получено 2026-09-30
3. [vLLM v0.30.0 — SchedulerConfig](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/vllm/config/scheduler.py) — получено 2026-09-30
4. [vLLM v0.30.0 — EngineArgs defaults](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/vllm/engine/arg_utils.py) — получено 2026-09-30
5. [vLLM v0.30.0 — Benchmark CLI and latency definitions](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/benchmarking/cli.md) — получено 2026-09-30
6. [vLLM v0.30.0 — bench serve CLI implementation](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/vllm/benchmarks/serve.py) — получено 2026-09-30
7. [vLLM v0.30.0 — OpenAI-compatible server](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/serving/online_serving/openai_compatible_server.md) — получено 2026-09-30
8. [vLLM v0.30.0 — Security guidance](https://github.com/vllm-project/vllm/blob/ced6857afa0ea7b2e3f0846a62e1394e90f15607/docs/usage/security.md) — получено 2026-09-30