# Перегрузка провайдера: Retry-After как часть контракта

Как описывать перегрузку inference API до открытия SSE: rate policy, Retry-After, ограниченные повторы и проверка фактической политики провайдера.

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

Провайдеру полезнее отклонить недопустимую нагрузку понятным ответом, чем открыть SSE и долго держать запрос без возможности обслуживания. Но само число 429 не описывает всю политику. Клиенту нужно понимать, является ли причина ограничением rate, временной нехваткой ресурса или другой ситуацией, а серверу — подтверждать, что отказ произошёл до дорогостоящей работы. Это provider-side контракт, а не инструкция обхода пользовательского лимита.

## Назовите причину отклонения

[RFC 6585](https://www.rfc-editor.org/rfc/rfc6585.html) определяет 429 Too Many Requests и возможность Retry-After. Он не устанавливает одну схему квот для всех сервисов. Собственный интерфейс должен описать область ограничения: ключ, tenant, маршрут или иной выбранный ресурс. Не следует раскрывать внутренние детали инфраструктуры, которые не нужны для действий клиента.

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

## Зафиксируйте Retry-After

[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) описывает формы Retry-After, включая дату и задержку в секундах. Проверьте, что клиент умеет обрабатывать именно объявленный вариант. Неверная единица или неправильная работа с датой способна вызвать немедленную серию повторов вместо ожидаемого ожидания.

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

## Проверьте входной gate

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

Первый fixture проходит при небольшой частоте, второй создаёт заранее ограниченный burst. Оба используют короткие synthetic inputs и конечный срок. Наблюдайте принятые, задержанные и отклонённые операции отдельно. Одно число «ошибок» скрывает, накапливается ли очередь или работает раннее ограничение.

## Испытайте поведение клиента

Fake endpoint может последовательно вернуть ограниченный отказ, затем разрешённый ответ. Это проверяет parser заголовка и общий retry budget без настоящей перегрузки GPU. Сохраните время попыток и причину завершения сценария. Тест считается завершённым и тогда, когда установленный бюджет корректно остановил новые попытки.

Добавьте отказ без Retry-After и некорректное значение заголовка. Клиент должен иметь документированный безопасный исход, а не бесконечное ожидание или мгновенный цикл. Конкретные fallback-правила являются свойством приложения; стандарт HTTP не выбирает их автоматически за оператора.

## Не превращайте отклонение в SLA

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

Связанные темы — [ошибка 429 у клиента](/ru/journal/openrouter-429-error/) и [fallback с лимитами](/ru/journal/router-failover-and-rate-limits/). Здесь центр внимания другой: честная выдача перегрузки самим сервисом, согласованная с наблюдениями до начала stream и ограниченным поведением повторов.