Ollama pull и run: различия и хранение моделей

ollama pull против ollama run

ollama pull загружает модель и завершает работу. ollama run загружает модель только в том случае, если она отсутствует, затем помещает её в память и открывает интерактивный чат. Процесс загрузки идентичен, и файлы сохраняются в одном и том же месте. Только run продолжает работу после этого.

Это единственное различие определяет, какая команда подходит для скрипта, а какая — для работы за клавиатурой.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

Первая строка скачивает модель и завершает выполнение, поэтому её безопасно использовать при подготовке окружения и в юнит-файлах systemd. Вторая открывает сессию чата; введите /bye или нажмите Ctrl+D, чтобы выйти из неё. Третья отправляет один запрос, выводит ответ и завершает работу — именно такой формат нужен скрипту, когда требуется получить ответ, а не открывать сессию. Этот третий вариант всё ещё оставляет длину ответа на усмотрение модели, поэтому вопрос в одну строку может вернуться в виде трёх абзацев, и ограничение ответа через num_predict — это то, что позволяет удерживать вывод run в скрипте в пределах размера, который вызывающая сторона может обработать. Имена моделей быстро меняются, поэтому рассматривайте gemma4 здесь как заполнитель: это пример, который использует официальная документация Ollama по состоянию на август 2026 года, и любой тег из библиотеки ведёт себя точно так же. Если вы предпочитаете использовать модель, размер которой уже был сопоставлен с реальным сервером, запуск Nemotron 3.5 Lightning на VPS содержит точный тег для загрузки и объем памяти, который она ожидает найти.

Почему первый запуск ollama выглядит зависшим

Первый run на чистом VPS может не выводить ничего в консоль в течение нескольких минут. Это не ошибка. Приглашение к чату не появится, пока модель не будет загружена на диск и в оперативную память, поэтому run выполняет загрузку данных объемом в несколько гигабайт, прежде чем сможет что-либо отобразить.

Две причины скрывают этот процесс. Ollama рисует индикатор прогресса только при выводе в терминал, поэтому run внутри shell-скрипта, cron-задачи, шага CI или обычного ssh host ollama run ... не выводит ничего во время загрузки. Затем, после завершения скачивания, файл должен быть прочитан с диска в RAM перед генерацией первого токена, и на небольшом VPS это чтение происходит медленно. Если на сервере недостаточно памяти для модели, ядро начинает использовать swap, и время ожидания значительно увеличивается.

Вместо догадок наблюдайте за процессом из второй сессии:

df -h /
watch -n5 df -h /

Уменьшение свободного места ступенями означает, что загрузка продолжается. Если свободное место перестало уменьшаться, а команда всё ещё выполняется, значит, загрузка завершена и началось чтение в память.

Это основной аргумент в пользу предварительной загрузки моделей. Тот, кто вводит ollama run, не должен ждать завершения загрузки.

Загрузка модели до поступления запросов

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

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

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

Запустите процесс внутри tmux или передайте его systemd как однократный юнит (one-shot), выполняемый при загрузке. Создайте файл /etc/systemd/system/ollama-pull.service:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Обе команды намеренно выполняются через /bin/sh -c. Прямой вызов ExecStart= требует указания абсолютного пути, а установщик не всегда размещает бинарный файл в одном и том же каталоге, поэтому command -v ollama на вашей машине — единственный надежный вариант. Использование оболочки позволяет задействовать переменную PATH службы, а не путь, скопированный из руководства. Первый вызов ExecStart также важен: After=ollama.service означает, что юнит сервера был запущен, но это не то же самое, что готовность к работе, поэтому цикл ожидает ответа от ollama list перед началом загрузки.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

В журнале должно отобразиться успешное завершение загрузки без ошибок, а команда ollama list после этого должна показать модель. Чтобы поддерживать актуальность динамического тега, добавьте таймер systemd или еженедельную запись в cron, которая выполняет ту же команду загрузки. Повторная загрузка обновленного тега скачивает новые слои, оставляя старые без ссылок на них; такие слои автоматически удаляются при следующем запуске сервера.

Что происходит при прерывании загрузки

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

Одно действие уничтожает этот прогресс. При запуске сервер Ollama удаляет сохраненные слои, на которые не ссылается ни один манифест модели, а частичный слой, оставшийся после прерванной загрузки, является именно таким объектом. Поэтому перезапуск службы перед повторной попыткой приведет к удалению уже скачанной части. Сначала повторите загрузку, а затем перезапускайте службу. Если частичная загрузка действительно должна пережить перезапуск, установите OLLAMA_NOPRUNE=1 в переменные окружения службы, а затем уберите эту настройку, так как именно эта очистка при запуске предотвращает накопление «осиротевших» слоев на диске.

