LiteLLM и OpenRouter: стоимость, контроль и отказоустойчивость

При выборе LLM-шлюза важно не столько то, умеют ли LiteLLM и OpenRouter работать с OpenAI-совместимым API, сколько то, кто отвечает за слой маршрутизации. OpenRouter — самый простой вариант для старта, если у команды ещё нет собственной production-инфраструктуры шлюза. LiteLLM оправдывает дополнительные расходы, когда приватная сеть, собственные политики или стабильная высокая нагрузка делают контроль важнее затрат на эксплуатацию.

Вы выбираете не формат API, а операционную модель

LiteLLM — это open-source ПО, которое можно использовать как Python SDK или самостоятельно размещаемый прокси. OpenRouter — управляемый API и каталог моделей: OpenRouter эксплуатирует шлюз, объединяет доступ к провайдерам и предоставляет единый аккаунт для работы с моделями.

Оба решения могут предоставлять OpenAI-совместимый интерфейс, но ответственность распределяется по-разному:

Из этого же различия следует, что эти решения можно комбинировать: LiteLLM будет отвечать за внутренние политики и учёт, а OpenRouter — за доступ к отдельным моделям.

Выбирайте ограничение, которое проявится первым

Правильный выбор определяется первым требованием, которым команда не готова поступиться.

Считайте не только токены, но и стоимость эксплуатации

LiteLLM и OpenRouter берут деньги за разные уровни сервиса. OpenRouter передаёт базовую стоимость моделей без наценки за инференс, а затем взимает комиссию 5,5% при покупке кредитов. У open-source-прокси LiteLLM нет комиссии шлюза за каждый токен, зато инфраструктуру и специалистов для его эксплуатации оплачиваете вы.

Страница тарифов OpenRouter — актуальный источник условий по комиссиям. Комиссия взимается при покупке кредитов, а не представляет собой простую наценку 5% на стоимость токенов каждой модели.

Когда комиссия OpenRouter оказывается выгоднее

Если команда покупает достаточно кредитов OpenRouter, чтобы покрыть месячный счёт за инференс:

• При ежемесячных расходах $500 комиссия 5,5% за покупку кредитов составит $27.50.
• При расходах $20,000 тот же процент составит $1,100.
• При расходах $50,000 — $2,750.

Эти суммы показывают, какую стоимость LiteLLM должен превзойти с учётом хостинга, развёртывания, установки патчей, алертов, резервного копирования и времени инженеров. При $500 в месяц OpenRouter часто оказывается более простым в эксплуатации вариантом для команды, которая ещё не поддерживает собственный шлюз, если только приватная сеть не является обязательным требованием. При $20,000 команде, отвечающей за платформу, уже стоит серьёзно посчитать LiteLLM.

Когда отсутствие комиссии LiteLLM действительно экономит деньги

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

В официальном Docker quickstart отдельно описаны простой прокси без базы данных и развёртывание с базой данных. В сценарии Compose PostgreSQL используется для хранения моделей, ключей и логов расходов. Без базы данных, как указывает LiteLLM, недоступны виртуальные ключи, отслеживание расходов и полноценное применение бюджетных ограничений; заданный max_budget нельзя считать надёжным жёстким лимитом.

Redis создаёт ещё один порог готовности к production. В разделе требований LiteLLM к Redis рекомендуется общее состояние Redis, если прокси работает более чем с одним worker’ом или репликой. Без него rate limits, бюджеты, cooldown’ы, записи кэша и данные для маршрутизации распределяются между worker’ами. Тест с одним worker’ом стоит недорого, а production-шлюз с горизонтальным масштабированием — это уже более крупная система.

Сравнивайте решения по такой формуле, а не только по цене токенов:

Полная стоимость LiteLLM = счета провайдеров + инфраструктура + эксплуатация + ответственность за безопасность
Полная стоимость OpenRouter = инференс у провайдера + комиссия за покупку кредитов

Универсальной точки безубыточности не существует. Для расчёта нужны месячные расходы на инференс, стоимость хостинга, часы инженерной работы, покрытие дежурствами и возможная надбавка за требования комплаенса.

Сравните control plane, которым придётся управлять

LiteLLM даёт платформенной команде больше контроля, но не создаёт доступ к провайдерам автоматически. OpenRouter удобнее для поиска моделей и единого биллинга, однако размещённый каталог — не то же самое, что прямые отношения с провайдерами.

