Kimi K3 Weights Just Landed, and They Are 4-Bit Only

Moonshot AI pushed the Kimi K3 weights to huggingface.co/moonshotai/Kimi-K3 at 13:31 UTC this afternoon, a few hours before its own July 27 deadline ran out. The repository is 96 safetensors shards, 1,560,998,983,759 bytes, roughly 1.56 TB. What nobody flagged in the first wave of coverage is the part that actually changes how you use this model: every routed expert in the file is 4-bit, and there is no full-precision version of K3 anywhere. Not held back, not coming later. MXFP4 is the precision K3 was trained in from the supervised fine-tuning stage onward, so the compressed checkpoint is the model, not a convenience copy of it.

• 96 shards, 1.56 TB on disk (about 1,454 GiB of accelerator memory), largest shard 17.0 GB.
• Format is mxfp4-pack-quantized, 4 bits, group size 32, symmetric, via compressed-tensors. quantization_status reads compressed.
• No base checkpoint. Only the instruct-tuned multimodal model was published. There is no Kimi-K3-Base repo to fine-tune from.
• The license is not Apache 2.0, despite several write-ups saying so. It is a bespoke "Kimi K3 License" with two commercial trip-wires.

What is actually inside the repo?

The config.json is more informative than the model card. K3 is 2.8 trillion total parameters with 104 billion activated per token, routing through 16 of 896 experts plus 2 shared experts. It stacks 93 layers, of which 69 use Kimi Delta Attention and 24 use gated MLA, with a 1,048,576-token position limit and a 163,840-token vocabulary. A vision tower sits alongside the language stack, so this is natively multimodal rather than a text model with an adapter bolted on.

RelatedKimi K3's Weights Are Due Today. Can You Run Them?

The quantization block is where the release gets interesting. It carries an ignore list, and that list is long: attention projections, the two shared experts, the dense MLP in layer one, the LM head, the vision tower and the multimodal projector all stay at bfloat16. Only the routed expert Linear layers were compressed. Since those experts are where nearly all of the 2.8 trillion parameters live, compressing them alone accounts for almost the entire size reduction, and the handful of bf16 components explain why the download came in heavier than a clean 4-bit calculation predicts.

Why 1.56 TB instead of the 1.4 TB everyone predicted?

We ran that arithmetic this morning, before the file existed: 2.8T parameters at four bits is about 1.4 TB, at bf16 about 5.6 TB. The shipped repo is 1.56 TB, roughly 11 percent above the pure 4-bit floor. The ignore list is the whole explanation. Two shared experts run on every token, so they were left at full precision. Attention, the LM head and the vision tower are small in parameter count but disproportionately sensitive to rounding, and they were left alone too. Add the per-group scale factors that MXFP4 needs at group size 32, and the overhead lands about where you would expect.

Read in GiB rather than terabytes, the number matters more than it looks. 1.56 TB is 1,454 GiB. A single node of eight 192GB accelerators holds 1,536 GiB. K3 fits on one machine, with roughly 82 GiB to spare.

Can a single node really serve it?

Weights are the floor, not the bill. The 82 GiB left on a full node has to cover the KV cache and activations. Here the architecture pays off: only 24 of the 93 layers use conventional attention, and those use MLA with a 512-dimension latent, so cached state runs on the order of 27 KB per token rather than the hundreds of kilobytes a dense-attention stack this deep would demand. A full 1,048,576-token context therefore costs roughly 27 GiB. The 69 Kimi Delta Attention layers carry a fixed-size recurrent state that does not grow with sequence length at all.

That leaves something like 55 GiB for activations and concurrent requests, which is workable for one long-context stream and thin for a busy endpoint. Moonshot lists vLLM, SGLang and TokenSpeed recipes. Nobody is running this on a workstation, but "one rack-mounted node" is a materially different claim from where the open-weight ceiling sat a week ago.

How open is the Kimi K3 license?

Several outlets have already called it Apache 2.0. It is not. The LICENSE file is a permissive MIT-shaped grant with two added conditions. If you run a model-as-a-service business and your group revenue passes 20 million dollars over any rolling 12 months, you must sign a separate agreement with Moonshot before any commercial use. And if a product built on K3 clears 100 million monthly active users or 20 million dollars in monthly revenue, "Kimi K3" has to appear prominently in that product's interface. Internal use is exempt from both. This is close to the Llama-style threshold pattern, and for the overwhelming majority of teams neither clause bites, but it is not OSI-approved and calling it Apache 2.0 is wrong.

RelatedAnthropic Ships Claude Opus 5 at Half of Fable 5’s Price

What the benchmarks claim

Those are Moonshot's own numbers on Moonshot's own harnesses, so treat them as claims. The independent read we track is vals.ai, which runs every model itself on one neutral bash-only harness and puts K3 at 93.4 percent on SWE-bench Verified, fourth on our AI coding leaderboard. That figure has not moved with this release, and it is the number worth quoting. Artificial Analysis separately measured Terminal-Bench 2.1 at 85.0 percent against the 88.3 percent claimed above, which is the usual size of the vendor gap.

1. Jun 13, 2026Empty moonshotai/Kimi-K3 repo appears on Hugging Face placeholder, no files
2. Jul 16, 2026K3 launches as an API model, weights promised by Jul 27 2.8T params, 1M context
3. Jul 18, 2026vals.ai independently scores it 93.4% on SWE-bench Verified fourth overall
4. Jul 27, 13:31 UTC96 shards land, 4-bit only, deadline met 1.56 TB

Our take

The interesting thing here is not that Moonshot hit its date. It is that the company shipped a checkpoint it clearly never intended to publish at full precision, and that this appears to be deliberate rather than a concession. Training in MXFP4 from the SFT stage forward and then releasing exactly that artifact is a coherent position: the weights you download are the weights they evaluated, with no lossy step in between. It also quietly removes the option most of the open-weight ecosystem has relied on, which is taking a full-precision base and building something else on top of it.

For anyone deciding whether to self-host, the practical answer changed today and it changed in a good direction. A 2.8 trillion parameter frontier-class model that fits on one eight-card node with room for a million-token context is a different proposition from one that needs a cluster. For anyone hoping to fine-tune it, the answer is worse than it looked yesterday.

Original analysis by GenZTech. Repository byte counts, shard counts and quantization settings were read directly from the Hugging Face API and config.json at 15:55 UTC on July 27, 2026.