Weights + KV cache taken from the real Unsloth GGUF files and Qwen3.6's config. Speed is an order-of-magnitude estimate, not a benchmark.
| Model / quant | Weights | KV | Total | Budget usage | ~tok/s | Verdict |
|---|
How to read this. The Total column is the hard constraint: weights + KV cache × slots + ~1.5 GB of buffers.
Go over budget and the model won't start — or macOS begins swapping and throughput collapses to nothing.
The ~tok/s column is the soft constraint: on Apple Silicon generation is memory-bandwidth-bound,
so what matters is how many bytes of weights get read per token — not how many GB the model occupies.
That's why a 35B MoE with 3B active parameters is ~4× faster than a dense 27B of the same file size.
KV cache computed, not estimated. Qwen3.6 is hybrid: only 1 layer in 4 does full attention
(full_attention_interval: 4), the rest are linear attention and accumulate no KV.
The 35B-A3B has 10 full layers of 40 with 2 KV heads → 20 KB/token. The dense 27B has 16 full layers of 64
with 4 KV heads → 64 KB/token. That's why the KV cache is small here and there's no reason to quantize it.
Reference bandwidth: M3 Pro ≈ 150 GB/s · M4 Pro ≈ 273 · M3/M4 Max ≈ 400–546 · M3 Ultra ≈ 819.
File sizes are exact byte counts from Unsloth's GGUF repos; tok/s estimates assume ~75% bandwidth
efficiency and should be read with a ±30% margin. Your browser can't report installed RAM — set that slider yourself.
Units. Every size here is binary (GiB), which is what About This Mac, ls -lh and
llama.cpp all report — a "36 GB" Mac really holds 36 GiB. Bandwidth is the one decimal figure,
because GB/s is how the memory bus is specced; mixing the two costs ~7%, so the tok/s column derives
separately from the same byte count.