LiteLLM: один OpenAI-compatible API для Ollama, OpenAI, Anthropic и других моделей
Если Home Assistant, Open WebUI, скрипты, боты и coding-agents используют разные AI-провайдеры, быстро появляется зоопарк API-ключей, URL и несовместимых форматов. LiteLLM ставится между приложениями и моделями и даёт им единую точку входа. За одним API можно скрыть локальный Ollama, облачный OpenAI, Anthropic, Gemini, Bedrock и другие backends.
LiteLLM — не модель и не inference server, а переводчик и gateway между приложением и LLM
Сам LiteLLM не запускает тяжёлую нейросеть вместо Ollama или vLLM. Его задача другая: принять запрос в известном формате, определить нужный deployment, подставить provider credentials, перевести параметры в формат выбранного backend и вернуть унифицированный ответ.
Многие клиенты достаточно перенаправить на новый base_url.
Приложению не обязательно знать реальное имя модели у провайдера.
Несколько deployments можно объединить под одним logical model name.
Provider keys остаются на gateway, а клиентам можно выдавать отдельные virtual keys.
Главная польза LiteLLM появляется, когда моделей и клиентов уже больше одного
Каждое приложение знает обо всех providers
OpenAI key хранится в одном сервисе, Anthropic — в другом, Ollama URL — в третьем. Замена модели требует менять несколько конфигураций.
Клиенты знают только один адрес
Реальный provider, fallback, budget и credentials можно менять централизованно.
Обычные запросы идут в Ollama, а сложные можно отправлять облачной модели.
Home Assistant, Open WebUI, scripts и automations используют общий gateway.
Каждому пользователю или сервису можно дать отдельный credential и лимиты.
Несколько deployments, retries, spend logs и Prometheus metrics.
LiteLLM Python SDK и LiteLLM Proxy — это разные сценарии
Вы импортируете LiteLLM в собственный Python-код и вызываете разных providers через общий интерфейс. Отдельного сетевого gateway нет.
Несколько клиентов обращаются к одному endpoint. Здесь появляются central auth, routing, virtual keys, spend tracking и admin UI.
Он позволяет не встраивать LiteLLM отдельно в каждое приложение и централизовать переключение моделей.
Минимальный LiteLLM без базы данных
Для одного владельца и нескольких внутренних сервисов можно начать с config file и master key. В этом режиме не будет полноценного Admin UI с virtual keys и корректного budget accounting.
1. Создать litellm_config.yaml
model_list:
- model_name: local-chat
litellm_params:
model: ollama/qwen3.5:8b
api_base: http://host.docker.internal:11434
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY2. Запустить pinned stable image
docker run -d \
--name litellm \
-p 4000:4000 \
--add-host=host.docker.internal:host-gateway \
-v "$PWD/litellm_config.yaml:/app/config.yaml:ro" \
-e LITELLM_MASTER_KEY="sk-CHANGE-ME-LONG-RANDOM-KEY" \
--restart unless-stopped \
docker.litellm.ai/berriai/litellm:1.102.0 \
--config /app/config.yaml3. Проверить запрос
curl http://localhost:4000/v1/chat/completions \
-H "Authorization: Bearer sk-CHANGE-ME-LONG-RANDOM-KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "local-chat",
"messages": [
{"role": "user", "content": "Ответь одним предложением: что такое LiteLLM?"}
]
}'Это административный credential. Если gateway используют несколько клиентов, переходите на database + virtual keys.
Пример конфигурации Ollama, OpenAI и Anthropic
model_list:
- model_name: local-chat
litellm_params:
model: ollama/qwen3.5:8b
api_base: http://host.docker.internal:11434
input_cost_per_token: 0
output_cost_per_token: 0
- model_name: cloud-fast
litellm_params:
model: openai/YOUR_OPENAI_MODEL
api_key: os.environ/OPENAI_API_KEY
- model_name: cloud-claude
litellm_params:
model: anthropic/YOUR_ANTHROPIC_MODEL
api_key: os.environ/ANTHROPIC_API_KEY
general_settings:
master_key: os.environ/LITELLM_MASTER_KEYКлиенту достаточно знать LiteLLM URL, logical model name и свой LiteLLM key. Это удобнее, чем раздавать OpenAI/Anthropic credentials каждому приложению.
Ollama через LiteLLM: когда proxy полезен, а когда только усложняет схему
Проще
Один Home Assistant или один Open WebUI обращается к одной локальной модели. Дополнительный gateway может быть не нужен.
Гибче
Несколько клиентов, aliases, cloud fallback, central logging и одинаковый API для разных providers.
model_list:
- model_name: home-assistant
litellm_params:
model: ollama/qwen3.5:8b
api_base: http://192.168.1.50:11434
input_cost_per_token: 0
output_cost_per_token: 0Явные нулевые cost fields полезны, если локальная модель должна считаться бесплатной в budget logic. В актуальной документации LiteLLM именно так обозначает self-hosted/free model для budget fallback.
Один model name может скрывать несколько deployments
Например, logical model assistant может иметь два backend:
локальный сервер и запасной cloud endpoint. LiteLLM Router умеет выбирать deployment,
делать retries и применять fallback policy.
Если локальный backend недоступен и Router отправляет prompt во внешний API, пользовательские данные покидают локальную инфраструктуру. Это должно быть осознанным решением.
Budgets без database — не реальный spend cap
Это одна из самых опасных ошибок конфигурации. В официальном Docker quick start прямо указано:
если LiteLLM запущен без database, proxy не может загрузить накопленный spend и
max_budget не ограничивает расходы так, как ожидает пользователь.
Запросы могут продолжать обслуживаться после заявленного бюджета.
Virtual keys, team/user budgets и accumulated spend получают persistent state.
Для полноценного gateway
Официальный quick start поднимает LiteLLM вместе с Postgres через Docker Compose. База хранит models, keys и spend logs. Для production дополнительно могут использоваться Redis, Prometheus и отдельные deployment patterns.
OpenAI/Anthropic/Azure provider-side spending limits остаются независимой защитой от неконтролируемого счёта.
Не раздавайте приложениям master key и upstream API keys
В database-backed deployment LiteLLM может выдавать отдельные virtual keys. Их можно связать с user/team, разрешёнными models, rate limits и budget.
Разрешить только локальный model alias и небольшой request limit.
Дать доступ к локальным и нескольким облачным моделям.
Отдельный credential, который легко отозвать без смены provider key.
Отдельный budget и usage tracking для группы пользователей.
LiteLLM остаётся сетевым сервисом, который хранит очень ценные provider credentials.
Home Assistant → LiteLLM → локальная LLM и резервная модель
Такая схема полезна, если кроме Home Assistant те же модели используют другие приложения. Если же Home Assistant — единственный клиент Ollama, отдельная официальная интеграция Ollama проще.
LiteLLM хранит provider credentials — относитесь к нему как к критичному API gateway
В 2026 году у LiteLLM опубликован ряд серьёзных advisories. Например, critical Host Header authentication bypass затрагивал версии ниже 1.84.0, а августовская SSRF/provider-credential exfiltration — старые ветки до соответствующих patched releases. Текущая 1.102.0 новее этих исправлений, но это не повод перестать обновляться.
Не поднимать старый image из статьи 2024–2025 года.
Не выставлять management endpoints непосредственно в интернет.
Explicit server_name/host allowlist остаётся полезной дополнительной защитой.
Не хранить provider keys прямо в Git-tracked config.yaml.
Master key должен оставаться административным credential.
Gateway должен быть единой контролируемой точкой входа.
История advisories включает SSRF и утечки provider credentials через параметры routing. Для multi-user deployment нужны и обновления, и least-privilege model/key policies.
Когда LiteLLM не нужен или создаёт лишнюю точку отказа
Прямое подключение проще и надёжнее.
Если LiteLLM недоступен, все клиенты теряют доступ сразу.
Это активно развивающийся security-sensitive proxy.
OpenAI compatibility не отменяет различия tools, reasoning, streaming и provider-specific params.
Virtual keys, budgets и UI требуют persistent database infrastructure.
Маршрутизация должна учитывать не только availability, но и правила обработки данных.
Один backend — прямое подключение. Несколько backend/клиентов/ключей — gateway уже начинает окупать свою сложность.
Три разумных варианта
Один владелец, LAN, master key, Ollama + 1–2 cloud providers. Без budgets и virtual keys.
Virtual keys, spend tracking, UI, отдельные credentials для Home Assistant/Open WebUI/automation.
Load balancing, high availability, Prometheus, reverse proxy и отдельные access policies.
LiteLLM: версия, документация, security и лицензия
Актуальный stable PyPI release на дату проверки — litellm 1.102.0 от 20 сентября 2026 года.
LiteLLM полезен не как «ещё один AI», а как единая точка управления всеми остальными
Для одного локального Ollama дополнительный gateway чаще всего не нужен. Но когда появляются Home Assistant, Open WebUI, automation scripts, несколько cloud providers и разные API credentials, централизованный слой становится удобным.
Самая практичная домашняя схема — LiteLLM в LAN/VPN, локальный Ollama как основной backend,
облачные модели только как осознанные aliases/fallback, а provider keys хранить исключительно на gateway.
Если нужны budgets и virtual keys — сразу добавлять Postgres, а не рассчитывать на config-only max_budget.
Частые вопросы о LiteLLM
LiteLLM запускает локальные модели?
Нет. Локальную модель запускает Ollama, vLLM или другой inference server. LiteLLM проксирует запросы к нему.
Зачем ставить LiteLLM перед Ollama?
Чтобы получить единый API, aliases, routing, fallback, central auth и возможность одновременно подключать cloud providers.
Можно ли использовать LiteLLM без базы данных?
Да. Для простого config-only proxy достаточно config.yaml и master key. Но virtual keys и полноценные budgets требуют database.
Работает ли max_budget без Postgres?
Официальная документация предупреждает, что без database accumulated spend не хранится корректно, поэтому такой max_budget нельзя считать надёжным spending cap.
Можно ли подключить Home Assistant?
Да, через OpenAI-compatible endpoint. Но если используется только Ollama и ничего больше, отдельная официальная интеграция Ollama проще.
Безопасно ли хранить OpenAI key в LiteLLM?
Это нормальный сценарий gateway, но сервер становится критичной точкой: secrets должны храниться в environment/secrets store, gateway — обновляться и не быть открытым напрямую наружу.
Какой порт использует LiteLLM Proxy?
Типичный default в документации — 4000.
Какая версия актуальна?
На момент проверки 21 сентября 2026 года stable PyPI release — 1.102.0.
Нужно объединить Ollama, облачные LLM и несколько приложений за одним API?
Можно подобрать архитектуру gateway, aliases, fallback и безопасный доступ, чтобы Home Assistant, Open WebUI и другие сервисы не хранили provider credentials каждый у себя.
