Kimi K3: 2.8 trillion open weights that almost nobody can run

Moonshot AI put the Kimi K3 weights on Hugging Face on July 27, eleven days after announcing the model on July 16. The headline number is 2.8 trillion parameters, which makes it the largest open-weight model ever released. The number that matters if you actually want to run it is different: the MXFP4 checkpoint is about 1.4 TB, the native safetensors download is around 594 GB, and Moonshot's recommended deployment is a supernode of 64 or more accelerators in a single high-bandwidth domain. Open, yes. Runnable at home, no.

What shipped

K3 is a mixture-of-experts model with 896 experts and 16 active per token, Kimi Delta Attention, native vision, and a 1M-token context. Moonshot announced a Modified MIT license; the pre-release material noted the exact terms would only be confirmed with the weight drop, so read the file before you build on it. The API has been live since July 16.

The benchmark story is genuinely strong. In the blind Frontend Code Arena K3 took first place at 1,679 points, ahead of Fable 5. On the overall Arena score it still sits behind Fable 5 and GPT-5.6 Sol. Artificial Analysis ranked it fourth among all frontier models, slightly ahead of Claude Opus 4.8. Moonshot's own numbers show 93.5% on GPQA Diamond and 84.2% on MCP Atlas, and against GLM-5.2 it claims DeepSWE 67.5 vs 46.2 and FrontierSWE 81.2 vs 67.3. Markets reacted hard enough that several outlets called it a second DeepSeek shock.

Why open no longer means runnable

Until recently, open weights implied you could download a GGUF and run it on a workstation. K3 breaks that assumption in three places.

• Footprint. 594 GB of safetensors is before you load anything. Even the 4-bit MXFP4 build is 1.4 TB across the cluster because the expert count is so large; MoE sparsity saves compute per token, not storage.
• Format. MXFP4 runs natively today only on NVIDIA Blackwell and AMD MI400. It is not the same thing as a Q4 GGUF on a Mac. If you are on Hopper or Apple Silicon you are converting, and conversions of a 2.8T model are not weekend projects.
• Topology. The 64-accelerator supernode is a recommendation for bandwidth, not a marketing flourish. With roughly 50B parameters active per token according to the pre-release material, decode is dominated by moving expert weights across the interconnect.

Open weights used to mean you could run it. Now it means somebody with a supernode could.

Self-hosting K3 is realistic for cloud providers and well-funded institutions. For a team with a rack of H100s it is a stretch; for a solo engineer with an M-series Mac it is not a question.

When self-host versus API makes sense

The decision is not about K3's quality; it is about who owns the hardware and the data.

• Data residency or air-gap requirement: self-host, but budget for the supernode or a dedicated cloud tenancy, and compare against GLM-5.2 (744B MoE, MIT, 62.1% SWE-bench Pro at roughly $0.32 per task on Artificial Analysis), which fits far smaller clusters.
• Cost-sensitive agent traffic: use the API and route by task. DeepSeek V4 and GLM-5.2 under plain MIT are cleaner commercial bases than a Modified MIT you have not read yet.
• Local development on Apple Silicon: forget K3. Use the unified memory sizing guide to pick a model that fits, and treat K3 as a frontier API endpoint.
• Frontend-heavy agentic coding: the Arena result is the one place K3 has a clear, independently measured edge, so it is a fair candidate for a routing tier there. Build your own eval on your own tasks before moving traffic.

The honest gap

The strongest coding deltas (DeepSWE, FrontierSWE) are Moonshot's own numbers and I have not seen them reproduced. The Arena and Artificial Analysis rankings are independent but measure preference and aggregate intelligence, not your workload. And the operational numbers, 1.4 TB, 594 GB, 64 accelerators, come from pre-release documentation; expect them to shift as community quantizations land. What will not shift is the shape of the problem: a 2.8T MoE is a datacenter artifact, and the MXFP4 dependency on Blackwell and MI400 puts a hardware wall in front of most teams that would otherwise love to run it.