Kimi K3

Last updated: 5 November 2026. Kimi K3.1 Pro’s official weights are now on Hugging Face, so we’ve confirmed the parameter count, expert layout, MXFP4 format and checkpoint size, replaced the K3 licence terms with the published K3.1 Pro licence, corrected the attention layout and added a section on downloading the weights safely.

Before anyone argues about which GPU to rent, a smaller question settles most of the argument: how many bytes have to sit in accelerator memory before the first token comes out? For Kimi K3.1 Pro hardware requirements, that number already exists, even though the model’s own weights don’t.

Moonshot AI launched Kimi K3.1 Pro on its API on 23 October and describes it as a post-trained version of Kimi K3. K3’s weights have been public since July, and they occupy 1.561 TB. Unless Moonshot changes the format when it publishes K3.1 Pro, that’s the floor: about 1.56 TB of weights before a single cached token, activation buffer or draft model.

A model name doesn’t give you a GPU count. Weight format, memory per accelerator, the engine’s reservation, context length and concurrency do. This guide works through each with the arithmetic shown, so you can swap in your own numbers.

Quick Answer

• Weights released: Kimi K3.1 Pro’s official weights went live on Hugging Face at the start of November 2026, under the moonshotai organisation.
• Model size: 2.8T total parameters with 104B active, shipped as a 1.56 TB MXFP4 checkpoint split across 96 files.
• Memory needed: about 1.6 TB of GPU memory for the weights alone, before KV cache.
• Minimum GPUs: eight 288 GB GPUs (B300, GB300 or MI355X) as a floor, 16 B200 or H200 cards, or 24 to 32 H100s. These are our estimates, since Moonshot publishes no minimum hardware.
• Long context: the 1M-token window adds up to about 18 GB per request on our revised estimate.
• Licence: the Kimi K3.1-Pro License is MIT-style, with extra conditions above $20M in revenue or 100M monthly users.
• Download safely: use only the official moonshotai repository and verify the files before you load them.

Key Takeaways

• The official weights are out: 2.8T total parameters, 104B active, 1.56 TB across 96 safetensors shards on Hugging Face.
• Fake and repackaged Kimi K3.1 Pro uploads are likely to follow, so download only from the moonshotai organisation and verify model weights before you download.
• “2.8 TB at 8-bit” is arithmetic for a file that doesn’t exist. The native release is already 4-bit, trained that way.
• Eight 288 GB GPUs in one node are the floor. B200, H200 and H100 fleets need two or more nodes just to hold the weights.
• Every request costs a fixed 0.2 to 0.4 GB of KDA state plus about 14 KB per token of FP8 MLA cache, so short requests aren’t as cheap as their length suggests and million-token contexts are cheaper than on dense models.
• A single on-demand AWS node costs about $102,540 a month before redundancy, staff or storage.
• Matching the $2/$10 API on a 20k-in, 2k-out workload takes roughly 13,000 input and 1,300 output tokens per second, sustained around the clock. Measure whether your hardware can do that before you sign anything.
• The K3 licence isn’t MIT: model-as-a-service businesses above $20 million in total company revenue need a separate agreement.

Quick Navigation

What is confirmed about Kimi K3.1 Pro

With the weights released on Hugging Face, every core specification on this page now comes from Moonshot’s own model card and config.json rather than from Kimi K3.

One change from Kimi K3 matters for memory planning. K3.1 Pro swaps K3’s 24 full-attention Gated MLA layers for Gated DSA, a sparse attention design, which changes the KV cache figures below. Moonshot doesn’t state minimum hardware anywhere in the release, so the GPU counts on this page remain our estimates from the published sizes.

Calculating Kimi K3.1 Pro weight memory

The formula is plain: weight bytes = parameters x bits per parameter ÷ 8. Using K3’s 2,779,931,837,184 parameters:

The released checkpoint confirms the MXFP4 estimate. Moonshot’s config lists the format as mxfp4-pack-quantized with one scale per group of 32 weights, and the Hugging Face repository totals 1.56 TB across 96 shards. Plan for about 1.6 TB of memory for weights, plus room for the vision encoder, KV cache and runtime overhead.

