LiteLLM против OpenRouter: что выгоднее и когда

MAATRIX

Один ключ и сотни моделей у OpenRouter — или свой шлюз, где вы платите провайдерам напрямую. Вопрос «LiteLLM или OpenRouter» упирается не в список фич, а в три вещи: где проходит наценка, сколько миллисекунд добавляет лишний хоп и из какой страны уходит запрос. Разберём по цифрам, посчитаем точку безубыточности и покажем конфиг, где оба работают вместе.

LiteLLM или OpenRouter: в чём принципиальная разница

Оба дают приложению один OpenAI-совместимый эндпоинт вместо зоопарка SDK. Дальше различия архитектурные.

OpenRouter — чужой сервис. Пополняете баланс, получаете ключ вида sk-or-v1-…, меняете базовый URL на https://openrouter.ai/api/v1. Договоры с OpenAI, Anthropic, Google, Mistral и десятками мелких провайдеров держит он, аптайм тоже его.

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

Для приложения разница — в двух переменных окружения:

# OpenRouter: чужой шлюз, один ваш ключ на всё
OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=sk-or-v1-xxxxxxxx
# LiteLLM: свой шлюз, ключи провайдеров лежат внутри него
OPENAI_BASE_URL=https://llm.example.com/v1
OPENAI_API_KEY=sk-team-analytics-01

Формулировка выбора: OpenRouter продаёт отсутствие эксплуатации, LiteLLM продаёт контроль. Остальное — следствия. Разворачивание шлюза разобрано отдельно: как установить и настроить LiteLLM на VPS.

Деньги: где именно проходит наценка

Главное заблуждение про OpenRouter — что он «дороже, потому что перепродаёт токены». Цена токенов у него обычно равна прайсу провайдера, наценка сидит в пополнении баланса.

• Картой — процессинг порядка 5–5,5% с минимумом около $0,80 на транзакцию. Пополнения по $5 бьют сильнее всего: минимальная комиссия превращается в 16%.
• Криптой — около 5%, минимума нет.
• BYOK, со своим ключом OpenAI, — примерно 5% от суммы, во сколько запрос обошёлся бы по прайсу.

По любому маршруту агрегатор стоит около 5% оборота. У LiteLLM наценка на токены нулевая, но появляется фиксированная статья расходов — VPS. Точка безубыточности считается в одну строчку:

Оборот на моделях = 20 × месячная стоимость VPS.

Ниже — дешевле агрегатор, выше — свой шлюз:

Честный минус LiteLLM, который в таблицу не влезает, — ваше время. Настройка с Postgres, TLS и ключами занимает час-полтора, дальше — полчаса в месяц на обновления и бэкапы базы. При обороте $30 эти полчаса дороже сэкономленного доллара.

Второй минус: встроенный подсчёт расходов не всегда точен. Стоимость считается по вшитому в пакет справочнику model_prices_and_context_window.json; провайдер поменял прайс, а образ не обновлён — /spend/logs покажет старые цифры:

curl -s http://127.0.0.1:4000/spend/logs \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" | jq '.[0] | {model, spend, total_tokens}'

У агрегатора такой проблемы нет: баланс списывается по факту — вот его настоящее преимущество для бухгалтерии.

Доступ из России: 403 от OpenAI и чем это лечится

Критерия, который у нас решает всё, нет ни в одном англоязычном сравнении. С российского адреса прямой запрос в OpenAI отвечает так:

$ curl -s -o /dev/null -w '%{http_code}\n' https://api.openai.com/v1/models \
    -H "Authorization: Bearer $OPENAI_API_KEY"
403

Тело ответа:

{"error":{"message":"Country, region, or territory not supported",
"type":"request_forbidden","param":null,
"code":"unsupported_country_region_territory"}}

Anthropic отдаёт свой 403 с тем же смыслом. Это не проблема ключа: отказ выдаётся по IP источника ещё до проверки авторизации. Похожий отказ уже на самом шлюзе разобран отдельно: LiteLLM не видит API-ключи.

• OpenRouter страновую блокировку по IP не ставит и технически работает даже с домашнего провайдера. Но российской картой там платить нельзя, остаётся крипта, а весь доступ висит на одном домене openrouter.ai — он может отвалиться и по решению сервиса, и по решению регулятора, а запасного маршрута в этот момент не будет.
• LiteLLM на сервере в США решает задачу иначе: наружу запрос уходит с нью-йоркского адреса, а приложение из России ходит по TLS на ваш домен. Домен ваш, DNS ваш, сменить хост — пять минут.

Здесь же контраргумент за агрегатор: сервер за рубежом не выдаёт вам ключи. Аккаунт в OpenAI или Anthropic нужно открыть и оплатить, а это сложнее, чем закинуть USDT на баланс OpenRouter. Если этот вопрос ещё не решён — начните с агрегатора, а на свой шлюз переезжайте, когда ключи появятся.

Оговорка про 152-ФЗ: если в промпты попадают персональные данные российских граждан, логи в базе LiteLLM — уже обработка ПДн. Схема тогда гибридная: шлюз с Postgres на узле в России, исходящий канал к зарубежным провайдерам — через американский. У агрегатора такой развилки нет: и трафик, и логи у него.

Сравнение по критериям: таблица без маркетинга

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

Задержка: сколько миллисекунд добавляет каждый слой

Любой шлюз — лишний сетевой хоп, и его стоит измерить, а не обсуждать:

curl -s -o /dev/null -w 'ttfb=%{time_starttransfer} total=%{time_total}\n' \
  -X POST https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"gpt-4o-mini","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'

Прогон в 50 запросов с VPS 2 vCPU / 4 ГБ в Нью-Йорке, медиана времени до первого байта:

