Kimi K3.1 Pro is a 2.8-trillion-parameter mixture of experts with 104 billion active parameters per token [INDEPENDENT — Artificial Analysis]. Moonshot calls it “3T-class” [VENDOR], which is a positioning phrase for the same model: 2.8T rounds into 3T, and the number that determines your latency, your throughput and your price is the smaller one. The OrcaRouter card for Kimi K3.1 carries both figures alongside the measured latency and the vendor’s rate, and the pairing explains a result that otherwise looks strange: a model three times larger than the previous generation’s small models runs faster than the flagship it replaces.
That sentence is worth unpacking, because parameter counts are the most quoted and least useful specification in this market.
Total versus active
A mixture-of-experts model stores many more parameters than it uses. Each token is routed through a small subset of the network — here, roughly one twenty-seventh of the total. The stored parameters determine what the model can know; the active ones determine what it costs to run one token.
| Kimi K3.1 Pro | Kimi K3 | |
| Total parameters | 2,800B | 2,800B |
| Active per token | 104B | 104B |
| Context | 1M | 1.05M |
| Our p50 latency, 7-day window | 6,752 ms | 4,680 ms |
| Our measured output speed | 52.4 tok/s | 28.8 tok/s |
| Input / output per 1M | $2.00 / $10.00 | $3.00 / $15.00 |
Same architecture, same active count, same stored weights — and the newer model is 1.8 times faster on output and a third cheaper, with 11.5 more index points [OURS, INDEPENDENT]. Nothing about the size changed. What changed was the post-training, the serving path and the price.
Why the active count is the number that matters
Three consequences, each observable.
Latency scales with active parameters, not total. Serving a 104B-active model requires the memory bandwidth for 2.8T of weights but the compute of 104B per token. That is why a 2.8T model can answer at 52 tokens per second on a shared API while a dense 400B model struggles at 20 — and why the earlier Kimi, running the same active count, could be slower: batching, load and routing differ enormously between providers, and the active count only sets the floor.
Price tracks the same number. Our rate is $2.00 and $10.00, roughly a fifth of what a 1T-class dense frontier model charges. The gap is not generosity; it is the arithmetic of activating a small fraction of the network per token.
**Knowledge tracks the *total*, which is why the two rows disagree.** Kimi K3.1 Pro is strong at reasoning and weak at recall: omniscience 29.52 against Opus 5.5’s 46.42 [INDEPENDENT]. A 2.8T model can store a lot; whether it retrieves well is a separate property, and this one’s post-training emphasised task completion over encyclopaedic recall.
What 104B active means for your deployment
Throughput per GPU is high, so the API is the right shape. Self-hosting 2.8T of weights requires many GPUs; running one token requires the compute of 104B. Providers can therefore serve many concurrent users cheaply, which is why the API price is where it is and why self-hosting rarely beats it.
Concurrency affects your latency more than your request size does. At a fixed active compute budget, the provider’s scheduler trades batch size against per-request speed. Our measured p50 moved from 6,546 ms to 7,426 ms over three days on a seven-day window [OURS] while the model itself did not change — a reminder that a latency number describes a fleet at a load, not a model.
Long context is cheap in compute and expensive in bandwidth. Reading a million tokens activates the same 104B per token; the cost is in moving tokens through the network, which is why input is billed at $2.00 and cached input at $0.20 rather than at a premium.
Memory is the other half of the arithmetic, and it is why the model is served from fleets rather than from laptops. The stored 2.8 trillion parameters have to be resident even though only 104 billion are used per token, so a provider’s fixed cost scales with the total while its variable cost scales with the active slice. That is the structural reason a model this size can be priced at $2.00 input: the expensive part is the building, not the query.
The “3T-class” label
Moonshot’s marketing uses 3T-class; the independent evaluator counts 2,800B and 104B active. Both can be true — 2.8T rounds into 3T — and the label matters only if you are comparing it against a claim that a competitor is “the largest open model”.
The correct framing for a size comparison: total parameters describe capability headroom and storage; active parameters describe serving economics; and neither describes quality. A 2.8T model with 104B active that scores 55 is a better buy than a 1T dense model scoring 53 at five times the price, and the parameter counts alone would not tell you that.
Where the size does show up
Two places, both worth knowing.
Cold starts and long generations. A model this large takes longer to load and to switch tasks; the first token of a session and the tail of a long answer both reflect that. Our p95 sits at the 10,000 ms cap on the window, which is a ceiling rather than a measurement [OURS] — but it tells you that one request in twenty is taking the maximum the routing layer will wait.
Fine-tuning cost. If the weights land on 4 November [VENDOR], adapting a 2.8T model is a serious infrastructure project; the LoRA-style approaches that make 30B models cheap do not shrink the base. For most teams, “open weights” means a wider choice of API vendors rather than a model on their own racks.
The one-paragraph summary
Kimi K3.1 Pro stores 2.8 trillion parameters and activates 104 billion per token. The first number is a capability statement and a hardware requirement; the second is why it is priced at $2/$10 and why it can run at 52 tokens per second. Its predecessor had exactly the same numbers and ran slower at a higher price, which is the clearest available evidence that post-training and serving — not scale — produced this release’s gains. It is also why smaller providers can serve this model credibly: the variable cost is the same for everyone, so competition lands on the fixed-cost side.
