BLUF
On my 32 GB Mac mini (Apple M2 Pro), qwen3-coder:30b — a 30B Mixture-of-Experts model with roughly 3B active parameters — hit 43.3 tok/s generation speed, well ahead of the dense qwen2.5-coder:32b at 6.6 tok/s and qwen2.5-coder:14b at 15.1 tok/s. If raw generation throughput is your priority on constrained hardware, the MoE architecture makes a noticeable practical difference.
Why I Ran This
I use my Mac mini as a daily coding assistant backend. When Qwen3-Coder dropped with its MoE design, I wanted to know whether the “only ~3B parameters are active at inference” claim actually translates to faster tokens-per-second in Ollama — not in theory, but measured on my own machine with my own hands.
Models Tested
- qwen3-coder:30b — 30B total parameters, MoE architecture, ~3B active at inference time (default Ollama quantization)
- qwen2.5-coder:32b — dense 32B model (default Ollama quantization)
- qwen2.5-coder:14b — dense 14B model (default Ollama quantization)
Results
| Model | Load Time (s) | Generation Speed (tok/s) | Prompt Eval Speed (tok/s) |
|---|---|---|---|
| qwen3-coder:30b (MoE ~3B active) | 15.2 | 43.3 | 2038.3 |
| qwen2.5-coder:14b (dense 14B) | 48.7 | 15.1 | 1077.2 |
| qwen2.5-coder:32b (dense 32B) | 11.9 | 6.6 | 490.3 |
The MoE vs. Dense Angle
The headline story here is architectural. qwen3-coder:30b is a Mixture-of-Experts model: it has 30B total parameters on disk, but at any given token, only roughly 3B of those parameters are actually activated. That means the memory bandwidth the chip has to exercise per generated token is closer to a small model’s workload, even though the model file is large.
The numbers back this up. qwen3-coder:30b delivered 43.3 tok/s generation while the dense qwen2.5-coder:32b — a model of similar total size — came in at 6.6 tok/s. Even qwen2.5-coder:14b, which is substantially smaller in total parameter count, only reached 15.1 tok/s. The MoE design is doing real work here in throughput terms.
Prompt evaluation speed tells a similar story: qwen3-coder:30b processed prompts at 2038.3 tok/s versus 1077.2 tok/s for qwen2.5-coder:14b and 490.3 tok/s for qwen2.5-coder:32b.
One interesting outlier: qwen2.5-coder:14b had the slowest load time at 48.7 s, compared to 15.2 s for qwen3-coder:30b and 11.9 s for qwen2.5-coder:32b. I don’t have a solid explanation for that — possibly a quantization or memory-mapping quirk — and I’d want to see it reproduced before drawing conclusions.
Method and Honest Limitations
- Hardware: Mac mini, Apple M2 Pro, 32 GB unified memory, macOS, Ollama 0.32.1
- Prompt: Single fixed coding prompt across all models
- Settings: num_predict=256, temperature=0.3, thinking off, default quantizations from Ollama library
- Averaging: Warm average of 2 runs (first cold run discarded)
- What this measures: Throughput only — tokens per second. It says nothing about code quality, correctness, instruction following, or context length handling.
- Single machine, single prompt: Results may vary with different prompts, longer contexts, or different hardware. MoE routing behavior can shift depending on prompt content.
- Not tested: Quality benchmarks, multi-turn coding tasks, fill-in-the-middle accuracy, or any agentic workflows.
My Takeaway
If you’re running a coding assistant on a 32 GB Apple Silicon machine and throughput matters to you — especially for long completions or agentic loops where the model generates a lot of tokens — qwen3-coder:30b’s MoE architecture produces a real, measured advantage in tok/s over both dense alternatives I tested. Whether the code quality justifies swapping your current model is a separate question I haven’t answered here.
I’ll be running quality evals next. But for now, the speed numbers are what they are.
Running your own coder model benchmarks on Apple Silicon or another platform? Drop your tok/s numbers in the comments — I’d like to see how other setups compare.