All rows are weights only, with no runtime overhead. The brief’s “2.8 TB at 8-bit, 1.4 TB at 4-bit” is correct arithmetic for the wrong question. Moonshot trained K3 to run in MXFP4 from supervised fine-tuning onward, so there is no 8-bit release to plan around.

The gap between 1.39 TB and 1.561 TB has two sources. MXFP4 stores a shared 8-bit scale for every block of 32 weights, adding about 0.09 TB. And the config leaves attention, shared experts, the dense first-layer MLP, the output head and the vision encoder unquantized. The “5.6 TB” figures circulating for K3 come from assuming BF16.

Watch your units. TB is 10^12 bytes and TiB is 2^40, about 10% larger. NVIDIA lists a DGX B300’s total GPU memory as “2.1 TB”, yet eight 288 GB GPUs hold 2,304 GB, which is 2.10 TiB. Compare a TiB capacity with a TB weight file and you’ve lost a tenth of your headroom on paper.

How many GPUs Kimi K3.1 Pro needs

The lower bound is: GPUs = ceiling(weight bytes ÷ (memory per GPU x usable fraction)). vLLM’s Kimi K3 recipes run at 0.88 to 0.92 of GPU memory; this guide uses 0.90.

Memory per GPU from AMD’s MI355X page (which also lists B200 at 180 GB) and NVIDIA. Seven 288 GB GPUs clear the bound, but tensor parallelism splits the 96 attention heads across GPUs, and 96 doesn’t divide by seven. Eight is the real floor, and it’s what the vLLM recipe states: at least 8x GB300, or 8x MI355X/MI350X on ROCm, with “multi-node for real production traffic”.

Eight GPUs are not one 2.3 TB pool. Each holds its own shard, and every layer exchanges activations between them. Inside a DGX B300 that traffic rides NVLink at 14.4 TB/s aggregate. Between nodes it crosses InfiniBand or Ethernet at up to 800 Gb/s per port, roughly 100 GB/s, which is why two-node recipes split the model into pipeline stages (TP8 x PP2) and why NVIDIA’s Dynamo recipes target GB200 and GB300 racks with NVLink spanning trays: 16 GB200s aggregated, or 32 split between prefill and decode.

Hopper is the awkward case. H100 and H200 lack native FP4 tensor cores, so MXFP4 experts run through dequantising kernels. The recipe page builds commands for H200, but its stated minimum is Blackwell or MI355X, and we found no published throughput for K3 on Hopper.

Can a single GPU or workstation run it?

No single GPU comes close. The workstation route is llama.cpp with the experts in system RAM. One published test loaded a ~554 GB 1-bit GGUF of K3 on a 160 GB VRAM machine with the MoE weights on CPU. Nobody has published quality figures for that quant. The 4-bit GGUF is 1,508.7 GB, barely smaller than the native file, because the native file is already 4-bit. It’s a way to poke at the model, not to serve users, and Now that the weights are public, community quants of Kimi K3.1 Pro can appear, but none are official, and their quality and memory use are unverified until someone tests them. The K3 result above (a 554 GB 1-bit GGUF reportedly running on 160 GB of VRAM) is the best guide for now. Before you run any community build, put it through the checks in our model weights verification guide..

The KV cache changes the Kimi K3.1 Pro calculation

This is the one part of the page where the release changed our numbers. Our first estimate assumed K3’s Gated MLA layers. Kimi K3.1 Pro uses Gated DSA in those 24 layers instead, and its config gives the inputs for a revised estimate.

• DSA layers: the config keeps a 512-value compressed KV latent plus a 64-value positional key (576 values), and adds a lightning indexer with a 128-dimension key. Assuming each of the 24 layers caches both, as DeepSeek’s DSA does, that’s 24 × (576 + 128) = 16,896 values per token, or about 16.9 KB at FP8.
• KDA layers: these keep a fixed-size state rather than a growing cache. At 69 layers × 96 heads × 128 × 128 values in BF16, that’s about 0.22 GB per request, whatever the context length.

