# Очередь vLLM: как ограничить backlog запросов и prefill-токенов

Backlog vLLM следует ограничивать с учетом принятой движком работы: количество запросов и объем ожидающего prefill не равнозначны.

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

Backlog vLLM следует ограничивать с учетом принятой движком работы: количество запросов и объем ожидающего prefill не равнозначны. Одинаковая очередь из коротких вопросов и длинных документов создает разное ожидание. Сначала определите смысл каждого лимита текущей версии, затем проверьте перегрузку контролируемым всплеском. Это настройка serving scheduler и связанного admission внутри vLLM, отдельно от квот, аутентификации или универсального API gateway.

## Три разных величины

Активные последовательности описывают выполняемую работу, queued requests — количество накопленных запросов, queued tokens — token backlog. В [справочнике vLLM](https://docs.vllm.ai/en/stable/cli/serve/) приведены `max-num-active-seqs`, `max-num-queued-reqs` и `max-num-queued-tokens` с различной семантикой. Учитывайте описанную область подсчета, включая API process и data parallel конфигурацию. Не интерпретируйте любой параметр как размер единственной физической очереди GPU и не считайте все токены уже выделенными KV blocks. Это разные модели учета.

## Почему число запросов недостаточно

Два входа одинаковой длины ответа могут требовать совершенно разного prefill. Поэтому защита только по count оставляет большой разброс времени ожидания. Token backlog позволяет учитывать объем входной работы, но его оценка может быть консервативной. Не заменяйте ее самостоятельно подсчетом оставшихся tokens без понимания реализации. [Руководство по оптимизации](https://docs.vllm.ai/en/stable/configuration/optimization/) помогает связать этот вопрос с бюджетом выполнения scheduler, который определяет обработку принятой работы, но не является ее admission пределом.

## Пример контролируемого всплеска

Подготовьте короткие вопросы и длинные документы, сохранив их фактические token lengths. Подайте сначала одну группу, затем другую при одинаковом числе запросов. Для каждого запуска запишите принятые обращения, ожидаемые отказы, TTFT и завершенные ответы. Проверка должна намеренно пересечь выбранный предел в тестовой среде, чтобы подтвердить документированное поведение, включая 503 для соответствующего ограничения. Это план эксперимента: числа отказов нельзя заранее выводить только из размера входного списка без учета уже выполняемой работы.

## Свяжите отказ с причиной

Клиент должен отличать admission rejection от ошибки генерации уже принятого запроса. Сохраните статус и серверный журнал с временной отметкой. Автоматический немедленный retry способен снова наполнить очередь и скрыть эффект ограничения. Для диагностики используйте сохраненное расписание без неконтролируемых повторов. Если внешний gateway имеет собственные пределы, отмечайте, какой слой вернул отказ. Иначе изменение внутри vLLM можно ошибочно признать неработающим, хотя запрос до движка вообще не дошел.

## Зафиксируйте рабочую политику

Выберите пределы по допустимому ожиданию для конкретного профиля, а не по максимальному количеству успешно открытых соединений. Сохраните runtime version, длины входов, настройки data parallel и правила клиента. Отдельно документируйте execution budget и admission backlog: увеличение первого может изменить компромисс TTFT/ITL, но не заменяет предсказуемую границу второго. При смене модели повторите всплеск, поскольку стоимость prefill изменится. Практический артефакт — таблица слоев ограничения с единицами измерения и наблюдаемым поведением отказа. Она предотвращает путаницу между scheduler tokens, общей памятью, внешним rate limit и числом активных последовательностей в одном процессе сервера.

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

[Планирование GPU-пула: когда действительно нужен следующий сервер](/ru/journal/inference-capacity-planning/); [Скорость потока и задержка: как выбрать рабочий режим GPU](/ru/journal/throughput-latency-tradeoff/).