Will this model fit on my machine?
A 9B model at 4-bit is a 5 GB download, and a 16 GB laptop has 16 GB, so it fits. Then you give it a long document and it stops. What fits is not the file; it is the file plus the memory for every token of context you allow, inside the share of the machine the GPU is actually permitted to use. Pick yours.
It fits. 5.5 GB free after 8K of context, and the context could grow to about 171K tokens before it does not.
The weights are the fixed cost. A model’s parameter count times the bits per weight is the download, and it is the part everyone checks. Quantisation is what makes home inference possible at all: at 4-bit a weight takes a little over half a byte, so a 9B model that needs 18 GB as trained needs 5.5 GB, and the difference in what it writes is small enough that Q4_K_M is the default download for a reason. Below that the loss becomes visible on small models; above Q6 nobody can tell.
The context is the variable cost, and it is the one that gets you. Every token the model has read is kept as a key and a value in every attention layer, the KV cache, and that memory scales with the context length you allow, not the length you use. A dense 8B model keeps 128 KiB per token, so 32K of context is 4 GB, most of the room a 16 GB Mac has left after the weights. Newer architectures cut this hard: Qwen3.5 keeps a growing cache on only one layer in four and a fixed-size state on the rest, so it holds 32 KiB per token, a quarter of the dense figure at the same size. That is why the 9B fit the measured laptop with a long context and an older 8B would not have.
A Mac does not give the GPU the whole box. macOS caps the memory Metal may pin, at 12.7 GB of 16 on the measured machine, and buffers, activations and the engine itself come out of that before any weights do. So a 16 GB Mac is an 11 GB machine for this purpose. The 9B Q4 fit it, and left the rest of the computer 825 MB, which is what the warning above means: it runs, and everything else swaps. Shipping models are sized in whole gigabytes; the number to plan around is the one after the cap and the reserve.
What this model leaves out
Prefill working memory. Reading a long prompt needs scratch space that scales with its length, over and above the cache that stays afterwards. On the measured machine a 16K prompt on Qwen3.5 4B raised peak memory by 1.7 GB, four times what the cache alone accounts for. If you plan to feed long documents, leave that much more than the bar shows.
Prefill speed. The decode estimate is a memory-bandwidth argument and it is a reasonable one; time to first token is a compute argument that depends on the GPU’s arithmetic rate and the engine’s kernels, and a 4K prompt took 16 seconds on the measured Air. The page does not estimate it.
The engine. The decode figure is a ceiling at 80% of quoted bandwidth, which MLX reached on the measured machine and which the estimate overshoots by 13% (35.6 estimated, 31.4 measured). llama.cpp got 17 tokens per second on the same model and machine, a little over half. Which engine, and why, is the next page.
Read next
- at-home/
- MLX or llama.cpp on a Mac?
MLX decodes 1.8 times faster here, and two defaults matter more than the engine.
- Can a laptop do real inference experiments?
Yes, if every comparison is paired, and no, for anything smaller than the noise.
- explainers/
- The KV cache is the thing you are actually renting
The same arithmetic on a datacenter card, where the cache is what caps how many users a GPU serves.
- Two phases, two bottlenecks
Why decode is bandwidth divided by bytes, which is the whole decode estimate above.
- feed/