В этом материале
Статус перегрузки, время ожидания и возможность повтора требуют явной семантики. Retry-After не гарантирует свободную ёмкость к указанному моменту.
Провайдеру полезнее отклонить недопустимую нагрузку понятным ответом, чем открыть SSE и долго держать запрос без возможности обслуживания. Но само число 429 не описывает всю политику. Клиенту нужно понимать, является ли причина ограничением rate, временной нехваткой ресурса или другой ситуацией, а серверу — подтверждать, что отказ произошёл до дорогостоящей работы. Это provider-side контракт, а не инструкция обхода пользовательского лимита.
Назовите причину отклонения
RFC 6585 определяет 429 Too Many Requests и возможность Retry-After. Он не устанавливает одну схему квот для всех сервисов. Собственный интерфейс должен описать область ограничения: ключ, tenant, маршрут или иной выбранный ресурс. Не следует раскрывать внутренние детали инфраструктуры, которые не нужны для действий клиента.
Rate policy и временная недоступность ёмкости могут требовать разных решений. Сохраните диагностический reason внутри системы и документированную внешнюю классификацию. Один общий статус без контекста затрудняет отличение неправильной нагрузки от случая, где повтор позже действительно имеет смысл.
Зафиксируйте Retry-After
RFC 9110 описывает формы Retry-After, включая дату и задержку в секундах. Проверьте, что клиент умеет обрабатывать именно объявленный вариант. Неверная единица или неправильная работа с датой способна вызвать немедленную серию повторов вместо ожидаемого ожидания.
Этот заголовок не резервирует будущий слот и не гарантирует успех следующей попытки. Приложению нужен верхний предел числа попыток и общего срока. Если повтор требует снова выполнить генерацию, семантика исходной операции и возможная неоднозначность принятия рассматриваются отдельно.
Проверьте входной gate
NGINX limit_req описывает rate-based механизм с burst, delay и настройкой статуса. Это один возможный слой ограничения, а не универсальная модель inference-очереди. Запишите фактическую конфигурацию и то, где считается запрос, прежде чем интерпретировать результат эксперимента.
Первый fixture проходит при небольшой частоте, второй создаёт заранее ограниченный burst. Оба используют короткие synthetic inputs и конечный срок. Наблюдайте принятые, задержанные и отклонённые операции отдельно. Одно число «ошибок» скрывает, накапливается ли очередь или работает раннее ограничение.
Испытайте поведение клиента
Fake endpoint может последовательно вернуть ограниченный отказ, затем разрешённый ответ. Это проверяет parser заголовка и общий retry budget без настоящей перегрузки GPU. Сохраните время попыток и причину завершения сценария. Тест считается завершённым и тогда, когда установленный бюджет корректно остановил новые попытки.
Добавьте отказ без Retry-After и некорректное значение заголовка. Клиент должен иметь документированный безопасный исход, а не бесконечное ожидание или мгновенный цикл. Конкретные fallback-правила являются свойством приложения; стандарт HTTP не выбирает их автоматически за оператора.
Не превращайте отклонение в SLA
Проверка подтверждает известную политику допуска на выбранной версии. Она не устанавливает гарантированный объём запросов и не означает, что любой внешний маршрутизатор будет повторять работу тем же способом. После изменения gate повторите fixture и сверку причин отказа.
Связанные темы — ошибка 429 у клиента и fallback с лимитами. Здесь центр внимания другой: честная выдача перегрузки самим сервисом, согласованная с наблюдениями до начала stream и ограниченным поведением повторов.