Повторные попытки и резервные варианты

Автоматический failover

Резервный вариант обеспечивает автоматическое аварийное перключение (failover), когда основной LLM-провайдер недоступен. Будь то rate limit, падение или недоступность модели — Meridian последовательно перебирает резервных провайдеров в указанном вами порядке, пока кто-то из них не ответит.

Когда срабатывает fallback, Meridian рассматривает попытку как полностью новый запрос: все настроенные плагины (кэш, governance, логирование и т. д.) выполняются повторно для нового провайдера. Это обеспечивает единообразное поведение по всем провайдерам.

Как работает резервный вариант

При настроенных резервный вариант Meridian действует так:

1. Первичная попытка. Запрос отправляется основному provider/model.
2. Автоопределение сбоя. При сетевой ошибке, rate limit или недоступности модели Meridian фиксирует сбой.
3. Последовательные fallback'и. Резервные провайдеры пробуются по очереди, пока один из них не ответит успешно.
4. Ответ при успехе. Возвращается ответ первого успешного провайдера.
5. Полный отказ. Если все провайдеры упали, возвращается исходная ошибка от основного.

Каждая fallback-попытка — это новый запрос, поэтому все настроенные плагины (семантический кэш, governance, мониторинг) применяются к тому провайдеру, который в итоге обработал запрос.

Пример запроса

Резервные провайдеры передаются массивом fallbacks прямо в теле запроса. Каждый элемент имеет вид provider/model и пробуется по порядку, пока один из них не ответит успешно.

# Chat completion с несколькими резервными вариантами
curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "Explain quantum computing in simple terms"
      }
    ],
    "fallbacks": [
      "anthropic/claude-3-5-sonnet-20241022",
      "bedrock/anthropic.claude-3-sonnet-20240229-v1:0"
    ],
    "max_tokens": 1000,
    "temperature": 0.7
  }'

Ответ (от того провайдера, который сработал):

{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Quantum computing is like having a super-powered calculator..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 12,
    "completion_tokens": 150,
    "total_tokens": 162
  },
  "extra_fields": {
    "provider": "anthropic",
    "latency": 1.2
  }
}

Сценарии из реальной жизни

Сценарий 1: rate limit.

• Основной: OpenAI упёрся в rate limit → fallback: Anthropic отвечает.
• Приложение продолжает работать без перебоев.

Сценарий 2: модель недоступна.

• Основной: конкретная модель временно недоступна → fallback: другой провайдер с эквивалентной моделью.
• Бесшовный переход на сопоставимую модель.

Сценарий 3: падение провайдера.

• Основной: провайдер испытывает downtime → fallback: альтернативный провайдер.
• Непрерывность бизнес-процесса.

Сценарий 4: оптимизация стоимости.

• Основной: премиум-модель для качества → fallback: экономичная альтернатива при превышении бюджета.
• Governance-правила могут запускать fallback'и по факту использования.

Подробности поведения

Что запускает fallback:

• сетевые ошибки;
• ошибки API провайдера (500, 502, 503, 504);
• rate limit (429);
• недоступность модели;
• таймауты запроса;
• ошибки аутентификации.

Что сохраняет исходную ошибку (fallback не запускается):

• ошибки валидации запроса (неправильный формат);
• блокировка плагином (нарушение governance);
• определённые provider-specific ошибки, помеченные как non-retryable.

Выполнение плагинов. Когда срабатывает fallback, новый запрос проходит весь pipeline заново:

• проверяется семантический кэш (у другого провайдера может быть кэш);
• governance-правила применяются к новому провайдеру;
• логирование фиксирует факт fallback;
• все настроенные плагины выполняются для fallback-провайдера с нуля.

Контроль fallback'ов из плагинов. Плагины могут влиять на то, запускать ли fallback. Например:

• кастомный плагин может запретить fallback для определённых типов ошибок;
• security-плагин может отключать fallback из соображений compliance.

Когда плагин решает, что fallback недопустим, механизм пропускается, и наверх возвращается исходная ошибка.

Это даёт единообразное поведение независимо от того, какой провайдер в итоге обработал запрос, при этом плагины полностью контролируют решение о fallback. Какой именно провайдер ответил — всегда видно в extra_fields.