Guide
Storage for local models
Buy capacity for the models you will keep; use NVMe so loads and pulls are not the bottleneck — not so tokens/sec magically rise. VRAM decides whether a model is pleasant. Disk decides whether you can keep more than two without deleting something every Tuesday. A half-full 2 TB NVMe used as a model library beats a maxed 512 GB boot drive every time. Peak MB/s charts are not a model library. — Tech-Gurunomics.
This is the storage half of the shopping problem — capacity, where models live, and what a fast NVMe actually buys you. Pair with VRAM and RAM for local LLMs. File-size bands below are order-of-magnitude estimates for typical GGUF/library growth — not a promise your pulls will match.
Who it's for / who it's not
| For | Not for |
|---|---|
| Builders whose C: fills after Ollama / LM Studio weekends | People expecting SSD speed to replace GPU/CPU for tokens/sec |
| Mixed LLM + image (Comfy-style) libraries on one box | Cloud-only object-storage shoppers |
| Desktop “add a second NVMe” upgrades | Assuming laptop single-slot upgrades match desktop flexibility |
How fast libraries grow (estimated)
| What you collect | Typical size band (estimate) | What “a weekend” can look like |
|---|---|---|
| 7B–13B GGUF quants | A few to ~10 GB each | A handful of variants → tens of GB |
| 30B–70B-class files | Tens of GB each | Two or three “just in case” downloads → 100 GB+ |
| Image / diffusion stacks | Checkpoints + LoRAs + VAEs + ControlNets | Stacks beside LLMs on the same disk |
| Docker images + UIs | Open WebUI and friends | Quiet extra pile on the same volume |
Framing (2026-09-10): Tech-Gurunomics planning estimates for local libraries — plan for what you will keep, not the one model in a YouTube thumbnail. It replaces “my C: drive is mysteriously full” surprise after a weekend of Ollama pulls, LM Studio downloads, or llama.cpp GGUF collecting. It does not replace backups, and it does not make a slow CPU generate tokens faster.
What NVMe speed actually buys
| Expectation | Reality |
|---|---|
| Faster tokens/sec after load | Mostly no — once weights are in VRAM/RAM, sequential SSD benchmarks stop mattering for generation |
| Faster first load / model switch | Yes — this is the main win |
| Less painful pulls / unpacking | Yes |
| Rescue from a dying SATA + swap thrash | Yes |
| Capacity vs last 500 MB/s on a chart | Capacity and free space win |
A half-full 2 TB NVMe used as a model library beats a maxed 512 GB boot drive every time.
Practical layout
| Do | Why |
|---|---|
| OS on one volume; model caches on a dedicated fast disk when you can | Avoid “C: mysteriously full” after a pull weekend |
| Know runner paths before “clean up” | Ollama model dir, LM Studio downloads, Hugging Face cache, Comfy folders |
| Internal NVMe for active models; USB enclosure for cold archives | Daily active library prefers internal speed |
Example hardware (disclosed Associates)
Real NVMe category only — not a ranking. Tag techgurunomic-20.
2 TB listing reused from the local LLMs hub;
4 TB is the same product line looked up on Amazon for larger libraries.
- Samsung 990 PRO 2TB NVMe SSD — solid default library disk for a mixed set of 7B/13B quants plus room to breathe.
- Samsung 990 PRO 4TB NVMe SSD — same family, more headroom when 70B-class files and image checkpoints share a box.
Some links are Amazon Associates (tag=techgurunomic-20). Tech-Gurunomics may earn a commission if you buy.
Free sample — Local LLM Chooser + Failure-Mode Sample: printable chooser and failure-mode worksheet (not a blank tease PDF). Tech-Gurunomics digital product (separate from Amazon Associates hardware links).
Paid worksheets pack ($39) — Local LLMs + Agents Without the Hype: checklists and failure modes we use on these pages. Tech-Gurunomics digital product (separate from Amazon Associates hardware links).
Where this advice falls over
- DRAM-less bargain SSDs can feel fine until sustained writes and a full disk meet.
- Laptop single-slot upgrades force tradeoffs the desktop “add a second NVMe” crowd never sees.
- Cloud object storage ≠ the machine under your desk.
- Chasing peak MB/s while the boot drive is maxed still leaves you deleting models every Tuesday.
- A fast NVMe does not make a slow CPU generate tokens faster.
- Forgetting where Ollama / LM Studio / HF caches live turns “cleanup” into accidental data loss.
FAQ
How much disk space do local LLMs need?
Estimated: 7B–13B GGUF quants are often a few to ~10 GB each; a handful of variants becomes tens of GB. 30B–70B-class files are tens of GB each — two or three downloads can be a 100 GB+ weekend. Plan for the library you keep, not one thumbnail model (Tech-Gurunomics, 2026-09-10).
Does a faster NVMe improve tokens per second?
Usually not after the model is loaded. Once weights are resident in VRAM/RAM, sequential SSD speed stops driving generation rate. NVMe mainly helps first load, model switches, and pulls.
Is 2 TB enough for a local model library?
Often a solid default for a mixed set of 7B/13B quants with room to breathe. Jump toward 4 TB when 70B-class files and image checkpoints share the same box. Estimates — your mix varies.
Should models live on the OS drive?
Prefer not, when you can avoid it. Keep the OS on one volume; put model caches on a dedicated fast disk. Know Ollama / LM Studio / Hugging Face / Comfy paths before cleaning up.
VRAM or storage first?
Different jobs. VRAM decides pleasant day-to-day chat; disk decides whether you can keep the library. See VRAM and RAM for local LLMs, then pick a runner from the local LLMs cluster.
Verdict
Buy capacity for the models you will keep; use NVMe so loads and pulls are not the bottleneck. Size VRAM separately — VRAM and RAM guide — and pick a runner from the local LLMs cluster. Peak MB/s charts are not a model library. — Tech-Gurunomics, 2026-09-10.