Ollama в Docker Compose с использованием GPU и постоянным хранилищем моделей

Ollama отлично работает на «голом» железе. Но становится еще интереснее, если рассматривать его как сервис: стабильный конечный пункт, зафиксированные версии, постоянное хранилище данных и GPU, который либо доступен, либо нет.

Эта статья фокусируется на одной цели: воспроизводимый локальный или одноузловой «сервер» Ollama с использованием Docker Compose, с ускорением GPU и постоянным хранилищем моделей.

Здесь намеренно пропущены основы Docker и Compose. Если вам нужен компактный список команд, к которым вы обращаетесь чаще всего (образы, контейнеры, тома, docker compose), то Шпаргалка по Docker станет отличным компаньоном.

Если вам нужен HTTPS перед Ollama, корректная потоковая передача и проксирование WebSocket, а также средства управления на границе сети (аутентификация, таймауты, лимиты запросов), см. Ollama за обратным прокси с Caddy или Nginx для потоковой передачи по HTTPS.

Что касается того, как Ollama соотносится с vLLM, Docker Model Runner, LocalAI и компромиссами облачного хостинга, см. Хостинг LLM в 2026 году: локальное, самодостаточное и облачное инфраструктурное сравнение.

Когда Compose выигрывает у установки на «голом» железе

Нативная установка бесшовна для одного разработчика на одной машине. Но как только появляется что-либо из следующего, Compose начинает выигрывать в плане эргономики:

Настройка для команды выигрывает, потому что определение сервиса представляет собой файл, который можно просмотреть, версионировать и поделиться. Одноузловой сервер выигрывает, потому что обновления превращаются в смену тега образа и перезапуск, при этом хранилище моделей остается на месте (пока оно находится в томе). Ollama также часто сосуществует со вспомогательными сервисами: веб-интерфейс, обратный прокси, шлюз аутентификации, векторная база данных или среда выполнения агентов. Compose хорош тем, что позволяет запустить «всю стопку» одной командой, не превращая хост в снежинку.

Этот подход хорошо согласуется с тем, как спроектирован официальный контейнер Ollama: образ по умолчанию запускает ollama serve, открывает порт 11434 и предназначен для сохранения состояния в монтируемой директории.

Скелет Compose, который действительно полезен для Ollama

Начните с двух решений:

Во-первых, как вы будете фиксировать версии. Образ на Docker Hub — это ollama/ollama, поэтому вы можете закрепить конкретный тег в .env, вместо того чтобы полагаться на latest.

Во-вторых, где будут находиться данные моделей. В официальной документации том монтируется в /root/.ollama, чтобы модели не скачивались заново каждый раз при замене контейнера.

Вот файл Compose, который включает эти решения и держит «рычаги» управления рядом с сервисом:

services:
  ollama:
    image: ollama/ollama:${OLLAMA_IMAGE_TAG:-latest}
    container_name: ollama
    restart: unless-stopped

    # По умолчанию держим его локально, откройте позже, если нужно.
    ports:
      - "${OLLAMA_BIND_IP:-127.0.0.1}:11434:11434"

    # Постоянные модели и состояние сервера.
    volumes:
      - ollama:/root/.ollama

    environment:
      # Официальный образ по умолчанию уже использует 0.0.0.0:11434 внутри контейнера,
      # но явное указание помогает, когда вы переопределяете настройки позже.
      - OLLAMA_HOST=0.0.0.0:11434

      # Настройка сервиса.
      - OLLAMA_KEEP_ALIVE=${OLLAMA_KEEP_ALIVE:-5m}
      - OLLAMA_NUM_PARALLEL=${OLLAMA_NUM_PARALLEL:-1}
      - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_MAX_LOADED_MODELS:-1}

      # Опционально, но важно, когда веб-интерфейс обращается к Ollama напрямую.
      # Раздел «Сетевые настройки» объясняет, зачем это нужно.
      - OLLAMA_ORIGINS=${OLLAMA_ORIGINS:-}

    # Резервирование GPU — отдельный раздел ниже.
    # Добавьте это только на хостах, где действительно есть GPU NVIDIA.

volumes:
  ollama: {}

Соответствующий файл .env делает обновления скучными:

# Закрепите версию образа, которую вы протестировали.
OLLAMA_IMAGE_TAG=latest

