Your Mac might be storing the same AI model three times: Ollama, LM Studio, Hugging Face

If you build with local models, you probably have more than one tool that downloads them. Ollama, LM Studio, the Hugging Face libraries and ComfyUI each keep their own folder, and none of them looks in the others’. Pull a model in Ollama, try the same quantization in LM Studio, load it once from a Python script, and the same file can end up on your disk three times.

Here’s where each tool keeps its models on macOS, how to measure and remove them, and how to prove two files are the same before you delete either.

Where each tool keeps its models

A few details change where you should look:

• LM Studio moved its home folder from ~/.cache/lm-studio to ~/.lmstudio in version 0.3.6, but only for first-time installs, and it doesn’t move existing data. If you’ve used it since before then, your models may be in ~/.cache/lm-studio/models. Check both.
• Ollama keeps small manifests in manifests and the actual weights in blobs.
• Hugging Face keeps one cache for the Python libraries that download from the Hub, such as transformers and diffusers. mlx-lm downloads into it too, so MLX models you run from Python live here. If you set HF_HOME, the cache is $HF_HOME/hub.
• ComfyUI sorts models into folders by type (checkpoints, loras, vae and so on). A manual install keeps them in ComfyUI/models inside the folder you installed it in. In Comfy Desktop, ~/ComfyUI-Shared also holds output, which is where your generated images go, so never clear that folder wholesale.

Measure what you have

Start with totals. du reports what’s actually on disk, and 2>/dev/null hides the errors for folders you don’t have:

du -sh ~/.ollama/models ~/.lmstudio/models ~/.cache/lm-studio/models ~/.cache/huggingface/hub ~/ComfyUI-Shared/models ~/.cache/torch/hub 2>/dev/null

If you’ve moved a folder, ask the tool where it is. hf env prints the HF_HUB_CACHE in use, and the Ollama app shows its folder under Model location in Settings.

Then list what’s inside, model by model:

ollama list
lms ls
hf cache ls --sort size

ollama list shows each model’s size, lms ls lists the models LM Studio sees on disk, and hf cache ls --sort size lists cached Hugging Face repos, largest first. The hf cache commands arrived in huggingface_hub 1.0 (--sort in 1.1); older versions use huggingface-cli scan-cache.

Find the same model stored twice

No tool tells you when another tool holds the same file. But two of them name their large files after a SHA-256 hash of the contents, which makes duplicates easy to spot:

• Ollama names every blob sha256-<hash>. Its source computes the hash while writing the file, and the name is that hash.
• The Hugging Face cache names each large file in a repo’s blobs folder after its SHA-256 (small text files get a shorter Git hash). The readable file names under snapshots are symlinks to those blobs.

LM Studio and ComfyUI keep the original file names, so for those you compute the hash yourself with shasum, which comes with macOS.

Check one file

Say LM Studio has a GGUF and you suspect Ollama or the Hugging Face cache has it too. Hash it, then search the other two folders for that hash:

hash=$(shasum -a 256 ~/.lmstudio/models/bartowski/Llama-3.2-1B-Instruct-GGUF/Llama-3.2-1B-Instruct-Q4_K_M.gguf | cut -d' ' -f1)
find ~/.ollama/models/blobs ~/.cache/huggingface/hub -name "*$hash" 2>/dev/null

Any path it prints holds the same bytes.

A real example: the Q4_K_M file in the bartowski/Llama-3.2-1B-Instruct-GGUF repo on Hugging Face is 807,694,464 bytes, with a SHA-256 starting 6f85a640. For ollama pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF:Q4_K_M, the manifest Hugging Face serves lists the model layer with that same digest and size, so Ollama saves it as blobs/sha256-6f85a640…. LM Studio downloads the same file from Hugging Face under its original name, and a Python download adds a third copy to the Hugging Face cache. That’s about 808 MB, stored three times.

You can read a Hub file’s SHA-256 without downloading it, from the X-Linked-Etag header:

curl -sI https://huggingface.co/bartowski/Llama-3.2-1B-Instruct-GGUF/resolve/main/Llama-3.2-1B-Instruct-Q4_K_M.gguf | grep -i x-linked-etag

Check every folder at once

Hashing reads every byte, so it’s slow on files this size. Identical files must be the same size, so this check lists sizes first and hashes only files that share one. It only reads. Run the three parts in order:

find ~/.ollama/models/blobs ~/.cache/huggingface/hub ~/.lmstudio/models ~/.cache/lm-studio/models ~/ComfyUI-Shared/models -type f -size +100M -exec stat -f '%z %d:%i %N' {} + 2>/dev/null | awk '!seen[$2]++' | sort -n > /tmp/model-files.txt

awk '{print $1}' /tmp/model-files.txt | uniq -d | while read -r size; do
  grep "^$size " /tmp/model-files.txt | cut -d' ' -f3- | while IFS= read -r file; do
    shasum -a 256 "$file"
  done
done | sort > /tmp/model-hashes.txt

awk '{print $1}' /tmp/model-hashes.txt | uniq -d | while read -r hash; do
  grep "^$hash" /tmp/model-hashes.txt; echo
done

The first part lists every file over 100 MB with its size and a disk-and-inode ID, the second hashes files whose size matches another’s, and the third prints each hash that appears more than once, with its paths. Add any other folder where you keep .gguf or .safetensors files, such as ~/Downloads, to the find line. A few notes:

• -type f skips symlinks, so Hugging Face snapshots links aren’t counted twice.
• awk '!seen[$2]++' keeps one path per file, so hard links (two names for one file, stored once) don’t show up as duplicates.
• It works for safetensors shards as well as GGUF files, which covers MLX models you may have in both LM Studio and the Hugging Face cache.

