🔀

Обзор LiteLLM 2026: единый AI-шлюз для 100+ LLM-провайдеров

Обзор LiteLLM 2026: единый AI-шлюз для 100+ LLM-провайдеров

🏷️ LLM Gateway
📝 3100 words

LiteLLM — единый AI-шлюз к 100+ LLM-провайдерам

Открытый LLM Gateway, ставший де-факто стандартом: один OpenAI-совместимый эндпоинт, виртуальные ключи, бюджеты по командам, fallback и роутинг по стоимости. Одна строка кода — и вы больше не привязаны к провайдеру.

🕒 Обновлено: сентябрь 2026  ·  🔀 LLM Gateway / Proxy  ·  🪪 MIT (open-core)  ·  🏷️ ~53.6K★ GitHub

Что такое LiteLLM и почему это «шлюз»

LiteLLM решает проблему, с которой сталкивается каждая команда, вышедшая за пределы одного LLM-провайдера: менять модель — значит менять код. OpenAI говорит по-своему, Anthropic — по-своему, Gemini и Bedrock — совсем иначе. LiteLLM убирает эту связку: вы пишете один вызов completion() против OpenAI-схемы, а шлюз сам переводит запрос в формат нужного вендора и переводит ответ обратно.

К 2026 году это превратилось в настоящий стандарт Python-разработки: ~53,6 тыс. звезд на GitHub и ~96 млн PyPI-загрузок в месяц, а продакшен на LiteLLM держат команды Netflix, Lemonade и Rocket Money. Если вы уже видели DSPy, CrewAI или LangChain в действии — вероятно, LiteLLM был у них роутинг-слоем.

💡 Производственный ориентир из наблюдений: корпоративные траты на LLM-API в 2026 перевалили за $8+ млрд, и заметная часть «сгорания бюджета» приходится не на сами модели, а на отсутствие роутинг-слоя между кодом и провайдером. LiteLLM заточен именно под эту проблему.

Два режима: Python SDK и Proxy Server

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

РежимЧто этоКому подходит
Python SDKБиблиотека, встраиваемая прямо в код: один completion() для 100+ провайдеров.Сольные разработчики, прототипы, приложения на Python.
Proxy ServerСамодостаточный HTTP-сервер (FastAPI) — корпоративный AI-шлюз, к которому подключаются любые клиенты OpenAI-API.Команды, Cursor / Claude Code backend, централизованные ключи и бюджеты.

Как это выглядит в архитектуре

LiteLLM Proxy — единый эндпоинт для всей команды Claude Code Cursor / IDE Python / Node curl / API LiteLLM Proxy /v1/chat/completions · виртуальные ключи · бюджеты OpenAI / Anthropic GPT · Claude · Gemini Local (Ollama / vLLM) без API-ключа Bedrock / Vertex / Azure любые 100+ провайдеров Любой клиент overnight: без смены кода переключается между облаком и локальной моделью

Главное для команд: виртуальные ключи и бюджеты

Сильная сторона Proxy — централизованное управление доступами. Приложения получают не реальные ключи провайдеров, а виртуальные ключи, выпущенные шлюзом. Если ключ утёк — отзываете его в панели, не ротируя креды в каждом сервисе.

Поверх виртуальных ключей LiteLLM умеет вести пер-командные бюджеты, rate limiting и автоматический подсчёт стоимости каждого вызова. Это превращает кучу разных счетов от разных провайдеров в единую картину расходов с учётом по командам и проектам — как раз то, чего не хватает, когда стек растёт.

Ключевые возможности Proxy

ФункцияЧто даёт
Виртуальные ключиОтдельные ключи для каждого сервиса/разработчика; отзыв без смены провайдерских кредов.
Бюджеты и лимитыПер-командные лимиты, rate limiting, стоп при превышении.
Fallback-цепочкиПри падении одного провайдера запрос автоматически уходит к резервному.
РоутингРаспределение по латентности, стоимости или весу; least-busy, simple-shuffle.
Кэш и guardrailsСемантический кэш, модерация («грабли») на уровне шлюза.
НаблюдаемостьOpenTelemetry, интеграция с Langfuse / MLflow / Helicone в одну строку.

Установка и первый запуск

