Running a model locally is a download, and the download stays. Every tool that makes local inference easy also makes it easy to try one more model, and none of them tell you what the last month of trying added up to. On the Macs we scan, the AI models category is the largest single item for anyone who has spent an afternoon with Ollama, and it is the one people are most surprised by, because nothing in the tools shows a total.

This article covers where each tool keeps its files, how big they are, why testing multiplies them, and which ones you can delete without losing anything you cannot get back.

How big a model is

Size follows parameter count and quantization. As a rule of thumb for the formats these tools download:

Model size 4-bit (Ollama, MLX, most GGUF) 8-bit 16-bit (Hugging Face safetensors as published)
1 to 3B 1 to 2 GB 2 to 3.5 GB 2.5 to 7 GB
7 to 9B 4 to 5.5 GB 8 to 9.5 GB 14 to 18 GB
12 to 14B 7 to 9 GB 13 to 15 GB 25 to 30 GB
27 to 35B 16 to 20 GB 32 to 36 GB 55 to 70 GB
70B 38 to 43 GB 70 to 75 GB 130 to 145 GB

Sizes are for the weights alone, rounded, as of September 2026. A model from Hugging Face that was never quantized is the 16-bit column, which is why one unquantized 8B model takes more space than three 4-bit ones.

Other files that ride along: Whisper large is about 3 GB, image models like Stable Diffusion and Flux run 4 to 25 GB per checkpoint, embedding models are 0.3 to 2 GB each, and vision-language models bundle a second encoder of 1 to 2 GB.

Where each tool puts them

Ollama keeps everything under ~/.ollama/models. Weights are content-addressed blobs, and a manifest per tag points at them, so two tags of the same underlying file share it. Two quantizations of the same model do not. ollama list shows each model’s size and ollama rm removes one, and there is no command that shows what the whole folder weighs.

LM Studio keeps downloaded GGUF and MLX files under ~/.lmstudio/models (older versions used ~/.cache/lm-studio/models), organised by publisher and model. Each download is a complete file. Trying the Q4, Q5 and Q8 builds of one model is three full copies.

Hugging Face is the one that surprises people. The transformers, diffusers, sentence-transformers and huggingface_hub libraries all download into ~/.cache/huggingface/hub, one folder per repository, with a snapshot per revision. Pull a model, then pull it again after the author pushed a fix, and you have two snapshots. Load a model in a script once and it is there for good. huggingface-cli scan-cache prints the whole thing with sizes, and huggingface-cli delete-cache walks you through removing revisions. Datasets go to ~/.cache/huggingface/datasets and can be larger than the models.

MLX on Apple silicon uses the same Hugging Face hub cache for mlx-community models. If you converted a model yourself with mlx_lm.convert, the output landed wherever you pointed it, often a project folder, and the original 16-bit weights are still in the hub cache. A conversion is the full size of the model again.

Everything else. Python environments pull in PyTorch at 2 to 4 GB per venv, and a Mac with a few ML projects has a few of them. Docker’s model runner and the Ollama Docker image keep their own copies inside Docker’s disk image. Jupyter checkpoints and .ipynb_checkpoints folders hold copies of notebooks, small individually and numerous.

Why testing bloats it

An afternoon of evaluation looks like this. You pull Llama 3.1 8B in Ollama to compare with Qwen 2.5 7B, 9 GB. One of them is slow, so you try the Q8 build in LM Studio, 8 GB more. A paper mentions a 14B reasoning model, 9 GB. You want to embed some documents, so a script downloads an embedding model and, because you copied the example, the 16-bit version of the chat model it was demonstrated with, 15 GB. You try MLX because it should be faster on this Mac, and the 4-bit conversion is another 4.5 GB next to the 16-bit original it was made from.

That is about 46 GB, five tools, and one model you are still using. Nothing in that sequence was a mistake. It is how evaluation works. The difference from a build cache is that the tool will not clean it up for you, and the files are large enough that a handful of them is the gap between a comfortable disk and a full one.

On the setups we scan, an LLM developer’s Mac carries a couple of hundred gigabytes in this category, and 250 GB is ordinary once a 70B model is on the disk next to a few smaller ones. A Python and ML engineer who uses local models occasionally still carries 40 to 50 GB. See the full table by setup.

What is safe to delete

All of it comes back with a download, which is why Cache Goblin grades every model as Restorable rather than Safe: it lists them, shows the size of each, and asks before moving them to the Trash. Nothing about a downloaded model is unique to your Mac.

The exceptions are files you made. A fine-tune you trained, LoRA adapters, a model you converted with settings you would have to work out again, a GGUF you quantized yourself with an imatrix. These live next to the downloads and look the same, and Cache Goblin treats any weights inside a project folder you touched recently as yours and shows them without offering to remove them.

A practical order:

  1. ollama list and remove the models you tried once. Keep the one you actually call.
  2. huggingface-cli scan-cache and delete old revisions and anything you cannot remember downloading. This is usually the biggest number.
  3. Look in the LM Studio models folder for duplicate quantizations of one model and keep one.
  4. Check the hub cache for a 16-bit original of a model you only ever run as a 4-bit MLX conversion.
  5. Delete Python environments for projects that ended. PyTorch is a few gigabytes per copy.

Or run a scan. Cache Goblin lists Ollama, LM Studio, Hugging Face and MLX models by name and size in one place, with the total the tools never show you, and the Restorable button removes the ones you pick.

Download Cache Goblin free for Mac and see what your afternoon of testing left behind.