Надёжность через балансировку и резервные варианты

Проблема

LLM-провайдеры — внешние сервисы с собственными SLA, rate limits и периодами деградации. Когда продукт построен на одном провайдере, инцидент у вендора моментально превращается в инцидент у вас. Типичные сценарии:

• Rate limit на одном ключе — рост трафика упирается в лимит провайдера; приложение получает шквал 429.
• Деградация модели — один регион/модель отвечает медленно или с ошибками, остальные работают.
• Полный отказ провайдера — региональный сбой OpenAI или Anthropic блокирует все ваши вызовы.
• Истечение или ротация ключа — один из upstream-ключей становится недействительным, часть запросов падает.

Решение в коде каждого сервиса — обвязка с retries, ручной переключатель провайдеров, попытка чтения из нескольких ключей — это «налог надёжности» на каждое новое приложение и каждую команду.

Кого это касается: SRE, владельцы продукта, отвечающие за uptime LLM-фичи; платформенные команды, желающие убрать обвязку надёжности с уровня прикладных сервисов.

Решение

• Uptime LLM-фичи отвязан от uptime одного провайдера. Региональный сбой OpenAI не блокирует ваш сервис, если в fallbacks указан Anthropic или Bedrock.
• Rate limits на одном ключе не блокируют сервис. Балансировщик переключается на следующий ключ автоматически, без участия приложения.
• Обвязка надёжности — на уровне шлюза, а не каждого сервиса. Команды не дублируют retry/fallback-логику в каждом приложении.
• Прозрачность фактического провайдера. Ответ содержит extra_fields.provider, отражающий, кто на самом деле обработал запрос — это видно в логах и метриках.
• Контролируемая стоимость fallback. Каждый fallback пересчитывается через governance: если у VK нет бюджета на резервного провайдера, запрос отвергается; неконтролируемый расход исключён.

Что предлагает Meridian

В этой редакции Meridian есть четыре механизма надёжности, работающие вместе:

1. Retries — встроенные автоматические повторы при транзиентных ошибках upstream.
2. Взвешенная балансировка ключей — несколько upstream-ключей одного провайдера с весами и фильтрами по моделям. При сбое выбранного ключа автоматически берётся следующий.
3. Резервные провайдеры — упорядоченный список fallbacks в теле запроса. При отказе текущего провайдера Meridian переключается на следующего, повторно прогоняя весь стек плагинов (governance, кэш, логи).
4. Маршрутизация по правилам и provider routing — статический выбор провайдера/модели по метаданным запроса.

Сценарий

Команда alpha запускает в промышленную эксплуатацию сервис, критичный к доступности. Допустимая деградация — единичные секунды; полный отказ недопустим.

1. Платформа добавляет в Meridian провайдер OpenAI с двумя upstream-ключами: основной (weight: 0.7) и резервный из другого аккаунта (weight: 0.3). Каждый ключ снабжён фильтром models: ["openai/gpt-5.4", "openai/gpt-5.4-pro"].
2. Платформа также добавляет провайдер Anthropic и провайдер Bedrock (для географической независимости).
3. Команда в своих запросах указывает резервную цепочку в теле:

   {
     "model": "openai/gpt-5.4",
     "fallbacks": ["anthropic/claude-4-6-sonnet", "bedrock/claude-4-6-opus"]
   }

4. В нормальном режиме трафик распределяется между двумя ключами OpenAI 70/30; retries поглощают транзиентные 5xx.
5. При rate limit на ключе-1 балансировщик переключается на ключ-2; при rate limit на обоих ключах OpenAI запрос уходит в Anthropic; при отказе Anthropic — в Bedrock.
6. SRE наблюдает в Prometheus метрики по провайдерам и ключам; при систематическом росте отказов на одном из ключей вес пересматривается вручную через UI.

Конфигурация

curl -X POST http://localhost:8080/api/providers/openai/keys \
  -H "Content-Type: application/json" \
  -d '{
    "name": "openai-primary",
    "value": "env.OPENAI_API_KEY_1",
    "models": ["openai/gpt-5.4", "openai/gpt-5.4-pro"],
    "weight": 0.7
  }'

curl -X POST http://localhost:8080/api/providers/openai/keys \
  -H "Content-Type: application/json" \
  -d '{
    "name": "openai-secondary",
    "value": "env.OPENAI_API_KEY_2",
    "models": ["openai/gpt-5.4", "openai/gpt-5.4-pro"],
    "weight": 0.3
  }'

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-bf-vk: sk-bf-alpha-prod" \
  -d '{
    "model": "openai/gpt-5.4",
    "messages": [{"role": "user", "content": "Привет!"}],
    "fallbacks": [
      "anthropic/claude-4-6-sonnet",
      "bedrock/claude-4-6-opus"
    ]
  }'

{
  "providers": {
    "openai": {
      "keys": [
        {
          "id": "openai-primary",
          "value": "env.OPENAI_API_KEY_1",
          "models": ["openai/gpt-5.4", "openai/gpt-5.4-pro"],
          "weight": 0.7
        },
        {
          "id": "openai-secondary",
          "value": "env.OPENAI_API_KEY_2",
          "models": ["openai/gpt-5.4", "openai/gpt-5.4-pro"],
          "weight": 0.3
        }
      ]
    },
    "anthropic": {
      "keys": [
        {
          "id": "anthropic-primary",
          "value": "env.ANTHROPIC_API_KEY",
          "models": ["anthropic/claude-4-6-sonnet"],
          "weight": 1.0
        }
      ]
    },
    "bedrock": {
      "keys": [
        {
          "id": "bedrock-primary",
          "value": "env.AWS_ACCESS_KEY_ID",
          "models": ["bedrock/claude-4-6-opus"],
          "weight": 1.0
        }
      ]
    }
  }
}

Ограничения и важная информация

• Балансировка статическая. Веса (weight) задаются вручную и не реагируют автоматически на латентность или процент ошибок в реальном времени. Адаптивная балансировка — отдельная возможность upstream-проекта и не поставляется в этой сборке.
• Fallback задаётся per-request. Цепочка fallbacks передаётся в теле запроса; нет глобального дефолта на уровне VK. Команды должны включить fallback-логику в шаблон обращения к LLM.
• Pricing fallback-провайдеров различается. Если основной — самая дешёвая модель, а fallback — самая дорогая, бюджет может «съесться» аварийным переключением. Контролируйте через governance бюджеты.
• Различия в API между провайдерами не маскируются полностью. Function calling, vision, длина контекста — фичи, поддерживаемые не у всех. Для гарантированного fallback выбирайте сопоставимые модели.
• Retries — на стороне Meridian, не клиента. Клиентское приложение получает один окончательный ответ; промежуточные неудачные попытки видны только в логах и метриках Meridian.

Связанные материалы

• Управление ключами провайдеров — взвешенная балансировка, Direct Key Bypass, фильтрация по моделям.
• Резервные варианты (fallbacks) — формат fallbacks в запросе, поведение плагинов при переключении.
• Маршрутизация по правилам и Provider routing — статический выбор провайдера/модели.
• Телеметрия — Prometheus-метрики по провайдерам и ключам для принятия решений о пересмотре весов.
• Отладка и аудит LLM-приложений — диагностика, когда срабатывают fallback'и.