The first thing most people notice about Kimi K3 is the 1.56 TB download. The second is the license. Moonshot released the full weights on July 27, right on the date it promised, but the result is not a standard MIT or Apache release. It is a very large open-weight model with a very specific commercial boundary.

That distinction matters more than the headline parameter count. Researchers can inspect the checkpoint, runtime teams can optimize it, and organizations can run it inside their own infrastructure. A company that wants to sell K3 as a general model service, though, needs to read the legal text before someone downloads 96 shards and calls it a product.
The impressive part is real
Kimi K3 is a 2.8 trillion parameter mixture-of-experts model with 104 billion active parameters per token. Its router selects 16 experts out of 896, and the model uses Kimi Delta Attention, Attention Residuals, and a Stable LatentMoE design. The released configuration lists 93 layers, native MXFP4 weights with MXFP8 activations, a 1,048,576-token context window, and a 401-million-parameter MoonViT-V2 vision encoder.
Those numbers describe a serious serving problem, not a desktop download. Simon Willison measured the Hugging Face release at roughly 1.56 TB. The repository contains 96 safetensors shards. Even with four-bit weights, K3 needs a multi-accelerator deployment with fast interconnects, enough local storage, and a runtime that understands its hybrid attention state. Moonshot points users toward vLLM, SGLang, and TokenSpeed rather than pretending this is a model for a single workstation.
The architecture is unusual in ways that show up in serving. KDA carries recurrent state instead of storing a conventional key-value pair for every token, while periodic full-attention layers preserve access to exact token history. Attention Residuals add cross-layer reads and writes. Sparse experts reduce the compute used per token, but they increase routing and communication pressure across the cluster.
vLLM's release work makes the practical tradeoff clear. Its Kimi K3 integration separates the physical block size used for KDA state from the smaller boundary used for prefix matching. That lets a request reuse a shared prefix without forcing the runtime to store a huge recurrent state at every small cache boundary. It is a clever fix for a model that does not fit neatly into the usual paged-KV assumptions.
The scores need asterisks
Moonshot's model card reports 93.5 on GPQA Diamond, 88.3 on Terminal-Bench 2.1, 91.2 on BrowseComp, 94.5 on MCPMark-Verified, and 84.8 on OSWorld-Verified. The same table puts K3 near or ahead of several closed models on individual tasks. It also shows the limits: K3 trails Claude Fable 5 and GPT 5.6 Sol on a number of coding, office, and vision evaluations, and Moonshot explicitly says the user experience still lags those systems.
The benchmark table is useful, but it is not a neutral tournament result. K3 uses Kimi Code on several coding tests. Other models use Codex, Claude Code, or different harnesses. Some entries are vendor results, some come from public leaderboards, and some were recomputed from raw scores. K3's official card says its agentic runs use maximum reasoning effort and often include tools. A score without the harness and effort setting is a comparison-shaped object, not a comparison.
The community discussion on Hacker News landed on the same problem from a different angle. One commenter asked whether the published architecture was reproducible enough to implement, while another pointed out that vLLM, SGLang, and MLX work already suggested the documentation was usable. A third response pushed back on calling open weights open source because the training data and exact training process remain unavailable. That argument is less academic than it sounds. You can fine-tune K3 and inspect its runtime behavior, but you cannot recreate the original model from a clean build recipe.
There is also a reliability catch in the model card. K3 was trained with preserved thinking history. In multi-turn tool use, the complete assistant message, including reasoning content and tool calls, must be passed back exactly. Dropping that state or switching a live session from another model can make generation unstable. The model card also warns that K3 can be overly proactive when a task is ambiguous. For a coding agent, that may look like initiative. In a production workflow, it can look like an unauthorized edit made at 3 a.m.
Open weight, closed deal
The Kimi K3 License grants broad rights to use, copy, modify, publish, distribute, sublicense, sell, deploy, fine-tune, and create derivative works. That sounds permissive until the Model as a Service clause arrives.
If a licensee or one of its affiliates operates a Model as a Service business and the combined revenue exceeds $20 million over any consecutive 12 months, the license requires a separate agreement with Moonshot before commercial use of the software or derivatives. The definition covers giving third parties access to inference or fine-tuning through an API where those users have meaningful control over inputs, parameters, or training data. Embedded end-user functions and simple request relays are treated differently.
A second threshold applies to large commercial products. If a product using K3 has more than 100 million monthly active users or more than $20 million in monthly revenue, the interface must prominently display "Kimi K3." Internal use is exempt, as is use through Moonshot's official products or certified inference partners.
That is not a gotcha hidden in a footnote. It is the product strategy. Moonshot is giving infrastructure teams enough freedom to experiment and self-host while protecting the high-volume inference business that would otherwise compete directly with its API. The company also calls K3 open weight rather than open source in its own materials, which is unusually honest for this category.
For a research lab, an internal coding assistant, or a company that wants to run a model behind a narrow product feature, the license may be workable. For a startup whose business is selling customizable K3 endpoints, the $20 million line is a contract milestone, not a trivia fact. The threshold applies to the licensee and affiliates, so corporate structure matters too.
The bigger question is whether open-weight releases are becoming a new kind of platform deal. The weights are available. The architecture is documented. The serving stack is arriving with them. Yet the most valuable commercial path still has a toll gate. That may be a reasonable trade, but it is not the same thing as a fully permissive model release.
K3 is worth downloading if you have a real reason to inspect or control a frontier checkpoint. It is not worth downloading because the word open makes a 1.56 TB cluster feel cheap. The model is a strong research artifact and a credible competitor on several agent tasks. The license is the part that decides whether it can become your business.
Sources
- Moonshot AI Kimi K3 technical blog: architecture, capabilities, launch claims, and limitations
- Kimi K3 Hugging Face model card: released configuration, benchmark table, deployment guidance, and usage requirements
- Kimi K3 License: Model as a Service and attribution thresholds
- vLLM Kimi K3 serving preview: hybrid attention caching and production serving work
- Hacker News architecture discussion: community debate about reproducibility and open weights
- Simon Willison on the K3 release: checkpoint size, license context, and hosted pricing