Ollama Model Storage Guide: Where Ollama Stores Models & How to Change Location

Local LLM weights are big — a single 70B quant is tens of gigabytes, and three or four models can consume more than 100 GB. Because Ollama installs them on your primary drive by default, it’s one of the first things that silently fills a boot SSD. This guide covers where every byte lives, how the storage format actually works (it’s smarter than a folder of files), how to move the whole model library to a bigger disk on each OS, and how to reclaim space cleanly.

If you’re new to Ollama and want the surrounding setup and commands first, the Ollama Complete Guide is the right starting point. This page focuses narrowly on storage.

1. Default storage locations by OS

The most confusing case is Linux: if you installed via the official script, the daemon runs as a dedicated ollama system user and models live under /usr/share/ollama/.ollama/models, not in ~/.ollama of your own account. Look in the right place before you “can’t find” your models.

2. Why the folder isn’t a flat pile of files

Ollama uses a content-addressable layout inspired by Docker image layers. Instead of one .bin per model, files are split into a small manifests index plus a large pool of blobs keyed by SHA-256 hash:

.ollama/models/
├── manifests/
│   └── registry.ollama.ai/
│       └── library/
│           ├── llama3.2/
│           │   └── latest      # JSON: which blobs this model needs
│           └── qwen2.5/
│               └── 7b
└── blobs/
    ├── sha256-a80c4f172d6e...  # the GGUF weights tensor
    ├── sha256-43070e2d4e53...  # chat template + tokenizer
    └── sha256-c43d0b2113e8...  # params + license layer

Two practical consequences. First, models that share a base (same tokenizer, same license) also share blobs — Ollama deduplicates them, so five Llama-3.2 variants cost less than five times the biggest tag. Second, you should never hand-edit or drop raw GGUF files into blobs/; the hash-named layout expects to be managed by the tool (Section 4 shows the right way to import a custom model).

3. Moving the model library to another drive

The safe sequence is always: stop the daemon, relocate the directory, point OLLAMA_MODELS at the new path, restart, verify. Never copy while the daemon is running process-local files, and never delete the old copy until the new one lists cleanly.

Windows

1. Quit Ollama fully — right-click the llama tray icon and choose Quit (closing the window isn’t enough).
2. Copy C:\Users\<You>\.ollama\models to the target, e.g. D:\OllamaModels.
3. Set the variable. Win+R → sysdm.cpl → Advanced → Environment Variables → add a User variable OLLAMA_MODELS with value D:\OllamaModels.
4. Restart Ollama, then verify: ollama list should show the same models. Only then delete the original.

Linux (systemd)

1. Stop: sudo systemctl stop ollama
2. Move, preserving permissions: sudo rsync -avP /usr/share/ollama/.ollama/models/ /mnt/nvme/ollama/models/
3. Fix ownership: sudo chown -R ollama:ollama /mnt/nvme/ollama/models/
4. Point the service at it via a systemd override:

   sudo systemctl edit ollama
   # [Service]
   # Environment="OLLAMA_MODELS=/mnt/nvme/ollama/models"

5. Reload and start: sudo systemctl daemon-reload && sudo systemctl start ollama

macOS

Move to an external or secondary volume and register the new path with launchctl so the app picks it up on restart:

mv ~/.ollama/models /Volumes/FastSSD/OllamaModels
launchctl setenv OLLAMA_MODELS "/Volumes/FastSSD/OllamaModels"

For the Homebrew service, also restart it afterward so the daemon reads the new environment: brew services restart ollama.

4. Importing a model from a raw GGUF file

If you downloaded a .gguf straight from Hugging Face, the right way to get it into Ollama is a Modelfile pointing at your file — not dropping it into blobs/:

FROM ./my-model.q4_k_m.gguf

ollama create my-model -f ./Modelfile
ollama list   # my-model now appears alongside pulled models

This copies the weights into Ollama’s blob store under its own hash. If you’d rather keep full file-level control and skip Ollama’s storage layer entirely, that’s the point where running llama.cpp directly becomes appealing — a running comparison is in the llama.cpp vs Ollama guide.

5. Reclaiming disk space cleanly

Removing a model with ollama rm purges its manifest and the blobs that are no longer referenced, so it’s the clean way to free space (force-deleting files yourself leaves orphaned hashes behind):

# See what you have and how much it occupies
ollama list

# Remove a model by tag
ollama rm llama3.1:70b

# Recheck the freed space
ollama list

For bulk cleanup across many models and scripts to automate it, see How to Delete and Remove Ollama Models.

Frequently asked questions

Can I keep models on an external USB drive or NAS?

Yes, but load latency follows the disk. An NVMe SSD loads an 8B model in about a second; a spinning USB drive or a slow network share can push first-response latency to tens of seconds. It works, but for anything you actually use, prefer a fast local disk. Also note that a USB drive that disconnects mid-run can corrupt the model store, so back it up.

Does moving models re-download them?

No, if you copy the folder correctly and point OLLAMA_MODELS at it, Ollama finds the existing blobs and never re-downloads. The verification step (ollama list) is what confirms the move took before you delete the source.

Why does my download “stick” at the start or fail?

Usually disk space or the network. Check free space before pulling, and re-run ollama pull — it resumes at the blob level rather than restarting from zero.

Where do downloads go while in progress?

Into the same blob store, as incomplete layers under a temporary digest. If a pull fails, these are usually cleaned up automatically; if you ever want a completely clean slate, ollama rm the affected tag and re-pull.