На отказоустойчивости различия становятся особенно заметны

Оба продукта умеют повторять запросы и переключаться при сбоях, но ответственность за failover устроена по-разному. OpenRouter управляет пулом провайдеров, а LiteLLM позволяет вам самим определить этот пул — и требует встроить шлюз в собственный стек надёжности.

В документации OpenRouter по маршрутизации провайдеров сказано, что по умолчанию сервис распределяет нагрузку между доступными провайдерами с учётом цены и недавних сбоев. Можно задать порядок провайдеров, разрешить или запретить fallback, потребовать определённые параметры, отфильтровать варианты по политике работы с данными или сортировать их по цене, пропускной способности и задержке. В руководстве по fallback для моделей описан упорядоченный список models; оплата рассчитывается по модели, которая в итоге обслужила запрос.

В документации LiteLLM по маршрутизации описаны взвешенный и случайный выбор, маршрутизация с учётом использования, задержки, наименее загруженного узла и стоимости, а также пользовательские стратегии. Поддерживаются приоритеты deployment’ов, cooldown’ы, повторы и группы fallback. Эти настройки дают больше возможностей для программирования, но их корректность зависит от вашей конфигурации, health checks, общего состояния и реакции на инциденты.

Задержки агентов, кэширование и изменения у провайдеров

Один дополнительный сетевой переход может быть незаметен при длинном потоковом ответе. Но когда агент делает десятки коротких вызовов модели, задержки шлюза, сети и повторных запросов накапливаются от шага к шагу. Self-hosted-прокси LiteLLM можно разместить рядом с приложением, тогда как OpenRouter добавляет управляемый сервис между ним и выбранным провайдером. Общая документация обоих сервисов не заменяет тестирование в вашем регионе, с нужной моделью, потоковой передачей и уровнем параллелизма.

Маршрутизация влияет и на экономику кэширования. OpenRouter может выбирать разные endpoint’ы провайдеров для одной модели, а LiteLLM — распределять запросы между настроенными deployment’ами. Если процесс зависит от prompt caching на стороне провайдера, смена маршрута может изменить локальность кэша и стоимость токенов. Поведение кэша нужно проверять в составе теста нагрузки.

Одинаковый slug модели также не гарантирует одинаковое поведение. Реализации провайдеров могут различаться ограничениями контекста, поддержкой tool calls, задержкой, квантизацией, кэшированием и специфичными параметрами. OpenRouter предоставляет фильтры провайдеров, например require_parameters, а LiteLLM приводит вызовы разных провайдеров к единому интерфейсу. Проверяйте именно те схемы инструментов и параметры моделей, которые использует ваш агент.

Какие сбои нужно предусмотреть

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

У наблюдаемости и приватности разные границы

«Self-hosted» и «приватный» — не синонимы, а «управляемый» не означает «сервис записывает каждый промпт». Важно понимать, какой слой хранит содержимое, какой — метаданные и какие провайдеры получают запрос.

В документации OpenRouter по Zero Data Retention сказано, что ZDR можно включить для всего аккаунта, группы моделей, guardrail или отдельного запроса. Документация различает endpoint’ы без хранения данных и провайдеров, которые не используют данные для обучения, но могут временно их сохранять. ZDR относится к маршрутизации инференса; включённые инструменты и плагины требуют отдельной проверки.

LiteLLM даёт больше контроля над сетью, базой данных, аутентификацией и логами шлюза, но вся ответственность лежит на вас. Защищайте прокси, устанавливайте патчи, ограничивайте административные маршруты, берегите ключи провайдеров и проверяйте условия хранения и использования данных для обучения у каждого внешнего провайдера.

Гибридная схема часто оказывается самым практичным решением

Ставьте LiteLLM перед OpenRouter, если вам нужен стабильный внутренний endpoint и централизованное управление, но нет желания открывать отдельный аккаунт для каждой модели или каждого провайдера. Чувствительный или предсказуемый трафик направляйте напрямую к одобренным провайдерам, а запросы к экспериментальным моделям и широкому каталогу — через OpenRouter.

Упрощённый вариант конфигурации выглядит так:

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