# По умолчанию локально. Измените на 0.0.0.0, когда вы сознательно хотите открыть доступ.
OLLAMA_BIND_IP=127.0.0.1

# Настройки таймера активности для баланса между задержкой холодного старта и потреблением памяти.
OLLAMA_KEEP_ALIVE=5m

# Рычаги конкурентности.
OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_LOADED_MODELS=1

# Оставьте пустым, если вы не обслуживаете браузерных клиентов, которые напрямую обращаются к Ollama.
OLLAMA_ORIGINS=

Небольшой, но важный нюанс: сам Ollama имеет настройку привязки хоста по умолчанию 127.0.0.1:11434 в общей конфигурации, но официальный контейнерный образ устанавливает OLLAMA_HOST=0.0.0.0:11434, чтобы сервис был доступен через опубликованные порты.

Если вы хотите быструю проверку работоспособности без участия клиентских SDK, API Ollama включает эндпоинт «список локальных моделей» по адресу GET /api/tags.

Постоянное хранилище моделей и наименее болезненный способ перемещения

Если вы запомните только одну вещь, пусть это будет это: контейнер должен иметь постоянное хранилище, иначе каждая пересборка приведет к повторной загрузке.

Ollama позволяет выбрать директорию моделей, используя OLLAMA_MODELS. В эталонной реализации по умолчанию используется $HOME/.ollama/models, и установка OLLAMA_MODELS переопределяет это.

Внутри официального образа Docker $HOME естественным образом соответствует структуре /root, используемой для документированного монтирования тома (/root/.ollama), именно поэтому примеры docker run монтируют эту директорию.

Существует два паттерна хранения, которые хорошо работают на практике:

Именованный том Docker — самый простой и переносимый вариант. Его также легко случайно оставить без присмотра (сиротой), поэтому стоит намеренно дать ему имя (например, ollama) и сохранять его стабильным при рефакторинге Compose.

Прямое монтирование на отдельный диск лучше, когда размер моделей начинает доминировать в вашей корневой файловой системе. В этом случае вы либо монтируете весь /root/.ollama на этот диск, либо монтируете пользовательскую директорию и указываете OLLAMA_MODELS на нее.

Если вы активно перестраиваете хранилище, здесь поможет явный план «перемещения моделей». См.: move-ollama-models .

Поддержка GPU NVIDIA с Compose и NVIDIA Container Toolkit

Ollama может использовать GPU NVIDIA в Docker, но образ не может чудесным образом создать GPU. Хосту необходимы работающие драйверы NVIDIA и NVIDIA Container Toolkit, а Docker должен быть настроен на их использование. Документация Ollama для Docker прямо указывает на необходимость установки nvidia-container-toolkit, настройки runtime через nvidia-ctk runtime configure --runtime=docker и перезапуска Docker.

Со стороны Compose чистый и современный способ — резервирование устройств. Docker документирует доступ к GPU в Compose с помощью deploy.resources.reservations.devices, с capabilities: [gpu], driver: nvidia и либо count (включая all), либо device_ids.

Добавьте это к сервису ollama, если вы на хосте NVIDIA:

deploy:
  resources:
    reservations:
      devices:
        - driver: nvidia
          count: all
          capabilities: [gpu]

Если у вас несколько GPU и вы хотите держать Ollama на конкретных устройствах, замените count на device_ids, как документировано Docker (они взаимно исключают друг друга).

Вы иногда увидите устаревшие примеры Compose, использующие runtime: nvidia. Это может привести к ошибкам на новых настройках, например «unknown or invalid runtime name: nvidia», что является сильным указанием на то, что нужно перейти к поддерживаемому паттерну резервирования устройств и убедиться, что toolkit настроен на хосте.

Полезная деталь, скрытая на виду: официальный образ ollama/ollama устанавливает NVIDIA_VISIBLE_DEVICES=all и NVIDIA_DRIVER_CAPABILITIES=compute,utility. Это стандартные настройки, распознаваемые runtime-ом контейнера NVIDIA, и они уже присутствуют, если вы их не переопределяете.

Чтобы подтвердить, что вы действительно получаете инференс на GPU (а не просто запускаете контейнер), Ollama рекомендует использовать ollama ps и проверить столбец «Processor», который показывает, находится ли модель в памяти GPU.

