Where Ollama stores models, and how to move or delete them

Faheen Ahamed — Wed, 11 Nov 2026 08:26:07 +0000

Ollama keeps every model you pull in one folder called models, inside a hidden .ollama folder. On a Mac and on Windows that folder is in your home directory. On Linux, if you used the official install script, it is in the home directory of a separate ollama user, which is why du on your own home finds nothing while the disk fills up.

The space adds up quickly. llama3.1:8b is 4.9 GB in Ollama's library and llama3.1:70b is 43 GB, so trying out a few large models costs a hundred gigabytes or more, in a hidden folder the Finder does not show.

The paths

Platform	Model store
macOS	`~/.ollama/models`
Windows	`C:\Users\<you>\.ollama\models`, or `%USERPROFILE%\.ollama\models`
Linux, official install script (systemd service)	`/usr/share/ollama/.ollama/models`
Linux, `ollama serve` run as yourself	`~/.ollama/models`
Docker, official image	`/root/.ollama/models` inside the container, kept in the volume you mount there

These are the defaults from Ollama's FAQ. Two things change them: the OLLAMA_MODELS environment variable, and the Model location setting in the desktop app on a Mac or Windows PC. If you, an installer or a guide you followed ever set either, the models are wherever that points.

Find the store your install really uses

On a Mac, the desktop app shows the current folder under Settings, Model location. From Terminal, check whether the variable is set for apps, then measure the default folder:

launchctl getenv OLLAMA_MODELS
du -sh ~/.ollama/models

On Linux with the systemd service, the variable lives in the service, not in your shell, and the default folder belongs to the ollama user. These print the variable if it is set, and that user's home folder:

systemctl show ollama --property=Environment
getent passwd ollama | cut -d: -f6
sudo du -sh /usr/share/ollama/.ollama/models

A distribution's own package can give that user a different home than the install script does, so trust the second command over the table above.

On Windows, look in the app's Settings, or ask PowerShell for the variable and the size of the default folder:

[Environment]::GetEnvironmentVariable("OLLAMA_MODELS", "User")
"{0:N1} GB" -f ((Get-ChildItem "$env:USERPROFILE\.ollama\models" -Recurse -File | Measure-Object Length -Sum).Sum / 1GB)

With Docker, the models are in whatever volume you mounted at /root/.ollama. docker volume inspect ollama shows where Docker keeps that volume, if you used the name from Ollama's instructions.

Blobs, manifests, and why the numbers disagree

The store has two folders. models/blobs holds the weights as files named sha256-<hash>, and that's where nearly all the size is. models/manifests holds small files, one per model tag, each listing the blobs that tag is built from.

Because blobs are named by their content, two tags that share a layer share the file. A model you create from a Modelfile with FROM llama3.1:8b reuses the base weights and adds a few kilobytes of its own. ollama list shows each model's full size, so shared layers are counted once per model, and the list can add up to far more than the folder holds.

ollama list
du -sh ~/.ollama/models/blobs

Trust du for how much disk you're using and ollama list for how big each model is.

Deleting models

Always through Ollama, never by deleting blobs:

ollama rm llama3.1:70b

That removes the manifest and then any blob no other manifest still uses, and the space comes back straight away. The same command works in Terminal, in a Linux shell and in PowerShell. To remove every model at once on a Mac or Linux:

ollama list | awk 'NR>1 {print $1}' | xargs -n1 ollama rm

A model that's loaded keeps its memory until it's unloaded, which Ollama does by default five minutes after it was last used. ollama ps shows what's loaded, and ollama stop llama3.1:70b unloads it now.

Deleting a blob by hand leaves a manifest pointing at a file that no longer exists. You find out later, when the model won't load and the error mentions a missing layer. The repair is to remove that model and pull it again. There's no repair tool for the store.

A model you pulled is a re-download. A model you built with a Modelfile, or fine-tuned, has no copy anywhere else, and deleting it is permanent. Look through ollama list for names that aren't on any registry before a clear-out.

Removing Ollama and its models completely

On a Mac, quit Ollama, delete the app, and delete ~/.ollama, which holds the models, your keys and the logs. Ollama's macOS notes list the few smaller folders it also leaves in ~/Library.

On Windows, uninstall Ollama from Settings, Apps. Ollama's documentation says the uninstaller doesn't remove models you moved with OLLAMA_MODELS, so delete that folder yourself if you had one.

On Linux, Ollama's Linux page gives the full uninstall. The part that frees the space is:

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo userdel ollama
sudo groupdel ollama
sudo rm -r /usr/share/ollama

Moving the store to another drive

Quit Ollama first, on every platform. Then point it at the new folder and move the existing models across, or you'll start with an empty store.

On a Mac or Windows PC with the desktop app, the simplest way is Settings, Model location: choose the folder on the other drive. Then run ollama list. If your models are missing, quit Ollama again, move the contents of the old models folder into the new one and start Ollama.

Without the app, set OLLAMA_MODELS. On a Mac, set it through launchd so the app sees it, not only your shell:

launchctl setenv OLLAMA_MODELS /Volumes/External/ollama
mv ~/.ollama/models /Volumes/External/ollama

A value set with launchctl setenv doesn't survive a restart of the Mac, so it has to be set again after a reboot, before Ollama starts.

On Windows, open Settings, search for "environment variables", choose Edit environment variables for your account, and add OLLAMA_MODELS with the new folder as its value. Move the old models folder there, then start Ollama from the Start menu.

On Linux with the systemd service, the variable goes in the service, and the ollama user has to own the new folder:

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_MODELS=/mnt/models"
sudo systemctl restart ollama

An external SSD is fine for running models. The weights are read once when the model loads, so a slower drive costs you a few seconds at load time, not speed while you chat. A spinning disk or a network share is different: loading a 43 GB model over a network takes minutes. Sharing one store between two machines works with a read-only mount and a single writer, but two machines pulling into it at once can corrupt manifests. Moving model stores to an external drive covers the other tools' stores too.

If you were looking for LM Studio

LM Studio keeps its models in a different folder and a different format, so the two never share files:

Platform	LM Studio models
macOS	`~/.lmstudio/models`, older versions `~/.cache/lm-studio/models`
Windows	`C:\Users\<you>\.lmstudio\models`
Linux	`~/.lmstudio/models`

The app shows the current folder under My Models, and you can change it there. LM Studio's model folder explains the layout, and where AI models are stored puts Ollama, LM Studio and Hugging Face side by side on all three systems.

On a machine doing local AI work, the same model is often on disk more than once, in each tool's format. This shows all the usual stores on a Mac or Linux:

du -sh ~/.ollama ~/.cache/huggingface ~/.lmstudio ~/.cache/lm-studio 2>/dev/null

The Hugging Face cache keeps every revision you've ever downloaded unless you prune it.

Questions

Why is my blobs folder bigger than the models I have?

Usually a partial download from an interrupted pull, or blobs orphaned by deleting manifests by hand. Compare the blobs folder with what the manifests list before you assume it's normal.

Can Ollama and LM Studio use the same model files?

Not directly. Ollama stores weights as hashed blobs with its own manifests, and LM Studio reads model files from a publisher and model folder tree. You can import a GGUF file into Ollama with a Modelfile, but that copies it into Ollama's store.

Is a quantised model worth the space it saves?

Usually, and the trade-off isn't linear. A four-bit quantisation of a larger model is commonly better than an eight-bit one of a smaller model at the same size on disk.

Originally published at bytesweep.app. Written with AI assistance and checked against Ollama's documentation.

DEV Community: Bytesweep