Dense vs Mixture of Experts: Why a 1,000B Model Can Cost Like a 40B One
Kimi K2 has roughly 1,000 billion parameters, more than fourteen times the size of a 70 billion parameter model that already strains a single high-end GPU. Yet running Kimi K2 costs about as much per token as running a well-tuned 40 billion parameter dense model. That’s not a marketing trick. It’s the direct result of a design choice called mixture of experts, and understanding it explains one of the stranger trends in open models over the last year: total size going up while per-token cost barely moves.
What a parameter actually does at inference time
A parameter is one learned weight, a single adjustable number set during training. “70B” just means 70 billion of these weights. In a standard, dense model, every one of those weights gets used to compute every single token the model produces. There’s no shortcut: if the model has 70 billion parameters, all 70 billion take part in each forward pass. That’s why size and compute cost have historically moved in lockstep. Bigger model, more math per token, higher cost, simple as that.
Mixture of experts (MoE) breaks that link. Instead of one dense network, the model is split into many smaller specialized sub-networks, called experts, and a routing mechanism decides, token by token, which handful of experts actually needs to fire. The rest of the network sits idle for that token. Total parameter count still describes how much the model has learned and stored, but it no longer describes how much work happens per token. That’s now a separate number: active parameters.
Two numbers, not one
This is the part that trips people up when they see a headline parameter count. An MoE model has both a total parameter count (its overall capacity, everything the routing mechanism can draw on across all tokens) and an active parameter count (what’s actually switched on for any single token, which drives compute cost and speed).
DeepSeek V3 has 671 billion total parameters, but only about 37 billion are active per token. Kimi K2 pushes this further: around 1,000 billion parameters total, but only about 32 billion active per token, less than DeepSeek V3’s active count despite having roughly 50 percent more total parameters. In both cases, the number that determines how expensive and how fast the model is to run looks like a mid-sized dense model, not a frontier-scale one. The trillion-parameter figure describes what the model knows. The 32 billion figure describes what you’re paying for on any given request.
Why this broke an old assumption
For years, “bigger” and “more expensive to run” were the same statement. MoE separates them. It’s a bit like an enormous encyclopedia sitting on a shelf: answering one question means opening perhaps three pages out of thousands, and the rest of the volume just sits there, unconsulted, for that particular question. The encyclopedia can keep growing (more volumes, more entries, more total knowledge) without every question taking longer to answer, because each answer only ever touches a small, relevant slice of it.
That decoupling is exactly what triggered the race toward trillion-parameter open models through 2025 and into 2026. Labs realized they could keep expanding total capacity, and with it the range of knowledge and specialization a model could hold, without a matching jump in the cost of serving each token. Scale stopped being a straightforward tax on inference, which is a large part of why the size numbers in model announcements now need a second number sitting right next to them before they mean much of anything.
If you haven’t already, Parameters and Scale is worth reading first for what a parameter is and how parameter count relates to capability in general terms, before MoE complicates the picture. And since total and active parameter counts affect memory footprint very differently, the next piece in this series looks at what hardware it actually takes to run one of these models locally.