Kimi K3 VRAM Requirements: What 2.8T Actually Takes

How Much VRAM Does Kimi K3 Need?

The short answer, now that the weights are public: the download alone is 1.56 TB, and that is the part that locks you out. The context window, counterintuitively, is nearly free. Moonshot’s launch post confirms a 2.8-trillion-parameter Mixture-of-Experts model shipping natively in MXFP4, and the published files measure 1.561 TB across 96 safetensors shards. Moonshot’s own deployment guidance says “supernode configurations with 64 or more accelerators.” Open weights landed July 27, 2026, and the config file came with them, so the KV-cache half of the math is finally computable. It turns out to be the most interesting number in the model. Here is everything that is official, what the leaks got wrong, and what the numbers mean if you were hoping to run it on your own hardware.

You can now run K3 locally in a 594 GB 1-bit build

Kimi K3 VRAM Requirements at a Glance

Everything below is measured from Moonshot’s published files or computed from their own config.json, not estimated:

For scale, that is roughly thirteen H200s (141 GB each) just to hold it, and Moonshot’s own guidance goes further, recommending “supernode configurations with 64 or more accelerators” for actual serving, which accounts for batching and activations on top of residency. On 24 GB consumer cards you would need about 75 of them.

The striking part is the second column. Going from 8K to a full million tokens costs about 33 GB, under 2% more. That is the opposite of how nearly every other model behaves, and the reason is in the architecture section below.

Where to Get It

• Weights: moonshotai/Kimi-K3 on Hugging Face (96 safetensors shards, 1.561 TB, ungated)
• Official announcement: Moonshot’s Kimi K3 blog post
• API and model docs: platform.kimi.ai Kimi K3 quickstart
• Licence: the Kimi K3 License in the repo, which is not MIT (see the table below)

Official Specs vs. What the Leaks Said

For weeks the aggregator sites have repeated “2.5 trillion parameters” as fact. The official launch post says otherwise. This table is sourced from Moonshot’s tech blog and announcement only, as of July 2026:

Two of those rows matter more than all the leak-correcting: the weights format and the undisclosed dimensions. We’ll take them in order.

The Benchmarks: Vendor-Published, Plus What Early Testers Report

Moonshot published a 20-row benchmark table comparing K3 against Claude Fable 5, GPT 5.6 Sol, and Claude Opus 4.8, among others. Selected scores, vendor-published (treat accordingly, since every lab tunes its own launch table):

The vendor’s own table places K3 between the Western frontier models, ahead on some agentic and coding rows and behind on others, which is itself notable restraint compared with the usual launch-table sweep.

Early community reports (community-reported and unverified: benchmark videos and API testers, with no formal methodology published anywhere yet): testers describe coding performance in the Opus-class range, with the strongest showings in agentic and long-context tasks and mixed results against GPT 5.6 Sol on polish-heavy multimodal work. No independent, methodology-published benchmark of K3 existed at launch. When one appears, this section gets updated; until then, the vendor table plus the API price sheet ($0.30/MTok cache-hit input, $3.00 cache-miss, $15.00 output) are the hard public numbers.

The Local Math: What 2.8T Means for Your Hardware

Weights. The published files measure 1.561 TB, which is 4.46 effective bits per parameter once the unquantized attention and shared-expert tensors are counted. Our pre-launch arithmetic put this at “roughly 1.5 TB class” and it held. For scale: the largest model in our calculator today, DeepSeek-R1 at 671B, computes to 407 GB of Q4_K_M weights (the tool’s own reading); K3 is roughly 3.8 times that. An H200 holds 141 GB. Moonshot saying “64 or more accelerators” is not hedging. It is the arithmetic. For where K3 sits among the other Chinese open-weight releases, see our full tier breakdown.

The MXFP4 twist, and the genuinely interesting part for local AI. K3 was trained quantization-aware from the SFT stage, natively in MXFP4. On every previous frontier model, the 4-bit file you run locally is a lossy afterthought of an FP16 original. K3’s 4-bit tier is the native tier. Whatever the GGUF ecosystem produces now, the usual “how much did Q4 hurt it” question starts from a different place: the vendor already answered it during training. That’s new for a model this size, and it’s the one spec that makes the local conversation more than academic.

Sparsity won’t save your GPU, but it changes the streaming math. Moonshot published the figure with the weights: 104B activated parameters of 2.8T, so roughly 3.7% of the model fires on any given token. As we covered in the weight-streaming reality check, MoE sparsity is exactly what makes disk-streaming viable-ish: GLM-5.2 at 753B runs from a 370 GB NVMe file at community-reported 0.3-1.2 tok/s. K3 more than quadruples that to a measured 1.56 TB. Streaming K3 will be possible in the way crossing an ocean in a rowboat is possible; the invoice will be measured in minutes per reply.

