Kimi K3: 2.8 Trillion Parameters, 1.56 TB, and a License That Changed Sides
On June 13th I wrote on these pages that the Modified MIT license of K2.7-Code was “a license your lawyers can live with”. Six weeks later that statement needs an asterisk, and the asterisk is the news.
Moonshot AI published the weights of Kimi K3 on July 27th, keeping the promise it had made on the 16th. The weights are on Hugging Face: 1.56 TB spread across 118 files. That part came out exactly as announced. What didn’t come out as announced is the paperwork that comes attached.
What Was Actually Published
K3 is a Mixture-of-Experts model with 2.8 trillion total parameters and 104 billion active per token. The architecture is 93 layers—69 of Kimi Delta Attention, 24 of Gated MLA, one dense—across 896 experts, of which 16 are selected per token plus 2 shared. The context window is 1,048,576 tokens.
The number I’d flag first isn’t the parameter count. It’s the quantization. The weights are native MXFP4 with MXFP8 activations, and Moonshot indicates that comes from quantization-aware training applied from the SFT stage onward—not from a post-hoc compression pass over a bf16 checkpoint before uploading. The distinction matters, because it means the MXFP4 artifact is the model Moonshot trained and runs, not a degraded copy for convenience. You’re receiving the same numerical format the vendor uses internally.
The practical consequence is a resident footprint of approximately 1.4 TB, at half a byte per parameter, before the KV cache and activation buffers. vLLM, SGLang, and TokenSpeed handle it. This is multi-node deployment, not a workstation. Self-hosteable is a true statement here, but it’s a statement with a hardware bill attached.
The License Is the News
Moonshot didn’t renew the Modified MIT. K3 comes under a document titled, plainly, “Kimi K3 License”. The operative clause says:
the Licensee must enter into a separate agreement with Moonshot AI
That obligation activates when the licensee or its affiliates operate a Model as a Service business—defined in the license as providing third parties access to inference or fine-tuning of language models, for example via API, with significant control over inputs, parameters, or training data—whose combined revenue exceeds twenty million dollars in any consecutive twelve-month period. The agreement has to be signed before commercial use, not after crossing the threshold. The branding requirement from the K2 era survives in parallel: above 100 million monthly active users or twenty million dollars of monthly revenue, “Kimi K3” has to be displayed prominently in the interface.
There are two exemptions, and they’re the reason this clause is narrower than the headlines suggest. Internal use is exempt. So is access through Moonshot’s own products or its certified inference partners.
Credit to Moonshot on one point: in no official material does it call this open source. The model card says “Open Frontier Weights”. The company is describing with precision what it published, which is more than can be said for a good number of releases this year.
What This Changes for a CTO in Latin America
If you’re evaluating K3 for data sovereignty—weights on your own infrastructure, zero inference leaving your perimeter, compliance approving—the MaaS clause doesn’t touch you. Internal deployment is exempt, period. Your decision is a hardware decision: can you stand up and maintain a cluster that sustains 1.4 TB resident plus cache, and does that come cheaper over three years than paying for an API?
The math on that second half is easy to check, because K3 is already on OpenRouter with seven providers, all at three dollars per million input tokens and fifteen per million output—the same rates Moonshot charges directly. Uniform pricing across seven providers tells you the ceiling is set by the license, not the market. That’s your baseline. Self-hosting has to beat it.
The clause bites in another place entirely: if you’re building a product that resells inference. A regional AI platform, a vertical SaaS with a fine-tuning API, a managed inference shop—that falls into MaaS territory, and at twenty million annual revenue it needs an agreement signed with a company in Beijing to keep operating. Twenty million isn’t a hyperscaler number. It’s a successful regional business.
So the real calculation isn’t “hardware versus API” anymore. It’s hardware, plus API, plus a question about what your company will be doing in three years. If the answer is “running models for ourselves”, K3 is as open as you need it to be. If the answer is “selling access to models”, you’ve acquired a dependency that no benchmark score can afford.
The Pattern Worth Watching
K2.7-Code was permissive because Moonshot was buying mindshare. K3 is revenue-tiered because Moonshot now has a business to protect. None of that is scandalous—it’s what a company does when its model is good enough that people will pay for it. But it does mean that “open weight” stopped being a stable category you can plan around. Now it’s a per-release attribute, and you have to reread it every time.
The version of the sovereignty argument I’ve already made before still holds: weights you can deploy beat an API you can only call. K3 doesn’t reverse it. It adds a clause. Read the license before the leaderboard—this release is the clearest evidence so far that the license moves faster than the benchmark.
Technical Box
| Total / active | 2.8 trillion / 104 billion per token |
| Experts | 896 (16 active + 2 shared) |
| Layers | 93 — 69 KDA, 24 Gated MLA, 1 dense |
| Context | 1,048,576 tokens |
| Format | MXFP4 weights / MXFP8 activations, QAT from SFT |
| Download | 1.56 TB, 118 files |
| Resident | ~1.4 TB + KV cache + buffers |
| Engines | vLLM, SGLang, TokenSpeed |
| API | $3/M input · $15/M output (7 providers on OpenRouter) |
Are you evaluating K3 for internal deployment, or does the product you’re building fall on the MaaS side of the clause? Tell us how you’re reading it.