AI Vibe Craft
← Назад к AI Vibe News

Редакция 3 июня 2026 г.

Разборы

AI-агент в проде чаще падает от rate limit, а не от «галлюцинаций»

AI-агент в проде чаще падает от rate limit, а не от «галлюцинаций».

В проде LLM-агент чаще «сыпется» не из‑за плохого рассуждения, а из‑за HTTP 429: квота провайдера исчерпана, ретраи множатся, а команда всё ещё крутит промпты и guardrails. Разбор @p0rt на Dev.to предлагает другой порядок диагностики — сначала capacity engineering, потом охота за hallucinations.

Когда доминирует capacity, а не reasoning

Типичный сценарий у автора: агент падает в production, команда усиливает промпты, схемы ответов и guardrails — надёжность почти не растёт. Рассуждение модели оставалось в порядке; ломалась инфраструктурная обвязка — rate limits на исходящих вызовах к LLM.

В посте — ссылка на анализ Datadog по observability-трейсам: ошибки rate limit составляют большую долю сбоев LLM-вызовов; для марта 2026 там же пересказывается оценка «примерно треть» всех ошибок LLM-span как rate limits — «на порядок миллионов отдельных ошибок». Первоисточник Datadog отдельно не проверялся; цифры приведены по пересказу в Dev.to.

Если доминирующий failure mode — capacity, усиливать нужно capacity engineering, а не prompt engineering.

Демо показывает один happy-path запрос. Production — concurrency, fan-out, ретраи и нагрузка, где лимит API становится главным «потолком».

Почему агент бьётся о квоту сильнее, чем чатбот

У чатбота на один ход пользователя — один вызов API. У агента цепочка длиннее: planning call, несколько итераций выбора инструмента, вызов на каждый результат tool, ретраи, иногда sub-agents. На одно user action уходит порядка 10–40 model calls, часто параллельных и с повторными попытками.

«Галлюцинации» в заголовке — риторический якорь, а не количественное сравнение failure modes в процентах. Количественного «X% галлюцинаций vs Y% 429» в материале нет; есть нарратив о доминировании capacity и доле 429 в цитируемом срезе Datadog.

Serverless: compute растёт, квота LLM — нет

Парадокс на примере Cloud Run: serverless autoscaling разгоняет вычислительные инстансы, а квота у LLM-провайдера остаётся фиксированной. Чем «здоровее» дашборд compute, тем больше параллельных агентов одновременно упирается в одну квоту — и тем чаще прилетает 429.

Квота как requests/minute и tokens-per-minute — ресурс с жёстким потолком, ближе к пулу соединений с БД, чем к масштабируемому CPU. Ментальная модель смещается с «модель тупит» на «провайдер сказал no».

HTTP 429, Retry-After и retry storm

Код ответа HTTP 429 («too many requests») и заголовок Retry-After стоит учитывать при ретраях, а не игнорировать.

Иллюстративная арифметика (мысленный эксперимент, не заявление вендора): при 500 requests/minute у провайдера и ~20 model calls на одну agent-task без ретраев хватает примерно на 25 concurrent tasks — квота исчерпывается до того, как начнутся повторы. Немедленные синхронные ретраи на 429 превращаются в retry storm: все конкурируют за тот же лимит ещё агрессивнее.

Конкретные tier’ы OpenAI, Anthropic или Google, burst vs sustained в тексте не названы — только общая модель RPM/TPM.

Пять паттернов, которые держат агентов под нагрузкой

Ниже — сжатый перечень capacity-engineering patterns; формулировки — редакционный пересказ по посту @p0rt.

1. Budget и backpressure. Перед всеми исходящими model calls — семафор или token bucket; при исчерпании бюджета — очередь, а не «выстрелить и сразу ретраить». В примере на Python — asyncio.Semaphore с запасом под то, что вы не единственный потребитель квоты:

import asyncio

llm_budget = asyncio.Semaphore(8)  # headroom: не вы единственный клиент квоты

async def call_model(...):
    async with llm_budget:
        return await client.messages.create(...)

2. Retry с exponential backoff и jitter. Не ретраить мгновенно и синхронно; jitter снижает thundering herd; уважать Retry-After.

3. Fallback model. При rate limit на primary — маршрут на более дешёвую модель, другого провайдера или меньший tier на отдельной квоте. Тезис: degraded answer лучше, чем мёртвая задача; distillation (student/teacher) упоминается как аналогия по availability, не по capability.

4. Агрессивное кэширование. Prompt/response caching и provider-side prompt caching — меньше запросов доходит до лимитера.

5. Capacity observable. Логировать класс ошибки (429 vs timeout vs tool error), метрики in-flight concurrency и доли 429, алерты — отделять «модель ошиблась» от «провайдер отказал по квоте».

Граница надёжности: не «GPT-6», а инженерия ёмкости

Reliability frontier для агентов в 2026 — не intelligence, а capacity engineering. Даже гипотетическая «GPT-6» вернёт 429, если превысить квоту.

В конце исходного поста — вопрос к читателям: какой dominant failure mode при разделении error classes — reasoning, capacity, tool integration; там же ставка на capacity.

Для команд, которые уже деплоят агентов с tool loops и оркестрацией, практический сдвиг звучит так: промпты и guardrails остаются нужны, но без семафоров, backoff, fallback, кэша и observability по 429 агент в проде будет выглядеть «нерассуждающим» — хотя проблема в plumbing и лимитах API.

Источники