Ollama on Mac mini M4: 16 GB Means 11.84 GiB

I run this business on a base M4 Mac mini with 16 GB of memory. When I went looking for what Ollama actually does on that machine, almost every number I found came from a different computer. The top results are M2 Max chips with 32 GB, or tables of estimates with no machine attached at all. One commenter on Hacker News said it plainly: the per-machine tok/s estimates are off, and some models run at twice the speed listed.

So I measured five models on this one, with Ollama 0.34.2. The useful result is not any single tokens-per-second number. It is that the number governing all of them is not 16 GB. It is 11.84 GiB, it comes from a property Apple documents as a suggestion, and Ollama treats it as a wall.

The budget is 12,713,115,648 bytes, not 16 GB

The first line Ollama writes to its log when it finds the GPU on this machine is this one:

msg="inference compute" library=Metal description="Apple M4"
  type=iGPU total="11.8 GiB" available="11.8 GiB"

Total, on a 16 GB machine, is 11.8 GiB. That is not a rounding artifact. I asked Metal directly with a five-line Swift program:

recommendedMaxWorkingSetSize bytes: 12713115648
  GiB: 11.840011596679688
maxBufferLength bytes: 9534832640  (8.88 GiB)
hasUnifiedMemory: true

Ollama reads that exact property. In discover/gpu_info_darwin.m, getRecommendedMaxVRAM() is a one-liner returning device.recommendedMaxWorkingSetSize. Then gpu_darwin.go holds back a further metalMinimumMemory = 512 * format.MebiByte, which is why every load in my logs reports available="11.3 GiB" free="11.8 GiB" minimum="512.0 MiB".

The part worth pausing on is what Apple says that property means. Its documentation calls it "an approximation of how much memory, in bytes, this GPU device can allocate without affecting its runtime performance," and adds that you can "help the GPU maintain its performance by keeping the total memory footprint of its resources and heaps less than this threshold value." That is advice about performance. Ollama turns it into a hard budget, and there is no way to raise it from Ollama's side: I read the full environment variable list in envconfig/config.go and the only related knob is OLLAMA_GPU_OVERHEAD, which subtracts. Raising it means changing iogpu.wired_limit_mb at the OS level, which I did not do, because this is the machine the business runs on and I was not willing to reboot out of a bad value.

Five models, measured here

Greedy decoding, seed 42, 128 tokens, the same prompt each time, five runs per model, median reported. Every model was unloaded before the next one loaded. Spread across the five runs was under 2 percent in every case.

Model	Weights on disk	ollama ps	Generation	Prompt	Effective bandwidth
llama3.2:1b (Q8_0)	1,321,082,688 B	1.5 GB	73.19 tok/s	2,643 tok/s	96.7 GB/s
llama3.2:3b (Q4_K_M)	2,019,377,376 B	2.5 GB	46.71 tok/s	-	94.3 GB/s
Llama 3.1 8B Q4_K_M	4,920,739,232 B	5.6 GB	21.34 tok/s	990 tok/s	105.0 GB/s
Llama 3.1 8B Q6_K	6,596,011,424 B	6.8 GB	16.33 tok/s	756 tok/s	107.7 GB/s
Llama 3.1 8B Q8_0	8,540,775,840 B	8.6 GB	12.99 tok/s	601 tok/s	110.9 GB/s

One thing to note about the library tags: llama3.2:1b ships as Q8_0, not Q4_K_M. I assumed otherwise until I ran ollama show. The three 8B rows are the same Llama 3.1 8B weights at three quantization levels, imported from local GGUF files with ollama create, which took 9 and 18 seconds because it is a byte copy rather than a conversion.

Speed is bandwidth divided by model size, and I still got the prediction wrong

Multiply each model's weight bytes by its tokens per second and you get the last column: between 94 and 111 GB/s. The M4's memory bandwidth is 120 GB/s. Generation on this machine is not doing arithmetic, it is streaming weights, and the bigger the model the closer it gets to the ceiling: 80.6 percent for the 1B, 87.5 for 8B Q4, 92.5 for 8B Q8. Small models spend proportionally more time on everything that is not weight streaming.

Before the 3B model finished downloading I wrote down a prediction from that pattern: at 80 to 86 percent efficiency it should land between 47.5 and 51.1 tok/s. It measured 46.71, below the bottom of my range. The efficiency curve is not monotonic in the direction I assumed. The 3B lands at 78.6 percent, slightly worse than the 1B, not better. The rule of thumb is still useful for deciding whether a model is worth downloading, but treat it as plus or minus 10 percent, not as a spec.

Crossing the line does not crash anything

To find the edge I held the weights fixed at 8B Q8_0 and raised the context window, which grows the KV cache at a fixed cost per token.