# Python SDK uv add litellm # или pip install litellm # Proxy Server (с поддержкой шлюза) uv tool install 'litellm[proxy]' # запуск шлюза litellm --config config.yaml --port 4000 # → http://localhost:4000/v1/chat/completions (OpenAI-совместимый)

В production Proxy обычно разворачивают в Docker/Docker Compose вместе с Redis (кэш, rate limiting). Клиенты — Claude Code, Cursor, OpenAI SDK, LangChain, Vercel AI SDK — просто указывают api_base на ваш шлюз, и код можно не трогать.

Полный пример конфигурации с провайдерами и fallback — на официальной документации LiteLLM.

LiteLLM vs альтернативы (Portkey, Cloudflare AI Gateway)

Универсальный шлюз — не единственная опция. Сравниваем с ближайшими коммерческими конкурентами, чтобы была видна цена «open-source-пути».

КритерийLiteLLMPortkeyCloudflare AI Gateway
МодельOpen-source (MIT, open-core)SaaSSaaS-платформа
ЦенаБесплатно, вы хостите самиот $49/мес (Hobby) / $199 (Growth)+$0.20 за млн gateway-запросов
Установкаpip + свой сервериз коробкина вашем Cloudflare-аккаунте
Операционная нагрузкаВы отвечаете за аптайм и обновлениянизкаянизкая
Лучше длякоманд с собственной K8s/opsтех, кто не хочет хоститьуже живущих в Cloudflare
⚠️ Трезвый компромисс: open-source-шлюз — самый дешёвый путь по деньгам, но вы забираете себе эксплуатацию — мониторинг, масштабирование и патчи. Если у команды нет ops-возможностей, SaaS-шлюз может оказаться дешевле по совокупной стоимости владения.

Где это в экосистеме Qantcore

LiteLLM закрывает «роутинг-слой» стека. По соседству с ним:

  • OpenRouter — SaaS-аналог шлюза (одна подписка, единый API). LiteLLM — self-hosted вариант того же паттерна.
  • Langfuse — наблюдаемость LLM-стеков, с которой LiteLLM интегрируется в одну строку.
  • LangGraph — оркестрация агентов поверх провайдеров; LiteLLM — слой доступа к ним.
  • RAG-стеки — удобно гонять через один шлюз, чтобы менять модель ретривала без правок кода.
  • Ollama / vLLM — локальные модели как «провайдеры» в том же конфиге шлюза.

✅ Для команды, строящей AI-стек, LiteLLM — самый дешёвый способ перестать быть запертым у одного вендора: облачные и локальные модели объединяются под единственным эндпоинтом.

Ключевые метрики

53.6K★
звёзд на GitHub
📦
96M/мес
PyPI-загрузок
🔀
100+
провайдеров
8ms
P95-латентность
🚀
1.5K+
RPS throughput
🏢
Netflix
и др. в проде

Плюсы и минусы

✅ Что радует

  • Один API ко всем — пишете раз, провайдера меняете строкой конфига.
  • Виртуальные ключи — чистая безопасность и отзыв доступа без ротации.
  • Бюджеты и учёт стоимости — контроль расходов по командам из коробки.
  • Fallback и роутинг — меньше простоев и счёта за дорогую модель.
  • Open-source — бесплатно, MIT, тысячи контрибьюторов.

⚠️ Чего не хватает

  • Операционная нагрузка — шлюз надо хостить, мониторить и патчить.
  • Enterprise-фичи paywalled — часть корпоративных возможностей закрыта в платном ядре.
  • Кривая настройка — базовое — просто, production-конфиг требует погружения.
  • Не для одной модели — если провайдер один и навсегда, оверинжиниринг.

Итог и вердикт Qantcore

🏆 Оценка Qantcore: ★★★★☆ 8.8 / 10

LiteLLM — это не «ещё одна библиотека», а тот самый невидимый слой, который де-факто уже держит на себе значительную часть LLM-приложений в Python. Особенно он незаменим там, где команда перестала выбирать «одну модель навсегда» и начала микстовать провайдеров по цене и скорости.

Практический вывод: начинайте с Python SDK, а с ростом числа разработчиков и сервисов поднимайте Proxy — виртуальные ключи и бюджеты окупят затраты на хостинг уже на второй-третьей команде. Для тех, кто не хочет хостить вовсе, рядом есть SaaS-аналоги (включая OpenRouter), но именно LiteLLM даёт максимум контроля без подписки.