• напрямую в api.openai.com — 0,42 с;
• через LiteLLM на том же хосте (127.0.0.1:4000) — 0,44 с, накладные расходы прокси около 15–25 мс;
• через openrouter.ai/api/v1 с того же сервера — 0,55 с, примерно +130 мс.

Сотня миллисекунд не убивает чат, но в агентном цикле из десяти вызовов инструментов даёт лишнюю секунду на итерацию. Две оговорки. Первая: накладные расходы LiteLLM растут под нагрузкой — это Python и uvicorn, на одном воркере при десятках одновременных запросов p95 уезжает в десятки миллисекунд, лечится --num_workers 4 и запасом по памяти (сколько RAM нужно для LiteLLM-шлюза). Вторая: между Нью-Йорком и Москвой добавляется RTT 110–130 мс, поэтому шлюз ставят рядом с провайдером, а не рядом с пользователем — до модели вы ходите постоянно, а канал до пользователя при keep-alive оплачивается один раз на соединение.

Какая модель ответила на самом деле, LiteLLM пишет в заголовках вида x-litellm-model-id и x-litellm-response-cost (добавьте -D - в curl), а OpenRouter — в ответе https://openrouter.ai/api/v1/generation?id=….

Гибрид: LiteLLM, у которого OpenRouter — один из провайдеров

Практический ответ для большинства команд — не «или», а «и». LiteLLM ходит в OpenRouter как в обычного провайдера, через префикс openrouter/: прямые ключи — основной маршрут, агрегатор — страховка и доступ к экзотике. Рабочий кусок config.yaml:

model_list:
  - model_name: gpt-4o-mini
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY
  - model_name: gpt-4o-mini-backup
    litellm_params:
      model: openrouter/openai/gpt-4o-mini
      api_key: os.environ/OPENROUTER_API_KEY
  - model_name: sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"gpt-4o-mini": ["gpt-4o-mini-backup"]}]

litellm_settings:
  num_retries: 2
  drop_params: true
  cache: true
  cache_params:
    type: redis
    ttl: 600

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

На практике важно:

• master_key обязан начинаться с sk-, иначе шлюз не поднимется. Держите его в .env, не в YAML.
• drop_params: true спасает от падений, когда приложение шлёт параметр, которого у модели нет.
• Кэш на Redis с ttl: 600 экономит на повторяющихся системных промптах, но срабатывает только на идентичных запросах: смена символа — промах.
• Порт 4000 наружу не публикуем: в compose пишем "127.0.0.1:4000:4000", снаружи Nginx с сертификатом, фаервол закрыт — ufw allow 22/tcp, ufw allow 443/tcp, ufw deny 4000/tcp.
• Образ фиксируем тегом, а не latest: ghcr.io/berriai/litellm-database:main-stable либо релиз вида main-v1.72.6. Релизы частые, ломающие изменения — обычное дело.

Ключ с бюджетом выдаётся одним запросом:

curl -X POST http://127.0.0.1:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"models":["gpt-4o-mini","sonnet"],"max_budget":25,"duration":"30d"}'

Главная грабля гибрида — несовпадение имён моделей. В прямом вызове это anthropic/claude-sonnet-4-5, а через агрегатор путь другой, вида openrouter/anthropic/claude-sonnet-4.5. Ошибка в символе — и fallback молча не сработает, а узнаете вы об этом в момент аварии основного провайдера. Проверяйте резерв принудительно: подставьте в основной ключ мусор и убедитесь, что запрос прошёл. И держите на балансе агрегатора запас — иначе вместо fallback получите 402 про недостаток кредитов, а на моделях с суффиксом :free упрётесь в лимиты порядка 20 запросов в минуту (ошибка 429 в LiteLLM).

Какой сервер под LiteLLM брать в MAATRIX

Шлюз — задача сетевая, а не вычислительная: он перекладывает JSON и ждёт ответа провайдера, упираясь в память и число одновременных соединений, почти не в CPU.

Минимум — 1 vCPU / 2 ГБ / 20 ГБ SSD. Хватает для личного шлюза: один воркер, конфиг в YAML, без Postgres и веб-интерфейса, авторизация по мастер-ключу. Ограничение честное: без базы нет виртуальных ключей, бюджетов и истории расходов — половины смысла LiteLLM. На 1 ГБ ставить не советуем: контейнер сам занимает 400–600 МБ, и первый всплеск нагрузки кончается визитом OOM-killer.

Комфортный вариант — 2 vCPU / 4 ГБ / 40 ГБ NVMe. Помещаются LiteLLM с четырьмя воркерами, Postgres 16 и Redis, остаётся запас на логи. Такая машина тянет команду в 10–30 человек и несколько десятков проксируемых запросов в секунду. Место считайте заранее: spend_logs растёт на 1–2 КБ на запрос, миллион запросов — 1–2 ГБ базы, чистите старше 90 дней. Под большой Redis-кэш берите 4 vCPU / 8 ГБ.

Локация — США, Нью-Йорк: чистый американский IP не ловит unsupported_country_region_territory, а до api.openai.com, api.anthropic.com и generativelanguage.googleapis.com идёт короткий стабильный маршрут. Если команда и аудитория в Европе — берите Лондон или Францию, доступ к тем же API есть и оттуда, а пинг до ЕС ниже. Россию — только в описанном выше сценарии с 152-ФЗ: шлюз в РФ до OpenAI напрямую не достучится.

Оплата — картами российских банков, по СБП, криптой или токеном MAAT; иностранная карта для аренды американского сервера не нужна. И последнее, честно: свой шлюз — единая точка отказа, упал VPS — встали все приложения разом. Страховка стоит ноль рублей: держите в конфиге приложения запасной base_url на OpenRouter с небольшим балансом, и авария превратится из простоя в несколько часов чуть более дорогих запросов.

Частые вопросы