Ollama pull vs run: Where Models Dey Live

ollama pull vs ollama run

ollama pull dey download one model then e stop. ollama run dey download the model only if e no dey available, then e load am into memory and open interactive chat. The download na the same, and the files go the same place. Na only run dey continue afterwards.

Na this one difference dey decide which command fit enter script and which one fit use for keyboard.

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

The first line dey fetch the model and exit, so e safe for provisioning and inside systemd unit. The second one dey open chat session; type /bye or press Ctrl+D to comot. The third one dey send one prompt, print the answer and exit. Na this format script want when e need answer instead of session. Model names dey change quickly, so treat gemma4 here as placeholder: na the example wey official Ollama documentation dey use as of August 2026, and any tag from the library dey behave the same way.

Why first ollama run dey look like e don freeze

First run for fresh VPS fit sit without any output for several minutes. Nothing spoil. Chat prompt no fit show until model don save for disk and load into memory, so run dey download several gigabytes before e get anything to show you.

Two things dey hide this work. Ollama dey draw progress bar only when e output go terminal, so run inside shell script, cron job, CI step or plain ssh host ollama run ... no go print anything while e dey download. Then, after bytes don land, system still need read file from disk enter RAM before first token fit show. For small VPS, this read fit slow. If the box no get enough memory for the model, kernel go start swapping and the wait go long well well.

Watch am from another session instead of guessing:

df -h /
watch -n5 df -h /

If free space dey drop in steps, download still dey run. If free space stop dropping while command still busy, download don finish and loading into memory don start.

This na why you suppose pull ahead of time. Person wey type ollama run no suppose be the one wey dey pay for the download.

Pull model before anybody ask for am

For new box, pull am inside the same script wey install the server:

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

If na the first time you dey set up the server, the complete Ollama on a VPS installation explain the service itself and who get permission to reach am. After that, the useful thing to set up na pull wey go continue after your terminal close, because download wey stop halfway fit leave model store half-filled.

Run am inside tmux, or give am to systemd as one-shot unit wey go run during boot. Write /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

Both commands dey pass through /bin/sh -c deliberately. Bare ExecStart= need absolute path, and installer no always put the binary for the same directory. So, command -v ollama for your own box na the only reliable answer. When you pass through the shell, e use the service PATH instead of path wey you copy from guide. The first ExecStart dey important too: After=ollama.service mean say server unit don start, but that no mean say e ready. So the loop go wait until ollama list answer before pull start.

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

Journal suppose show say pull don finish without error, and ollama list suppose then show the model. If you wan keep moving tag current, add systemd timer or weekly cron entry wey go run the same pull. If tag don move, pulling am again downloads the new layers and leaves the old ones without anything pointing to dem. Dem go clean up the next time the server start.

Wetin dey happen when pull stop halfway

Dem store every layer of model under hash wey come from the layer contents. So interrupted pull no be wasted work: run the same ollama pull again, and e go recognise and skip layers wey don finish already. The download go continue from the layer wey stop halfway.

One action dey destroy that progress. When Ollama server start, e dey remove stored layers wey no model manifest refer to. The partial layer wey dead pull leave behind na exactly that kind layer. So if you restart the service before you retry, you go throw away the part wey don already download. Retry the pull first, then restart later. If partial download really need survive restart, set OLLAMA_NOPRUNE=1 for the service environment, then remove am later. Na that startup cleanup dey stop orphaned layers from piling up for disk.

If the pull stop with no space left on device, free space before you retry. If df report say disk full and du for model directory no explain the missing space, the space dey somewhere else. Read why df and du fit show different space usage before you delete anything.

Ollama dey store models for where on VPS?

Ask your own box instead of trusting path from any guide, including this one. The location dey different between package install and container. E go change again if anybody don set OLLAMA_MODELS.

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

systemctl cat go print the unit file together with every drop-in. So, any OLLAMA_MODELS line wey you set or wey dey inside your image go show there. If no such line dey, the store dey under the home directory of the account wey the service dey run as. getent passwd go print that home directory for the sixth field wey colon separate. find go search one filesystem for blobs directory. Na there dem dey actually write the layers. Remove -xdev if the models fit already dey for separate mount.

Now measure am, and read your own numbers:

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

The store get two parts. manifests get one small file for every model tag. That file list the layers wey dem use build the tag. blobs get the layers themselves. Each layer name na the hash of its contents, and almost all the size dey there. Because tags dey share layers, two models wey dem build with the same weights fit each report their own size for ollama list, while the disk dey store that space only once. So, the sizes wey dem list fit add up pass wetin du report for the directory.

Model files fit fill small VPS root filesystem faster than almost anything else wey you likely install. The biggest factor wey control their size na the weight format. How to choose between q4, q8 and fp16 fit save gigabytes for each model.

Move the models go data volume with OLLAMA_MODELS

If the plan get second disk or bigger data volume, move the store before root filesystem full. Stop the server first, so you no go copy file wey still dey write.

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 go open editor for drop-in file, so the packaged unit remain untouched and package upgrade no fit overwrite your change. Add these two lines:

