Разница между 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"

Первая строка загружает модель и завершает выполнение, поэтому её безопасно использовать при подготовке окружения и в unit-файлах systemd. Вторая строка открывает сессию чата; введите /bye или нажмите Ctrl+D, чтобы выйти из неё. Третья строка отправляет один запрос, выводит ответ и завершает работу — именно такой формат требуется скрипту, когда нужен результат, а не интерактивная сессия. Названия моделей быстро меняются, поэтому воспринимайте gemma4 как заполнитель: это пример, который используется в официальной документации Ollama по состоянию на август 2026 года, и любой тег из библиотеки ведет себя аналогичным образом.

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

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

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

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

df -h /
watch -n5 df -h /

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

Именно поэтому стоит выполнять предварительную загрузку моделей. Тот, кто вводит ollama run, не должен ждать окончания загрузки.

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

На новом сервере выполните тот же скрипт, который устанавливает сервер:

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-in), поэтому строка 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

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

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, поэтому исходный unit-файл остается нетронутым, и обновление пакета не перезапишет ваши изменения. Добавьте эти две строки:

[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-mount активен. Bind-mount полезен, если другие компоненты системы уже ожидают данные в расположении по умолчанию. У него есть один нюанс: файлы, которые вы скопировали, все еще остаются под точкой монтирования на корневом диске, скрытые самим монтированием, поэтому место не будет освобождено, пока вы не размонтируете том и не удалите их. Переменная окружения — более простой для понимания вариант для любого, кто будет работать с сервером в будущем.

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

Официальный образ хранит модели в том месте, которое вы примонтировали, а не в каталогах хоста, принадлежащих пользователю 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 напрямую указывает на директорию с уровнями (layers). Для контейнера хранилище находится внутри смонтированного тома, а 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 для тега, чтобы очистить запись, а затем перезапустите сервер, который удалит уровни, не имеющие ссылок в манифестах.