Text / Multimodal LLM
Self-hosting Kimi starts with one question: how many cards hold 1.56TB?
Moonshot AI has open-weighted everything from K2.5 through K2.7-Code to K3 — and those checkpoints span two orders of magnitude, 16B to 2.8T. Here is the honest VRAM arithmetic for each, and the cards to rent by the hour.
Kimi · self-hosted
Kimi is Moonshot AI's chat product, but engineers searching for "Kimi local deployment" are really after the pile of open weights sitting at huggingface.co/moonshotai. That line is long now: Kimi K2 in July 2025 (1T total / 32B activated, context stretched from 128K to 256K in the September update), K2 Thinking in November, K2.5 in January 2026 adding native multimodality plus instant and thinking modes, K2.6 on 20 April bringing Agent Swarm, K2.7-Code on 12 June aimed squarely at agentic coding, and then K3 with open weights on 27 July — 2.8T total, 104B activated, 1M context.
Each generation rewrites the self-hosting arithmetic. Every release from K2 Thinking onward ships a native INT4 checkpoint, quantised with QAT during post-training rather than bolted on afterwards with GPTQ. That is why a trillion parameters land at roughly 594GB on disk (about 630GB for K2.7-Code) and measure around 640GB of VRAM in practice, on the officially validated 8x H200 141GB, TP=8 configuration. K3 pushes harder: MXFP4 weights with MXFP8 activations, quantisation-aware from the supervised fine-tuning stage onward, and a Hugging Face repo of 96 safetensors shards totalling 1.561TB. That is no longer a "will it fit on one card" question.
So the real question is never "how much VRAM does Kimi need" — it is "which Kimi do you want?" For vision reasoning, Kimi-VL-A3B-Thinking-2506 is 16B under a plain MIT licence and fits on a single 48GB card. To probe KDA linear attention and million-token context, Kimi Linear 48B-A3B needs about 102GB at FP16 — two A100 80GBs. For K2.6's multimodal agent stack, eight H200s is the entry point. For K3 at native precision, budget 1.7TB of aggregate VRAM. NexGPU runs from $0.188/GPU-hour V100s up to 141GB H200s, with up to 14 GPUs and 2,152GB of VRAM in a single node — all four routes are rentable.
01 —
Kimi open-weight releases, side by side
From 16B on one card to 2.8T across a rack, all under the same moonshotai org
| Version | Parameters | VRAM | Context | Notes |
|---|---|---|---|---|
| Kimi K3 | 2.8T-A104B (896 experts, 16 routed + 2 shared) | Native MXFP4 checkpoint 1.561TB; community GGUF bottoms out at UD-IQ1_S 594GB (RAM+VRAM >= 610GB recommended) | 1,048,576 (1M) | Current flagship and the first shipping model built on Kimi Delta Attention (69 KDA layers + 24 Gated MLA). Thinking is always on, image and video input are native. Licensed under a standalone Kimi K3 License, not MIT. |
| Kimi K2.7-Code | 1T-A32B (384 experts, 8 routed + 1 shared) | Native INT4 around 630GB; needs an 8-GPU box with >=140GB per card (TP=8) | 256K | Agentic coding specialist. Thinking is forced and preserve_thinking stays on, yet it burns roughly 30% fewer thinking tokens than K2.6. Third-party engines do not support video input or instant mode. |
| Kimi K2.6 | 1T-A32B (61 layers, MLA hidden 7168 / 64 heads) | Native INT4 around 594GB, roughly 640GB VRAM measured | 256K | The general-purpose workhorse, with a 400M MoonViT vision encoder and Agent Swarm. Modified MIT, runs on vLLM, SGLang and KTransformers — the best value in the 1T tier for self-hosting. |
| Kimi K2.5 | 1T-A32B | Native INT4 around 594GB | 256K | The first natively multimodal K2, with 15T tokens of vision-language pretraining and switchable instant / thinking modes. Pick it if you need low-latency non-thinking responses — K2.7-Code no longer lets you turn thinking off. |
| Kimi Linear 48B-A3B-Instruct | 48B-A3B | About 102GB at FP16 (1K context) / about 114GB at the full 1M context | 1M | The public proving ground for KDA: linear attention interleaved with MLA at 3:1, KV cache cut by roughly 75%, decoding up to about 6x faster. The cheapest way to learn how K3's architecture behaves. |
| Kimi-VL-A3B-Thinking-2506 | 16B-A2.8B | About 32GB at bf16 (budget ~40GB with the vision tower and KV) | 131,072 | MIT-licensed vision reasoning model, up to 3.2 million pixels in a single image, 65.2 on VideoMMMU. The only member of the family that genuinely fits on one consumer or workstation card. |
02 —
Four Kimi self-hosting scenarios, four honest GPU picks
VRAM matched for real: nobody gets told a 1T model runs on a 24GB card
Single card, Kimi-VL-A3B-Thinking-2506 for vision reasoning evals
RTX A6000 48GB$0.817/GPU-hour
16B at bf16 is about 32GB; 48GB leaves room for MoonViT's high-resolution tiles and a 128K KV cache without tensor parallelism or extra quantisation.
Two cards, Kimi Linear 48B-A3B to test KDA and 1M context
A100 PCIE 80GB x 2$0.824/GPU-hour
Published FP16 usage starts at 102GB and reaches about 114GB at the full million-token context; 160GB aggregate covers it with headroom for CUDA graphs and batching.
Production Kimi K2.6 / K2.5 / K2.7-Code on the native INT4 checkpoint
H200 141GB x 8$6.660/GPU-hour
This is the officially validated 8-GPU TP=8 shape. After roughly 640GB of weights, the remaining 1,128GB of aggregate VRAM goes entirely to the 256K KV pool and concurrency.
K3 at native MXFP4 precision on a single node
H200 141GB x 14$6.660/GPU-hour
Spread across 14 cards, the 1.561TB checkpoint is about 112GB of weights per GPU; 1,974GB aggregate leaves more KV headroom than the published 16-GPU two-node report (102.75GB weights + 7.95GB KV per card).
03 —
From cold instance to a working Kimi endpoint
K2.6 native INT4 as the main line, with K3's topology and the budget route alongside
- 01
Launch the box and pull the weights — check the repo size first
Pick an 8x H200 node in the NexGPU console and one of the prebuilt vLLM images (CUDA and PyTorch already in place, from 2,000+ images). K2.6's INT4 weights are about 594GB; K3 is 1.561TB across 96 shards, so size the data volume before you start. Compute is metered per second and stops when the instance stops, but storage keeps billing until you destroy the volume.
hf download moonshotai/Kimi-K2.6 --local-dir /workspace/Kimi-K2.6 - 02
Serve with vLLM — neither parser is optional
Kimi's thinking traces and tool calls only come out cleanly through dedicated parsers: drop --reasoning-parser and you never see reasoning_content, drop --tool-call-parser and you get raw text instead of structured calls. Run the multimodal encoder data-parallel — MoonViT's overhead grows as TP goes up. transformers must be >=4.57.1,<5.0.0.
vllm serve /workspace/Kimi-K2.6 -tp 8 --mm-encoder-tp-mode data --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2 --max-model-len 262144 - 03
Echo reasoning_content back on every multi-turn tool call
This is the single most common self-hosting failure. In multi-step tool calling, the reasoning_content from the previous assistant message must go back into the context verbatim or the request errors out. Tool call IDs also have to follow the functions.{name}:{idx} format — feed the model a malformed id like search:0 in the history and it will happily generate broken ids from then on. Sample at the recommended temperature 1.0 and top_p 0.95.
messages.append({"role": "assistant", "reasoning_content": msg.reasoning_content, "tool_calls": msg.tool_calls}) - 04
Budget route: run K3 as a low-bit GGUF under llama.cpp
If you will not pay for 1.561TB, take the community quants. Unsloth's dynamic ladder runs UD-IQ1_S at 594GB (about 78.9% top-1, PPL 2.58), UD-IQ1_M at 648.9GB (81.2%), UD-Q2_K_XL at 861.3GB (90.4%, PPL 1.74), and UD-Q8_K_XL at 1,560GB for lossless. Rule of thumb: RAM plus VRAM should roughly equal the quant's file size. One warning — Hopper has no native MXFP4, so SGLang falls back to marlin dequantisation; the public report shows 16.8 tok/s single-stream and about 147 tok/s at 54 concurrent requests, with roughly eleven minutes just to load weights. Point Triton's JIT cache at local /tmp, not a shared filesystem, or ranks collide and crash.
./llama.cpp/llama-server --model /workspace/K3/UD-IQ1_S/Kimi-K3-UD-IQ1_S-00001-of-*.gguf --mmproj mmproj-BF16.gguf --ctx-size 32768 --temp 1.0 --top-p 0.95 -ngl 99
What running Kimi actually costs
A six-hour private K2.6 evaluation: eight H200s at 8 x $6.660 = $53.28/hour, so $319.68 for the run. Keep the 594GB INT4 checkpoint for three days at 594 x $0.414 / 30 x 3 = about $24.59. Export 20GB of logs and results at 20 x $0.0081 = about $0.16. Total roughly $344.43, and compute billing stops the moment you stop the instance. Want the cheap lane instead? Kimi Linear 48B-A3B on two A100 PCIE 80GBs is 2 x $0.824 = $1.648/hour — a full week of 168 hours costs $276.86, less than those six hours above. And if you insist on K3 at native precision, own the number: 14 H200s is $93.24/hour, and the roughly eleven minutes of weight loading plus 40 seconds of CUDA graph compilation costs about $20.2 on its own under per-second metering. Tune without restarting the server where you can. No minimum, no setup fee, no quota request — those are the only line items.
04 —
FAQ
Can I deploy Kimi locally on a single 24GB GPU?
Should I self-host Kimi K3 or Kimi K2.6?
Do Kimi's open-weight licences allow commercial use?
Why is a 1T model only 594GB? FP16 math says 2TB.
Is self-hosting Kimi cheaper than the official API?
Is Kimi K2 Thinking still worth deploying?
Start building on NexGPU
Enterprise R&D team or solo developer — either way, your first job can be running in minutes.
Sign up to browse live network pricing. No payment method required.