[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 suppose print your new path, and ollama list suppose show the same models wey e show before the move. Empty list mean say server no fit read the new directory. The service dey run as the ollama user, so that user need read and write access to the destination. Na the chown line above dey provide this access. Check journalctl -e -u ollama for permission errors wey name the new path. Delete the old copy only after the list correct, because failed move plus deleted source mean say you go download everything again.

The other option keep the original path and mount the data volume onto am:

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 printing the mount mean say the bind dey live. Bind mount dey useful when something else for the box already expect the default location. E get one problem: the files wey you copy out still dey under the mount point for root disk, but the mount hide dem. The space no go return until you unmount and remove dem. The environment variable na the easier option to explain to whoever go log in next.

Where container dey keep dem instead

The official image dey store models for anywhere wey you mount, not for any host directory wey belong to an ollama user. The documented run command na:

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

ollama before the colon na a named Docker volume, while /root/.ollama na where the server dey write inside the container. So du against the paths from the previous section no go find anything, because nothing dey there. Print the real location and size:

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

Read the Mountpoint field from docker volume inspect, then run sudo du -sh against am. To put the models for a data volume, replace the named volume with a host directory (-v /mnt/data/ollama:/root/.ollama) and recreate the container. The container dey write as root, so that host directory go end up owned by root. Under rootless Podman, the ids dey map into your user's subuid range instead, so host ownership go look different again: how to run Ollama under rootless Podman covers that mapping.

One warning about cleanup. docker volume prune removes every volume wey no container dey refer to. If you remove or recreate the ollama container without its volume, a later prune go delete every model wey you download, and the only way back na to download dem again. Read how to prune Docker disk usage on a VPS before you run prune for a box wey dey host models.

Remove model with ollama rm, no be with rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm dey delete manifest for that tag, then e delete layers wey no remaining manifest dey refer to. Space dey come back immediately once dem unlink those files, so df dey update straight away. Because layers dey shared, removing one of two tags wey closely relate fit free space wey far smaller than the size wey ollama list print beside am. Na correct behaviour be this, no be failed delete.

Deleting files by hand dey break the pair. Remove blob with rm and manifest still list am, so ollama list go continue show the model, and any attempt to use am go fail when e try read the missing layer. Remove manifest by hand, and the layers go remain for disk without anything pointing to dem. Dem go hold space wey no Ollama command go report to you. If you don already do am, ollama rm for the tag go clear the leftover entry, and restarting the server go clear layers wey nothing dey refer to.

One last difference, because people dey mix the two up all the time. ollama rm na about disk. ollama stop gemma4 dey unload model from memory and e no free any disk space. How long model go remain for RAM after download don finish na separate setting, and how to keep model loaded instead of reloading am for every request explain am.

FAQ

Wetin be di difference between ollama pull and ollama run?

ollama pull dey download model go disk, then e stop. ollama run dey check whether model don already dey disk; if e no dey, e download am, load am into memory, then open interactive chat session. Both dey write the same files for the same directory. Use pull for provisioning and scripts, and use run when person dey for keyboard. ollama run <model> "your prompt" dey send one prompt, then e stop; na the scriptable form of run.

Why my first ollama run dey look like e hang?

E dey download. Chat prompt no fit show until model dey disk and don load into memory, and model fit be several gigabytes. Ollama dey show progress bar only when output dey go terminal, so run inside script, cron job or ssh host ollama run ... no go show anything while e dey work. Open second session and run watch -n5 df -h /: if free space dey reduce step by step, download dey happen. Pull the model before time, and the wait go disappear.

Where Ollama dey store its models?

The location depend on the install, so print am instead of assuming. Run systemctl cat ollama.service to see whether OLLAMA_MODELS dey set for the unit or drop-in. If e no dey set, the store dey under the home directory of the account wey the service dey run as, and getent passwd ollama go print am. sudo find / -xdev -type d -name blobs 2>/dev/null dey locate the layer directory directly. For container image, the store dey inside the mounted volume, and docker volume inspect ollama go print the host Mountpoint.

How I fit move Ollama models go another disk?

Stop the service, copy the store go the new location with rsync -a, give the directory to the service account with sudo chown -R ollama:ollama <directory>, then run sudo systemctl edit ollama.service and add Environment="OLLAMA_MODELS=<directory>" under a [Service] line. Reload with sudo systemctl daemon-reload and restart. Confirm with systemctl show ollama --property=Environment and ollama list. Empty list almost always mean say ollama user no fit read the new directory; journalctl -e -u ollama go show the path.

Deleting the model files go free the space?

Deleting files by hand go free the bytes, but e go leave the store inconsistent. If you remove blob, manifest still dey list that model, so e go continue to appear for ollama list and e go fail when you use am. If you remove manifest, the layers go remain for disk without anything wey refer to dem. Use ollama rm <model>; e dey delete manifest first, then the layers wey no other model need. If files don already delete by hand, run ollama rm on the tag to clear the entry, then restart the server. The server go remove layers wey no manifest dey refer to.