Main/AI Engineering/Blueprints/Evals & AI Gateway/Отказоустойчивый корпоративный AI Gateway (LiteLLM, кэширование и фоллбэки)
Back to «Evals & AI Gateway» cards
Evals & AI Gateway(ТЗ 6 из 6)
ТЗ: Отказоустойчивый корпоративный AI Gateway (LiteLLM, кэширование и фоллбэки)
Evals & AI Gateway1 шагов • +5 XP

ТЗ: Отказоустойчивый корпоративный AI Gateway (LiteLLM, кэширование и фоллбэки)

Инженерная спецификация развертывания централизованного ИИ-шлюза: единый OpenAI-совместимый эндпоинт, семантический кэш в Redis, балансировка нагрузки между провайдерами, ограничение бюджетов и Circuit Breaker.

~12 ч работыУровень: SeniorLiteLLM ProxyDocker ComposeRedis Semantic CachePrometheus / GrafanaCircuit Breaker Pattern
+5 XP за шаг
Выполнено 0 из 1 шагов (0%)
Трудозатраты~12 рабочих часов
Фриланс вилка~$540 – $900 (€480 – €840)
Оценка веб-студии~$1,140 – $1,920 (€1080 – €1800)

ТЗ заказчика (исходный бриф):

Хаос с API-ключами в разных микросервисах приводит к перерасходу бюджетов и падениям сервисов при исчерпании квот. Нужен единый фасад с виртуальными ключами, контролем затрат и 100% аптаймом.
Ключевые требования:
  • •Развертывание LiteLLM Proxy в Docker с поддержкой протокола OpenAI API
  • •Автоматический Fallback: если Claude возвращает 429 Rate Limit — прозрачно переключать на Gemini 2.5 Flash
  • •Семантическое кэширование повторных запросов в Redis для экономии до 40% бюджета
  • •Выпуск виртуальных ключей для команд с лимитом расходов ($50/месяц на отдел)
Ограничения проекта:
  • •Задержка шлюза (Proxy Overhead) не более 10 мс
  • •Хранение мастер-ключей строго в защищенном Vault / переменной окружения
Критерии приёмки (KPI):
  • 99.99% доступность AI-инфраструктуры благодаря фоллбэкам
  • Экономия до 35% бюджета за счет кэширования

Пошаговое практическое руководство по ТЗ

Подробный разбор архитектуры, код реализации и советы эксперта по каждому этапу:

1
Этап 1 из 1

Конфигурация LiteLLM Proxy с маршрутизацией и Redis кэшем

~60 мин

Практическое руководство:

Создать config.yaml и docker-compose.yml для запуска шлюза с моделями claude-3-5-sonnet, gemini-2.5-flash и подключением Redis кэширования.

Важные технические нюансы и подводные камни:

Указывайте fallback_models для каждой модели в списке router_settings.

Архитектурная база (Почему выбрано такое решение):

LiteLLM маршрутизирует запросы на уровне конфигурации, позволяя менять модели без пересборки и перезапуска микросервисов.

Совет эксперта (Best Practice):

Используйте cooldown_time: 30, чтобы временно вывести упавшего провайдера из ротации на 30 секунд.

Ожидаемый артефакт этапа:

Конфигурация LiteLLM Proxy с отказоустойчивой связкой моделей.

YAML
# litellm/config.yaml
model_list:
  - model_name: production-primary
    litellm_params:
      model: claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY
      tpm: 80000
      rpm: 1000

  - model_name: production-fallback
    litellm_params:
      model: gemini/gemini-2.5-flash
      api_key: os.environ/GEMINI_API_KEY
      rpm: 2000

router_settings:
  routing_strategy: usage-based-routing
  fallbacks:
    - production-primary: ["production-fallback"]
  allowed_fails: 2
  cooldown_time: 30

litellm_settings:
  cache: true
  cache_type: redis
  cache_params:
    host: redis
    port: 6379
  success_callback: ["prometheus"]
  failure_callback: ["prometheus"]

Типичные грабли на этом ТЗ

1 антипаттерна

Что сдаём клиенту (Deliverables)

Чек-лист сдачи
Docker Compose стек LiteLLM + Redis
Конфигурация автоматических фоллбэков при 429 ошибках
Система квот и бюджетирования команд

Инструменты экосистемы Fullstack AI Lab для этого ТЗ

Интеграция

AI-Собеседование

Пройти голосовое или текстовое интервью по технологиям ТЗ

Архитектурные Воркфлоу

43 пошаговых сценария с командами CLI и готовыми конфигами