LiteLLM Proxy для Ollama: единый локальный API без облачного fallback

Когда нужен прокси поверх Ollama?

Если приложение ожидает OpenAI-совместимый /v1/chat/completions, LiteLLM Proxy может дать ему единый адрес, сохранив Ollama как backend. В model_list клиентское имя model_name сопоставляется с провайдером и конкретным тегом; провайдер LiteLLM ollama_chat предназначен для диалогового API /api/chat Ollama. Это способ унифицировать интерфейс, а не обещание, что любая модель поддержит нужные инструменты или формат ответа. s1 s2 s3

Для минимальной проверки возьмите qwen3:0.6b из библиотеки Ollama. Карточка показывает digest с началом 7df6b6e09427 и Apache License 2.0; сверьте digest реально загруженного тега, а условия использования — с полным текстом лицензии. Малый вариант нужен здесь лишь для проверки проводки: способность решать конкретную бизнес-задачу, качество русского языка и аппаратные требования этим выбором не установлены. Размер файла весов на странице модели не равен минимальной RAM или VRAM. s8 s7

Как настроить единственный локальный маршрут?

Сначала установите и запустите Ollama по вводному руководству, загрузите ollama pull qwen3:0.6b, проверьте наличие нужного тега командой ollama list и ответ curl http://127.0.0.1:11434/api/tags. Данные /api/tags включают имя и digest. Загрузка пакетов и весов сама требует сети: не начинайте её с реальными документами в закрытом контуре. s6 s7 s8

На одном хосте с Ollama создайте в отдельном каталоге файл config.yaml с таким содержимым: строка 1 — model_list:, строка 2 — - model_name: local-qwen, строка 3 — litellm_params:, строка 4 — model: ollama_chat/qwen3:0.6b, строка 5 — api_base: http://127.0.0.1:11434. Эти пять строк образуют один YAML-документ; отступы важны. Здесь нет второго deployment, облачного провайдера, fallbacks, общего имени с облачной моделью или произвольного URL. Если прокси работает в отдельном контейнере, его 127.0.0.1 указывает на сам контейнер, а не на Ollama: тогда нужно отдельно проверить доступный адрес в закрытой сети контейнеров и не публиковать порт наружу. s1 s2 s4 s6

Создайте уникальный секрет LITELLM_MASTER_KEY в окружении процесса, не вписывая его в статью, конфигурацию или историю команд. Запустите установленный LiteLLM Proxy командой litellm --config config.yaml --host 127.0.0.1 --port 4000 и убедитесь, что он слушает только loopback. Флаги CLI документированы; способ установки зависит от выбранного окружения и версии. Master key — административное полномочие: не передавайте его браузерному приложению или в публичный репозиторий; для командной проверки используйте локальный процесс с защищённой переменной окружения. Без БД минимальный режим не предоставляет полноценный цикл виртуальных ключей и учёт расходов. s2 s3 s5

Как проверить, какой backend ответил?

С тестовой вымышленной фразой выполните curl -sS http://127.0.0.1:4000/v1/chat/completions -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" -H 'Content-Type: application/json' -d '{"model":"local-qwen","messages":[{"role":"user","content":"Ответь одним словом: тест"}]}'. Успех означает, что клиент получил ответ по имени local-qwen; отдельно сопоставьте время запроса с журналом прокси и Ollama. Затем остановите Ollama и повторите тот же запрос: вместо правдоподобного ответа ожидайте ошибку недоступного backend; если ответ всё-таки пришёл, прекратите тест и выясните реальный маршрут. Это критерий проверки, а не обещание конкретного HTTP-кода или текста ошибки. s1 s2 s3 s6

Верните Ollama на место и отправьте запрос с несуществующим model в том же тестовом окружении. Не доверяйте одному коду ошибки: администратор может добавить модели через другие каналы конфигурации или изменить маршрутизацию. Сохраните снимок текущего списка deployments/настроек, скройте чувствительные поля в журналах и сопоставьте реальные обращения с локальным сервером. Возможности Router включают повторные попытки, балансировку и fallback между развертываниями; поэтому при расширении конфигурации перепроверьте каждый маршрут заново. s2 s4

Когда нельзя считать маршрут приватным?

Адрес 127.0.0.1 в api_base — конфигурационное намерение, не доказательство отсутствия сетевых обращений процесса. В отдельном протоколе проверки офлайн-контура проверьте сетевой след LiteLLM и Ollama: разрешите только необходимый локальный трафик, заблокируйте внешние назначения, повторите положительный запрос и негативный тест с отключённым Ollama. Обратите внимание на плагины логирования, дополнительные модели, динамические настройки и обновления: перед обработкой реальных данных их надо оценивать по фактической конфигурации. Локальный API http://localhost:11434/api и прямой облачный https://ollama.com/api — разные адреса. s2 s4 s6

Если ответ не приходит, начните с /api/tags на Ollama, точного тега, отступов YAML, model_name, переменной master key и того, видит ли прокси 127.0.0.1:11434 из своего сетевого пространства. Если диалоговая модель не понимает API-запрос, проверьте ollama_chat/ и версию интеграции. Не включайте подробное логирование реальных запросов лишь ради диагностики: оно может сохранить содержимое чувствительного сообщения. Modelium не запускал эту связку, не измерял скорость и не проверял закрытый контур. s1 s2 s3 s5 s7

Следующий шаг: пройдите сетевой тест закрытого контура на вымышленных данных. Задокументируйте версии, адреса, digest, ожидаемые ошибки и фактические назначения соединений; только после положительного и отрицательного теста решайте, может ли этот маршрут обслуживать корпоративные документы. s4 s6 s7