A 70B Q4 GGUF is 42 GB. A 70B Q8 GGUF is 75 GB. If you have ever tested both quantisations of the same model in LM Studio and then forgotten which one you actually use, you have already paid for an SSD upgrade you did not need. The pain shows up in audits like the one captured at brtkwr.com, where the author found "Unused GPT4All / LLM model files, 7 GB" sitting on a 487 GB drive, alongside Docker volumes and Python venvs. LM Studio is the friendliest local-LLM app on Mac, and that friendliness is exactly why its storage footprint hides in plain sight.
Where does LM Studio store models on Mac?
LM Studio writes everything into a hidden directory in your home folder. The default model store is ~/.lmstudio/models/, and inside that, models are saved in a Hugging Face-style three-level tree: publisher, repo, file. So a typical Llama 3 70B quantised by Bartowski lands at ~/.lmstudio/models/bartowski/Meta-Llama-3-70B-Instruct-GGUF/Meta-Llama-3-70B-Instruct-Q4_K_M.gguf.
LM Studio also keeps a separate cache for app state, downloads in progress, and logs. On Apple Silicon Macs that cache is ~/.cache/lm-studio/ when you installed via the standard installer. Older versions stashed logs under ~/Library/Application Support/lm-studio/, which is worth checking on machines that have been on LM Studio since 2024.
The full layout, by purpose:
~/.lmstudio/models/: the GGUF model store. Multi-GB files. State-bearing.~/.lmstudio/config/: config JSON. Tiny. Keep.~/.lmstudio/conversations/: chat history. Tiny but personal.~/.cache/lm-studio/: logs, partial downloads, telemetry buffers.~/Library/Application Support/lm-studio/: legacy state on older installs.
How much LM Studio storage is too much LM Studio storage?
There is no fixed number. The honest threshold is "as much as you can afford to redownload over your worst Wi-Fi." A 70B at Q4 is 42 GB and pulls in roughly an hour on a 100 Mbps link. A 7B at Q4 is 4.4 GB. Most LM Studio users I have audited carry three to five model copies they have not loaded in months, which becomes 80 to 250 GB sitting idle.
| Model size | Q4_K_M | Q5_K_M | Q8_0 | Notes |
|---|---|---|---|---|
| 7B | ~4.4 GB | ~5.0 GB | ~7.5 GB | Tiny by today's GGUF standards. |
| 13B | ~7.9 GB | ~9.3 GB | ~14 GB | Most "small but capable" workhorses. |
| 34B | ~20 GB | ~24 GB | ~36 GB | Watch for double copies across quantisations. |
| 70B | ~42 GB | ~50 GB | ~75 GB | A single test can eat half a 512 GB SSD. |
| 405B | ~230 GB | ~270 GB | ~430 GB | Almost no consumer Mac can hold the Q8. |
The real failure mode is not the single big model. It is the fact that you tried three quantisations of one 70B six months ago to benchmark output quality, never deleted the losers, and now have 150 GB of "research" sitting in ~/.lmstudio/models/.
How do I audit LM Studio storage from Terminal?
A clean audit takes one paste. No sudo, no third-party tool, no installer.
# Sizes by publisher (top of ~/.lmstudio/models/)
du -sh ~/.lmstudio/models/*/ 2>/dev/null | sort -h
# Sizes by repo (publisher/repo level)
du -sh ~/.lmstudio/models/*/*/ 2>/dev/null | sort -h | tail -20
# Individual GGUF files over 5 GB, with last-modified dates
find ~/.lmstudio/models -name "*.gguf" -size +5G \
-exec stat -f "%Sm %z %N" -t "%Y-%m-%d" {} \; 2>/dev/null \
| sort
# Cache and logs
du -sh ~/.cache/lm-studio 2>/dev/null
du -sh ~/Library/Application\ Support/lm-studio 2>/dev/null
Read the third command's output the way you would read a fridge audit: anything modified more than ninety days ago and never opened since is a candidate for archival or deletion. The stat -f flag is the macOS form; on Linux you would use stat -c.
Is it safe to delete LM Studio model files?
Yes, with one caveat: GGUF files are state-bearing assets, not caches. Deleting Meta-Llama-3-70B-Instruct-Q4_K_M.gguf frees 42 GB and breaks exactly one thing. The next time you click that model in LM Studio's UI it will redownload from Hugging Face. Deleting a ~/Library/Caches folder is reversible in seconds. Deleting a 42 GB GGUF is reversible in an hour of bandwidth.
This matches the broader cleanup philosophy captured in the brtkwr write-up: "After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB." The author's second pass included LLM model files precisely because each one was big enough to count and old enough to remove without regret.
The safe sequence on a Mac:
- Open LM Studio, note which models you have loaded in the last thirty days.
- Quit LM Studio. The app holds open file handles on the active model, and you do not want to delete a file mid-mmap.
- Move the GGUF files you no longer need to the Finder Trash. Do not
rm -rf. The Trash gives you a roll-back window. - Empty Trash only after the next week of work confirms you did not need them.
If you prefer the CleanMyDev flow, the LM Studio rows show up in the model audit screen alongside Ollama and Hugging Face entries with the same per-row receipt: path, size, last-modified, owning tool, risk label set to redownload-required. The deeper rationale for that label lives in Where does Ollama store models on Mac and Hugging Face cache location on Mac.
Can I move LM Studio's storage to an external drive?
Yes, and on a 256 GB or 512 GB MacBook this is often the right answer. LM Studio reads the model path from its ~/.lmstudio/config/ directory. You can change the models directory inside the app's Settings, point it at /Volumes/External/lmstudio-models/, and the app will load from there going forward.
The migration itself is a mv plus a re-point:
# 1. Quit LM Studio first.
# 2. Move the existing tree to the external drive.
mv ~/.lmstudio/models /Volumes/External/lmstudio-models
# 3. Optional: symlink the old path so LM Studio's settings still
# resolve if you ever launch the app before re-configuring it.
ln -s /Volumes/External/lmstudio-models ~/.lmstudio/models
# 4. Open LM Studio, change the models path in Settings,
# then verify a model loads.
The symlink step is belt-and-braces. The official path change in Settings is sufficient on current LM Studio releases. Always start LM Studio after a move and confirm one small model loads before you do anything else, because a mv across volumes is one operation but the verification is the receipt that the operation worked.
What about LM Studio logs and the ~/.cache/lm-studio folder?
This is the cache equivalent of ~/Library/Caches/claude-cli-nodejs, where logs and partial downloads can quietly accumulate over months of heavy use. The Claude Code postmortem on GitHub Issue #18869 shows the upper bound of what unbounded log growth looks like: 472 GB across ~/.claude/debug and a sibling cache. LM Studio's logs are smaller in practice (usually under 2 GB even after a year of heavy use), but the principle is the same: the app does not auto-prune them, and you can.
# Audit the cache directory.
du -sh ~/.cache/lm-studio 2>/dev/null
du -sh ~/.cache/lm-studio/* 2>/dev/null | sort -h | tail -10
# Trash logs older than 30 days (safe; logs are not state).
find ~/.cache/lm-studio/logs -type f -mtime +30 \
-exec mv {} ~/.Trash/ \; 2>/dev/null
Logs are diagnostic, not state. Deleting them does not affect models, conversations, or settings. The only reason to keep older logs is to debug a specific crash, and after thirty days the diagnostic value is usually gone.
How does LM Studio storage compare to Ollama and Hugging Face cache?
These three tools are the holy trinity of "Ollama is the new node_modules." Each has its own directory and its own deduplication story, which means three GGUF copies of the same Llama 3 70B can end up on the same Mac without any of the three knowing about the others.
| Tool | Default path | Dedupe | Typical footprint | What deletion costs |
|---|---|---|---|---|
| LM Studio | ~/.lmstudio/models/ |
None across tools | 5 GB to 250 GB | Redownload from Hugging Face |
| Ollama | ~/.ollama/models/ |
Internal blob store | 4 GB to 200 GB | ollama pull redownload |
| Hugging Face | ~/.cache/huggingface/hub/ |
Per-revision symlinks | 2 GB to 100 GB | Redownload via transformers |
There is no cross-tool dedupe. If you have Meta-Llama-3-70B-Instruct-Q4_K_M.gguf in LM Studio and you also have the same model in Ollama, you are paying 84 GB for one model. This is one of the strongest cases for an audit pass that names the duplicates, not a one-button cleaner that empties a folder it does not understand.
Closing: receipts before deletion, even for LM Studio
LM Studio storage on Mac is one of the cleaner stories in the local-LLM ecosystem: one main directory, a sane on-disk layout, and a settings option to relocate it. The hard part is not the path. The hard part is deciding which 42 GB GGUF you can afford to lose. If that decision belongs to you and not to a cleaner that runs presets, then CleanMyDev is the $9.99 lifetime tool that gives you the receipt before it deletes anything. Per-row metadata, Move to Trash by default, no admin password, no subscription.