Если загрузка прервалась с ошибкой no space left on device, освободите место перед повторной попыткой. Если команда df сообщает о заполнении диска, а du в каталоге модели не объясняет этого, значит, место занято чем-то другим, и перед удалением чего-либо стоит ознакомиться с причинами расхождения данных df и du.

Где Ollama хранит модели на VPS?

Спросите об этом у своей системы, а не полагайтесь на пути из руководств, включая это. Расположение различается при установке пакетом и в контейнере, а также меняется, если кто-то задал OLLAMA_MODELS.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat выводит юнит-файл вместе со всеми дополнениями (drop-ins), поэтому строка OLLAMA_MODELS, заданная вами или встроенная в образ, отобразится там. Если такой строки нет, хранилище находится в домашнем каталоге учетной записи, от имени которой запущен сервис, а getent passwd выводит этот домашний каталог в шестом поле, разделенном двоеточиями. Команда find ищет в файловой системе каталог blobs — именно там фактически записываются слои. Используйте -xdev, если модели могут находиться на отдельном разделе.

Теперь выполните измерения и посмотрите на свои цифры:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

Хранилище состоит из двух частей. manifests содержит по одному небольшому файлу на каждый тег модели, в котором перечислены слои, составляющие эту модель. blobs содержит сами слои, каждый из которых назван по хешу своего содержимого; именно там сосредоточен почти весь объем данных. Поскольку слои являются общими для разных тегов, две модели, построенные на одних и тех же весах, показывают собственный размер в ollama list, хотя на диске занимают это место только один раз. Поэтому суммарный размер моделей может превышать значение, которое du сообщает для этого каталога.

Файлы моделей заполняют корневую файловую систему небольшого VPS быстрее, чем что-либо другое, что вы, вероятно, установите. Самый эффективный способ управления их размером — выбор формата весов. Выбор между q4, q8 и fp16 позволяет сэкономить гигабайты на каждой модели.

Перенос моделей в том данных с помощью OLLAMA_MODELS

Если в плане предусмотрен второй диск или том данных большего объема, перенесите хранилище до того, как файловая система root будет заполнена. Сначала остановите сервер, чтобы не копировать файл, в который в данный момент идет запись.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit открывает редактор для файла drop-in, поэтому упакованный юнит остается нетронутым, и обновление пакета не сможет перезаписать ваши изменения. Добавьте эти две строки:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment
ollama list

systemctl show должен вывести ваш новый путь, а ollama list должен показать те же модели, что отображались до переноса. Пустой список означает, что сервер не может прочитать новый каталог. Сервис работает от имени пользователя ollama, поэтому этому пользователю необходимы права на чтение и запись в целевой директории, что и обеспечивает строка chown выше. Проверьте journalctl -e -u ollama на наличие ошибок доступа, указывающих на новый путь. Удаляйте старую копию только после того, как список станет корректным, так как неудачный перенос вместе с удалением исходных данных приведет к необходимости повторной загрузки всего содержимого.

Другой вариант — сохранить исходный путь и смонтировать в него том данных:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt, выводящий точку монтирования, означает, что bind-монтирование активно. Bind-монтирование полезно, когда другие компоненты системы уже ожидают данные в стандартном расположении. У него есть один нюанс: файлы, которые вы скопировали, все еще остаются под точкой монтирования на диске root, скрытые самим монтированием, поэтому место не освободится, пока вы не размонтируете том и не удалите их. Переменная окружения — более простой для понимания вариант для любого, кто будет работать с системой в будущем.

Где контейнер хранит их на самом деле

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

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama перед двоеточием — это именованный том Docker, а /root/.ollama — путь, по которому сервер записывает данные внутри контейнера. Поэтому выполнение du для путей из предыдущего раздела ничего не даст, так как там пусто. Выведите реальное расположение и размер:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Прочитайте поле Mountpoint из вывода docker volume inspect, затем выполните sudo du -sh для этого пути. Чтобы разместить модели на томе данных, замените именованный том на каталог хоста (-v /mnt/data/ollama:/root/.ollama) и пересоздайте контейнер. Контейнер выполняет запись от имени root, поэтому владельцем этого каталога на хосте станет root. В случае с rootless Podman идентификаторы отображаются в диапазон subuid вашего пользователя, поэтому права владения на хосте будут выглядеть иначе: запуск Ollama в rootless Podman содержит подробности об этом отображении.

