В этом материале
Rate limit, число активных запросов и очередь движка ограничивают разные величины. Их нужно согласовать с измеряемым бюджетом ожидания.
Новая работа может поступать быстрее, чем сервер её завершает. Если сервис только складывает запросы в очередь, HTTP остаётся успешным всё дольше, а полезное ожидание пользователя растёт. Admission control задаёт границу до такого состояния: какая работа принимается, сколько может ждать и когда сервис явно отказывает. Это отдельная задача от пакетирования уже допущенных запросов внутри движка.
Разделите три ограничителя
Rate gate контролирует интенсивность поступления за выбранный интервал. In-flight limit ограничивает одновременно принятые операции. Engine queue описывает ожидание внутри реализации модели. Эти величины связаны, но не взаимозаменяемы: редкие длинные запросы могут занять много активных слотов даже при небольшой частоте.
Google SRE о нагрузке рассматривает управление потоком как сочетание механизмов, а не одно универсальное решение. Для собственного inference API нужно назвать ресурс каждого ограничителя и место его применения. Нельзя автоматически считать IP клиента правильной единицей, если весь трафик приходит через общий маршрутизатор.
Проверьте возможности выбранного gate
NGINX limit_req описывает rate-based ограничение, burst и delay. Это полезный конкретный механизм, но он не знает самостоятельно стоимость каждого модельного запроса и не заменяет учёт GPU-памяти. Сохраните фактическую конфигурацию и объясните, какую проблему она решает.
Если gate задерживает превышение, появилась ещё одна очередь. Её срок должен вписываться в общий бюджет пользователя. Если он отклоняет сразу, нужна документированная классификация причины. Оба варианта требуют наблюдения, иначе в отчёте невозможно отличить раннюю защиту от медленного внутреннего отказа.
Постройте bounded burst
Сначала измерьте короткий контрольный поток. Затем отправьте заранее ограниченное число synthetic requests с известным расписанием. Не увеличивайте нагрузку бесконечно до аварии. Цель — увидеть границу принятия и поведение уже принятой работы при достижении выбранного ограничения.
Для каждого запроса сохраните время отправки, принятия при доступности, первый useful event и итог. В сводке отдельно покажите accepted, queued и rejected. Суммарный tokens/s не описывает стоимость ожидания, особенно если клиент прекращает медленные операции до получения полного результата.
Свяжите отказ с метриками
Метрики vLLM включают наблюдения очередей и отказов допуска выбранной версии. Проверьте реальные имена и наличие показателей на установленном сервере. Документированная метрика другой версии не должна автоматически появляться в обещанной карте мониторинга без проверки.
Сравните причину внешнего отказа с наблюдаемым слоем. Если gate считает запрос принятым, а движок отклоняет его позже, это другой исход, чем ранний отказ перед запуском. Такая связь помогает настроить пределы без выдуманной точности и не подменять неизвестное внутреннее состояние одним общим числом ошибок.
Выберите рабочую границу
Итогом является проверенная политика допуска для определённого профиля, а не максимальная мощность устройства навсегда. При изменении длины контекста, модели или времени генерации политика может потребовать пересмотра. Сохраняйте профиль вместе с результатом, чтобы более лёгкий тест не выглядел доказательством работы тяжёлого потока.
Связанные материалы — continuous batching и планирование пула. Они помогают оценить уже допущенную нагрузку; admission control обеспечивает честную границу входа без универсального SLA и без утверждений о существующей инфраструктуре конкретного проекта.