One Models Folder to Rule Them All: Stop Duplicate AI Models From Eating Your Disk

I went looking for free disk space last week and found 130 GB of it hiding in plain sight — the same AI models, downloaded over and over by every local tool I'd been experimenting with.

I'd been bouncing between Ollama, LM Studio, EasyDiffusion, and WideAreaAI, and each one had quietly built up its own private models directory. The same Llama and Qwen weights existed three times. My Stable Diffusion checkpoints existed twice. None of these tools knows the others exist, so none of them dedupes.

The fix took an afternoon: I created one models folder on a second drive and pointed every tool at it. My system drive got 130 GB back, and new tools now inherit the whole library instead of re-downloading it. Here's exactly how to do it, on both Mac and Windows.

Why this happens

Every local AI tool ships with its own model manager, and each one downloads independently — from Hugging Face, from its own registry, from wherever. There's no shared package cache the way npm or pip have one. So the moment you run the same 8B model in two different apps, you're paying for it twice on disk. Run four tools and a few large models and you're easily into hundreds of gigabytes of pure duplication.

There are two distinct wins available, and it's worth being honest about which is which:

1. Relocation — move each tool's store off your cramped system drive onto one big drive. This always works, for every tool, and it's what reclaimed most of my 130 GB.
2. True file-sharing — get multiple tools to read one physical copy of a model. This works within a format family but not across all of them (more on the one big exception below).

The one gotcha: not every format is shareable

Before you start, understand the formats, because it determines what you can actually share:

