Kimi K3 Hardware Requirements: The Honest Pre-Release Math
Last updated:
Status check: nobody outside Moonshot has run Kimi K3 locally yet — weights are due by July 27, 2026. But the published 2.8T parameter count lets us do honest arithmetic today: expect roughly 5.6TB of weights at BF16, 2.8TB at FP8, and 1.4–1.6TB at 4-bit, before KV-cache and runtime overhead. That is multi-node GPU territory, or extreme-RAM servers for slow offloaded inference. If you're hoping "MoE" means it secretly fits on a 4090 — it doesn't, and here's why.
The arithmetic, shown
Weight storage is parameters × bytes per parameter. There is no magic in this table — just the 2.8T figure from the launch listings multiplied out, which is exactly how K2's published file sizes tracked its 1T count:
| Precision | Bytes/param | Weights (≈2.8T params) | Realistic host |
|---|---|---|---|
| BF16 | 2 | ≈5.6 TB | research clusters |
| FP8 | 1 | ≈2.8 TB | multi-node H200/B200-class serving |
| INT4/Q4 | ~0.5 | ≈1.4–1.6 TB | terabyte-RAM server, heavy offload, slow |
Add KV-cache on top: at a 1M-token context, cache alone can claim hundreds of additional gigabytes depending on attention layout — the KDA architecture noted in the listings exists partly to tame this, but it doesn't eliminate it.
Why MoE sparsity doesn't rescue memory
Mixture-of-experts routes each token through a subset of experts, so compute per token scales with active parameters — likely a few tens of billions, if K3 follows K2's 1T-total/32B-active pattern (Moonshot hasn't published K3's active count). But routing is per-token and unpredictable: any expert can be needed at any moment, so all experts must be resident in fast memory or streamed at painful cost. MoE makes K3 fast for its size; it does not make it small.
Realistic deployment tiers, post-release
- Rented multi-GPU nodes (the practical "local"): an 8×H200-class node holds ~1.1TB of HBM — enough for an aggressive quant of K3 with paging; two nodes serve FP8 comfortably. vLLM/SGLang support will likely land fast, as it did for K2. By-the-hour rental beats API pricing only at sustained multi-billion-token monthly volumes — run yours through the cost calculator before buying anything.
- Extreme-RAM CPU boxes: a 1.5–2TB-RAM server can technically run a Q4 GGUF with llama.cpp-style offload at seconds-per-token speeds — fine for research curiosity, useless for serving.
- Consumer hardware: waits for distills. After every major open release, the community ships smaller distilled/pruned variants; those, not the full 2.8T model, are the realistic path to "K3 at home."
What to do before July 27
Follow moonshotai on Hugging Face for the drop; pre-provision storage and bandwidth (a Q4 file set is still a >1.4TB download); and prepare a 20-prompt eval suite from your own workload so you can compare a quantized local K3 against the API version on day one. We'll publish measured numbers — real file sizes, first tokens/sec reports, working configs — in the local deployment guide as soon as they exist. Until then, anyone quoting exact K3 tokens/sec is guessing; the arithmetic above is the only honest hardware answer available this week.
Frequently asked questions
Can a single GPU run Kimi K3?
No realistic chance for the full model: even at 4-bit quantization the weights alone are roughly 1.4–1.6TB, far beyond any single GPU's memory. Single-GPU setups will depend on community-made distilled or heavily pruned variants, if and when they appear.
How much disk space will Kimi K3 weights need?
Arithmetic from the 2.8T parameter count: about 5.6TB at BF16, about 2.8TB at FP8, and roughly 1.4–1.6TB at 4-bit quantization, before KV-cache and serving overhead. Official file sizes arrive with the July 27 release.
Does MoE mean Kimi K3 needs less memory?
No — MoE reduces compute per token because only some experts activate, but all experts must be resident (or streamed) in memory. Sparsity helps speed and energy, not the memory footprint.