Rate limit AI API: adaptive concurrency без бесконечных retry

Короткий ответ: контролируйте очередь у себя

Начните не с максимального числа запросов, а с понятной единицы работы и ограниченной серверной очереди. У каждой задачи должны быть срок жизни, владелец, приоритет и состояние отмены. Пользовательский запрос не должен бесконечно ждать из-за batch-процесса, а повторная доставка не должна создавать дубль. Когда очередь заполнена, приложение честно возвращает контролируемый статус или предлагает повторить позже вместо скрытого накопления задач.

Параллелизм измеряйте отдельно для маршрута, проекта и класса операции. Простая классификация, streaming и генерация видео имеют разную длительность и риск. Не публикуйте один глобальный «лимит» и не предполагаете значение по чужому примеру. Актуальные ограничения зависят от контракта, модели, учётной записи и ответа сервиса. Код должен реагировать на наблюдение, а не на недокументированную константу.

Какие сигналы использовать для регулирования

Минимальный набор — число активных задач, размер очереди, доля 429, локальные deadline, 5xx и доля ответов, прошедших серверную валидацию. Измеряйте окно достаточно долго, чтобы не реагировать на один случайный ответ, но достаточно коротко, чтобы не продолжать перегрузку. Записывайте только агрегаты, route label и correlation ID. Prompts, ответы, ключи, cookie и полный Authorization header не нужны для регулятора и не должны попадать в метрики.

Не смешивайте 429 с любой другой ошибкой. Ошибка схемы показывает проблему интеграции, а 401 или 403 требует проверки прав и конфигурации, а не большей задержки. Для временного сигнала сократите лимит и дайте очереди восстановиться. Для неизвестного формата ответа остановите маршрут и разберите контракт в staging. Такая классификация помогает не лечить ошибку доступа повторными запросами.

Алгоритм увеличения и уменьшения без резких скачков

Практичный старт — медленно повышать concurrency малыми шагами только после нескольких стабильных окон. При росте 429 или deadline уменьшайте лимит заметнее, чем увеличивали: перегруженная система восстанавливается не мгновенно. Добавьте минимальный и максимальный пределы, чтобы баг в телеметрии не обнулил весь сервис и не открыл неограниченный поток. Все значения должны быть конфигурацией приложения, доступной для безопасного изменения через feature flag.

Привязывайте решение к локальному deadline. Если задача уже не успеет дать пользователю полезный результат, не отправляйте её «на удачу» и не занимайте место в очереди. Отмените работу, сохраните безопасный идентификатор и предложите корректный следующий шаг. Для идемпотентных операций можно выполнить ограниченный retry с jitter; для операций с побочным эффектом сначала нужна собственная защита от дублей.

429 и retry: меньше попыток, больше предсказуемости

Ответ 429 — наблюдаемый сигнал ограничить темп, а не приглашение повторять запрос до успеха. Сначала проверьте фактические заголовки и документацию текущего маршрута; не выдумывайте header или квоту. Затем примените ограниченное число попыток к безопасной операции, добавьте случайную паузу и общий deadline. Если результат не получен, верните приложению понятную ошибку и не продолжайте расходовать очередь в фоне без согласованной задачи.

Храните idempotency key на стороне приложения там, где повтор может создать две задачи или два списания. Для асинхронного видео сохраняйте task ID и сверяйте статус по контракту, а не создавайте новый task после сетевого таймаута. Для обычного чата покажите пользователю, что ответ не подтверждён, вместо того чтобы незаметно отправить тот же prompt несколько раз. Безопасность и понятность важнее максимального количества попыток.

Проверка в staging и canary

Протестируйте регулятор на synthetic нагрузке: небольшой всплеск, медленное восстановление, очередь с отменами, 429, 5xx и сбой валидации. Проверьте, что он снижает нагрузку, но не раскрывает секреты в логах и не пересылает задачу в неразрешённый маршрут. Зафиксируйте исходную конфигурацию, версию кода и критерии остановки. Не используйте production prompts для нагрузки только потому, что они «реалистичнее».

В production включайте adaptive concurrency для одного низкорискового сегмента и наблюдайте метрики вместе с владельцем продукта. Если растёт время ожидания или процент недействительных ответов, не поднимайте лимит ради числа успешных HTTP-кодов. Вернитесь к подтверждённой конфигурации, разберите причину и меняйте один фактор за раз. Такой контур делает rate limit частью надёжности приложения, а не попыткой угадать границы чужой инфраструктуры.

Server-side пример

Пример показывает локальную проверку на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут, model ID и параметры в текущем каталоге RussiaAPI.

export function nextConcurrency({ current, limited, timedOut, min = 1, max = 12 }) {
  if (limited || timedOut) return Math.max(min, Math.floor(current / 2));
  return Math.min(max, current + 1);
}

export function retryDelay(attempt, random = Math.random) {
  if (attempt < 0 || attempt > 3) throw new Error('retry_limit');
  return Math.min(4_000, 250 * 2 ** attempt) + Math.floor(random() * 120);
}

// Apply only to safe, server-side operations with a total deadline.

Проверьте синтаксис через node --check, добавьте аутентификацию своего маршрута и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.

Границы и безопасный запуск

Это инженерное руководство, а не юридическое заключение и не инструкция по обходу законов, санкций, региональных, платёжных или платформенных ограничений. Не передавайте в тесты персональные данные, коммерческие секреты, upstream-ключи, cookie, пароли или полный заголовок Authorization. Для чувствительных данных подтвердите цель, минимизацию, срок хранения и договорные условия с ответственными специалистами.

Ключ RussiaAPI хранится только в server-side secret store. Разделяйте development, staging и production, ограничивайте доступ и журналируйте лишь безопасные метаданные. Неизвестную функцию, модель, квоту или поле ответа считайте неподтверждёнными, пока не проверите их в текущем разрешённом тестовом контуре.