Как запустить LLM в продакшене: Ollama и Docker для самообслуживания

Запуск локальной языковой модели (LLM) в продакшене требует больше, чем просто установка Ollama в один контейнер. В этой статье мы разберем, как превратить Ollama из демо-инструмента в масштабируемый сервис с помощью Docker, балансировки нагрузки и мониторинга. Вы узнаете, какие архитектурные решени

Запуск локальной языковой модели (LLM) в продакшене требует больше, чем просто установка Ollama в один контейнер. В этой статье мы разберем, как превратить Ollama из демо-инструмента в масштабируемый сервис с помощью Docker, балансировки нагрузки и мониторинга. Вы узнаете, какие архитектурные решения обеспечат стабильную работу, как кешировать модели и контролировать производительность.

Архитектура продакшена: от одного контейнера к оркестрации

Когда вы запускаете Ollama локально, всё работает быстро: модель загружается, отвечает на запросы и выгружается. Но в продакшене такой подход приводит к катастрофическому росту времени отклика, если каждый запрос требует загрузки модели с нуля. Решение — построить архитектуру на основе Docker Compose с несколькими сервисами: сам Ollama, балансировщик нагрузки (например, Traefik или Nginx), кеш моделей и система мониторинга (Prometheus + Grafana). Это позволяет обрабатывать множество запросов, не теряя производительность.

Ключевая проблема — загрузка моделей в память. Ollama поддерживает настройку OLLAMAKEEPALIVE, которая определяет время удержания модели в памяти после последнего запроса. Установив это значение в несколько минут или часов, вы избегаете перезагрузки модели для каждого нового запроса. Однако нужно учитывать, что модель занимает значительный объем RAM (например, Llama 3 8B — около 16 ГБ в float16). Поэтому важно настроить пул моделей, которые постоянно остаются в памяти, и балансировать запросы между ними.

Как работает балансировка нагрузки для LLM?

В отличие от обычных веб-сервисов, LLM потребляют много ресурсов и имеют длительное время ответа. Балансировщик должен учитывать, что каждый запрос может быть к разной модели. Решение — использование очередей и лимитов на количество одновременных запросов. В руководстве SitePoint предлагается использовать Traefik с middleware для ограничения скорости и проверки доступности модели. Если модель не загружена, запрос должен быть перенаправлен на сервис загрузки, а затем обработан. Для этого можно использовать отдельный эндпоинт /api/pull и кеширование на уровне Docker-образов.

Важно: для продакшена необходимо настроить HTTPS, авторизацию и логирование. Traefik автоматически получает SSL-сертификаты через Let's Encrypt, а middleware может проверять API-ключи. Также стоит добавить health check для каждого сервиса, чтобы балансировщик не отправлял запросы на неработающие инстансы.

Технические детали: Docker Compose и мониторинг

Пример docker-compose.yml включает три основных сервиса: - ollama: основной сервис с монтированием томов для хранения моделей и настройками OLLAMAKEEPALIVE. Рекомендуется использовать образ ollama/ollama:latest и указать переменные окружения, например OLLAMAKEEPALIVE=5m. - traefik: балансировщик, который маршрутизирует запросы к Ollama и обеспечивает HTTPS. Настройка включает правила маршрутизации по хосту или пути, а также middleware для ограничения скорости. - prometheus и grafana: для сбора метрик (время ответа, количество запросов, использование памяти). Ollama экспортирует метрики в формате Prometheus, которые можно визуализировать в Grafana.

Модели предлагается кешировать с помощью Docker-слоёв: при первом запросе модель загружается в слой, который затем используется повторно. Это сокращает время запуска новых экземпляров. Для этого можно создать Dockerfile, который предварительно загружает нужные модели, или использовать volume, чтобы модели сохранялись между перезапусками.

Для мониторинга используются метрики Ollama, которые экспортируются через Prometheus. Grafana позволяет отслеживать загрузку GPU (если используется) и предсказывать пики нагрузки. Например, можно настроить алерты на высокую задержку или использование памяти.

Кого затронет и как

Разработчики, которые хотят развернуть свой чат-бот или AI-ассистент без привязки к облачным провайдерам, получат готовый шаблон. Особенно это актуально для российских компаний, где доступ к OpenAI и другим API может быть нестабильным. Решение на Ollama и Docker позволяет сохранить контроль над данными и снизить затраты.

Для DevOps-инженеров статья — это практическое руководство по инфраструктуре для LLM. Они смогут адаптировать примеры под свои нужды, добавив авторизацию, логирование и автоскейлинг. Например, можно использовать Kubernetes вместо Docker Compose для большей гибкости, но это потребует дополнительной настройки.

Ограничение: решение не подходит для очень высоких нагрузок (тысячи запросов в секунду) — для этого нужны специализированные движки вроде vLLM или TensorRT. Но для малого и среднего бизнеса (до 100 одновременных пользователей) архитектура оптимальна.

Что будет дальше

Скорее всего, Ollama продолжит развиваться в сторону продакшен-функций: появится встроенная поддержка кластеризации и балансировки. Уже сейчас сообщество разрабатывает плагины для Kubernetes. В ближайшие месяцы можно ожидать официальных релизов с улучшенной производительностью.

Альтернативный сценарий — рост популярности managed-сервисов на базе Ollama, которые предложат готовую инфраструктуру. Но для тех, кто хочет полный контроль, вариант с Docker-композом останется основным.

Итог

Переход от демо к продакшену с Ollama и Docker — это не просто добавление балансировщика, а переосмысление архитектуры. Кеширование моделей, мониторинг и правильная настройка удержания в памяти — ключевые факторы успеха. Если вам нужна стабильная работа LLM без облачных провайдеров, описанный подход — надёжная отправная точка.