Every guide on this site starts from memory: how much VRAM or RAM a model needs before it will run at all. Disk is a separate budget, and it is the one that catches people out. The same 9B model takes 6.6 GB on disk at Q4, 10 GB at Q8 and 19 GB at BF16, and its weights often end up stored two or three times over because two runtimes want them in two different formats.
Verified November 2026 against the runtimes’ own documentation, the Ollama library and the model repositories on Hugging Face.
Where local models actually live
Four storage locations matter, and one machine can easily end up using three of them.
Ollama keeps everything under a single models directory. Its FAQ lists ~/.ollama/models on macOS, /usr/share/ollama/.ollama/models on Linux and C:\Users\%username%\.ollama\models on Windows, and says: “If a different directory needs to be used, set the environment variable OLLAMA_MODELS to the chosen directory.” Inside that directory, weights sit in a blobs folder with one file per layer, named for the layer’s digest, while the list of layers for each model lives separately in a manifests folder. Two tags built from the same layer therefore point at one copy of that file.
The Hugging Face cache is shared by much more than the transformers library. The Hub CLI guide states: “If not using --local-dir, all files will be downloaded by default to the cache directory defined by the HF_HOME environment variable”, which defaults to ~/.cache/huggingface, with repositories held under hub in a models--org--name layout containing blobs, snapshots and refs folders.
LM Studio uses ~/.lmstudio/models/, organised as publisher/model/model-file.gguf.
llama.cpp downloads into the same Hugging Face cache. Its cache-directory resolution reads LLAMA_CACHE, HF_HUB_CACHE, HUGGINGFACE_HUB_CACHE, HF_HOME and XDG_CACHE_HOME, falling back to ~/.cache/huggingface/hub, and names each repository models--org--name. Hand-placed files work too: “llama.cpp can also run models you have downloaded locally to your filesystem”.
| Runtime | Default location | How to check the size | How to remove |
|---|---|---|---|
| Ollama | ~/.ollama/models (macOS), /usr/share/ollama/.ollama/models (Linux), C:\Users\%username%\.ollama\models (Windows) | ollama ls, or GET /api/tags, which returns each model’s size in bytes | ollama rm <model> |
| Hugging Face cache | ~/.cache/huggingface/hub | hf cache ls, which accepts --filter "size>30g" and --sort size | hf cache rm <repo>, hf cache prune |
| LM Studio | ~/.lmstudio/models/ | lms ls, which prints a total disk-space line and a per-model size column | delete the .gguf file |
| llama.cpp and manual files | wherever you put them | du -sh <path> | delete the file |
What one model actually costs
The Ollama library publishes a size for every tag, and the same family at different quantizations differs by more than people expect. These are the published sizes for the Qwen3.5 9B family:
| Ollama tag | Size on disk |
|---|---|
qwen3.5:9b-q4_K_M | 6.6 GB |
qwen3.5:9b-nvfp4 | 7.2 GB |
qwen3.5:9b-mlx | 8.9 GB |
qwen3.5:9b-mtp-q4_K_M | 9.0 GB |
qwen3.5:9b-q8_0 | 10 GB |
qwen3.5:9b-mxfp8 | 11 GB |
qwen3.5:9b-mtp-q8_0 | 13 GB |
qwen3.5:9b-bf16 | 19 GB |
qwen3.5:9b-mlx-bf16 | 19 GB |
That is 103.7 GB for the nine tags listed, all of one model, and no two of them are the same file. The Q4_K_M build is the smallest of the group at 6.6 GB, the BF16 builds are the largest at 19 GB, and the -mtp tags sit above their plain counterparts at the same quantization (9.0 GB against 6.6 GB for Q4_K_M, 13 GB against 10 GB for Q8_0), so each of those is a separate download rather than a second copy of the same file. Which of them is worth keeping is the trade covered in the quantization format guide.
The library page shows the default tag as a band rather than a single number, qwen3.5:9b as “6.6GB - 7.6GB”.
Why the same weights get stored three times
Three file formats coexist on a normal machine, and they do not substitute for each other.
| Build | Repository | Measured size |
|---|---|---|
| BF16 safetensors | Qwen/Qwen3.5-9B | 19,306,310,880 bytes (19.31 GB) |
| GGUF Q4_K_M | unsloth/Qwen3.5-9B-GGUF | 5,680,522,464 bytes (5.68 GB) |
| GGUF Q8_0 | same repository | 9,527,502,048 bytes (9.53 GB) |
| GGUF BF16 | same repository | 17,920,697,312 bytes (17.92 GB) |
| MLX 4-bit safetensors | mlx-community/Qwen3.5-9B-4bit | 5,977,073,303 bytes (5.98 GB), whole repository |
The BF16 safetensors (9,653,104,368 parameters at 2 bytes each, plus a few F32 values) and the BF16 GGUF are not the same set of bytes: 19.31 GB against 17.92 GB, so a BF16 label does not predict a BF16 file size. The label alone does not tell you what a download will cost, which is why the byte counts above are the ones to plan against.
The larger trap is the repository itself. The Unsloth GGUF repository for this model ships 25 .gguf files: 22 weight files totalling 144,139,545,152 bytes, plus three mmproj projector files in different precisions, mmproj-F16.gguf among them at 918,166,080 bytes. All 25 together come to 147,803,478,272 bytes. Downloading “the model” from a repository page can mean all of it.
Ollama’s published tag sizes track the same arithmetic. Add the 0.92 GB projector file to the 5.68 GB Q4_K_M weight file and you get the 6.6 GB the Q4_K_M tag lists; add it to the 17.92 GB BF16 weight file and you get the 19 GB the BF16 tag lists. The Q8_0 tag lists 10 GB, against a 9.53 GB weight file plus the same projector.
Reclaiming space
Each runtime has its own tooling, and using it is safer than deleting files by hand.
For Ollama, ollama ls lists what is installed and ollama rm <model> removes a model. The API does the same job programmatically: GET /api/tags returns the installed models with a size field in bytes, which is the number to sort by when hunting for the space hogs.
For the Hugging Face cache, hf cache ls shows every cached repository with its size, and hf cache prune is described in the CLI guide as “a convenience shortcut that reclaims space taken by cache garbage”, which covers detached revisions that are no longer reachable through a branch or tag, leftover .incomplete files from interrupted downloads, and blobs no longer referenced by any cached repository. hf cache rm removes a whole repository, a single revision, or one file.
For LM Studio, lms ls prints the total directly, in a form like “You have 47 models, taking up 160.78 GB of disk space.”
Moving storage rather than deleting it is the other half of the job. OLLAMA_MODELS moves the Ollama store, HF_HOME or HF_HUB_CACHE moves the Hugging Face cache, and llama.cpp honours the same variables plus LLAMA_CACHE. On Linux, the Ollama documentation notes that the ollama user needs read and write access to whichever directory is chosen.
Planning a disk budget
Sizes published by the Ollama library, added up, show what a given drive holds:
| Model tag | Size | Running total |
|---|---|---|
qwen3.5:9b-q4_K_M | 6.6 GB | 6.6 GB |
qwen3.5:35b-a3b | 22 GB | 28.6 GB |
gpt-oss:120b | 65 GB | 93.6 GB |
qwen3.5:122b-a10b | 81 GB | 174.6 GB |
llama4:128x17b | 245 GB | 419.6 GB |
qwen3.5:9b-bf16 | 19 GB | 438.6 GB |
A 500 GB drive holds all of those except the llama4:128x17b build, and leaves room for the small stuff: an embedding model such as Qwen/Qwen3-Embedding-0.6B has a 1,191,586,416-byte (1.19 GB) safetensors file. A 1 TB drive buys the headroom to keep a BF16 reference copy next to a 4-bit working copy.
Note the outlier: llama4:128x17b alone is 245 GB, more than the other five tags combined.
Bottom line
Disk is a budget you plan before the first pull, not after. Decide the runtime first, because that decides the directory, and decide one quantization per model, because every extra tag is another copy of the same weights. Check what is already installed with ollama ls or hf cache ls before downloading anything, and reclaim with ollama rm, hf cache rm and hf cache prune rather than by hand.
The catch is that a model you want to convert, fine-tune or re-quantize later needs its higher-precision form kept around, and that is the copy that eats the drive. The VRAM guide covers the memory side of the same decision, and the runner comparison covers the software that decides where the files land.