A mixture of experts model splits its feed-forward layers into many separate "experts" and uses a small router to pick which two or three handle each token. The other experts sit idle. A model with a trillion total parameters might activate only thirty billion of them for any given word.
The payoff is decoupling size from cost. A dense model uses all its parameters on every token, so making it bigger makes every request proportionally more expensive. An MoE model can hold far more knowledge while keeping the per-token compute roughly flat — which is why most frontier releases are now MoE, and why open-weight models like Kimi K3 can post enormous parameter counts and still be practical to serve.
Why it matters at your desk. Mostly it explains pricing that otherwise looks inconsistent. Headline parameter counts stopped predicting cost once MoE became standard, so a "bigger" model is not reliably a more expensive one. It also explains why hardware is being redesigned around serving patterns rather than raw training throughput — Google's Gemini-specific Frozen v2 chip is aimed at exactly that.
If you self-host, the catch is memory. Every expert must be resident even though only a few run per token, so an MoE model's VRAM requirement tracks its total size while its speed tracks the active portion. Cheap to compute, expensive to hold.
What to watch for: MoE is an efficiency architecture, not a capability one. It shapes what a model costs to serve, not whether it is good at your task.