Так LiteLLM получает место для применения внутренних ключей, бюджетов, тегов и логирования. Но это не отменяет комиссию OpenRouter, передачу данных через его инфраструктуру или границу политики провайдера для запросов, отправленных по маршруту OpenRouter. Кроме того, появляется ещё один переход и ещё одна зона отказа, поэтому не стоит автоматически проводить через оба слоя весь трафик.

Разумное разделение выглядит так:

1. Прямые маршруты к провайдерам — для чувствительных данных, стабильных production-моделей или согласованных контрактов с провайдерами.
2. Маршруты через OpenRouter — для поиска моделей, редких провайдеров и управляемого fallback между провайдерами.
3. Контроли LiteLLM — для ключей приложений, команд, бюджетов и внутреннего распределения расходов.
4. Отдельные дашборды и алерты для трафика через прямых провайдеров и OpenRouter.

Миграция: что изменится, а что останется прежним

Перенести OpenAI-совместимый клиент с одного шлюза на другой может быть несложно. Но перенос production-нагрузки — это не просто замена base URL.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter обычно использует https://openrouter.ai/api/v1 (справочник API), а прокси LiteLLM обычно доступен по приватному endpoint’у вроде http://localhost:4000 (quickstart прокси). При этом могут различаться идентификаторы моделей, префиксы провайдеров, аутентификация и дополнительные параметры.

Перед переключением production-трафика проверьте:

1. Поведение потоковой передачи и тайм-аутов.
2. Tool calls с вашими точными JSON-схемами.
3. Структурированные ответы и строгую обработку JSON.
4. Параметры reasoning, кэширования и специфичные для провайдера настройки.
5. Поведение fallback, когда основная модель возвращает 429, 5xx или ошибку валидации.
6. Распределение расходов, поскольку событие биллинга может происходить на другом уровне, чем запрос приложения.

Совместимость API помогает пройти первый этап интеграции. Она не гарантирует одинаковые ответы, задержку, выбор провайдера или правила биллинга.

Что команды обычно спрашивают перед выбором

Можно ли использовать LiteLLM и OpenRouter вместе?

Да. LiteLLM может использовать OpenRouter как upstream-маршрут: тогда LiteLLM отвечает за внутренние ключи, бюджеты, логирование и политики, а OpenRouter предоставляет выбранные модели и маршрутизацию между провайдерами. В объединённой схеме появляется дополнительный переход, а для такого трафика сохраняются комиссия OpenRouter и граница передачи данных через его инфраструктуру.

Что дешевле для production API?

Для небольшой команды, которая ещё не эксплуатирует собственную инфраструктуру шлюза, OpenRouter часто оказывается вариантом с меньшими операционными затратами. LiteLLM может быть дешевле при высокой нагрузке, если команда уже поддерживает необходимую инфраструктуру и хочет избежать процентной комиссии шлюза. Сравнивайте полную стоимость, а не только цену токенов.

Даёт ли LiteLLM доступ ко всему каталогу OpenRouter?

Сам по себе — нет. В quickstart прокси LiteLLM заявляет поддержку более 100 LLM и широкого набора провайдеров, но фактически работает только с теми провайдерами и учётными данными, которые вы настроили. Подключение OpenRouter как upstream расширит доступный каталог, однако такие запросы будут зависеть от доступности моделей и провайдеров OpenRouter.

Что лучше для приватности и комплаенса?

Self-hosted LiteLLM даёт больше контроля над размещением шлюза, логами, учётными данными и сетевой границей. OpenRouter предлагает настройки логирования содержимого, фильтры политик провайдеров, маршрутизацию ZDR и региональные варианты Enterprise для EU/US, но остаётся частью пути запроса. Перед выбором проверьте конкретного провайдера и точное договорное требование.

Выбирайте ту границу ответственности, которую способны поддерживать: сопоставьте процентную комиссию с реальной стоимостью эксплуатации собственного шлюза, определите, какие запросы могут проходить через управляемого посредника, и протестируйте сбои с учётом нужной вашему приложению маршрутизации и поведения tool calls. Если команда не может взять на себя базу данных, Redis, обновления и дежурства LiteLLM, OpenRouter — более честный вариант по умолчанию. Если такая платформенная база уже есть, LiteLLM или гибридная схема помогут вернуть контроль и сократить регулярные комиссии шлюза.

Более широкий список альтернатив OpenRouter ищите в статье OpenRouter alternatives. Это сравнение намеренно уже: оно посвящено именно выбору операционной модели LiteLLM.