KV cache: this is where K3 stops behaving like anything else. The config splits its 93 layers explicitly: 24 use MLA, the compressed-latent scheme the whole K2 line uses (512 + 64 = 576 dimensions per token per layer). The other 69 layers use Kimi Delta Attention, and those store no per-token keys and values at all. Each one keeps a fixed recurrent state, 96 heads of 128×128, plus small convolution buffers, and that state is the same size whether you feed it a thousand tokens or a million.

So only a quarter of the model’s layers pay for context. Run the numbers through our calculator and the KV cache comes to 0.7 GB at 8K, 4.1 GB at 128K, and 7.7 GB at 256K. Even at the full 1M window the cache is roughly 29 GB, on a model whose weights are 1.56 TB. Context is under 2% of the bill.

That inverts the usual advice. On most models long context is the thing that breaks your budget, which is why our per-model breakdown tracks it so closely. On K3 the context is nearly free and the weights are immovable.

What the Calculator Says Now

Kimi K3 went live in the calculator the same day the weights did, built from Moonshot’s own config.json and modeling code rather than from the launch post. That is the rule that kept our Gemma 4 numbers right when much of the internet had them wrong, and it is why this page had no KV figure until today. Select K3 to see the split at your own context length and quantization tier. If you want the reverse question, check what your own GPU can actually run.

FAQ

How much VRAM does Kimi K3 need?

About 1,796 GB at 8K context and 1,829 GB at the full 1M window. That is 1,561 GB of weights (measured from the published MXFP4 files), plus 0.7 to 29.5 GB of KV cache depending on context, plus roughly 15% runtime overhead. For comparison, Kimi K2.5 computes to about 698 GB in our calculator, so K3 is close to three times its predecessor.

Can I run Kimi K3 on an RTX 4090 or any consumer GPU?

No, and not by a small margin. A 24 GB card would need roughly 75 of them to hold the weights. This is not a quantization problem either, because the published files are already 4-bit native. If you want a capable model that does fit a consumer card, check what your GPU can run, or rent time on a large GPU to try frontier models before buying anything.

Is there a Kimi K3 GGUF for llama.cpp?

Not at launch. Moonshot published safetensors in native MXFP4 and contributed an implementation to vLLM, but no official GGUF conversion shipped with the weights, and llama.cpp needs support for Kimi Delta Attention before community quants can work properly. Be sceptical of any “Kimi K3 GGUF” repository that appeared before the weights did.

Can CPU offloading make Kimi K3 run on less VRAM?

Not meaningfully. Offloading experts to system RAM works well for MoE models, as we show with a 118B model on a 12GB card and a 26B on an RTX 4060. But offloading moves the problem from VRAM to RAM, and K3’s 1.561 TB still has to live somewhere. You would need more system memory than most workstations can physically address.

Is Kimi K3 free for commercial use?

The weights ship under a custom Kimi K3 License, not MIT as pre-launch reports suggested. It grants broad rights to use, modify, distribute and sell, but adds a condition covering “Model as a Service” deployments. If you plan to serve K3 commercially through an API, read the licence in the repository rather than relying on any summary, including this one.

Can I run Kimi K3 locally?

Not on consumer hardware. The weights are genuinely public as of July 27, 2026, but the download is 1.56 TB measured, and Moonshot’s own guidance calls for supernode configurations of 64 or more accelerators. What changed at launch is that the requirement is now computable instead of speculative.

How big will the Kimi K3 download be?

1.561 TB, measured from the published safetensors index: 2.8T parameters shipping natively in MXFP4, which works out to 4.46 effective bits per weight once unquantized tensors are counted. That is roughly 3.8 times the Q4_K_M footprint of DeepSeek-R1 671B (407 GB), currently the largest model in our calculator.

How many parameters does Kimi K3 activate per token?

104 billion, published on Moonshot’s model card alongside the weights and repeated in the technical report abstract. That is 16 routed experts of 896, plus 2 shared, and works out to roughly 3.7% of the 2.8T total firing on any given token. It is a notably large active slice: DeepSeek-V4-Pro activates 49B and Kimi’s own K2.5 activates 32B. Sparsity governs compute, not memory, so all 2.8T parameters still have to be resident.

Is Kimi K3 really 2.5 trillion parameters?

No. That was the pre-launch leak number, and it survives on many aggregator sites. Moonshot’s official launch post says 2.8 trillion, a Mixture-of-Experts model activating 16 of 896 experts per token.

What is Kimi Delta Attention?

Moonshot’s new attention mechanism in K3, paired with Attention Residuals. The vendor claims up to 6.3× faster decoding at million-token contexts. With the config public we can now say what it does. K3 runs 93 layers: 24 use MLA, and the other 69 use KDA, which keeps a fixed recurrent state instead of a per-token KV cache. That state does not grow with context, so K3’s cache is about 7.7 GB even at 256K tokens.