AI Gateway против кастомных решений: Vercel, LiteLLM и OpenRouter для продакшн-приложений

Когда вы начинаете мозолить глаза ошибками 429

Вы запускаете приложение на GPT-4 Turbo. Все работает. Потом добавляете Claude 3.5 Sonnet для сложных задач. Потом Gemini 2.0 Flash для дешевых запросов. И вот вы уже имеете три разных API ключа, три разных библиотеки, три разных формата запросов. А потом приходит первый крупный клиент, и ваш мониторинг показывает три тысячи запросов в минуту.

Rate limits начинают бить по всем фронтам. OpenAI отвечает 429, Anthropic - 429, Google - 429. Вы пытаетесь реализовать retry логику, но она ломает streaming ответы. Кэширование не работает с динамическим контентом. Логирование расползается по трем разным системам. И вот тут вы понимате: нужен единый слой абстракции.

Три подхода к проблеме: от готового SaaS до полного DIY

В 2026 году сформировались три четких лагеря:

Vercel AI Gateway: удобно, но за это платите

Vercel запустил AI Gateway в 2024 году как часть своей AI SDK. К 2026 году сервис оброс функциями, но сохранил философию «подключил и забыл».

1 Что получаете из коробки

• Единый API endpoint для 15+ провайдеров
• Автоматический retry с exponential backoff
• Кэширование запросов (но осторожно с GDPR)
• Базовый мониторинг и логирование
• Защита от prompt injection (базовая)

Звучит идеально? Почти. Проблема в vendor lock-in. Вы завязываетесь на инфраструктуру Vercel. Миграция на другого провайдера превращается в боль. Еще есть лимит на 1000 запросов в минуту на базовом тарифе - для enterprise приложений это смешно.

OpenRouter: не просто gateway, а рынок моделей

OpenRouter позиционирует себя как «единый API для всех моделей». Но это не просто прокси-сервер. Это агрегатор, который сам выбирает модель на основе цены и качества.

Вы отправляете запрос в OpenRouter, а система решает: сегодня GPT-4.5 дешевле, чем Claude 3.7, или maybe стоит использовать новую модель от Cohere. Для пользователя прозрачно. Для вас - экономия.

2 Как работает роутинг в OpenRouter

• Вы указываете бюджет на запрос (например, $0.10)
• OpenRouter выбирает лучшую модель по соотношению цена/качество
• Можно зафиксировать конкретную модель, если нужно
• В 2026 добавили performance-based routing - система учится на ваших оценках ответов

Но есть нюанс: OpenRouter берет наценку. Обычно 10-30% поверх стоимости API. Для небольших проектов это нормально. Для масштаба в миллионы токенов в день - уже ощутимо. И да, вы все равно зависите от одного провайдера (OpenRouter).

LiteLLM: полный контроль, полная ответственность

LiteLLM - это open-source библиотека, которую вы разворачиваете сами. Никаких наценок. Никаких лимитов, кроме вашей инфраструктуры.

Но готовьтесь к работе. Вам нужно:

• Настроить сервер (я рекомендую свои серверы для контроля)
• Реализовать rate limiting и retry логику
• Настроить мониторинг и логирование
• Обеспечить высокую доступность

В 2026 году LiteLLM 4.0 принес несколько важных улучшений:

• Unified streaming - нормализует streaming ответы от разных провайдеров
• Intelligent fallback - автоматически переключается между моделями при ошибках
• Cost tracking - детальный учет расходов по моделям и пользователям

3 Пример конфигурации LiteLLM

# config.yaml
model_list:
  - model_name: gpt-4.5-turbo
    litellm_params:
      model: openai/gpt-4.5-turbo
      api_key: ${OPENAI_API_KEY}
  - model_name: claude-3.7-sonnet
    litellm_params:
      model: anthropic/claude-3.7-sonnet
      api_key: ${ANTHROPIC_API_KEY}

routing_strategy:
  type: least_busy
  weight_by_latency: true
  fallback: ["gpt-4.5-turbo", "claude-3.7-sonnet", "gemini-2.0-flash"]

caching:
  type: redis
  ttl: 300  # 5 minutes
  semantic_cache: true

rate_limiting:
  enabled: true
  redis_url: ${REDIS_URL}
  limits:
    - namespace: user
      tpm: 10000  # tokens per minute
      rpm: 100    # requests per minute

LiteLLM дает гибкость, но требует экспертизы. Если у вас нет dedicated DevOps - лучше начать с Vercel или OpenRouter.

Streaming consistency: самая болезненная тема

В 2026 году пользователи ожидают real-time ответов от AI. Но разные провайдеры реализуют streaming по-разному:

• OpenAI: Server-Sent Events (SSE) с chunk'ами по 4-5 токенов
• Anthropic: HTTP streaming с более крупными chunk'ами
• Google: chunk'и разного размера, иногда с задержками

AI Gateway должен нормализовать эти различия. Vercel справляется хорошо, но иногда добавляет latency (50-100ms). OpenRouter пытается, но не всегда успешно. LiteLLM 4.0 вроде бы решил проблему, но требует тщательной настройки.

Когда что выбирать: decision matrix

Универсального решения нет. Вот как я принимаю решение для проектов:

Миграция и vendor lock-in: главная ловушка

Самая большая проблема с managed решениями - это lock-in. Вы настраиваете логику маршрутизации, кэширования, retry в рамках сервиса. Через год понимаете, что не можете уйти без переписывания половины кода.

Мой совет: проектируйте архитектуру так, чтобы gateway был заменяемым компонентом. Выносите логику маршрутизации в отдельный сервис. Храните конфигурацию в коде, а не в интерфейсе провайдера.

Что будет в 2027: мой прогноз

Тренд 2026 года - специализированные gateway для разных задач. Уже появляются:

• Gateway для локальных моделей с аппаратной оптимизацией
• Gateway для мультимодальных запросов (текст + изображение + аудио)
• Gateway с встроенной RAG (Retrieval-Augmented Generation)

Совет на будущее: не зацикливайтесь на одном gateway. Архитектура должна позволять использовать разные gateway для разных workload'ов. Например, Vercel для веб-приложения, но LLMRouter для batch-обработки данных.

И последнее: тестируйте под нагрузкой. Все gateway ведут себя по-разному при 100, 1000 и 10000 запросов в секунду. Если не хотите тестировать сами - используйте Lynkr как промежуточное решение для оценки производительности.

Выбор gateway в 2026 - это не просто техническое решение. Это стратегический выбор, который определит гибкость вашей архитектуры на годы вперед. Ошибетесь - будете платить дважды: деньгами и временем на переписывание.