Kimi K3.1 Pro open weights are out: 1.56 TB, 2.8 trillion parameters and what self-hosting really takes
Moonshot published the Kimi K3.1 Pro weights on Hugging Face on 2 November. We read the model card, the licence and the vLLM recipe, and measured the download. Here is who can actually run it.
Two days ago we wrote that we could not confirm Kimi K3.1 Pro's open weights were downloadable. They are now. Moonshot put the model on Hugging Face on 2 November, ahead of the 4 November date it had given.
"Open weights" sounds like "free to run". It is not quite that. We read the model card, the licence and the vLLM deployment recipe, and pulled the file list ourselves. Here is what you actually get, what it takes to run, whether self-hosting fixes the problems people want it to fix, and who should bother.
What is new
| Detail | Kimi K3.1 Pro |
|---|---|
| Published | 2 November 2026, on Hugging Face |
| Architecture | Mixture-of-experts, 896 experts, 16 used per token plus 2 shared |
| Total parameters | 2.8 trillion |
| Active parameters per token | 104 billion |
| Context window | 1,048,576 tokens |
| Weights | MXFP4 weights with MXFP8 activations, trained with quantisation in the loop |
| Inputs | Text and images, with a 401 million parameter vision encoder |
| Download size | 1.56 TB across 112 files, measured from the repository listing |
| Licence | Kimi K3.1-Pro License, a modified permissive licence |
| Supported runtimes | vLLM, SGLang and TokenSpeed |
Moonshot also serves it through its own API as kimi-k3.1-pro, with OpenAI-compatible and Anthropic-compatible endpoints. At launch it priced the API at $2 per million input tokens and $10 per million output.
The pain point: why people want open weights
Teams ask for open weights for three reasons:
- Data control. Contracts, health records or source code that must not leave your own servers.
- No lock-in. If a vendor changes prices, limits or terms, you keep a working model.
- Uptime. No dependency on someone else's API being up, which mattered a lot this week.
Fixed or not?
For data control and lock-in, yes. For cost, mostly no.
The size is the catch. Even with 4-bit weights, the model alone is about 1.56 TB, so it has to be spread across a full server of the newest data centre GPUs before you add memory for long contexts. vLLM's recipe describes its simplest working NVIDIA setup as one tensor-parallel group of 8 GPUs: two GB300 trays or one B300 node, with an AMD option on one MI355X node. That is not a workstation, and it is not a single rented GPU.
So unless you already run that class of hardware at high utilisation, the API will cost less per token than owning or renting the servers. The weights are still valuable, for a different reason: they guarantee the model exists on your terms, whatever happens to the API.
The licence, in plain English
The Kimi K3.1-Pro License lets you use, copy, modify, fine-tune, deploy and sell products built on the model. Two conditions apply only at very large scale:
- Model hosting businesses that let others send their own prompts or fine-tune the model, with more than $20 million in revenue over 12 months, need a separate agreement with Moonshot before commercial use. Building the model into a feature of your own product does not count as model hosting.
- Products with more than 100 million monthly users or $20 million in monthly revenue must show "Kimi K3.1-Pro" prominently in the interface.
Internal use, where nothing is exposed to third parties, is exempt from both. For a startup or an agency like ours, the licence is effectively permissive. Read the full text before you commit, as always.
What you can do with it
| Your situation | What we would do |
|---|---|
| You want a strong coding or agent model and have no data restrictions | Use the API. It is cheaper and you skip running a cluster |
| You need data to stay in your own cloud account | Use a certified inference partner in your region, or rent one B300-class node |
| You already run 8-GPU B300 or GB300 servers | Self-host with the vLLM recipe and keep the API as a fallback |
| You worry about a vendor changing terms | Keep the weights and a tested deployment script ready, even if you never run them daily |
| You want something that runs on a laptop or phone | Look at much smaller open models. This one is not built for that |
Whatever you choose, run it against twenty real tasks from your own product before trusting it, exactly as we said when the API launched. Moonshot's benchmark tables are its own numbers, and independent results are still coming in.
If you are weighing an open-weight model for a client project, this is the kind of build-or-buy call we help with on SaaS products.
Open weights do not make a frontier model cheap to run. They make it impossible to take away.