Kimi K3.1 Pro Weights Are Out: 1.56 TB on Disk and a $20M Licence Line

For the eleven days between the API launch and the download, most coverage of Kimi K3.1 Pro quoted 5.6 terabytes of BF16 weights. The repository that Moonshot AI actually published on Hugging Face on November 4, 2026 is 1.56 TB, spread over 96 safetensors shards. That is not a smaller model than the one everyone wrote about — it is the same Kimi K3-derived 2.8-trillion-parameter mixture-of-experts, shipped in the precision Moonshot trained it to serve in. The gap between the two figures is the first thing worth understanding about this release, because it decides whether a machine you already own can hold it.

The second thing is the licence, which is not Apache 2.0, not MIT, and not OSI-approved despite a permissive opening paragraph. It is a custom instrument called the Kimi K3.1-Pro License, and it contains a revenue threshold that turns a free download into a negotiation for one specific kind of company. Both facts were unanswerable on October 25, when the weights were a promise with a checklist attached. They are answerable now.

What actually landed on Hugging Face

The repo is moonshotai/Kimi-K3.1-Pro, it is ungated, and it holds 111 files. Ninety-six of them are weight shards; the rest are the config, the tokenizer, four Python files for the custom architecture, the model card and the licence. Total size across every file is 1,561 GB.

The reason it fits in 1.56 TB rather than 5.6 TB is written into the model card as a spec line, not a footnote: MXFP4 weights with MXFP8 activations, applied through quantization-aware training. This is not a post-hoc 4-bit quantisation someone ran after the fact. It is the native serving precision, which is why the repository carries the compressed-tensors tag and why there is no BF16 checkpoint sitting beside it. If you were planning around a 5.6 TB download, you were planning against a number Moonshot never shipped.

The rest of the spec sheet, so you can size the job:

• Total parameters — 2.8T in a mixture-of-experts, with 104B activated per token

• Depth — 93 layers, of which one is dense; the attention stack is 69 KDA layers plus 24 Gated DeepSeek Sparse Attention layers, a change from Kimi K3's full-attention Gated MLA layers

• Experts — 896 in total, 16 selected per token plus 2 shared, at a latent MoE dimension of 3,584

• Context — 1,048,576 tokens, unchanged from Kimi K3

• Modality — text and image in, text out; the vision encoder is MoonViT-V2 at 401M parameters

• Vocabulary — 160K tokens

Only one of those numbers is new relative to Kimi K3, and it is the attention change. Moonshot is explicit that this is a post-training release on the K3 base with heavier joint reinforcement learning across hundreds of domains, not a new architecture. The Gated DSA substitution is there for long-context efficiency, not for a capability jump.

The licence has three tiers, and the middle one is the one that matters

The Kimi K3.1-Pro License opens the way you would expect a permissive licence to open: permission to use, copy, modify, merge, publish, distribute, sublicense and sell, to run, deploy and fine-tune, and to create derivative works. Then it adds conditions, and the conditions are where the decisions live.

• Section 2, the model-as-a-service gate — if you or your affiliates run a business giving third parties access to inference or fine-tuning, and group revenue exceeds $20 million over any consecutive 12 months, you need a separate agreement with Moonshot before commercial use. Two carve-outs matter: end-user products where the model is embedded inside a feature or harness are not "model as a service", and neither is merely relaying requests to models hosted by someone else.

• Section 3, the attribution clause — commercial products with more than 100 million monthly active users, or more than $20 million in monthly revenue, must display "Kimi K3.1-Pro" prominently in the interface. That is a branding obligation, not a payment.

• Section 4, the exemptions — neither of the above applies to internal use, defined as any use that does not make the software, its outputs or its underlying capabilities available to third parties, or to use through Moonshot's official products and certified inference partners.

The practical reading is that internal deployments are free and unrestricted, and so is building a product on top of the model for your own users. What triggers the $20 million conversation is reselling raw model access at scale. If you were hoping to stand up a competing inference endpoint on these weights, that is the paragraph to take to a lawyer, and it is structurally the same licence Kimi K3 shipped under — so an existing legal review of K3 transfers, with the name changed.

One thing the licence does not do is make this open source in the OSI sense. The field in the repository metadata reads license: other, with the licence name set to kimi-k3.1-pro. Outlets that described it as modified MIT in the first hours after the drop were reading the permissive opening and stopping there.

What it takes to run, and where the API wins

The vLLM recipe published for this model is the most concrete deployment guidance available, and it is specific. It specifies vLLM 0.34.0 or newer, a baseline of one tensor-parallel group of 8 GPUs — two GB300 trays or one B300 node — with --tensor-parallel-size 8 across --nnodes 2. The optional long-context mode, DCP8, raises KV cache capacity to roughly 18.5 million tokens against 2.6 million with FP8 KV on 8 B300s, about seven times more.

Two consequences follow. First, an 8×H200 node is out: 1.13 TB of HBM does not hold 1.56 TB of weights before you allocate a single token of cache. Second, there is no consumer path. The model needs more VRAM than a workstation has, and the architectures that would make a slow CPU-offload version tolerable are still catching up with the custom kimi_k31 code — the repo ships trust_remote_code=True in its own quickstart snippet, which tells you the architecture is not yet in a released upstream library's default path.

