Зачем разбираться в теме
Rate limits и backpressure для LLM API — это не отдельный трюк, а часть production-архитектуры LLM-приложения. Ниже — практический способ внедрить подход так, чтобы качество можно было измерить, а изменения безопасно откатить.
429 — сигнал управления нагрузкой
Бесконечный retry только усиливает перегрузку. Клиент должен уважать Retry-After, ограничивать concurrency и иметь общий retry budget.
Token bucket
Лимитируйте не только requests/sec, но и token throughput, если provider считает ограничения по токенам.
Queue и backpressure
При burst трафике очередь сглаживает пики. Если queue age превышает SLO, лучше отклонить низкоприоритетную работу, чем бесконечно увеличивать задержку.
Приоритеты
Interactive user calls, background enrichment и batch jobs должны иметь разные quotas. Фоновая задача не должна вытеснять пользовательский запрос.
Adaptive concurrency
Снижайте параллелизм при росте 429/latency и постепенно увеличивайте после восстановления. Это устойчивее фиксированного максимума.
Наблюдаемость
Измеряйте 429 rate, queue depth, wait time, tokens/min, retries и dropped jobs. Capacity planning строится по пиковым, а не средним значениям.
Production checklist
Зафиксируйте исходный baseline и dataset.
Версионируйте конфигурацию и данные.
Логируйте ключевые входы, решения и ошибки.
Измеряйте качество вместе с latency и cost.
Не передавайте модели права, которые можно проверить детерминированно.
Запускайте изменения через feature flag или контролируемый cutover.
Держите rollback path до завершения наблюдаемого периода.
Вывод
Хорошая реализация отличается не количеством компонентов, а управляемостью: понятный контракт, измеримые метрики, безопасные границы и возможность воспроизвести результат. Начинайте с простого baseline и усложняйте систему только там, где evals показывают реальный выигрыш.