Kimi K3.1 Pro Hardware Requirements: GPU, Memory, and What the 1.56 TB Checkpoint Needs

The weights are out. Here's what it takes to run them, from the model card rather than the launch post.

Moonshot published the Kimi K3.1 Pro weights on Hugging Face on November 4, 2026, as moonshotai/Kimi-K3.1-Pro, under the Kimi K3.1 Pro License. The model card confirms what the launch post implied: K3.1 Pro is a post-trained Kimi K3 with the same architecture, the same parameter counts, and the same checkpoint size. So the hardware answer is K3's hardware answer, now with a model card behind it.

This post goes through the numbers that set the requirement, the GPU configurations that do and don't work, why the checkpoint can't be shrunk, what the license allows, and when the API is the better route.

The short version

• Checkpoint: 1.56 TB on disk, 96 safetensors shards, MXFP4 weights with MXFP8 activations from quantization-aware training.
• Parameters: 2.8 trillion total, 104B active per token (16 of 896 experts, plus 2 shared), 1M-token context, text and image input.
• Single GPU or single node: no. Eight 192 GB cards give about 1.5 TB, which is below the weights alone once serving overhead is counted.
• Planning floor: a multi-node cluster with 2 TB or more of aggregate GPU memory and fast interconnect. Sixteen 141 GB cards is the smallest realistic shape.
• Quantized version: the release is already 4-bit. There is no smaller official checkpoint, and re-quantizing below 4-bit costs quality.
• Engines: Moonshot recommends vLLM, SGLang, and TokenSpeed. It states no minimum hardware.
• License: Kimi K3.1 Pro License, MIT-style with two added conditions for large hosted services and very large products.

The numbers that matter

From the model card and the repository metadata on Hugging Face.

Two of these numbers do most of the work. The 1.56 TB checkpoint sets the floor for how much GPU memory you need before a single request is served. The 104B active parameters set the compute cost per token, which is why K3.1 Pro is cheaper per token to run than a dense model of this size would be. It is not cheaper to hold in memory. Every expert has to be resident because the router picks a different 16 for every token, so you pay for all 2.8 trillion parameters in memory even though 104 billion fire at a time.

The repository metadata is worth a sentence because it settles a question from launch week. The safetensors index reports 2.78 trillion parameters, almost all of them stored as packed 4-bit integers, with a small BF16 remainder for the parts that stay in higher precision. That is the same layout as the Kimi K3 release, and the total storage is 1,561 GB, which is the same 1.56 TB.

Which GPU configurations work

Start from the floor: 1.56 TB of weights. Then add what serving needs on top: KV cache for in-flight requests, activations, framework overhead, and communication buffers. With a 1M-token context window the cache is not small under load, and a deployment that serves real traffic wants meaningfully more than the weights alone. Around 2 TB of aggregate GPU memory is the sensible planning floor.

The 16-card H200 shape is the smallest deployment that makes sense, and it is tight. Two nodes, 2.26 TB, and about 700 GB left after the weights for everything else. That is enough to evaluate the model and serve moderate traffic at shorter context lengths. For the 1M-token window with concurrent users, plan on the 32-card tier or above.

Two things about the architecture help here, and one thing does not. K3.1 Pro's attention stack is 69 KDA layers and 24 Gated DSA layers rather than full attention throughout, a design meant to keep cache growth down at long context compared with full attention on every layer. Expert parallelism across nodes is also well understood for this family, and vLLM and SGLang both support it. What does not help is the interconnect requirement: expert-parallel and tensor-parallel traffic between nodes is constant, so the cluster needs the fast fabric that comes with a proper multi-node deployment, not GPUs connected over ordinary networking.

Can you quantize it smaller?

No, and this is the part that surprises people coming from models that ship in BF16. K3.1 Pro was trained quantization-aware and released in MXFP4, a 4-bit format. The usual move of taking 16-bit weights and quantizing to 4-bit to fit smaller hardware has already been done by Moonshot before the release. There is no 4x shrink left.

Going below 4 bits is possible in principle and costly in practice. Community re-quantization of a quantization-aware 4-bit checkpoint to 2 or 3 bits typically loses real quality, and we are not aware of a credible sub-4-bit K3-series checkpoint. Treat 1.56 TB as the optimized size, not the starting point.

The same goes for a smaller sibling. Moonshot has not announced a Flash-class K3.1, and the Highspeed variant on the API is the same model served faster, not a smaller one. Its weights are not part of the release.