The economics are easier to grasp in output tokens than in GPU line items. At $10 per million output tokens, one node's estimated capital cost of roughly $550,000 to $650,000 buys somewhere between 55 and 65 billion output tokens through the API at list price. A self-hosted node only beats that if you keep it busy enough to serve more than that before it is obsolete — and that comparison is before electricity, operations staff, idle time and the second node you need for redundancy. For most teams reading this, the honest answer is that the weights are a strategic asset and the API is the cheaper way to use the model.

That is also the reason kimi/kimi-k3.1-pro sitting in our catalogue at $2.00 per million input and $10.00 per million output changes the calculation rather than duplicating it. The same 1,048,576-token context and the same 104B active parameters are available over Chat Completions, the Responses API and Anthropic Messages, without a two-node cluster. Our pricing is 0% markup on the provider's list price, so when Moonshot moves the rate card the number here moves the same day rather than at the next contract renewal. And because the model is reachable through one key alongside more than 200 others, trying it on a real workload does not require committing a production path to it — you can put it behind failover and let it earn the traffic.

The benchmark table cuts both ways

Every figure in this section is vendor-reported from the model card, run at reasoning effort max with temperature 1.0 and top-p 0.95. The comparison columns are also taken at max effort with fallback enabled, which is worth knowing before you read a one-point gap as a win.

• Terminal-Bench 4.0 — Kimi K3.1 Pro 65.7% against Claude Opus 5.5 at 66.4%, GPT-6 Astra at 58.2% and Claude Fable 5.1 at 57.9%. Second on the table by eight-tenths of a point, and clearly ahead of two models it is being compared to.

• SWE Marathon v1.1 — 51.7% against 46.3% for Claude Opus 5.5 and 45.6% for Claude Fable 5.1. A real lead on long-horizon software work.

• HLE-Full with tools — 70.0% against 67.7% for Claude Opus 5.5 and 65.6% for Claude Fable 5.1. BrowseComp lands at 92.1% against 91.5% for GPT-6 Astra.

• Program Bench — 31.5% against 65.0% for Claude Opus 5.5, 53.5% for Claude Fable 5.1 and 50.0% for GPT-6 Astra. This is the widest loss on the sheet by a distance, and it is the row to look at if your work is program synthesis rather than terminal-shaped agent loops.

• Terminal-Bench-Science 0.1 — 38.1% against 68.1% for GPT-6 Astra and 63.3% for Claude Opus 5.5. Another category where the model is not close.

• HLE-Full without tools — 51.1% against 59.8% for Claude Opus 5.5. The tool-use column flips the ordering, which says more about harness quality than about raw reasoning.

The pattern is consistent enough to be useful: Kimi K3.1 Pro is strong where an agent is driving a shell, a browser or a long-running coding task, and weak on self-contained scientific and program-construction benchmarks. If you are choosing between it and Claude Opus 5.5 on the strength of a single headline number, the headline number is the one place they are closest.

Independent measurement is thin and worth stating plainly. Artificial Analysis currently scores Kimi K3.1 Pro at 46 on Intelligence Index v5.0.1 and lists it as open weights, at 32 output tokens per second, ranked first of 25 on the panel shown on its model page. Launch-week coverage quoted 55, but that was against the index build in use before the v5 rebuild on October 27 — different instruments, and subtracting one from the other produces a number that means nothing.

The open checkpoint is not the unrestricted one

Moonshot says it removed cyber-capability training data from parts of mid-training and reinforcement learning before releasing these weights, and the model card carries the evidence rather than leaving it as a press line. On its internal xdev-bench-hard set, the released checkpoint scores 81.0% against 90.5% for an unrestricted checkpoint of the same model. Whatever you download from that repository is the mitigated build.

The absolute numbers are not flattering in the other direction either. On ExploitBench the model scores 74.7 against 100 for GPT-6 Astra and 91.0 for Claude Opus 5.5; on ExploitGym it scores 20.7 against 42.4 for GPT-6 Astra. So the released model is both weaker than its own unrestricted variant and behind the frontier on exploitation tasks — a combination that is reasonable to want in an openly downloadable 2.8-trillion-parameter model, and worth knowing if your threat model assumed open weights meant unrestricted capability.

Who should download this, and who should not

Download it if you have a reason to hold the weights themselves: a data-residency requirement that rules out any third-party inference, a fine-tuning programme that needs the base model in-house, a research group auditing behaviour rather than renting it, or enough sustained volume that a dedicated node beats per-token billing. You will want two nodes, not one, and a plan for the KV cache if you intend to use anything close to a million tokens of context.

Do not download it if the goal is to save money on a moderate workload, or to run a frontier-class model on hardware you already own. The 1.56 TB is the floor, not the requirement, and the requirement is a B300 or GB300-class cluster. Skip it too if your workload is program synthesis or hard science — Program Bench and Terminal-Bench-Science are where this model is furthest from the alternatives, and no amount of licence permissiveness closes that gap.

For everyone in between, the weights landing is still the more important news, and not because of what they let you run. It is because a downloadable checkpoint is auditable, and an API is not — and a 2.8-trillion-parameter model within a point of Claude Opus 5.5 on Terminal-Bench 4.0 is now something an outside researcher can inspect rather than trust. That is the part of November 4 that does not depend on owning a datacenter.