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 використовує станом на August 2026, а будь-який тег із бібліотеки працює так само.

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

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

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

Перевіряйте процес із другої сесії, а не здогадуйтеся:

df -h /
watch -n5 df -h /

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

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

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

На новому сервері виконайте завантаження в тому самому скрипті, який встановлює сервер:

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

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

Виконайте це в 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= потрібен абсолютний шлях. Інсталятор не завжди розміщує бінарний файл в одному й тому самому каталозі, тому 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 має показати модель. Щоб підтримувати змінний тег в актуальному стані, додайте timer systemd або щотижневий запис cron, який виконує те саме завантаження. Повторне завантаження тегу, який змінився, завантажує нові шари. Старі шари залишаються без посилань на них. Вони очищуються під час наступного запуску сервера.

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

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

Одна дія знищує цей прогрес. Коли запускається Ollama server, він видаляє збережені layers, на які не посилається жоден model manifest. Саме таким є неповний layer, що залишився після перерваного pull. Тому перезапуск service до повторної спроби видаляє вже завантажену частину. Спочатку повторіть pull, а потім перезапустіть service. Якщо неповне завантаження справді має зберегтися після перезапуску, задайте OLLAMA_NOPRUNE=1 у середовищі service, а потім видаліть цей параметр. Саме очищення під час запуску не дає orphaned layers накопичуватися на диску.

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