• LM Studio, llama.cpp, Jan, KoboldCpp all store plain GGUF files in a publisher/repo/model.gguf tree. These can genuinely share one physical GGUF file. (What is GGUF? — it's the single-file format the whole consumer ecosystem standardized on.)
• Ollama is the exception. It repacks weights into a content-addressed blob store (blobs/sha256-… plus manifests/) rather than keeping named .gguf files. So Ollama cannot point at LM Studio's GGUF tree, and vice versa. You can still relocate Ollama's whole store to the shared drive — you just don't get single-copy sharing between Ollama and the GGUF-native tools.
• EasyDiffusion, Automatic1111, ComfyUI all read safetensors / ckpt checkpoints. These can share one folder of Stable Diffusion models, LoRAs, and VAEs.

So the realistic target architecture is: group by format, give Ollama its own subfolder, and let each format family share one copy.

Step 0: Set up the shared folder

Pick your big drive and create one root with format-based subfolders. I used a second internal drive; an external NVMe or USB4 SSD works just as well (avoid slow USB spinning disks — see the FAQ on load speed).

Windows (D: drive):

D:\AI\models\
├── gguf\               # shared by LM Studio, llama.cpp, Jan, KoboldCpp
├── ollama\             # Ollama's blob store (its own format)
└── diffusion\
    ├── stable-diffusion\
    ├── lora\
    └── vae\

macOS (external volume mounted at /Volumes/AI, or anywhere on a second internal drive):

/Volumes/AI/models/
├── gguf/
├── ollama/
└── diffusion/
    ├── stable-diffusion/
    ├── lora/
    └── vae/

Before you move anything, see what you're working with:

# macOS / Linux — sizes of the default stores
du -sh ~/.ollama/models ~/.lmstudio/models 2>/dev/null

On Windows, right-click each folder → Properties, or in PowerShell:

"$env:USERPROFILE\.ollama\models","$env:USERPROFILE\.lmstudio\models" |
  ForEach-Object { "{0}  {1:N1} GB" -f $_, ((Get-ChildItem $_ -Recurse -File -EA 0 | Measure-Object Length -Sum).Sum / 1GB) }

The golden rule for every step below: move the files first, then redirect the tool, then restart it. If you redirect first, the tool sees an empty folder and cheerfully re-downloads everything.

Ollama

Ollama's default store lives at:

• macOS: ~/.ollama/models
• Windows: C:\Users\<you>\.ollama\models
• Linux: /usr/share/ollama/.ollama/models

It reads its location from the OLLAMA_MODELS environment variable.

Move the files first:

# macOS
mv ~/.ollama/models/* /Volumes/AI/models/ollama/

# Windows (PowerShell)
Move-Item "$env:USERPROFILE\.ollama\models\*" "D:\AI\models\ollama\"

Then set the variable:

• Windows: Start → "Edit the system environment variables" → Environment Variables → New user variable OLLAMA_MODELS = D:\AI\models\ollama. Quit Ollama from the system tray and relaunch (it only reads the variable at startup).

• macOS (the menu-bar app): the reliable approach is launchctl, which the app inherits:

  launchctl setenv OLLAMA_MODELS "/Volumes/AI/models/ollama"
  # then quit Ollama from the menu bar and reopen it
  

  To make it stick across reboots, add the same export to your shell profile and keep the launchctl setenv (the GUI app doesn't read ~/.zshrc). Simpler still: skip the variable and symlink instead —

  rmdir ~/.ollama/models           # only after moving its contents out
  ln -s /Volumes/AI/models/ollama ~/.ollama/models
  

Confirm it took:

ollama list          # your models should still be here
ollama pull qwen3:8b # new pulls now land on the shared drive

LM Studio

LM Studio keeps plain GGUF files, which makes it the easy one — and the one that can share with llama.cpp.

Default location:

• macOS / Linux: ~/.lmstudio/models (older builds: ~/.cache/lm-studio/models)
• Windows: C:\Users\<you>\.lmstudio\models (older builds: .cache\lm-studio\models)

LM Studio has a native directory setting — no env vars needed. Open LM Studio → My Models tab → click the models-directory path at the top → Change → point it at D:\AI\models\gguf (or /Volumes/AI/models/gguf). Move your existing publisher/repo/*.gguf folders into that location first, and LM Studio will index them in place.

Because these are ordinary GGUF files, llama.cpp can run the exact same files with no extra copy:

llama-server -m /Volumes/AI/models/gguf/lmstudio-community/Qwen3-8B-GGUF/Qwen3-8B-Q4_K_M.gguf

One folder, two tools, one physical copy. That's the win that doesn't exist for Ollama.

EasyDiffusion (and other image generators)

Image tools store safetensors / ckpt checkpoints, LoRAs, and VAEs under their install directory — for EasyDiffusion, that's EasyDiffusion/models/stable-diffusion, .../lora, .../vae, and friends.

Check the app's settings first for a custom-models-path option. If there isn't a reliable one, the universal trick is a symbolic link — move the folder to the shared drive and link the original path to it so the app is none the wiser:

macOS / Linux:

mv ~/EasyDiffusion/models/stable-diffusion /Volumes/AI/models/diffusion/stable-diffusion
ln -s /Volumes/AI/models/diffusion/stable-diffusion ~/EasyDiffusion/models/stable-diffusion

Windows (run cmd as Administrator):

move "C:\EasyDiffusion\models\stable-diffusion" "D:\AI\models\diffusion\stable-diffusion"
mklink /D "C:\EasyDiffusion\models\stable-diffusion" "D:\AI\models\diffusion\stable-diffusion"

The payoff: Automatic1111 and ComfyUI can point at the same diffusion/stable-diffusion folder, so your 6 GB SDXL checkpoint exists once and every image tool sees it.

Wide Area AI

WideAreaAI keeps its own model/cache path, and — unlike most tools — it lets you set that path explicitly. Point it at the shared folder (the gguf subfolder for text models) so it draws from the same library as everything else instead of building a fourth private copy.

This is also where the consolidation pays off beyond disk space. WideAreaAI is an edge-first AI gateway: your apps get one OpenAI-compatible endpoint, and each request is routed edge cache → your own hardware (a llama.cpp node reached over a Cloudflare Tunnel, no inbound ports) → cloud burst as failover when your hardware is saturated or down. The model is own your baseline, burst to the cloud — no per-token fees on the hardware you already own. Once all your tools share one models folder, that folder is your baseline: a single, deduplicated library that your local gateway serves from and only reaches to the cloud when you choose to.

Verify, then reclaim

After every tool is redirected and restarted:

1. Confirm each tool still lists its models (ollama list, LM Studio's My Models tab, your image tool's checkpoint dropdown). If a model is missing, you moved files after redirecting — move them into the new location and re-scan.
2. Confirm new downloads land on the shared drive, not the system drive. Pull one small model in each tool and check where it appears.
3. Only then delete the old folders if anything was left behind. Empty out the originals and recheck your free space.

That last step is where the 130 GB showed up for me. The duplicates had been invisible precisely because each tool only ever looked at its own directory.

The bigger payoff

Freeing the disk is the immediate reward, but the real change is structural: you now have one library instead of four silos. Every new tool you try inherits the whole collection. Every model you download is available everywhere it can be. And when you're ready to put a real endpoint in front of all this — with caching, failover, and cloud burst — your shared folder is the clean, single-source baseline that makes it work.

If you're building out a local AI setup, start here. A shared models folder is the unglamorous foundation that makes everything downstream simpler — see Running Local AI: The Complete Guide for where to take it next.