Fallback стратегии
при отказе провайдера

Проблема: единственный провайдер = единая точка отказа

Ретрай отвечает на «моргнуло — повторим». Fallback — на другой вопрос: «а что если не починится, сколько ни повторяй?». Провайдеры LLM — внешние сервисы, и они падают по-настоящему: были громкие многочасовые простои OpenAI, Anthropic, облаков. Если весь агент завязан на одного — это single point of failure: его падение = падение твоего продукта, и ты ничего не можешь сделать, кроме как ждать.

Fallback снимает эту зависимость: когда основной путь мёртв, есть запасной. Разница с ретраем принципиальна:

Виды fallback

«Запасной вариант» — понятие широкое. У агента есть несколько осей, по которым можно откатиться:

• Другой провайдер, та же модель-класс. Лёг OpenAI → идём в Azure OpenAI или к аналогичной модели Anthropic. Самый прямой fallback: качество почти то же.
• Другая модель того же провайдера. Недоступна флагманская → берём модель попроще/подешевле у того же вендора. Работает, если проблема в конкретной модели, а не во всём провайдере.
• Более дешёвая/быстрая модель. Осознанная деградация качества ради доступности: лучше ответ похуже, чем никакого.
• Кэш / заготовленный ответ. Если запрос уже был — отдать закэшированный; для типовых — шаблонный ответ.
• Локальная/self-hosted модель как последний рубеж независимости от внешних API.

Fallback chain

На практике fallback оформляют как цепочку: упорядоченный список вариантов от лучшего к запасному. Запрос идёт по цепочке: не сработал первый (после своих ретраев) → второй → третий. Первый успешный ответ возвращается.

import structlog
log = structlog.get_logger()

# цепочка от лучшего к запасному; ② — ДРУГОЙ вендор (не тот же провайдер!)
PROVIDERS = [
    ("openai:gpt-4o",        call_openai),      # ① основной
    ("anthropic:claude",     call_anthropic),   # ② независимый вендор
    ("local:llama",          call_local),       # ③ последний рубеж, хуже но жив
]

def generate_with_fallback(prompt: str) -> str:
    last_err = None
    for name, call in PROVIDERS:
        try:
            result = call(prompt)              # внутри у call — свой retry+backoff
            if name != PROVIDERS[0][0]:
                log.warning("fallback_used", provider=name)  # НЕ основной → сигнал!
            return result
        except Exception as e:
            log.error("provider_failed", provider=name, error=str(e))
            last_err = e
            continue                            # переходим к следующему в цепочке
    raise RuntimeError("all providers failed") from last_err   # → graceful degradation

# фреймворки дают это из коробки: LangChain .with_fallbacks([...]),
# прокси-роутеры (LiteLLM и т.п.) маршрутизируют между провайдерами

Подводный камень: модели не взаимозаменяемы

Соблазнительно думать «просто подставим другую модель». Но модели разных провайдеров/семейств не эквивалентны, и наивная подмена ломается на деталях:

• Разный формат API. Структура запроса/ответа, имена полей, способ передачи tool-вызовов отличаются между OpenAI и Anthropic. Нужен слой абстракции или прокси, приводящий к единому виду.
• Разное поведение на том же промпте. Промпт, вылизанный под одну модель, на другой может дать иной формат/качество. Иногда fallback-модели нужен свой промпт.
• Разные возможности. Не у всех одинаковый tool calling, structured output, размер контекста. Fallback на слабую модель может не уметь того, на чём построен агент.
• Разный контекст-лимит. Запрос, влезавший в 200k токенов, не влезет в модель со 8k — fallback упадёт по другой причине.

Цена fallback: качество и стоимость

Fallback — это компромисс, а не бесплатная страховка. Спускаясь по цепочке, ты обычно жертвуешь:

• Качеством. Запасная (более дешёвая/локальная) модель отвечает хуже. Осознанное решение: «хуже, но есть» лучше, чем «идеально, но недоступно» — но пользователь получает деградированный ответ.
• Стоимостью/латентностью. Иногда наоборот: запасной вариант дороже или медленнее. Плюс двойной расход, если считать неудачные попытки основного.
• Консистентностью. Ответы от разных моделей отличаются по стилю/формату — пользователь может заметить «скачок».

Типичные ошибки

Шпаргалка

FALLBACK = план Б при ДЛИТЕЛЬНОМ отказе (когда retry исчерпан, провайдер лёг надолго)
  единственный провайдер = SINGLE POINT OF FAILURE (падают по-настоящему, надолго)
  retry: повторить ТО ЖЕ · fallback: переключиться на ДРУГОЕ
  лестница: retry → fallback → graceful degradation

ВИДЫ: другой ВЕНДОР (та же модель-класс) · др. модель того же вендора ·
  дешевле/быстрее (осознанная деградация) · кэш/шаблон · локальная модель
  ✓ настоящий резерв — у НЕЗАВИСИМОГО вендора (иначе лягут вместе)

FALLBACK CHAIN: упорядоченный список лучший→запасной, первый живой отвечает
  каждый уровень: свой retry → не помог → следующий
  качество/стоимость по цепочке обычно ДЕГРАДИРУЮТ («хуже, но есть» > «идеально, но нет»)
  инструменты: LangChain .with_fallbacks([...]) · прокси-роутеры (LiteLLM и т.п.)

⚠️ МОДЕЛИ НЕ ВЗАИМОЗАМЕНЯЕМЫ:
  разный формат API · разное поведение на промпте (нужен свой промпт) ·
  разные возможности (tool calling/structured output) · разный контекст-лимит
  → fallback-путь ТЕСТИРОВАТЬ (интеграционные тесты), а не надеяться

ЦЕНА: качество↓ · стоимость/латентность (иногда↑) · консистентность (разный стиль)
  📊 МОНИТОРЬ FALLBACK-RATE (доля не-основного) → алерт на рост = провайдер деградирует
  логируй КТО ответил · тихий fallback = маскировка проблемы

ГРАБЛИ: тот же провайдер · непротестированный путь · тихо без метрики · игнор совместимости

Практическое задание

Что дальше

Ретрай и fallback реагируют на отказ постфактум. Но часть отказов можно предотвратить — и самый частый из них у LLM это 429 «слишком много запросов». Управлять своим темпом запросов, чтобы не упираться в лимиты провайдера, — тема следующего урока: rate limiting и управление квотами.