Проверка реальности платформы: Ollama отмечает, что ускорение GPU в Docker доступно на Linux (и Windows с WSL2), но недоступно в Docker Desktop для macOS из-за отсутствия сквозного доступа к GPU.

Выбор сетевых настроек: host vs bridge, порты и CORS

Сетевые настройки — это то, откуда чаще всего возникают ошибки «это работает, но мое приложение не может подключиться».

Сетевая настройка bridge с опубликованными портами

Сеть по умолчанию в Compose — это bridge-сеть. В этой настройке публикация 11434:11434 делает Ollama доступным с хоста на порту 11434, в то время как другие контейнеры должны общаться с ним, используя имя сервиса ollama (не localhost). Многие спотыкаются об это, потому что localhost внутри контейнера означает «этот контейнер», а не «контейнер Ollama».

Сам Ollama запускает HTTP-сервер на порту 11434 (образ открывает его), и общепринятое соглашение заключается в том, что клиенты используют http://localhost:11434 на хосте, когда порты опубликованы.

Сетевая настройка host

network_mode: host может быть соблазнительным на одноузловом сервере, потому что это убирает публикацию портов и упрощает семантику localhost. Компромисс заключается в том, что вы теряете преимущества изоляции и именования bridge-сети и чаще сталкиваетесь с конфликтами портов.

Осознанное открытие доступа к Ollama

Ollama при обычной установке по умолчанию привязывается к 127.0.0.1, и документированный способ изменить адрес привязки — это OLLAMA_HOST.

В Docker у вас есть два уровня:

Адрес привязки Ollama, контролируемый OLLAMA_HOST (образ контейнера по умолчанию привязывается ко всем интерфейсам внутри контейнера).

Доступность извне контейнера, контролируемая ports в Compose и брандмауэром хоста.

Паттерн, который мне нравится: «привязываться локально по умолчанию» через 127.0.0.1:11434:11434, а затем переключаться на 0.0.0.0:11434:11434 только тогда, когда у меня есть причина открыть доступ.

Браузерные клиенты и OLLAMA_ORIGINS

Если браузерный интерфейс или расширение обращаются к Ollama напрямую, вы попадаете в зону CORS. Ollama по умолчанию позволяет междоменные запросы с 127.0.0.1 и 0.0.0.0, и вы можете настроить дополнительные источники, используя OLLAMA_ORIGINS.

Это важно даже на одном узле, потому что «это работает с curl» не означает «это работает из браузерного приложения».

Паттерны обновления и отката, подходящие для одноузлового сервера

Ollama быстро развивается. Ваш файл Compose может сделать этот процесс спокойным, а не сюрпризом в поздней ночи.

Обновление через смену тега, а не надежда на «latest»

Самая практичная стратегия обновления — закрепить образ на известном хорошем теге в .env и намеренно повышать его. Образ публикуется как ollama/ollama на Docker Hub.

Поскольку данные моделей и состояние сервера хранятся в монтируемой директории (/root/.ollama в официальной документации), замена контейнера не подразумевает повторную загрузку моделей.

Откат — это просто возврат к предыдущему тегу

Откат работает по тому же механизму, но в обратном порядке: установите предыдущий тег, пересоздайте контейнер, сохраните тот же том. Именно здесь закрепление тегов окупается.

Миграция данных — это в основном про пути хранения

Большинство «миграций» в одноузловой настройке не связаны со схемами баз данных. Они касаются структуры диска. Если вы меняете директорию моделей (через OLLAMA_MODELS) или перемещаете смонтированный том на новый диск, вы проводите миграцию данных, называете вы это так или нет.

Если вам нужно практическое руководство по перестройке директории моделей на реальных машинах, см.: move-ollama-models .

Финальная заметка, которую легко упустить: документация API Ollama явно говорит, что API ожидается стабильным и обратно совместимым, с редкими отменами поддержки, объявляемыми в заметках о выпуске. Это делает «обновить сервер, сохранить работу клиентов» разумным ожиданием по умолчанию для одноузлового конечного пункта сервиса.

Общие проблемы: права доступа к GPU, несоответствие драйверов и OOM

