The Backup Strategy for People With 500GB of AI Models

Photo: Unsplash

AI Power User

The Backup Strategy for People With 500GB of AI Models

Stop backing up the replaceable 500GB and start protecting the irreplaceable 2GB hiding next to it

Run this command right now:

du -sh ~/.ollama ~/.lmstudio ~/.cache/huggingface 2>/dev/null

If you’ve been playing with local AI for more than a few months, the total will frighten you. Mine read 412GB across the three, plus another 90GB of MLX conversions in project folders — over half a terabyte of model weights, much of it duplicated, all of it being faithfully shoveled onto my Time Machine disk every hour as if it were precious.

It isn’t precious. That’s the whole point of this post. Here’s where the space goes, how to reclaim 100GB+ this afternoon, and the contrarian backup strategy that actually makes sense for model hoarders.

Where Your Models Actually Live (and Why You Have Three Copies)

Every local-AI tool maintains its own cache, in its own format, and they do not share:

  • Ollama: ~/.ollama/models — content-addressed blobs under models/blobs/ with human-readable manifests under models/manifests/
  • LM Studio: ~/.lmstudio/models — GGUF files organized by publisher and repo
  • Hugging Face cache: ~/.cache/huggingface/hub — populated by anything using transformers, mlx-lm, diffusers, or hf download; full repos with multiple weight formats

Here’s how the waste compounds: you try Llama 3.1 8B in Ollama (~4.9GB). Later you download it in LM Studio because that’s where you were working (~4.9GB, byte-different file, same weights). Then a Python script pulls the original safetensors from Hugging Face (~16GB, because that’s the unquantized model). One model, three places, ~26GB. Multiply by every model you’ve ever been curious about, and finding 100GB+ of effective duplication is the norm, not the exception. I found 140GB.

There’s no clean cross-tool dedup — the formats genuinely differ. The fix is policy: pick one primary tool per format (for me: Ollama for daily driving, HF cache only for MLX work) and delete the rest.

The Cleanup: Commands That Reclaim Real Space

Ollama. List and remove what you don’t use:

ollama list
ollama rm llama2:13b mistral:7b-instruct-v0.2  # the 2024 nostalgia shelf

Then the sneaky part: orphaned blobs. Interrupted pulls and removed models can leave multi-gigabyte blobs in ~/.ollama/models/blobs that no manifest references. Recent Ollama versions clean up after ollama rm, but interrupted downloads still strand partial blobs. Sanity check: compare du -sh ~/.ollama/models against the sum of ollama list. If there’s a multi-GB gap, the nuclear-but-safe fix is to note your model list, delete the models directory, and re-pull the three you actually use — which is faster than forensic blob archaeology.

Hugging Face. The huggingface_hub CLI has a genuinely good interactive cleaner:

hf cache scan          # shows every cached repo with size and last-accessed date
hf cache delete        # interactive TUI: tick the corpses, confirm, gone

(Older installs: huggingface-cli scan-cache and huggingface-cli delete-cache.) The last accessed column is brutal honesty — mine showed 11 repos untouched since 2025, totaling 96GB.

LM Studio has a model manager UI (My Models → trash icon), or just delete folders from ~/.lmstudio/models directly; they’re plain GGUF files, nothing breaks.

My afternoon’s harvest with these three tools: 187GB reclaimed.

The Contrarian Take: Do NOT Back Up Your Models

Now the actual backup strategy, and it starts with a deletion of conventional wisdom: model weights do not belong in your backups. Ever.

Think about what a backup is for: protecting things you cannot get back. Model weights are the single most re-downloadable data on your machine — immutable, content-addressed, mirrored globally by Hugging Face and Ollama’s registry. If your Mac dies tomorrow, ollama pull llama3.1:8b restores that “lost” 5GB at the full speed of your internet connection. On a 1Gbps line, re-downloading my entire active model set (~120GB) takes under 20 minutes. Restoring the same data from a USB Time Machine disk would take longer.

What you cannot re-download — the irreplaceable few gigabytes hiding in the same directories:

  • Your Modelfiles — the custom system prompts, parameters, and templates that define your models. Export them: ollama show --modelfile mymodel > backups/mymodel.Modelfile
  • Fine-tuned adapters — LoRA weights from your own training runs. Hours of compute and irreplaceable. Usually a few hundred MB each.
  • Prompt libraries — every system prompt you’ve refined over months.
  • Chat history — Open WebUI’s database, LM Studio conversations (~/.lmstudio/conversations), llm CLI’s SQLite logs. Your accumulated thinking.

