# Admission control провайдера: ограничить очередь до роста задержек

Как ограничивать входную очередь inference API: rate gate, in-flight предел, engine queue, bounded burst и наблюдаемая причина раннего отказа.

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

Новая работа может поступать быстрее, чем сервер её завершает. Если сервис только складывает запросы в очередь, HTTP остаётся успешным всё дольше, а полезное ожидание пользователя растёт. Admission control задаёт границу до такого состояния: какая работа принимается, сколько может ждать и когда сервис явно отказывает. Это отдельная задача от пакетирования уже допущенных запросов внутри движка.

## Разделите три ограничителя

Rate gate контролирует интенсивность поступления за выбранный интервал. In-flight limit ограничивает одновременно принятые операции. Engine queue описывает ожидание внутри реализации модели. Эти величины связаны, но не взаимозаменяемы: редкие длинные запросы могут занять много активных слотов даже при небольшой частоте.

[Google SRE о нагрузке](https://sre.google/workbook/managing-load/) рассматривает управление потоком как сочетание механизмов, а не одно универсальное решение. Для собственного inference API нужно назвать ресурс каждого ограничителя и место его применения. Нельзя автоматически считать IP клиента правильной единицей, если весь трафик приходит через общий маршрутизатор.

## Проверьте возможности выбранного gate

[NGINX limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html) описывает rate-based ограничение, burst и delay. Это полезный конкретный механизм, но он не знает самостоятельно стоимость каждого модельного запроса и не заменяет учёт GPU-памяти. Сохраните фактическую конфигурацию и объясните, какую проблему она решает.

Если gate задерживает превышение, появилась ещё одна очередь. Её срок должен вписываться в общий бюджет пользователя. Если он отклоняет сразу, нужна документированная классификация причины. Оба варианта требуют наблюдения, иначе в отчёте невозможно отличить раннюю защиту от медленного внутреннего отказа.

## Постройте bounded burst

Сначала измерьте короткий контрольный поток. Затем отправьте заранее ограниченное число synthetic requests с известным расписанием. Не увеличивайте нагрузку бесконечно до аварии. Цель — увидеть границу принятия и поведение уже принятой работы при достижении выбранного ограничения.

Для каждого запроса сохраните время отправки, принятия при доступности, первый useful event и итог. В сводке отдельно покажите accepted, queued и rejected. Суммарный tokens/s не описывает стоимость ожидания, особенно если клиент прекращает медленные операции до получения полного результата.

## Свяжите отказ с метриками

[Метрики vLLM](https://docs.vllm.ai/en/stable/usage/metrics/) включают наблюдения очередей и отказов допуска выбранной версии. Проверьте реальные имена и наличие показателей на установленном сервере. Документированная метрика другой версии не должна автоматически появляться в обещанной карте мониторинга без проверки.

Сравните причину внешнего отказа с наблюдаемым слоем. Если gate считает запрос принятым, а движок отклоняет его позже, это другой исход, чем ранний отказ перед запуском. Такая связь помогает настроить пределы без выдуманной точности и не подменять неизвестное внутреннее состояние одним общим числом ошибок.

## Выберите рабочую границу

Итогом является проверенная политика допуска для определённого профиля, а не максимальная мощность устройства навсегда. При изменении длины контекста, модели или времени генерации политика может потребовать пересмотра. Сохраняйте профиль вместе с результатом, чтобы более лёгкий тест не выглядел доказательством работы тяжёлого потока.

Связанные материалы — [continuous batching](/ru/journal/continuous-batching/) и [планирование пула](/ru/journal/inference-capacity-planning/). Они помогают оценить уже допущенную нагрузку; admission control обеспечивает честную границу входа без универсального SLA и без утверждений о существующей инфраструктуре конкретного проекта.