Предупреждение об очистке. Команда docker volume prune удаляет все тома, на которые не ссылается ни один контейнер. Если вы удалите или пересоздадите контейнер ollama без его тома, последующая очистка удалит все загруженные вами модели, и восстановить их можно будет только повторной загрузкой. Прочитайте как очистить дисковое пространство Docker на VPS перед запуском очистки на сервере, где хранятся модели.

Удаление модели с помощью ollama rm, а не rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm удаляет манифест для указанного тега, а затем удаляет слои, на которые больше не ссылается ни один манифест. Место освобождается сразу после удаления ссылок на файлы, поэтому df срабатывает мгновенно. Поскольку слои являются общими, удаление одного из двух тегов, связанных между собой, может освободить гораздо меньше места, чем размер, указанный ollama list рядом с ним. Это корректное поведение, а не ошибка удаления.

Удаление файлов вручную нарушает целостность системы. Если удалить блоб с помощью rm, манифест продолжит ссылаться на него, поэтому ollama list будет по-прежнему показывать модель, а любая попытка её использования завершится ошибкой при чтении отсутствующего слоя. Если удалить манифест вручную, его слои останутся на диске, ни на что не указывая и занимая место, о котором не сообщит ни одна команда Ollama. Если вы уже выполнили такие действия, ollama rm для этого тега очистит оставшуюся запись, а перезапуск сервера удалит слои, на которые нет ссылок.

Последнее различие, так как эти понятия часто путают. ollama rm относится к дисковому пространству. ollama stop gemma4 выгружает модель из оперативной памяти и не освобождает место на диске. Время нахождения модели в RAM после завершения загрузки определяется отдельной настройкой, и удержание модели в памяти вместо перезагрузки при каждом запросе описывает этот процесс.

FAQ

В чем разница между ollama pull и ollama run?

ollama pull загружает модель на диск и завершает работу. ollama run проверяет наличие модели на диске, скачивает её при отсутствии, загружает в память и открывает интерактивную сессию чата. Оба варианта записывают одинаковые файлы в одну и ту же директорию. Используйте pull в скриптах автоматизации и развертывания, а run — при работе в интерактивном режиме. ollama run <model> "your prompt" отправляет один запрос и завершает работу, что является пригодной для скриптов формой run.

Почему первый запуск ollama run кажется зависшим?

Происходит загрузка. Приглашение чата не появится, пока модель не будет скачана на диск и загружена в память, а размер модели составляет несколько гигабайт. Ollama выводит индикатор прогресса только при работе в терминале, поэтому run внутри скрипта, cron-задачи или ssh host ollama run ... не показывают ничего во время работы. Откройте вторую сессию и запустите watch -n5 df -h /: уменьшение свободного места означает, что загрузка идет. Загрузите модель заранее, чтобы избежать ожидания.

Где Ollama хранит модели?

Расположение зависит от способа установки, поэтому лучше вывести его командой, чем предполагать. Запустите systemctl cat ollama.service, чтобы проверить, задана ли переменная OLLAMA_MODELS в юните или drop-in файле. Если она не задана, хранилище находится в домашней директории учетной записи, от имени которой работает сервис; ее путь выводит getent passwd ollama. sudo find / -xdev -type d -name blobs 2>/dev/null напрямую указывает на директорию слоев. Для контейнера хранилище находится внутри смонтированного тома, а docker volume inspect ollama выводит его Mountpoint на хосте.

Как перенести модели Ollama на другой диск?

Остановите сервис, скопируйте хранилище в новое место с помощью rsync -a, передайте права на директорию сервисной учетной записи через sudo chown -R ollama:ollama <directory>, затем выполните sudo systemctl edit ollama.service и добавьте Environment="OLLAMA_MODELS=<directory>" в секцию [Service]. Перезагрузите конфигурацию через sudo systemctl daemon-reload и перезапустите сервис. Проверьте результат командами systemctl show ollama --property=Environment и ollama list. Пустой список почти всегда означает, что пользователь ollama не имеет прав на чтение новой директории; journalctl -e -u ollama покажет текущий путь.

Освобождается ли место при удалении файлов моделей вручную?

Удаление файлов вручную освобождает байты, но нарушает целостность хранилища. Если удалить blob, манифест все равно будет ссылаться на модель, поэтому она продолжит отображаться в ollama list и вызывать ошибки при попытке использования. Если удалить манифест, его слои останутся на диске, не имея ссылок. Используйте ollama rm <model>: эта команда удаляет манифест, а затем и слои, которые не требуются другим моделям. Если файлы уже были удалены вручную, выполните ollama rm для тега, чтобы очистить запись, а затем перезапустите сервер, который удалит слои, не имеющие ссылок в манифестах.