Total that up and my truly irreplaceable AI data is about 2GB. The strategy writes itself: back up the 2GB obsessively (it fits in any cloud sync, three times over), back up the 500GB never. A tiny script keeps the precious parts gathered:

#!/bin/zsh
B=~/ai-precious
mkdir -p $B/modelfiles
for m in $(ollama list | tail -n +2 | awk '{print $1}'); do
  ollama show --modelfile "$m" > "$B/modelfiles/${m//[:\/]/_}.Modelfile"
done
cp -R ~/.lmstudio/conversations $B/ 2>/dev/null
cp "$HOME/Library/Application Support/io.datasette.llm/logs.db" $B/ 2>/dev/null

Run it weekly via launchd or cron, point it at a folder inside your normal cloud-synced backup scope, done.

Fix Time Machine Today: the Exact Exclusions

If you use Time Machine and you haven’t excluded your model directories, your backup disk is being strangled — every model you pull evicts months of real version history from a finite disk. Add the exclusions right now:

sudo tmutil addexclusion -p ~/.ollama/models
sudo tmutil addexclusion -p ~/.lmstudio/models
sudo tmutil addexclusion -p ~/.cache/huggingface

(The -p flag makes the exclusion stick to the path rather than the volume.) Verify with:

tmutil isexcluded ~/.ollama/models ~/.lmstudio/models ~/.cache/huggingface

Note the precision: we exclude ~/.ollama/models, not all of ~/.ollama — the parent directory holds your keys and config, which are small and worth keeping. Same logic everywhere: exclude blobs, keep config. If you back up with other tools, mirror these paths there too — Backblaze, Arq, and Carbon Copy Cloner all support path exclusions, and a 500GB churn of model weights will blow through bandwidth caps and versioned-storage quotas just as happily as it kills a Time Capsule.

The day I added these three exclusions, my next Time Machine snapshot shrank by 380GB and my backup disk’s retention window jumped from 5 weeks to over a year.

The External SSD Strategy for Serious Hoarders

If you legitimately need a large model library — you test models for work, you keep the 70B-class giants around — move the library off your internal drive entirely. A 2TB external NVMe SSD (Thunderbolt or USB4 enclosure) reads at 2,800–3,700 MB/s, which means a 40GB 70B model loads into memory in ~15 seconds — model loading is a sequential read, so external Thunderbolt storage costs you almost nothing versus internal once the model is resident in RAM. Avoid USB 3.0-only enclosures (~450 MB/s): that same load becomes a 90-second wait.

Two ways to relocate, both reversible:

Environment variables (cleanest):

# in ~/.zshenv
export OLLAMA_MODELS=/Volumes/ModelSSD/ollama-models
export HF_HOME=/Volumes/ModelSSD/huggingface

LM Studio’s models directory is changeable in-app: My Models → Models Directory.

Symlinks (when a tool ignores env vars or you want zero reconfiguration):

mv ~/.ollama/models /Volumes/ModelSSD/ollama-models
ln -s /Volumes/ModelSSD/ollama-models ~/.ollama/models

One warning from experience: if the SSD isn’t mounted when Ollama starts, it will see an empty/broken models path — symptoms look like “all my models vanished.” They didn’t; plug the disk in and restart the app. And yes, exclude the external volume from Time Machine too (sudo tmutil addexclusion -p /Volumes/ModelSSD), or you’ve just rebuilt the original problem on a bigger disk.

The Strategy on One Index Card

  • Dedupe: one tool per format; hf cache delete and ollama rm quarterly. Expect 100GB+ back the first time.
  • Back up: Modelfiles, adapters, prompts, chat history — the ~2GB you can’t re-download. Automate the gathering script.
  • Never back up: model weights. The internet is your backup; ollama pull is your restore command.
  • Exclude: the three tmutil addexclusion paths, today, before the next hourly snapshot.
  • Overflow: Thunderbolt/USB4 SSD with OLLAMA_MODELS and HF_HOME pointed at it.

Half a terabyte of models and the correct backup plan for it fits in 2GB. That asymmetry is the entire insight — protect what’s yours, re-download what’s everyone’s.

Get the next live webinar in your inbox

One email a month: the upcoming live event + free recording access for subscribers. No spam, unsubscribe anytime.