Treat these as planning estimates, not measured figures. Moonshot hasn’t published KV cache sizes, and vLLM or SGLang may store the cache differently. The indexer only picks the top 2,048 earlier tokens for each query (index_topk in the config), which saves compute, but the full cache still has to sit in memory. Check your engine’s own memory report once the model loads.

Two things fall out. Below about 16,000 tokens the fixed state outweighs the growing cache, so short chat traffic carries a per-request floor most sizing guides ignore. At the other end, long contexts are cheap: a 70B dense model with grouped-query attention needs about 160 KB per token, as our breakdown of AI memory costs works out, or roughly 172 GB for a million tokens against K3’s 14.7 GB.

On one 8x B300 node, 0.90 of 2,304 GB leaves about 2,074 GB, and weights take 1,561 GB. Set aside an assumed 110 GB for activations, CUDA graphs, communication buffers and the speculative draft model the recipes load, and roughly 400 GB remains for requests. That’s an upper bound of about 600 concurrent requests at 32K, 197 at 128K, or 27 at the full million.

Those counts assume the cache is spread across GPUs without duplication. vLLM’s decode context parallelism does that for MLA; without it, tensor-parallel ranks can each hold a copy and the numbers fall sharply. The recipes also spill to host RAM: one AMD prefill configuration budgets 1,799 GB of host DRAM for cache offload. Memory scales linearly with concurrency and context. Throughput at those concurrencies is a separate question that only measurement answers.

Where to download Kimi K3.1 Pro weights safely

The only official source is the moonshotai/Kimi-K3.1-Pro repository on Hugging Face. A 1.56 TB download is a big target for copycats, and a fake or tampered upload costs you days of transfer time and GPU hours before you notice anything is wrong.

There’s a second reason to be careful with this release. The repository ships its own Python files, and Moonshot’s usage example loads them with trust_remote_code=True. A mirror that changes those files can run code on your servers the moment you load the model. Our guide to spotting fake model weights walks through seven checks before you download. For Kimi K3.1 Pro, the short version is:

1. Check the organisation. The repo should sit under moonshotai, the same Hugging Face account that hosts Moonshot’s earlier Kimi K3 release.
2. Check the file list. Expect 96 safetensors shards totalling about 1.56 TB, plus config.json, the LICENSE and the custom code files. Pickle or .bin weight files are a warning sign.
3. Read the custom code before you trust it. If you pull from anywhere other than the official repo, compare the .py files against Moonshot’s versions line by line.
4. Compare hashes. Hugging Face shows a SHA-256 for each large file. Match your local copies against the official repo, not against the mirror you downloaded from.
5. Treat quants as third-party software. Moonshot hasn’t released any official quantised variants. Any GGUF or lower-bit build is a community conversion, so check who made it and what it was built from.

Quantisation trade-offs

Weight quantisation and cache quantisation are separate levers, and the first one is mostly pulled already.

Because K3 went through quantization-aware training, its 4-bit weights aren’t a lossy copy of some better original that’s available to you. Going below 4 bits is a real compression, and nobody has published K3 or K3.1 Pro quality numbers for those quants. Run your own evaluation against the hosted API before trusting one.

Hardware matters here too. Blackwell and AMD’s CDNA 4 parts execute MXFP4 natively; AMD lists 10.1 PFLOPs of MXFP4 matrix throughput for the MI355X. Hopper doesn’t, which is a second reason the recipes start at Blackwell. The cache side has its own knobs: the latency-tuned GB300 profile switches the KDA state to FP32, doubling that per-request floor to about 0.43 GB.

The real cost of self-hosting Kimi K3.1 Pro

Two dated price points for one 8x B300 node, on demand, 30 days at 24 hours:

AWS rate: us-east-1, Linux, on demand, per Vantage’s EC2 tracker, read 26 October 2026; the instance includes 4,096 GiB of host RAM and 8 x 3.84 TB local NVMe. Specialist rate: median across 10 providers per getdeploying, 8 September 2026; those offers may not match AWS on networking, storage or availability.

The effective-rate rows are the ones that matter. A node you pay for around the clock but keep busy half the time costs twice as much per useful hour, and real traffic has nights and weekends.

