Kimi K3 vs GPT-5.6 Sol: What 2.8T Really Means

"2.8 trillion parameters" is the line every Kimi K3 writeup led with, and it comes straight off Moonshot AI's launch materials from the July 16 rollout. It's the number in the headlines, the number in the X threads, and the number people reach for when they line Kimi K3 up against OpenAI's GPT-5.6 Sol. It's also the number doing the least work of any figure in the comparison, once you ask what it counts.

This is a look at that one figure. Where it was produced, what it literally measures, what it quietly leaves out, and what happens to it the moment you try to run the model or pay for a token.

Where 2.8T came from: a launch card, dated July 16

The number is a vendor spec, not a measurement. Moonshot published it as part of Kimi K3's announcement around July 16-17, alongside a 1M-token context claim and a date for the open weights: July 27. There is no third-party harness behind the 2.8T. Nobody re-ran it. It's an architectural fact about how the model was built, disclosed by the people who built it.

Kimi K3 is a mixture-of-experts (MoE) model. That matters for reading the number correctly, because in an MoE the headline parameter count and the amount of the model that actually does work on any given token are two different quantities. The 2.8T describes the first one. Almost every practical question you have about the model depends on the second.

A launch-card spec is a fine thing to publish. The trouble is downstream, in how the figure gets used. It travels as if it were a performance result, a "K3 is bigger than everything" score, when all it records is the total size of the model's expert bank.

The whole expert bank, not the part that runs per token

In a dense model, parameter count is close to a useful proxy. Every parameter participates in every forward pass, so a bigger model is a slower, more expensive, generally more capable model, and the single number tracks all three at once.

MoE breaks that link on purpose. The model is split into many expert subnetworks, and a router sends each token to only a small handful of them. The 2.8T is the sum of all experts, most of which sit idle for any given token. The number that governs latency, throughput, and per-token cost is the active parameter count, the slice that fires each pass. That is a much smaller figure, and it is not the one Moonshot put on the card.

So "2.8 trillion parameters" is best read as a storage number. It tells you how large the weight files are and how much total capacity the model was trained to hold. It does not tell you how much compute a request burns, which is the thing that actually shows up on your bill and your latency graph.

Total parameters describe the model you download. Active parameters describe the model you run. Only one of them is on the launch card.

It says nothing about quality, and Sol gives you no number to hold it against

The 2.8T excludes the two things a comparison shopper most wants. First, it says nothing about how good the model is. Parameter count is not a benchmark. The launch-week claims about Kimi K3 that circulated on X, including strong frontend-coding results and high overall placements, are separate assertions, most of them vendor-run or informal at that stage. Independent indexes like Artificial Analysis take time to publish verified agentic and coding numbers, and a launch-day total-parameter figure is not a stand-in for them.

Second, it excludes the active-parameter count, which is the only version of the number that would let you reason about cost against a rival.

And here the comparison with GPT-5.6 Sol falls apart on its own terms. OpenAI publishes no parameter count for Sol. Not a total, not an active figure, nothing. Sol is a closed model sold as an API, priced per token, benchmarked on outputs. So "Kimi K3's 2.8T vs GPT-5.6 Sol" is not a like-for-like line at all. You are holding a disclosed architectural spec next to a blank. The only honest cross-model comparisons between these two are the ones built on things both vendors expose: published pricing, context windows, latency, and third-party eval scores once they land. Parameter count is not on that list, because one side never filled it in.

There's a third exclusion that gets overlooked. The 2.8T describes the model Moonshot trained. Whether the open weights released July 27 are byte-for-byte the same model served through the API, at the same precision, with the same routing, is a separate question the number does not answer. Open-weights launches have shipped quantized or slightly different checkpoints before. Until the weights are out and inspected, "2.8T" is a claim about the API model that the download may or may not reproduce.

Loading 2.8T of weights is a data-center problem before it's a coding one

Here is where your own budget rewrites the number. The headline that sells Kimi K3 is "open weights," and the implied promise is that you can run it yourself, free of a per-token meter. Do the arithmetic on 2.8 trillion parameters and that promise gets expensive fast.

At 8-bit precision, one byte per parameter, 2.8T parameters is roughly 2.8 terabytes of weights just to load, before any context or activation memory. Quantize hard to 4-bit and you are still near 1.4TB. An NVIDIA H100 carries 80GB. So even at aggressive 4-bit you are looking at something like eighteen H100-class GPUs to hold the weights alone, and that is a cluster, not a workstation. The MoE routing means each token only touches a few experts, which helps throughput, but it does not help this: to serve the model you still have to keep all of it resident in memory, because you don't know in advance which experts a token will need.

What that does to the comparison is concrete. For the large majority of readers, "open weights" on a 2.8T model does not mean "I can run this." It means "someone with a GPU cluster can run this, and I'll rent it from them." The moment you go through a hosted endpoint, the open-weights advantage over a closed model like Sol narrows to the things that actually differ at the API layer: price per token, rate limits, data control, and the freedom to move providers. Those are real advantages. They are just not the ones the 2.8T figure was implying.

If you are genuinely weighing the two for work, the numbers to pull are the ones that map to your workload. Token pricing on each side. Context window against how much you actually stuff into a prompt. Published coding and agentic scores from an index you trust, once verified numbers exist. Latency at your prompt sizes. The parameter count sits above all of those and decides none of them.

When 2.8T stops being the number

The figure turns out to be the wrong thing to quote the moment the active-parameter count is published and it lands as a small fraction of the total, because at that point every "K3 is 2.8T" headline was measuring the model's storage footprint while claiming to measure its power. And if the July 27 weights arrive at a different size or precision than the served model, even the storage reading was describing something you can't actually download.