Этот раздел намеренно ориентирован на симптомы. Цель — не «каждая возможная ошибка Docker», а только те сбои, которые возникают конкретно в настройках Ollama + GPU + постоянное хранилище.

GPU виден на хосте, но отсутствует в контейнере

Если на хосте работает драйвер NVIDIA, но контейнер не видит GPU, распространенные причины:

NVIDIA Container Toolkit не установлен или runtime Docker не настроен через nvidia-ctk. Документация Ollama для Docker прямо указывает на это.

Compose не резервирует устройство GPU. Поддерживаемый способ — deploy.resources.reservations.devices с возможностью gpu, как документировано Docker.

Используется устаревшая конфигурация runtime: nvidia на демоне, который не распознает её, что приводит к ошибке «unknown or invalid runtime name: nvidia».

Для валидации ollama ps дает прагматичную проверку: он показывает, загружена ли модель в память GPU.

Отказ в доступе к устройствам GPU

«Отказ в доступе» в сбоях GPU обычно указывает на ограничения окружения, а не на сам Ollama. Примеры включают запуск без root Docker, политики безопасности или узлы устройств, которые не экспонируются как ожидалось. Документация Docker Compose по поддержке GPU явно указывает, что хост должен иметь устройства GPU и что демон Docker должен быть настроен соответствующим образом.

В случае сомнений уменьшите количество переменных: подтвердите конфигурацию toolkit (хост), затем подтвердите резервирование GPU (Compose), затем подтвердите использование GPU (ollama ps).

Неправильный драйвер, неправильные ожидания

Ollama в Docker полагается на стек драйверов хоста. Если драйвер хоста отсутствует, слишком стар или настроен неправильно, вы увидите сбои, которые выглядят как «Ollama сломан», но на самом деле означают «стека CUDA нельзя использовать». Официальная документация помещает toolkit контейнера и конфигурацию демона Docker в число предварительных требований для использования GPU NVIDIA.

Недостаточно памяти: VRAM или RAM исчезают быстро

OOM — самый предсказуемый режим сбоя для локального инференса, и он обычно является самоиндуцированным конфигурацией.

Ollama поддерживает конкурентную обработку через несколько загруженных моделей и параллельную обработку запросов, но он ограничен доступной памятью (системная RAM для инференса на CPU, VRAM для инференса на GPU). При использовании инференса на GPU новые модели должны поместиться в VRAM, чтобы позволить конкурентную загрузку моделей.

Две детали конфигурации заслуживают того, чтобы рассматриваться как первоклассные «настройки сервера»:

OLLAMA_NUM_PARALLEL увеличивает параллельную обработку запросов для каждой модели, но требуемая память масштабируется как OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH.

OLLAMA_KEEP_ALIVE контролирует, как долго модели остаются загруженными (по умолчанию 5 минут). Держание моделей загруженными снижает задержку холодного старта, но также закрепляет память.

Если вы стабилизируете одноузловой сервис под нагрузкой, не драматичные исправления обычно выглядят так:

Снижение параллелизма и контекстных значений по умолчанию перед тем, как менять что-либо еще.

Ограничение количества моделей, которым разрешено оставаться загруженными одновременно.

Рассмотрите функции снижения потребления памяти, такие как Flash Attention (OLLAMA_FLASH_ATTENTION=1) и типы кэша K/V с меньшей точностью (OLLAMA_KV_CACHE_TYPE), когда ваше узкое место — память, а не raw-вычислительная мощность.

Когда это не Ollama: выбор Docker Model Runner вместо

Иногда «сбой» на самом деле является несоответствием инструментов. Если в вашей организации уже стандартизированы артефакты и рабочие процессы Docker, Docker Model Runner (DMR) может подойти лучше, чем запуск Ollama как долгоживущего сервисного контейнера.

Docker позиционирует DMR как способ управления, запуска и обслуживания моделей напрямую через Docker, получая их из Docker Hub или других реестров OCI, и обслуживая API, совместимые с OpenAI и Ollama.

Он также поддерживает несколько движков инференса (включая llama.cpp и vLLM на Linux с GPU NVIDIA), что может иметь значение, если вас заботят характеристики пропускной способности, а не просто «запустить одну модель локально».

Если вы хотите практическую справку команд и углубленный сравнительный анализ, см.: Шпаргалка по Docker Model Runner: команды и примеры.