50% запросов к LLM-инструментам падают: как построить отказоустойчивую API-инфраструктуру для генеративного AI

Я — Denis Shokhirev, архитектор AI из Фрайбурга, Германия. В DennisCraft AI Studio я разворачиваю production-агентов для B2B-клиентов DACH на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres. За последние полгода 14 агентов — и на 3 проектах больше половины LLM-запросов стабильно возвращали 5xx или таймауты. Это не «теоретический» баг — это блокирует SLA и выносит в проде.

Почему LLM-инфраструктура так нестабильна

LLM-инструменты (Claude, OpenAI, локальные модели) не гарантируют стабильности API на уровне классических SaaS. В отчёте Anthropic (2024, документация) прямо указано: лимиты динамически снижаются без уведомлений, а возвраты 429, 502, 504 — ежедневная норма.

• У OpenAI в пиках — до 40% ошибок ответа (данные status.openai.com, март 2024).
• Claude периодически «замораживает» endpoint для европейских регионов на 1–2 минуты.
• Локальные модели (Llama, Mistral) на self-hosted GPU падают при нагрузке выше 40 rps.

Реальный SLA в таких условиях — миф без продуманной отказоустойчивости. В B2B этот уровень риска никто не примет.

Архитектура отказоустойчивой LLM-API

1. Мульти-провайдерный роутинг

Я реализую proxy-слой на n8n или FastAPI, который роутит запросы к нескольким LLM-провайдерам.

import requests

def route_llm_request(prompt):
    providers = [
        {"url": "https://api.openai.com/v1/chat/completions", "key": "OPENAI_KEY"},
        {"url": "https://api.anthropic.com/v1/messages", "key": "CLAUDE_KEY"}
    ]
    for provider in providers:
        try:
            resp = requests.post(
                provider["url"], 
                headers={"Authorization": f"Bearer {provider['key']}"},
                json={"prompt": prompt, "max_tokens": 500},
                timeout=12
            )
            if resp.ok:
                return resp.json()
        except Exception as e:
            continue
    raise Exception("All LLM providers failed")

Реальный эффект — 99% запросов доходят, даже если один из API недоступен.

2. Circuit Breaker и Retry-логика

Для каждого endpoint я применяю Circuit Breaker (через pybreaker) — чтобы не бомбить API, если провайдер «лежит».

import pybreaker

breaker = pybreaker.CircuitBreaker(fail_max=5, reset_timeout=60)

@breaker
def call_llm():
    # API-запрос (см. выше)
    pass

Retry-логика (экспоненциальная задержка) — обязательна: без неё всплески ошибок превращают вашу очередь задач в лавину фейлов.

3. Кэширование успешных результатов и fallback-ответы

Supabase/Postgres — для хранения успешных LLM-ответов и fallback-логики на случай сбоя всех провайдеров.

def get_or_generate(prompt):
    cached = db.query("SELECT response FROM llm_cache WHERE prompt=%s", (prompt,))
    if cached:
        return cached[0]
    try:
        response = route_llm_request(prompt)
        db.execute("INSERT INTO llm_cache (prompt, response) VALUES (%s,%s)", (prompt, response))
        return response
    except:
        # Fallback: возвращаем последний релевантный ответ или сообщение об ошибке
        last = db.query("SELECT response FROM llm_cache ORDER BY created_at DESC LIMIT 1")
        return last[0] if last else "LLM недоступен"

4. Контроль rate limits и балансировка нагрузки

Мониторинг rate limits через n8n + Doppler: при достижении лимита — переключение на альтернативного провайдера или временное снижение rps.

Задача — не выйти за лимиты, не получить бан и не потерять поток задач.

Безопасность и аудит LLM-инфраструктуры

Внутренние и внешние уязвимости

LLM-инфраструктура уязвима для prompt injection, утечек токенов, неправильных настроек CORS. Проверяю весь код через bandit, semgrep, gitleaks.

bandit -r ./llm_proxy
semgrep --config=auto ./llm_proxy
gitleaks detect

Логирование и мониторинг

n8n и Supabase позволяют логировать все входящие/исходящие запросы, отслеживать время ответа и аномалии. Для критичных задач — отдельный лог ошибок на Postgres, раздельный от основного трейсинга.

FAQ

Зачем использовать несколько провайдеров, если один кажется «стабильным»?

Любой LLM API может упасть из-за перегрева, обновления, регуляторных ограничений. Мульти-провайдер — единственный способ держать SLA выше 98% в Европе.

Какой вариант fallback наиболее надёжный?

Сохранять последние успешные ответы в Postgres и возвращать их при сбое всех API — это лучше, чем отдавать «ошибку» или пустой ответ. Пользователь получает хотя бы релевантный результат.

Как быстро переключаться между провайдерами без потери контекста?

Сохранять chain-of-prompts в Supabase — и подставлять их в запрос к резервному API. Так agent не теряет логику диалога.

Как мониторить отдельные точки отказа?

В n8n ставлю отдельные workflow на логирование ошибок для каждого провайдера, плюс алерты в Slack/Telegram при превышении 5 ошибок подряд.

Как защищаться от утечек ключей и prompt injection?

Все ключи через Doppler/Secrets Manager, в каждом prompt — фильтрация пользовательского ввода через регулярки, статический анализ кода bandit/semgrep.

В каком месте вашей LLM-цепочки чаще всего происходят сбои — на уровне API, очереди задач или кэширования? Я реально хочу знать.

Я делаю бесплатный 30-минутный аудит стека для фаундеров DACH, кто строит AI под регуляцию. Пишите в LinkedIn или на @ger_dennis_ai.