The GPU line also isn’t the bill. One node has no redundancy, so a production service needs a second, doubling the fixed cost before it serves an extra token. Add engineering time, monitoring, storage for 1.56 TB of weights plus staging on every node, egress, and the work of swapping in K3.1 Pro weights when they arrive. Published estimates of that total put it at 1.3 to 5 times the raw GPU rate, a range we unpack in the hidden fees in self-hosted LLM cost.

Kimi K3.1 Pro API vs self-hosting: the break-even

Moonshot’s API price for standard kimi-k3.1-pro is $2 per million input tokens, $10 per million output and $0.20 per million cached input, confirmed by Artificial Analysis. The Highspeed variant costs $4/$20. Cache writes are billed separately at a rate that wasn’t displayed when we checked.

The formula: API cost = (input tokens ÷ 1,000,000 x input rate) + (output tokens ÷ 1,000,000 x output rate).

Illustrative workload, an assumption: an agentic coding call with 20,000 input tokens and 2,000 output tokens, reasoning included. Uncached, that’s $0.04 + $0.02 = $0.06 per call. With 90% of input served from cache, it’s $0.0076 + $0.02 = $0.0276, before cache-write fees.

Break-even calls per month = monthly self-hosting cost ÷ API cost per call. Spread over 2,592,000 seconds in 30 days:

Caching makes the API cheaper, so it pushes break-even further away. And these are averages held for 720 hours straight. Peaks need headroom above them, so a fleet that just breaks even on average is running below capacity most of the day.

Can one node sustain those rates at an acceptable latency? There’s no independent published throughput for K3.1 Pro on 8x B300, so that’s the number to measure, not assume. Remember too that the right comparison is the cheapest API that meets your quality bar. Third-party hosts listed K3 below Moonshot’s own price on OpenRouter, and the same is likely once K3.1 Pro weights circulate. Our Kimi K3.1 Pro vs Sonnet 5.5 comparison covers per-task token use, which moves the API side of this equation more than the rate card does.

Self-hosting earns its place when data can’t leave your infrastructure, when load is high and steady enough to keep a node busy, when you need to fine-tune, or when you already own Blackwell capacity sitting idle.

Licence and operational constraints

Moonshot published the Kimi K3.1-Pro License with the weights. It starts as an MIT-style licence, then adds three conditions that matter for self-hosting.

• Model-as-a-Service: if you sell access to the model and earn more than $20M in aggregate revenue over any consecutive 12 months, you need a separate agreement with Moonshot.
• Attribution: a product with more than 100 million monthly active users, or more than $20M in monthly revenue, must prominently display “Kimi K3.1-Pro”.
• Exemptions: internal use is exempt, as is use through Moonshot’s official products or certified inference partners.

For most teams running the model in-house, the licence won’t change the hardware decision. If you plan to resell inference at scale, email license@moonshot.ai before you buy GPUs. This is a summary, not legal advice, so have your counsel read the full text.

A practical Kimi K3.1 Pro deployment decision

• Use the hosted API when traffic is small, spiky or unproven, or nobody on the team runs GPU clusters. Moonshot offers zero data retention to API customers, which settles some privacy objections without any hardware.
• Rent one 8x B300 or MI355X node for evaluations, fine-tuning experiments or steady internal batch work you can keep busy. Accept that it has no redundancy.
• Plan multi-node or rack-scale for production with latency targets, long contexts at high concurrency, or uptime commitments. Moonshot’s 64-plus accelerator guidance describes this tier.
• Benchmark before you sign. Replay 50 to 200 real requests, measure tokens per second at your p95 latency target, and compare any quantised variant’s outputs with the hosted API.

What would change this estimate? The K3.1 Pro file size and precision; the KDA state dtype your engine uses; your measured throughput per node; GPU rental prices, which roughly doubled for B300 through 2026 according to price trackers; and the K3.1 Pro licence terms.

Conclusion

Kimi K3.1 Pro’s weights are now public, and they match the estimates this page made before launch: a 1.56 TB MXFP4 checkpoint that needs about 1.6 TB of GPU memory before KV cache. Eight 288 GB GPUs remain the practical floor, and the 1M-token context adds up to about 18 GB per request on our revised estimate. For most teams the API is still the cheaper route unless usage is heavy and steady. If you do self-host, start from the official moonshotai repository and verify the files before anything touches your cluster.