What a match tells you, and what it doesn’t

A matching hash means identical bytes. A different hash doesn’t mean a different model. Models from Ollama’s own library come from Ollama’s registry, not a Hugging Face repo, so they won’t necessarily match a Hugging Face GGUF with the same name and quantization. And one model in two quantizations, say Q4_K_M in Ollama and Q8_0 in LM Studio, is two files by design. Whether you need both is your call.

To map an Ollama blob back to a model, run ollama show --modelfile <model>: for GGUF models, the FROM line is the blob’s path. Models Ollama stores in its Safetensors format (the ones it runs with MLX) are split across many smaller blobs, and their FROM line shows a model name instead, so this check won’t match them to anything.

Keep one copy

Once you know two tools hold the same bytes, these are the options the tools support.

Share a file between Ollama and LM Studio

A hard link gives one file two names. Both tools see an ordinary file, the data is stored once, and removing one name (with ollama rm, say) leaves the other working. The space comes back only when both names are gone. Both folders must be on the same disk.

First delete LM Studio’s copy in the My Models tab, from the model’s menu. Then recreate it as a hard link to Ollama’s blob, at the publisher/model/file.gguf path LM Studio expects inside its models folder:

mkdir -p ~/.lmstudio/models/bartowski/Llama-3.2-1B-Instruct-GGUF
ln ~/.ollama/models/blobs/sha256-<hash> ~/.lmstudio/models/bartowski/Llama-3.2-1B-Instruct-GGUF/Llama-3.2-1B-Instruct-Q4_K_M.gguf

ls -li on both paths should show the same inode number and a link count of 2. Use a hard link, not a symlink: a symlink into Ollama’s blob folder breaks as soon as Ollama removes that model.

lms import --hard-link also makes hard links, but it keeps the source file’s name, and an Ollama blob has no .gguf extension. Without --copy, --hard-link or --symbolic-link, lms import moves the file into LM Studio’s folder.

Import a GGUF into Ollama

If LM Studio already has a GGUF that you want in Ollama, put FROM /path/to/model.gguf in a file called Modelfile and run:

ollama create my-model -f Modelfile

This saves a download, not disk space: ollama create copies the file into its blob store (you’ll see “copying file” as it runs). The hard-link step above brings it back to one copy.

Point mlx-lm at a folder you already have

mlx-lm takes a local folder anywhere it takes a repo ID; its --model option accepts “the path to the local model directory or Hugging Face repo”. If LM Studio already holds a complete MLX model folder (weights, config and tokenizer files), you can point mlx-lm at it and remove the cached copy with hf cache rm.

Share models across ComfyUI installs

In Comfy Desktop, open the capsule menu at the top of the app and add model folders in the Storage tab. A manual install reads extra folders from extra_model_paths.yaml in its root folder; copy extra_model_paths.yaml.example to start. Restart ComfyUI after changing either.

Keep one Hugging Face cache

Hub-based libraries share one cache unless something overrides it, so check that your projects don’t each set their own HF_HOME or cache_dir. Since huggingface_hub 1.32, the cache also stores identical Xet-backed files once across repos.

Remove models with each tool’s own command

Deleting files inside these folders by hand can leave a tool pointing at files that are gone. Use the tool instead:

• Ollama: ollama rm <model> removes the model and any blobs no other model still uses.
• Hugging Face: hf cache rm model/<org>/<name> --dry-run shows what would go and how much space it frees; run it again without --dry-run to delete. hf cache prune removes revisions no branch or tag points to, plus interrupted downloads. Before huggingface_hub 1.0, the command is huggingface-cli delete-cache.
• mlx-lm: mlx_lm.manage --scan lists cached repos with “mlx” in the name, and mlx_lm.manage --delete --pattern <text> removes matching ones after asking.
• LM Studio: in My Models, open the model’s menu and choose Delete. lms has no remove command yet; there’s an open request for one.
• ComfyUI: models are plain files in their type folders, so move the ones you don’t want to the Trash in Finder.

ollama rm and hf cache rm delete permanently. They don’t use the Trash.

What you can’t download again

Most of what these folders hold is a download and can come back. These can’t, so check before you delete:

• Fine-tunes, LoRAs and adapters you trained. mlx-lm saves adapters to adapters and fused models to fused_model, in the folder you ran it from, outside the cache.
• Merges, conversions and quantizations you made yourself, such as mlx_lm.convert output in mlx_model. You can redo them, but not by downloading.
• Ollama models you created from a local file you’ve since deleted. The blob is then the only copy.
• Files you added with a plain lms import. It moves the file, so LM Studio’s copy may be the only one.
• ComfyUI’s output folder and any LoRAs you trained.
• Models from gated, private or deleted repos, which may not download again.

Other caches worth a look

Python environments for local AI pull in large packages, and their download caches grow quietly. Everything in them downloads again when needed. To see each cache’s folder and size:

pip cache dir
pip cache info
uv cache dir
uv cache size
conda clean --all --dry-run

To clear them, use pip cache purge, uv cache prune (which removes unused entries; uv cache clean removes everything) and conda clean --all. PyTorch hub downloads are plain files, with weights in ~/.cache/torch/hub/checkpoints; remove the ones you no longer use in Finder.

If you’d rather see all this in one place, Disk Whisk’s Overview groups Ollama, LM Studio, Hugging Face and ComfyUI storage under “AI models & datasets” and explains each item, and anything you approve for cleanup goes to the Trash.