The MoE shift: why every new local model is a Mixture-of-Experts

Sometime in the last eighteen months, the models we actually run locally stopped being dense. Qwen3-Coder-30B-A3B is MoE. LFM2.5-8B-A1B is MoE. The frontier open-weights names — GLM-5.2, Kimi K2.7 — are MoE. If you're picking a local model in 2026, you are almost certainly picking a Mixture-of-Experts, whether you know it or not.

So it's worth understanding what that actually means — because the two numbers on the tin ("total parameters" and "active parameters") are doing very different things, and only one of them decides whether the model fits on your card.

The one-paragraph explainer

A dense model activates every parameter on every token. A Mixture-of-Experts model has the same total parameter budget but a router that picks a small subset of "experts" (sub-networks) to activate per token. The number that determines speed and VRAM cost per token is the active parameter count, not the total. The total determines quality ceiling and disk footprint; the active determines tok/s and per-token compute.

That's the whole shift. Everything else follows from it.

Why this is the thing that made local viable

In 2024, "a 30B model" meant 30B dense — 30B parameters computed per token, ~60GB at FP16, ~18GB even at Q4. That fit on a 24GB card barely, and was slow.

In 2026, "a 30B model" probably means 30B total / 3B active. The quality comes from the full 30B parameter space; the cost per token comes from the 3B that actually fires. You get "30B-class quality" at "3B-class speed and VRAM." That is the entire reason a model like Qwen3-Coder-30B-A3B is the default recommendation on a $300 card. A dense 30B at the same quality would not fit there.

This is also why the landscape is full of names like "8B-A1B" and "30B-A3B" — the suffix is the active count, and it's the number that matters for your hardware.

The measured 2.5×, on our hardware

We can show this with our own data rather than ask you to take it on faith. In bm-007 and bm-008, we ran two 8B-class models on two GPUs:

• Llama-3.1-8B-Instruct — dense, ~8.03B active params
• LFM2.5-8B-A1B — MoE, ~1.7B active params

Same parameter class (8B total). Same byte-identical artifacts, sha256-verified. Same llama-bench flags. Generation speed:

	Arc B60 (Vulkan)	RX 7900 XT (ROCm)
Llama-3.1-8B (dense)	27.01 tok/s	105.22 tok/s
LFM2.5-8B (MoE)	68.79 tok/s	269.01 tok/s
MoE / dense	2.55×	2.56×

Read down the columns: MoE is roughly 2.5× faster than dense at the 8B class — and that ratio holds across both GPUs (2.55× on Arc, 2.56× on the Radeon). That consistency is what tells you it's the architecture doing the work, not a card-specific quirk. Fewer parameters firing per token → less compute per token → more tokens per second. Mechanical.

(The full 2×2 — including the GPU-vs-GPU read — is in Arc B60 vs RX 7900 XT. The point of this piece is the rows; the point of that one is the columns.)

The trade you're making

MoE is not free. You're trading per-token compute for two real costs:

• Total parameter footprint on disk and in VRAM. A 30B-A3B model still loads ~30B of parameters into memory; only ~3B compute per token. So your VRAM budget has to hold the full 30B (minus whatever the runtime can swap). This is why a 30B-A3B at Q4 still eats ~18GB even though it runs fast.
• Per-token quality. Each token only sees a subset of the model's parameters. On most benchmarks the gap is small; on the hardest reasoning, dense still has an edge at equal active params. The honest read: MoE buys you speed and VRAM efficiency at a modest quality cost per token, and most workloads come out ahead.

If you want maximum quality on hard reasoning and you have the VRAM, dense at the same active size is still the answer. If you want speed and fit, MoE wins. Almost every local workload in 2026 is the second case, which is why the carousel moved.

What this means for picking a model

Three practical rules the MoE shift implies:

1. Read the suffix, not the headline number. "30B-A3B" tells you it'll run like a 3B and fit like a 30B. A plain "30B" (dense) is a different hardware proposition entirely.
2. **Compare models at equal active params for speed, equal total params for quality.** A 30B-A3B and an 8B dense are not the same comparison either way; don't let a chart mash them together.
3. When a benchmark doesn't say whether the model is MoE or dense, the number is suspect. A lot of "model X is 2× faster than model Y" claims out there are just "MoE vs dense" in disguise, with the architecture variable hidden. Our own 2×2 methodology exists precisely to stop that.

The caveat we owe you

The 2.5× figure is measured at the 8B class, single-stream, short context, in llama-bench. Two models isn't every model, and the ratio will shift at other sizes (MoE routing overhead matters more at very small total sizes) and at long context (KV cache behaves differently). We're reporting what we measured on our fleet, not a universal constant. The direction — MoE meaningfully faster than dense at equal total class — is robust. The exact multiplier is workload-dependent.

The takeaway

The MoE shift is the single biggest architectural thing that happened to local AI between 2024 and 2026. It's why a $300 card runs a model that would have needed a $1,500 card two years ago, and it's why every release worth paying attention to is MoE now. Once you internalize that "total params = quality and disk, active params = speed and per-token compute," the model carousel stops being confusing and starts being legible. Pick the active size that gives you the tok/s you need, pick the total size that gives you the quality you need, and check that it fits before you download.

The data behind the 2.5× is in bm-007 and bm-008. For the broader landscape of which MoE models are worth running this month, start with the July 2026 roundup.