So don’t rent for Kimi K3.1 Pro hardware requirements yet. Use the API, log your real token mix and concurrency, and when the weights land, check the file size against 1.56 TB, then spend a week on one rented node measuring tokens per second at your latency target. If that number can’t clear the break-even rates in the table above with room for peaks and a second replica, the API was the cheaper machine all along.

Frequently asked questions

How much VRAM does Kimi K3.1 Pro need?

About 1.6 TB for the weights alone, based on the official 1.56 TB MXFP4 checkpoint, plus KV cache and overhead. That’s eight 288 GB GPUs at minimum, 16 B200 or H200 cards, or 24 to 32 H100s. Moonshot doesn’t publish minimum hardware, so these counts are our estimates.

Can Kimi K3.1 Pro run on one GPU?

No. The largest current accelerators, NVIDIA B300 and AMD MI355X, hold 288 GB each, under a fifth of the 1.56 TB weight file. Even heavily compressed community quants of K3 run to roughly 550 GB, which still needs several GPUs or large amounts of system RAM.

How many GPUs are needed for a model of this size?

Eight 288 GB GPUs are the practical minimum and match the vLLM recipe’s stated floor. With 180 GB B200s or 141 GB H200s you need 16 across two nodes. Moonshot recommends 64 or more accelerators for efficient production serving.

Does 4-bit quantisation reduce memory requirements?

For this model it’s already applied. Kimi K3 ships in MXFP4, a 4-bit format with shared scales, trained that way from fine-tuning onward. Converting to 8-bit would roughly double memory. Going below 4 bits shrinks the file further, but no published quality data exists for those quants.

How much does self-hosting cost per month?

One 8x B300 node costs about $102,540 for 30 days on AWS on demand, or about $47,117 at the median specialist-cloud rate (prices checked September to October 2026). Redundancy, staff, storage and idle time add substantially to that GPU line.

Is an API cheaper than running the model locally?

For most workloads, yes. At $2/$10 per million tokens, a self-hosted AWS node only matches the API if it sustains about 1.7 million 20k-token calls a month. Self-hosting can win on data control, steady high load or fine-tuning needs.

Can I run Kimi K3.1 Pro on a workstation?

Not at the official precision. The checkpoint is far larger than any workstation’s memory. Community quants may make heavily compressed versions possible, as a 1-bit GGUF did for Kimi K3, but none are official and quality is untested.

What licence applies to commercial deployment?

The Kimi K3.1-Pro License, an MIT-style licence with extra conditions. Model-as-a-Service businesses earning over $20M in 12 months need a separate agreement, and products above 100M monthly users or $20M monthly revenue must display “Kimi K3.1-Pro”. Internal use is exempt.

Where can I download Kimi K3.1 Pro safely?

Only from the official moonshotai/Kimi-K3.1-Pro repository on Hugging Face. Check the organisation, file list and hashes before downloading, and see our guide to verifying model weights for the full checklist.

Keep reading

Here are the latest posts from the blog.

Anthropic IPO: The $895 Billion Question Behind Its Valuation

November 9, 2026

Last updated: 9 November 2026. Latest confirmed development: Anthropic’s amended S-1, filed on 2 November, still leaves the share count and the IPO price range …

Read more

Claude Opus vs Sonnet: What the 2026 Price Gap Actually Buys

November 8, 2026

Last verified: 8 November 2026. All prices are Anthropic’s standard first-party API rates in US dollars per million tokens. They aren’t Claude Pro or Max …

Read more

Did AI Break RSA? What DeepMind Actually Found

November 8, 2026

Last verified: 8 November 2026. Both papers are unreviewed working papers, and no outside group has reproduced the results yet. No, AI did not break …

Read more

Model Distillation Explained: When AI Learning Becomes Extraction

November 7, 2026

Last verified: 7 November 2026. Government and company claims are attributed throughout. None has been tested in court. A support team trains a small, cheap …

Read more