BLUF
On my 32 GB Mac mini (Apple M2 Pro), qwen3-coder:30b — a Mixture-of-Experts model with roughly 3B active parameters — hit 41 tok/s generation speed, compared to 14.2 tok/s for qwen2.5-coder:14b and 6.9 tok/s for the dense qwen2.5-coder:32b. The MoE architecture is doing something very different from dense 32B here, and the raw numbers show it clearly.
Why I Ran This
I wanted a single, honest answer to a practical question: if you’re writing code locally on a 32 GB Mac mini and you care about how fast tokens appear on screen, which coding-oriented model should you load? I had three obvious candidates. I ran them all today on the same machine, same conditions.
Method
All tests run on my personal Mac mini (Apple M2 Pro, 32 GB unified memory), macOS, Ollama 0.32.1. I used a single fixed prompt, num_predict=256, temperature 0.3, thinking off, and recorded the warm average of 2 runs per model. Default quantizations were used as shipped by Ollama — I did not repack or requantize anything. Numbers reflect throughput only, not output quality. Limitations to keep in mind:
- Single fixed prompt — different prompts can shift numbers
- Only 2 warm runs averaged — not a large statistical sample
- Throughput is not quality; I did not evaluate code correctness here
- One machine, one day — your mileage may vary
Results
| Model | Load Time (s) | Generation (tok/s) | Prompt Eval (tok/s) |
|---|---|---|---|
| qwen3-coder:30b (MoE ~3B active) | 19.4 | 41.0 | 1829.1 |
| qwen2.5-coder:14b (dense 14B) | 10.0 | 14.2 | 1013.7 |
| qwen2.5-coder:32b (dense 32B) | 12.3 | 6.9 | 497.7 |
The MoE Angle
qwen3-coder:30b is a 30B Mixture-of-Experts model. Despite having 30 billion total parameters, only around 3B are active during any given forward pass — the router selects a small subset of experts per token. This is why the generation speed lands at 41 tok/s rather than somewhere near the dense 32B’s 6.9 tok/s. The memory footprint is larger than you might expect from a pure parameter count (it still needs to store all the experts), which is reflected in the longer load time of 19.4 s vs 10.0 s and 12.3 s for the dense models. But once it’s running, the active compute per token is much lighter.
The dense qwen2.5-coder:32b is the slowest of the three at 6.9 tok/s generation. That’s the expected cost of pushing every one of those 32 billion parameters through the forward pass for each token on Apple Silicon. The qwen2.5-coder:14b lands in the middle at 14.2 tok/s — it’s the lightest model and loads fastest at 10.0 s flat.
Prompt evaluation speed tells the same story in a different direction: qwen3-coder:30b processes the input prompt at 1829.1 tok/s, qwen2.5-coder:14b at 1013.7 tok/s, and qwen2.5-coder:32b at 497.7 tok/s. Prompt eval benefits heavily from batching, and the MoE’s lower active-parameter count compounds that advantage.
What This Means Practically
- If raw generation speed matters most for your interactive coding workflow on a 32 GB Mac, qwen3-coder:30b at 41 tok/s is the clear winner in this test.
- If you want the fastest load time and a simpler dense architecture, qwen2.5-coder:14b at 10.0 s load and 14.2 tok/s is the least friction to get started.
- The dense qwen2.5-coder:32b is the slowest to generate at 6.9 tok/s on this hardware — it fits in 32 GB unified memory, but only just, and you pay for it in speed.
- I have not evaluated output quality or code correctness here. Speed is one axis; capability is another, and these numbers say nothing about that.
Hardware & Software
Mac mini, Apple M2 Pro, 32 GB unified memory, macOS, Ollama 0.32.1. Default quantizations. All models pulled from Ollama’s library without modification.
Running your own coding model benchmarks on different Apple Silicon or other hardware? Drop your numbers in the comments — I’d genuinely like to see how other configs compare.
