Dense vs Sparse MoE Models: Which Is Cheaper to Run for Coding?

"27B dense" and "1T MoE with 48B active" describe two very different cost structures — even when they land at similar benchmark scores. Understanding the difference tells you which model is actually cheaper to run for your situation, on the API and on your own hardware.

Two architectures dominate today's coding models. A dense model activates every parameter for every token. A sparse Mixture-of-Experts (MoE) model has a large total parameter count but routes each token to a small subset of "expert" sub-networks, so only a fraction — the "active" parameters — fire per token. Qwen3.8-27B is dense; models like DeepSeek V4, GLM-5, and Kimi K3 are large MoEs with far fewer active parameters than total.

How Architecture Maps to Cost

Inference cost tracks active parameters and memory footprint, not headline size. That produces some counterintuitive economics:

• MoE: cheap compute, expensive memory. A 1T-total / 48B-active MoE only does ~48B worth of math per token — fast and cheap to compute. But all 1T parameters must be loaded into memory, so it needs a lot of VRAM (or a big multi-GPU host) even though each token is cheap.
• Dense: predictable compute, modest memory. A 27B dense model does 27B of math per token and needs ~27B worth of memory. Nothing is idle, but nothing is oversized either — which is exactly why a 27B dense model fits on a single consumer GPU while a 1T MoE does not.

On the API: You Pay for Active, Not Total

This is why a "1T-parameter" MoE can be priced cheaper per token than a much smaller dense model. The provider's per-token cost is driven by active parameters and throughput, so a sparse model with 48B active can undercut a 70B dense model on price. Don't let the total parameter count fool you — a huge MoE is often the cheaper API option, not the more expensive one. Judge by the posted per-token rate, which already bakes in the architecture.

On Your Own Hardware: The Story Flips

If you're self-hosting, memory footprint is the binding constraint, and dense wins for accessibility. A 27B dense model at 4-bit quant fits in ~17GB and runs on a 24GB consumer GPU. A 1T MoE, even at 48B active, still has to fit 1T parameters in memory — that's a multi-GPU server, not a laptop. So:

• Want to run locally on consumer hardware? A right-sized dense model is almost always the practical choice.
• Running at data-center scale? A big MoE gives you frontier quality at low per-token compute — its memory hunger is amortized across many concurrent requests.

Speed and Batching

MoE models are often faster per token because of the smaller active compute, which is why many high-throughput "fast" tiers are sparse. But their routing makes efficient batching more complex, and single-request latency on a lightly loaded host can be uneven. Dense models are simpler to serve predictably. For an interactive coding agent where consistent latency matters, that predictability has value; for bulk throughput, MoE's lower compute usually wins.

The Practical Takeaway

Don't shop by parameter count — shop by the number that matches your deployment. On the API, compare posted per-token rates and ignore total size; a giant MoE may be the budget option. For local deployment, compare memory footprint; a dense model sized to your GPU is what actually runs. The architecture label is a hint about which lever — compute or memory — dominates your cost.

Compare real per-token rates across dense and MoE coding models in our AI Cost Calculator.