The Real Ceiling for Local LLMs on an 8GB Mac Isn't RAM — It's Disk

My earlier benchmark on this machine stopped at 1B parameters and cited someone else's 8B numbers, reasoning that an 8B model "needs roughly 5-6GB just to load the weights, leaving almost nothing for the OS." That was a guess, not a measurement. This post is the actual attempt to push further on the same hardware — and it found a different ceiling than the one I expected.

One more real data point: Llama 3.2 3B

Same methodology as before: Ollama v0.32.4, same fixed prompt, num_predict: 200, temperature 0, three runs, throughput read directly from eval_count / eval_duration via the generate API — no stopwatch, no estimate.

Llama 3.2 3B (Q4_K_M) held 25.05, 25.05, and 25.22 tokens/second across the three runs — averaging ~25.1 tok/s, ollama ps confirming 100% GPU and a 2.5GB resident footprint. That continues the pattern from the first post: throughput drops faster than parameter count alone predicts (0.5B→1B roughly halved it; 1B→3B, a 3x parameter jump, only cost another ~28%), but nowhere near the cliff the earlier post cited for 8B. On raw throughput, 3B is still a genuinely usable model on this hardware tier.

What actually stopped the 8B test wasn't GPU memory

The plan was straightforward: delete the 3B model, pull an 8B Q4 model (roughly 4.7-4.9GB), and get a real number instead of a cited one. Before doing that, I checked free disk space, because this machine — the one I actually write this site on — started the session with only 5.6GB free, not the generous headroom a benchmark machine would have.

Pulling the 3B model alone took free space from 5.6GB to 3.9GB. Then, running just three generations — about 600 tokens total, on a model that reports a 2.5GB resident footprint — dropped it further, to 2.9GB. That second drop isn't disk used by the model; the model was already fully downloaded. I checked vm_stat before and after the three runs specifically: swapouts went from 49,600 pages to 105,128 pages (16KB each), meaning the three short generations wrote roughly 910MB to macOS's swap file in a few seconds. sysctl vm.swapusage confirmed it directly afterward: total = 2048.00M used = 1378.62M free = 669.38M.

Stopping the Ollama server afterward brought free disk back up to 4.8GB — not the full 5.6GB it started at. macOS had already grown a swap file to hold that ~1.4GB, and that allocation doesn't shrink back down until the machine reboots. Deleting the 3B model recovered less disk space than the model itself had used, because the real disk cost of running it was the swap it generated, not the weights it downloaded.

At that point, pulling a ~4.7GB 8B model would have needed the 4.8GB I had — with essentially zero margin, on a machine actively running other software, mid-swap-allocation, that I use for real work. I stopped there rather than force it. That's the honest finding of this post: the 8B model I set out to test wasn't blocked by GPU memory or by Ollama refusing to load it — it was blocked by macOS's own swap file quietly consuming the free disk space a bigger model would have needed, on a laptop that was already running low on storage before the benchmark started.

The lesson isn't "buy more RAM," it's "check disk, not just RAM"

Every local-LLM sizing guide talks about matching model size to unified memory. None of the ones I read before writing either of these two posts mentioned that on a machine already low on disk, three short generations from a mid-size model can eat close to a gigabyte of swap space — space that doesn't come back until reboot, and that a bigger model needs to even finish downloading. If you're planning to test a bigger model on constrained Apple Silicon hardware, df -h before you ollama pull matters as much as checking the model's own memory footprint.

I'm not reporting a fabricated 8B number here, and I'm not retesting the earlier post's cited 9.72 tok/s figure — that's still someone else's measurement, clearly labeled as such in the original post. What's new here is real: a genuine 3B measurement, and a genuine reason this machine's local-LLM ceiling turned out to be about storage headroom, not the number printed on the spec sheet.

Sources

• Measured directly by the author, Aug 2026: Ollama v0.32.4, llama3.2:3b (Q4_K_M), Apple M1 / 8GB unified memory, 3 runs via the Ollama generate API, ollama ps confirming 100% GPU and 2.5GB resident size
• Disk and swap telemetry measured directly by the author during the same session: df -h /, vm_stat, sysctl vm.swapusage, checkpointed before the pull, after the pull, after the benchmark runs, and after stopping the Ollama process

Every number in this post — throughput, disk space, and swap usage — was measured on the author's own machine during the writing of this post, not cited or estimated.