Where Ollama Stores Models and How Much Disk They Use

Ollama does not store models as files you can name. It stores a content-addressed blob store with a thin directory of manifests over the top, borrowed wholesale from container registries. Once that is clear, both the “where did my 40 GB go” question and the “why did deleting a model free nothing” question answer themselves.

Where the files are

Ollama’s FAQ documents three defaults, and they differ because the Linux package runs the server as a service user rather than as you:

• macOS — ~/.ollama/models
• Linux — /usr/share/ollama/.ollama/models
• Windows — C:\Users\%username%\.ollama\models

That Linux path is the reason a model you pulled with sudo is invisible to a server running as ollama, and vice versa. The location is overridden with OLLAMA_MODELS, one of Ollama’s environment variables read by the server process; the FAQ adds the part people miss, that on a standard Linux install the ollama user needs read and write access to whatever directory you point it at.

The parent ~/.ollama directory holds more than models. The signing keypair used to talk to the registry lives there as id_ed25519 and id_ed25519.pub, on the same per-platform paths, which is why pushing a model from a new machine asks you to register a new key. Server-level settings can also live beside them in server.json. Backing up models alone therefore preserves your weights but not your identity to the registry, and that is usually the right split — the weights are large and re-downloadable, the private key is small and should not travel.

Manifests and blobs

Inside the models directory there are exactly two things. Under blobs/ sit flat files named sha256-<64 hex characters>, each one an immutable chunk of content. Under manifests/ sits a directory tree keyed by registry host, namespace, model and tag — manifests/registry.ollama.ai/library/qwen3/8b — and each leaf is a small JSON file listing the blobs that make up that tag.

The manifest entries carry a media type saying what each blob is: application/vnd.ollama.image.model for the GGUF weights, and siblings ending .template, .params, .system, .license and .adapter. This is why ollama show --modelfile prints a FROM line pointing at a blob path rather than at the tag you pulled: the model genuinely is that blob, and the tag is a name pinned to a digest. It is also why rebuilding a custom model after a one-line change costs kilobytes rather than gigabytes.

The small layers are worth opening once, because they demystify what a Modelfile compiles to. The params blob is a few dozen bytes of JSON holding exactly the PARAMETER lines the model was built with — most commonly a stop-token list. The template blob is the Go template in plain text. The system blob, when present, is your SYSTEM string with nothing added. None of these are encoded or compressed; a text editor reads all three.

You can read a manifest without any local install, because the registry serves the same JSON over HTTP. Fetching registry.ollama.ai/v2/library/qwen3/manifests/8b returns the layer list with a byte size against every digest, which is where the numbers in the next section come from.

Deriving disk use from layer sizes

Disk use for a tag is the sum of its layer sizes, and the weights layer dominates everything else by four or five orders of magnitude. Taking the sizes Ollama’s registry itself returns for the qwen3 8B manifest and its siblings at the time of writing:

qwen3:8b-q4_K_M   model layer   5,225,374,496 bytes  = 4.87 GiB
qwen3:8b-q8_0     model layer   8,851,075,872 bytes  = 8.24 GiB
qwen3:8b-fp16     model layer  16,388,043,552 bytes  = 15.26 GiB

template 1,723 B   license 11,338 B   params 120 B

Two things fall out of that arithmetic. First, the non-weight layers total about thirteen kilobytes, so any estimate that ignores them is wrong by less than a rounding error — disk use per model is the weights file and nothing else. Second, dividing the fp16 size by two bytes per parameter gives 8.19 billion parameters, which matches the 8.2B that Alibaba’s model card states, so the file sizes are internally consistent and can be used to derive bytes per weight for each quantization. That derivation is on choosing a quantization when you pull.

Why two models can cost one

Because blobs are addressed by digest, two tags whose weights are byte-identical reference the same file. This is not a theoretical case: the registry manifests for llama3.1:8b and llama3.1:8b-instruct-q4_K_M list the same model digest and the same 4,920,738,944-byte size, because the short tag is an alias for the long one. Pull both and you have two manifests and one 4.9 GB file.

Sharing also happens across genuinely different models. The llama3.1:8b-text-q4_K_M manifest has a different weights blob from the instruct build, but the identical licence blob — one copy on disk, referenced twice.

The practical consequence is that ollama list cannot be summed. It reports a size per model, and adding those numbers double-counts every shared blob. The honest way to answer “how much disk is Ollama using” is to measure the models directory itself — the blob store is the ground truth, and it counts each byte once.

Moving the directory and reclaiming space

To relocate the store, stop the server, set OLLAMA_MODELS where the server reads its environment, move the whole models directory across intact, and restart. Moving blobs/ without manifests/ gives you a directory of unnamed files; moving manifests/ without blobs/ gives you a list of models that will not load. On Linux, fix ownership after the move or the service user will find an unreadable directory and report every model as missing.

Reclaiming space works by removing references, not files. ollama rm deletes a manifest; a blob is only eligible for collection once nothing points at it, and Ollama prunes unreferenced blobs at startup unless OLLAMA_NOPRUNE is set. So deleting one of two aliased tags frees a few kilobytes, and the space appears only after the last reference goes and the server restarts. Never delete blob files by hand to save space: without the manifest that names them, you cannot tell which model you just destroyed, and the remaining manifests will fail at load rather than at delete.