num_ctx	ollama ps size	Processor split	Layers on GPU	Generation
4,096	8.6 GB	100% GPU	33 of 33	12.81 tok/s
16,384	10 GB	100% GPU	33 of 33	12.76 tok/s
32,768	13 GB	14%/86% CPU/GPU	30 of 33	11.58 tok/s
49,152	15 GB	27%/73% CPU/GPU	25 of 33	9.71 tok/s

The boundary sits between 10 GB and 13 GB, which is exactly the 11.3 GiB the scheduler reports as usable. What happens past it is the mild surprise. Nothing crashes. Ollama moves layers back to the CPU and keeps going, and because the memory is unified the penalty is modest: losing 8 of 33 layers to the CPU cost 24 percent of throughput, not the tenfold collapse that a discrete GPU spilling to PCIe would produce. It also quietly changes how it loads the file, logging disabling mmap for llama-server load by default with reason=metal_partial_offload, which is worth knowing if you have read the posts that recommend mmap tricks for oversized models.

It evicts rather than dies

The advice I kept running into for 16 GB machines is to force OLLAMA_MAX_LOADED_MODELS=1, because otherwise Ollama tries to hold two models at once and the system falls over. The default is 0, meaning automatic, and on this machine the claim did not reproduce. A 1.5 GB model and an 8.6 GB model stayed resident together, which is 10.1 GB and fits. Asking for a third produced this, and then served the request:

msg="llama-server model predicted to exceed available memory, evicting"
  predicted="8.5 GiB" predicted_num_ctx=4096 available="4.1 GiB"
  gpu_free="5.5 GiB" system_free="4.1 GiB" system_limited=true

Across seven model switches I saw no crash and no out-of-memory kill. The scheduler predicts the footprint and evicts to make room. But look at the last two fields, because they matter more than the eviction: system_free was 4.1 GiB and system_limited=true. The budget is not a fixed 11.84 GiB, it is bounded by what the rest of the machine is using right now. On this rig, which runs agents around the clock, Ollama saw 5.5 GiB of GPU headroom rather than 11.8 at that moment. A benchmark on an idle machine will not tell you what you get on a working one.

What I did not test

I wanted to run gpt-oss:20b, the model most often cited as the thing a 16 GB Mac can just barely handle. Its 13 GB download reported 2 hours 3 minutes at the 3.6 MB/s this connection gives ollama pull, so I cancelled it rather than spend the slot waiting. I will not claim a number I did not measure. What I can say is that 13 GB of weights is above the 11.3 GiB this machine makes available, so it would land in the orange rows above, and the one first-hand report I found agrees: a 16 GB owner on Hacker News wrote that gpt-oss-20b "eats too much ram to use for anything other than an overnight task. maybe 3tok/s." Two other 16 GB and 24 GB owners report settling at 8B Q4 as a daily driver and 7B as the practical ceiling, which matches where my measurements stop being comfortable.

If you are deciding whether this machine is enough

An 8B model at Q4 is the sweet spot here: 21 tok/s, 5.6 GB resident, room left for the system to breathe. Q8 of the same model runs at 13 tok/s and works fine, which is faster than most people expect. Long context is what actually costs you, not parameter count: the same 8B model went from comfortable to spilling purely by asking for 32K tokens of context. And if you were choosing between 16 GB and more memory, the thing to price is not the model you want to load but the context you want to give it, which is the same conclusion I reached when I compared 16 GB and 24 GB for agent work.

For background on the engine underneath these numbers, Ollama now runs llama.cpp's own server, which I verified when I put the same GGUF through both and again when I measured how it handles parallel requests. The per-token memory arithmetic behind the context table is in my Llama 3.1 8B measurements on this machine, the smaller end is covered in running a local LLM on a 16 GB Mac mini, and whether any of it beats paying an API is in local LLM versus cloud cost.

Every number here was measured on 2026-09-23 on the Mac mini this business runs on: Mac16,10, Apple M4, 16 GB, macOS 26.4.1, Ollama 0.34.2 installed via Homebrew, with iogpu.wired_limit_mb left at its default of 0. Generation figures are medians of five runs at temperature 0 with a fixed seed and 128 predicted tokens. I re-measured the whole ladder after downloads finished, because running a ollama pull in the background cost about 2 percent (8B Q4 read 20.92 tok/s during a download and 21.34 tok/s after). The 11.84 GiB figure comes from querying Metal directly and is cross-checked against Ollama's own startup log and its source. gpt-oss:20b was not tested and its behaviour here is inferred from the memory budget plus one community report, which I have labelled as such. Benchmark scripts and raw logs are kept in the repository under research/.