LiteLLM: единый шлюз к LLM

MLOps / LLMOps · Шлюз

Не изучено

Добавлено 2026-10-29.

Проблема

Ключи облачных моделей раскиданы по сервисам, расходы не видны, а смена провайдера требует правок в коде каждого приложения.

Решение

Поставить OpenAI-совместимый proxy: приложения ходят в один адрес, провайдеры и локальные модели настраиваются в одном конфиге, виртуальные ключи получают бюджеты и лимиты.

Пример

config.yaml:

model_list:
  - model_name: local-llm
    litellm_params:
      model: ollama/llama3
      api_base: http://127.0.0.1:11434

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

litellm_settings:
  callbacks: ["prometheus"]

Перед запуском проверить подпись образа — проект публикует её для каждого релиза:

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
  ghcr.io/berriai/litellm:<release-tag>

Виртуальные ключи с бюджетом (max_budget) выдаются через /key/generate и требуют базу данных (DATABASE_URL).

Версии 1.82.7 и 1.82.8

24 марта 2026 года на PyPI вышли вредоносные litellm 1.82.7 и 1.82.8: токен публикации украли через незакреплённый Trivy в CI проекта. Фиксировать версию и digest образа, не ставить latest. Если эти версии ставились — считать машину скомпрометированной и ротировать доступные с неё секреты.

Когда применять

Когда LLM используют два и больше приложения или нужен учёт расходов по командам.

Источник

• BerriAI/litellm — MIT, кроме каталога enterprise/
• README: проверка подписи образов
• Snyk: разбор компрометации 1.82.7/1.82.8

Как применить у себя

1. Поднять proxy в Docker с закреплённым digest и проверенной подписью.
2. Подключить одну облачную и одну локальную модель.
3. Выдать виртуальный ключ с бюджетом и проверить, что лимит срабатывает.
4. Отметить «Изучено», когда метрики видны в Prometheus и приложения ходят только через шлюз.