What the license allows

The Kimi K3.1 Pro License is an MIT-style grant with two conditions added. You can use, modify, and redistribute the weights, including commercially, with the standard notice requirement. The conditions:

• Hosted model services. If you offer K3.1 Pro to third parties as a model-as-a-service, meaning API-style inference or fine-tuning access, and that business takes in more than $20 million in any 12-month period, you need a separate agreement with Moonshot first. Products that embed the model's output in an end-user application are not covered by this clause.
• Attribution at scale. 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.

Internal use is exempt from both, as is use through Moonshot's own products or its certified inference partners. For most teams self-hosting for their own applications, the license reads like MIT. The conditions bite only when you resell the model at scale.

This is the same shape as the Kimi K3 License. Moonshot calls it open weight, not open source, and that is the accurate description.

Self-host or call the API

The hardware above is a 16 to 32 GPU cluster with fast interconnect and someone to run it. Moonshot's API serves the same model at $2.00 per million input tokens and $10.00 per million output, and the Kimi K3.1 Pro pricing post has the full rate card with caching.

Self-hosting wins in three situations: sustained high volume where the per-token API bill exceeds the cluster cost, data that cannot leave your infrastructure, and fine-tuning or serving modifications the API doesn't offer. Outside those, the API is cheaper, and the per-token price already reflects 104B active parameters.

For the models it competes with, Yotta AI Gateway serves Kimi K3, DeepSeek V4 Pro, GLM 5.3, and Qwen3.8-Max behind one OpenAI-compatible key with flat per-token pricing, so measuring K3.1 Pro against them is a model-string change in the same client. If you are sizing a cluster for the open flagships generally, the Kimi K3 hardware requirements post covers the same math with the same conclusion, and the Mistral Large 4 hardware requirements post shows what the next tier down looks like at 610 GB in NVFP4.

Frequently asked questions

How much VRAM does Kimi K3.1 Pro need? About 2 TB of aggregate GPU memory as a planning floor: 1.56 TB for the MXFP4 weights plus room for KV cache and serving overhead. That means a multi-node cluster. Sixteen 141 GB GPUs is the smallest realistic configuration.

Can I run Kimi K3.1 Pro on a single GPU? No. The weights are 1.56 TB and the largest single GPUs hold under 200 GB.

Can I run Kimi K3.1 Pro on one 8-GPU node? No. Eight 192 GB GPUs give about 1.5 TB, which is below the weights once serving overhead is counted. Eight H200s at 141 GB give 1.13 TB, well below the weights.

How big is Kimi K3.1 Pro? 2.8 trillion total parameters, 104B active per token. The checkpoint is 96 safetensors shards totaling 1.56 TB.

Is there a quantized version of Kimi K3.1 Pro? The release is the quantized version. It was trained quantization-aware and ships in MXFP4 with MXFP8 activations. There is no official smaller checkpoint, and sub-4-bit community quantizations cost quality.

Does Kimi K3.1 Pro need the same hardware as Kimi K3? Yes. Same architecture, same parameter counts, same 1.56 TB MXFP4 checkpoint. A cluster that serves K3 serves K3.1 Pro.

What inference engines run Kimi K3.1 Pro? Moonshot recommends vLLM, SGLang, and TokenSpeed on the model card.

What is the Kimi K3.1 Pro license? The Kimi K3.1 Pro License, an MIT-style license with two added conditions: a separate agreement for hosted model services over $20 million in 12-month revenue, and attribution for products over 100 million monthly users or $20 million in monthly revenue. Internal use is exempt.

Is Kimi K3.1 Pro open source? Open weight. The weights are public and the license is permissive for most uses, but it is not an OSI-approved open-source license.

Can I run Kimi K3.1 Pro locally? Not on a workstation. Local means a multi-node GPU cluster with 2 TB or more of memory. For a desktop or single-server setup, use the API.

Bottom line

Kimi K3.1 Pro's weights are the same 1.56 TB MXFP4 checkpoint as K3 with better post-training inside, so the hardware requirement is unchanged: a multi-node cluster of 16 or more GPUs with 2 TB or more of aggregate memory and fast interconnect, and nothing smaller. The license is permissive unless you resell the model at scale.

If you have that cluster, vLLM or SGLang will serve it. If you don't, Moonshot's API at $2 in and $10 out is the route, and Yotta AI Gateway puts the open models it competes with behind one key so you can run the comparison before you buy the hardware.