Kimi K3 Is a Free Download. The Smallest Machine That Runs It Is Eight B300s.

Moonshot published the full 2.8-trillion-parameter Kimi K3 weights on July 26. The download is 1.56TB, and vLLM's documented floor for serving it is a single node of eight B300s.

The software gate is gone. Moonshot upstreamed its custom attention kernel ahead of launch, so vLLM and SGLang both had day-zero support. The hardware bill and the license are what stop you now.

Seven providers were serving K3 on OpenRouter at $3 per million input tokens on day one. For nearly every team, renting is the answer, and the sovereignty argument for open weights only pays out if you own the metal.

The number that matters is not 2.8 trillion

K3 is a mixture-of-experts model with 896 experts, 16 of which activate per token, giving 104 billion active parameters against a 2.8 trillion total. It takes 1 million tokens of context and handles text, images, and video natively. On Moonshot's published card it posts 93.5 on GPQA Diamond, 88.3 on Terminal-Bench 2.1, and 91.2 on BrowseComp, and it took first place in a frontend coding arena. This is a frontier model by any reading, and the weights are sitting on Hugging Face right now.

The number that decides whether you can use those weights is 1.56TB.

Moonshot trained K3 with quantization awareness from the supervised fine-tuning stage onward, MXFP4 weights and MXFP8 activations, so the four-bit release is not a lossy afterthought someone bolted on later. That is the compressed version. The 16-bit weights would run about 5.6TB. There is no smaller build coming, because this already is the small build.

All of that memory has to be resident before the first KV cache entry gets allocated. A 1-million-token context window is not free either.

Moonshot did the hard part, and it was the software

Credit where it is due, because this is the part that usually goes badly and this time did not.

K3 ships two pieces of custom architecture: Kimi Delta Attention, and a sparse MoE routing layer Moonshot calls Stable LatentMoE. Custom architecture normally means a three-week gap between the weights landing and any production server being able to load them, while maintainers reverse-engineer kernels from a paper.

Moonshot skipped that. It contributed the KDA implementation to vLLM upstream, with prefill caching, and vLLM published a production-scale preview on July 22, four days before the weights appeared. Day-zero serving landed in both vLLM and SGLang. The KDA backend runs FlashKDA for prefill and a fused CUDA kernel for decode. There is a working speculative decoding config, DSpark, that takes single-user decode from roughly 111 to 118 tokens per second up to 331 to 370 on a GB300 NVL72, accepting about 4.73 tokens per step on coding work.

Two years ago the gap between a Chinese lab's weight drop and usable inference was measured in weeks of community effort. Here it was negative four days. That is the genuinely new thing this week, and it got almost no coverage next to the parameter count.

The hardware gate went the other direction

vLLM's own guidance is blunt: at least one 8x B300 node, or a GB300 NVL72, with 16x B200 also supported. Moonshot's recommendation for production is a supernode of 64 or more accelerators. Moonshot has not published a minimum GPU count, a validated GPU list, or a required interconnect, which tells you something about who it expects to be running this.

Compare that against what self-hosting a Chinese coding model meant one generation ago. When Moonshot shipped K2.6, the setup guide I wrote ran it on a single H100 80GB, with two RTX 4090s and NVLink as the budget path. Ubuntu, CUDA, Docker, done in an afternoon. That was a real option for a mid-sized team with one server.

Eight B300s is not that. It is a capital purchase with a lead time, or a reserved cloud commitment, and it is the floor rather than the target. You are also taking on RDMA or NVLink between nodes once you go multi-node with expert and data parallelism.

So the frontier of open weights moved past the hardware most engineering teams have, in about nine months. Both things can be true at once: open weights are more capable than ever, and fewer people can actually host them than could last year.

The license is not open source

This is the part that gets skipped, and it is the part your legal team will find later.

K3 does not ship under the modified MIT license Moonshot used for K2. It ships under a bespoke document called the Kimi K3 License. It permits download, self-hosting, fine-tuning, and quantization, and then attaches two conditions.

If you operate a Model-as-a-Service business with group revenue above $20 million over any consecutive 12 months, you need a separate commercial agreement with Moonshot before you deploy. If your product passes 100 million monthly active users or $20 million in monthly revenue, you must display Kimi K3 prominently in your user interface.

Neither condition is unreasonable, and neither is open source. "Open weight" and "open source" have been drifting apart for two years, and K3 is where the distance becomes concrete enough to matter in a procurement review. If you are a startup at a few million in revenue, you are clear. If you are a platform reselling inference, you have a contract to sign, and it is worth finding that out before you have built on it.

What to do with this

For nearly everyone, the answer is that you rent K3 and stop thinking about it. Seven providers were live on OpenRouter on day one at roughly $3 per million input and $15 per million output. Set that next to Claude Opus 5, which landed on July 24 at $5 and $25, and K3 is a genuine price-performance option that costs you a config change to try.

If you were considering self-hosting for data sovereignty, be honest about what you are buying. Renting K3 from a US inference provider gives you the model without sending anything to Moonshot's API, which addresses the actual concern most teams have. Full sovereignty means owning eight B300s, and that is a different budget conversation with a different justification.

Two practical notes from the vLLM release if you do run it. Tool calling occasionally emits formats the parser cannot handle and returns empty results, so validate outputs and have a fallback path. And raise your max_tokens, because the model reasons at length before it answers, and the default limits people carry over from smaller models will truncate it mid-thought.

The old question was whether the open models were good enough to self-host. That one is settled. The new question is whether you can afford the machine, and for most teams the honest answer arrived the same day the weights did.