Лимиты, конкурентность и очереди в продакшен-конвейерах генерации изображений

Разница между демо и продакшен-конвейером генерации — в том, что происходит на 95-м перцентиле нагрузки. Этот пост про два лимита, с которыми вы встретитесь, клиентскую архитектуру, которая переносит их спокойно, и расчёт реальной пропускной способности.

Два лимита#

1. RPS на ключ (по умолчанию 10 запросов/с): как быстро можно разговаривать с API. Превышение — 429 rate_limited с заголовком Retry-After.
2. Одновременные задания на аккаунт (по умолчанию 20): сколько заданий может быть в очереди или в работе одновременно. Превышение — 429 too_many_inflight. GET /v1/account отдаёт и inflight, и max_inflight — запас виден в реальном времени.

RPS защищает входную дверь; лимит одновременных заданий — честность очереди генерации. Оба поднимаются — напишите из кабинета, когда ваш стабильный трафик этого требует.

Клиентская архитектура, которая не плавится#

Пропускайте работу через собственную ограниченную очередь, а не стреляйте пользовательскими запросами прямо в API:

запросы пользователей → ваша очередь → N воркеров (N ≤ max_inflight) → отправка → вебхук/опрос → доставка

• Выбирайте N из лимита, а не из оптимизма. При max_inflight = 20 и медиане генерации ~8 с потолок — ~2.5 изображения/с (20 ÷ 8). Нужно 10/с? Это разговор о повышении лимита, а не цикл повторов.
• 429 — это backpressure, а не ошибка. Подождите Retry-After, не считайте это пользовательской ошибкой и никогда не повторяйте со свежим Idempotency-Key (в других местах так рождаются дубли списаний; у нас это просто трата слота очереди).
• Приоритизируйте интерактив. Одна очередь для пользовательских запросов, другая для батчей; батчи разгружайте только когда inflight < max_inflight × 0.7.

Пики, сбои и спираль смерти, которой не будет#

Классический сценарий: пик → таймауты → клиенты повторяют → трафик повторов удваивает пик. Два свойства ломают спираль:

• Отправка дешёвая и отвечает за миллисекунды даже при глубокой очереди генерации — ваши запросы не таймаутятся, а встают в очередь.
• Повторные отправки с тем же Idempotency-Key — бесплатные no-op, поэтому агрессивные политики повторов не превращают нагрузку в двойную работу.

Добавьте экспоненциальный бэкофф с джиттером на транспортных ошибках (0.5 с → ×1.6 → потолок 5 с) — и всё: circuit breaker для этого пути не нужен.

Мониторинг, который важен#

Следите за тремя числами: глубина вашей очереди, inflight / max_inflight и доля неудачных заданий по error.code. Всплески ошибок не стоят вам кредитов (авто-возвраты), но это самый ранний сигнал плохих промптов или проблем выше по течению. Остальное — балансы, стоимость заданий, леджер — уже сверено на нашей стороне (как именно).

Справочник: лимиты · эндпоинт аккаунта · вебхуки.