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, щоб вийти. Третя команда надсилає один prompt, виводить відповідь і завершує роботу. Саме такий формат потрібен скрипту, коли йому потрібна відповідь, а не інтерактивний сеанс. Третя форма все одно залишає довжину відповіді повністю на розсуд моделі. Тому відповідь на запитання в один рядок може складатися з трьох абзаців. Обмеження відповіді за допомогою num_predict дає змогу зберегти scripted run у межах розміру, який може обробити викликач. Назви моделей швидко змінюються, тому сприймайте gemma4 тут як заповнювач. Станом на August 2026 це приклад, який використовує офіційна документація Ollama, а будь-який tag з library працює так само. Якщо ви хочете використати модель, для якої вже визначено вимоги на реальному сервері, Запуск Nemotron 3.5 Lightning на VPS містить точний tag для завантаження та обсяг пам’яті, який має бути доступним.

Чому перший запуск ollama виглядає так, ніби завис

Перший run на новому VPS може кілька хвилин не виводити жодних повідомлень. Це нормально. Запрошення чату не з’явиться, доки модель не буде завантажена на диск і в пам’ять, тому run спочатку завантажує кілька гігабайтів даних, перш ніж щось вивести.

Цю роботу приховують два чинники. Ollama показує індикатор прогресу лише тоді, коли його вивід спрямовано до термінала. Тому run у shell script, cron job, CI step або звичайному ssh host ollama run ... під час завантаження нічого не виводить. Після завершення завантаження файл ще потрібно прочитати з диска в RAM до появи першого токена. На невеликому VPS це може тривати довго. Якщо на сервері недостатньо пам’яті для моделі, kernel починає використовувати swap, і очікування стає значно довшим.

Спостерігайте за процесом із другої сесії, а не робіть припущення:

df -h /
watch -n5 df -h /

Якщо вільне місце зменшується поетапно, завантаження ще триває. Якщо вільне місце перестало зменшуватися, а команда все ще працює, завантаження завершилося і почалося завантаження моделі в пам’ять.

Саме тому модель варто завантажити заздалегідь. Користувач, який вводить ollama run, не повинен чекати на завантаження.

Завантажте модель до першого запиту

Те саме стосується всього, що не є людиною: coding agent, налаштований на ваш Ollama endpoint, зазвичай припинить роботу вже після першого запиту, а не чекатиме завершення завантаження обсягом у кілька гігабайт. На новому сервері додайте завантаження до того самого скрипту, який встановлює сервер:

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

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

Виконайте його всередині tmux або передайте systemd як одноразовий unit, що запускається під час завантаження системи. Створіть /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= потрібен абсолютний шлях, а інсталятор не завжди розміщує binary в одному й тому самому каталозі, тому command -v ollama на вашому сервері — єдина надійна відповідь. Запуск через shell використовує PATH сервісу, а не шлях, скопійований із посібника. Перша ExecStart також важлива: After=ollama.service означає, що unit сервера запущений, але це не означає, що сервер готовий, тому цикл очікує відповіді від ollama list перед початком завантаження.

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

У журналі має бути повідомлення про завершення завантаження без помилок, а ollama list після цього має показати модель. Щоб підтримувати змінний tag в актуальному стані, додайте timer systemd або щотижневий cron entry, який запускає те саме завантаження. Повторне завантаження tag, що змінився, завантажує нові шари, а старі залишає без посилань. Їх буде очищено під час наступного запуску сервера.

Що відбувається, коли pull переривається

Кожен шар моделі зберігається під хешем власного вмісту. Тому перерваний pull не означає втрату виконаної роботи: повторно виконайте той самий ollama pull, і вже завантажені шари буде розпізнано та пропущено. Завантаження продовжиться із шару, на якому його було перервано.

Є одна дія, яка знищує цей прогрес. Під час запуску сервера Ollama він видаляє збережені шари, на які не посилається маніфест жодної моделі. Частковий шар, що залишився після перерваного pull, є саме таким шаром. Тому перезапуск сервісу перед повторною спробою видалить уже завантажену частину. Спочатку повторіть pull, а перезапуск виконайте пізніше. Якщо часткове завантаження справді має зберегтися після перезапуску, додайте OLLAMA_NOPRUNE=1 до середовища сервісу, а потім приберіть цей параметр. Саме очищення під час запуску запобігає накопиченню непов’язаних шарів на диску.

Якщо pull завершився помилкою 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 виводить unit-файл разом з усіма 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 зручний, якщо інший компонент на сервері вже очікує стандартне розташування. Але є важливий нюанс: скопійовані файли все ще перебувають під точкою монтування на кореневому диску. Монтування приховує їх, тому місце не звільниться, доки ви не демонтуєте том і не видалите ці файли. Змінну середовища легше пояснити наступному адміністратору, який увійде в систему.

Де контейнер зберігає їх насправді

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

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

ollama перед двокрапкою — це іменований Docker volume, а /root/.ollama — каталог, у якому сервер записує дані всередині контейнера. Тому du за шляхами з попереднього розділу нічого не знаходить: там нічого немає. Виведіть фактичне розташування та розмір:

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

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

Окремо зверніть увагу на очищення. docker volume prune видаляє всі volume, на які не посилається жоден контейнер. Якщо видалити або повторно створити контейнер ollama без його volume, під час наступного prune буде видалено всі завантажені моделі. Відновити їх можна буде лише повторним завантаженням. Перед запуском prune на сервері, де зберігаються моделі, прочитайте матеріал як очищати використання диска Docker на VPS.

Видаляйте модель за допомогою ollama rm, а не rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm видаляє маніфест для цього тегу, а потім видаляє шари, на які більше не посилається жоден маніфест. Місце звільняється одразу після від’єднання цих файлів, тому df спрацьовує негайно. Оскільки шари спільно використовуються, видалення одного з двох близьких тегів може звільнити набагато менше місця, ніж розмір ollama list, указаний поруч із ним. Це очікувана поведінка, а не помилка видалення.

Ручне видалення файлів порушує відповідність між ними. Видаліть blob за допомогою 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 в unit або drop-in-конфігурації. Якщо змінну не задано, сховище розташоване в домашньому каталозі облікового запису, від імені якого працює сервіс. Цей каталог виводить getent passwd ollama. sudo find / -xdev -type d -name blobs 2>/dev/null безпосередньо знаходить каталог шарів. У container image сховище розташоване всередині змонтованого тому, а 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, manifest і надалі міститиме цю модель, тому вона продовжить відображатися в ollama list і не працюватиме під час використання. Якщо видалити manifest, його шари залишаться на диску без посилань на них. Використовуйте ollama rm <model>. Команда видаляє manifest, а потім шари, які не потрібні жодній іншій моделі. Якщо файли вже видалено вручну, виконайте ollama rm для відповідного tag, щоб видалити запис, а потім перезапустіть сервер. Він видалить шари, на які не посилається жоден manifest.