What actually landed
Moonshot AI released Kimi K3 on July 16: a 2.8 trillion parameter mixture-of-experts model, 1 million token context, native vision, served through the Kimi app and API at $3 per million input tokens and $15 per million output. The weights are promised as an open release by July 27. As I write this, they are not out yet, so everything below the API surface is vendor documentation. I will keep the two separated, because the gap between confirmed and claimed is where most launch-week coverage goes wrong.
Confirmed by observation: the model serves real requests, it took the top spot on Arena's front-end coding leaderboard ahead of Claude Fable 5 and GPT-5.6 Sol (a real result on a narrow benchmark, not a general ranking), and its capacity is visibly insufficient. StatusGator logged a 5-hour-44-minute API outage from server overload on July 17, and Moonshot's own error documentation now lists weekday peak-hour overload as an expected condition to retry through. I tried the API in launch week and got nothing back. That was the normal case, not bad luck: OpenRouter currently routes every K3 request to Moonshot's own endpoint, so one company's cluster is absorbing worldwide demand for a claimed frontier model at mid-tier prices. No second provider can stand up capacity until the weights drop.
Vendor-claimed, plausible, unverifiable until the 27th: a hybrid attention design called Kimi Delta Attention, where a linear recurrence handles most of the sequence and sparse full-attention passes are inserted at intervals, with a claimed 6.3× decode speedup at million-token context. An MoE configuration of 896 experts with 16 active per token. The active parameter count being reported at ~50B is at least self-consistent with the expert arithmetic: 16/896 of 2.8T lands right around 50B. (It turned out to be 104B. See the corrections at the end — that arithmetic counts routed experts and nothing else.) And Moonshot's own benchmark table has K3 beating Claude Opus 4.8 and GPT-5.5 while trailing Fable 5 and GPT-5.6 Sol overall. Self-reported, but a lab that inflates does not publish its own second-place finish.
The prediction that came due
In May I wrote that native-quantized formats were becoming first-class citizens of model releases, and that the "download BF16, quantize it yourself with your favorite scheme" workflow was living on borrowed time for the largest models. Kimi K2.6 shipping an officially supported INT4 path was the signal then.
K3 finishes the argument. Moonshot describes quantization-aware training from the supervised fine-tuning stage onward, and the released checkpoint carries MXFP4 weights at group size 32, with attention kept in BF16. The 4-bit constraint was not applied to a finished model. From supervised fine-tuning onward, the model trained inside it.
Think about what that does to the post-release ecosystem. For every previous open model of this class, the release was BF16 and the community spent the following two weeks producing 4-bit conversions of wildly varying quality, racing to be first on the download charts. For K3 there is nothing to race for. A GPTQ or AWQ pass over weights that already survived 4-bit training adds nothing; the artifact everyone wants on day one is the one the vendor ships. The traditional quantizer's job, for this model, no longer exists at 4 bits.
I do not think this is a one-off. Training-time quantization at frontier scale is a cost decision as much as a deployment decision (the FLOPs and memory savings compound through every phase trained under the constraint, and the incentive is to push it earlier into the run), and once two major labs have shipped it, the rest will follow. The quantization work that matters is migrating from after the release to inside the training run, where third parties cannot reach it.
The arithmetic still bites
Born quantized does not mean small. 2.8T parameters at 4 bits plus block scales and a modest BF16 attention share is roughly 1.4 to 1.5 TB of weights. That is about 19 H100-80GB cards for weights alone, before KV cache and activations. Moonshot's recommended deployment is a supernode of 64 or more accelerators. Nobody self-hosts this on a workstation, and with 104B active parameters per token it is not cheap to run even where it fits. Expert sparsity rescues the FLOPs, not the resident memory.
What renting it would cost
Put prices on the hardware counts. On Nebius's published on-demand rates (July 2026: H100 at $3.85 per GPU-hour, H200 at $4.50), the two smallest Hopper configurations that fit the weights are 24 H100-80GB (1.92 TB across three NVLink nodes) at about $92 per hour, or 16 H200-141GB (2.26 TB across two nodes) at $72 per hour. Moonshot's 64-accelerator recommendation sits well above both; these are the floor the break-even is computed on, not a serving recipe. Round the clock, that is roughly $67,000 and $53,000 a month before any engineering time. Preemptible rates roughly halve it, but a multi-node serving cluster on preemptible capacity is not a production story.
Now compare against Moonshot's own API. At $15 per million output tokens, $72 per hour buys 4.8 million output tokens per hour, which means the 16-H200 cluster has to sustain about 1,300 output tokens per second of billable traffic, around the clock, just to match the API price. Below that utilization you are paying for idle silicon. And in week one nobody will hit it: the open checkpoint arrives with a brand-new attention mechanism and a 16-of-896 expert layout that no serving stack has optimized kernels for yet, so third-party serving efficiency starts well below Moonshot's own.
Which is the real reading of the $3/$15 pricing: it is set at a level third parties cannot beat until the serving stack matures. The budget single-node GPU clouds, the tier where an individual rents an A100 by the hour, are excluded outright; nothing in that catalog fits the model at all. Self-hosting K3 is a sovereignty decision or a high-utilization enterprise decision. It is not a cost saving.
Community estimates put a 2-bit-class build near 1 TB and an aggressive 1.8-bit build somewhere around 650 to 700 GB. Those are the sizes at which single-fat-node serving starts to be arguable, and that is exactly why sub-4-bit is where all remaining third-party quantization interest concentrates. Which brings us to the part I actually care about.
The trap waiting below 4 bits
Sub-4-bit quantization of K3 is open territory, and it is booby-trapped twice over.
First trap: the weights were already pushed onto a 4-bit grid during training. How much slack remains below that grid is an empirical question with no prior art at this scale. Quantizing a QAT model further is not the same problem as quantizing a BF16 model harder, and nobody knows yet whether the established sub-4-bit methods transfer.
Second trap, the one I keep writing about: calibration coverage on extreme MoE. With 896 experts and top-16 routing, a generic calibration set of a few hundred sequences leaves a large share of experts seeing almost no tokens. Calibration statistics gathered from near-zero traffic are noise, whatever the scheme fits with them. And the failure is silent in the worst way: aggregate benchmarks route around the starved experts and look fine, then some specific domain, a programming language, a natural language, a math style, collapses because its experts were quantized blind. The model degrades exactly where the evaluation is not looking.
Any serious sub-4-bit K3 artifact needs router-aware calibration with per-expert token-coverage accounting, and any serious evaluation of one needs to probe expert coverage directly rather than trusting headline scores. My prediction, on the record: the first wave of community sub-4-bit quants will do neither, and at least one widely downloaded artifact will ship with silently broken domains. Producing the artifact takes a day. Knowing it is good is the expensive part, and that asymmetry is precisely why the verification side is where the durable value sits. It is the same argument as my validation work: the number a buyer trusts cannot come from the party that benefits from it, and it especially cannot come from an artifact nobody probed.
The KV problem partially dissolves
One more architectural note, because it inverts the usual long-context story. Normally a 1M-context model makes KV cache the dominant serving concern, and KV quantization the highest-value compression target. K3's hybrid design caps that at the architecture level: the linear-attention layers carry a bounded recurrent state instead of a growing cache, and only the interleaved full-attention layers accumulate KV with sequence length. How much KV pressure remains depends on the layer ratio, which is unknown until the config is public. But the direction is clear, and it continues a pattern I flagged in May with DeepSeek-V4: the architecture teams are eating the KV compression problem before the quantization teams get to it. Every generation of hybrid attention shrinks the space where post-hoc KV quantization matters.
What I am checking on July 27
- The config, before anything else: the ratio of linear-attention to full-attention layers, the confirmed active parameter count, the released precision format, and the license.
- Whether Moonshot ships the MXFP4 artifact directly. If they do, third-party 4-bit work on this model is redundant on arrival.
- The first sub-4-bit community quants, and specifically whether any of them document expert calibration coverage. See the prediction above.
- Which providers are serving K3 by early August, and at what price relative to Moonshot's $3/$15. The spread between those numbers is the market's real estimate of what serving a 2.8T hybrid-attention model costs.
One wider observation to close. The launch-week market reaction (the Philadelphia Semiconductor Index briefly fell into bear-market territory on DeepSeek-flashback logic, then recovered most of it within days) got the direction backwards. A 2.8-trillion-parameter model that recommends 64-accelerator pods and cannot meet its own inference demand in week one is not evidence that the world needs less compute. It is evidence that open weights turn frontier capability into a capacity problem, and capacity problems are solved by buying hardware. The weights drop on the 27th. Then we find out how much of the documentation survives contact with the checkpoint.
Update 2026-07-28 — the checkpoint is out, and the answer to that last question is: mostly, but not entirely. Reading config.json on moonshotai/Kimi-K3 directly settles four things this piece left open. The layer ratio is 3 KDA to 1 MLA — 69 KDA to 24 Gated MLA across 93 layers — so full softmax retrieval happens in one layer out of four. That is the conservative end of the hybrid range, not the aggressive one: Jamba and MiniMax-01 run one in eight. The release is MXFP4 at group size 32, confirming the born-quantized call. The licence is bespoke rather than Apache or MIT, so open weights here means downloadable.
Update 2026-07-29, and this one retracts part of yesterday's. I wrote here that the “MXFP4 weights with MXFP8 activations” description was wrong and that the shipped artifact was weight-only. That retraction was itself the error, and I am withdrawing it. Moonshot's model card says plainly: MXFP4 weights with MXFP8 activations for broad hardware compatibility, via quantization-aware training from the SFT stage onward. The activation half is real.
The mistake is worth naming precisely, because it is a trap anyone reading these files can fall into. I saw input_activations: null in config.json and read it as refuting the activation claim. It does not. That field describes how the serving path quantizes at runtime; MXFP8 activations describes how the model was trained. Both are true at once, and I collapsed a training property into a runtime one. The check that would have caught it took thirty seconds: read the model card, one level above the config file I was working from. I did not, because the finding felt like a debunk, and a debunk is exactly when the bar should go up rather than down.
What survives from that update, verified against the same card: the release is mixed precision rather than uniformly 4-bit, with only the routed-expert Linears in MXFP4 and attention, shared experts, dense MLP, the LM head and the vision stack left in BF16. And kv_cache_scheme is null, so the KV path ships unquantized, which means sub-4-bit MLA-latent KV is still open territory rather than closed by the vendor.
Two further corrections to the figures above, both first-party from the same card. Activated parameters are 104B, not the ~50B this piece repeated from pre-release reporting. The ~50B figure counts routed experts only (16/896 of 2.8T) and omits shared experts, attention and projections, so anyone sizing a deployment from it under-provisions by roughly half. And the layer split is 69 KDA to 24 Gated MLA, not 69 to 23: the leading dense layer carries MLA too, so the ratio holds at one in four but the count was off by one. Performance numbers anywhere in this piece remain vendor-run, with no independent reproduction as of today.