Kimi K3 / MXFP4 deployment worksheet

1.56 TB of weights. 64+ accelerators.

Q: How much GPU memory does Kimi K3 need?

The official Kimi K3 repository contains 96 safetensors files totaling 1,560,936,091,448 bytes, or 1,453.74 GiB, before runtime workspace and context memory. Moonshot separately recommends a supernode configuration with 64 or more accelerators for inference efficiency.

Q: Can Kimi K3 run on eight H200 GPUs?

No straightforward full-checkpoint plan fits. Eight 141 GiB-class H200 GPUs provide 1,128 GiB of physical memory, 325.74 GiB less than the official weight files alone. At a 90 percent planning limit, the shortfall is 438.54 GiB.

Q: What is the minimum H200 count for Kimi K3?

Artifact-only arithmetic reaches the 1,453.74 GiB checkpoint at 12 H200-class GPUs when 90 percent of each 141 GiB device is treated as usable. That leaves only 69.06 GiB for everything beyond weights and is not an official or production-ready topology.

Q: Why does Moonshot recommend 64 or more accelerators for Kimi K3?

Kimi K3 activates 16 of 896 experts and depends on large high-bandwidth communication domains. Moonshot says inference efficiency benefits from supernode configurations with 64 or more accelerators. This is a serving and communication recommendation, not merely the minimum count that can hold the weight files.

Q: Does Kimi K3 support a one-million-token context window?

Yes. The official model card lists a 1,048,576-token context window. Actual context and concurrency fit still require runtime measurement because Kimi Delta Attention and Gated MLA do not reduce to a portable dense KV-head formula.

Moonshot's official checkpoint spans 96 weight files and 1,453.74 GiB. Twelve H200-class GPUs only clear that artifact floor; the official serving recommendation is a 64-plus-accelerator supernode.

Open the editable 16 × H200 weight plan →

Quick answer / memory floors

Eight H200s do not hold the checkpoint. Twelve barely clear the files.

These cards test resident-weight arithmetic only. They deliberately do not turn an artifact fit into a supported deployment claim. Moonshot's 64-plus recommendation addresses expert-parallel communication and inference efficiency at a different layer.

Artifact · 8 × H200 SHORT 438.54 GiB 1,015.20 GiB usable vs 1,453.74 GiB files → Raw floor · 12 × H200 69.06 GiB remains Artifact fits; practical serving reserve does not → Reserved floor · 16 × H200 1,744.49 GiB target Artifact + 20% reserve; context memory excluded → Official serving guidance 64+ accelerators Supernode recommendation for inference efficiency →

Artifact vs architecture

The files prove memory. The architecture explains the cluster.

The repository establishes what must be loaded. The model card establishes how little of the sparse model is active per token. Moonshot's release note establishes the communication domain it recommends for efficient serving.

Swipe the matrix horizontally →

Input	Official value	What it changes	What it does not prove
Checkpoint	1,453.74 GiB · 96 files	Resident-weight floor	Runtime or cache allocation
Total / active	2.8T / 104B parameters	Storage vs per-token compute	Single-node feasibility
Expert routing	16 of 896 + 2 shared	Communication and sparse compute	Low interconnect cost
Attention stack	69 KDA + 24 Gated MLA layers	Context-state layout	Portable dense KV-cache math
Native context	1,048,576 tokens	Maximum advertised window	Concurrent full-window capacity
Official recommendation	64+ accelerators	High-bandwidth serving domain	A universal minimum GPU count

Artifact totals were calculated from the official Hugging Face repository's 96 safetensors file sizes on August 7, 2026. Recheck the inventory and model card after runtime or checkpoint revisions.

Read the estimate

Active is not resident.
Only 104B parameters activate per token, but the 2.8T model still has to be stored and routed.

Twelve H200s is only math.
It leaves about 69 GiB beyond the files and is not Moonshot's supported topology.

One million tokens is runtime state.
Measure KDA and Gated MLA cache behavior under your actual concurrency.

Context and cache boundary

A one-million-token window does not come free with the weights.

Official configuration
93 layers · 1,048,576 context

Sparse model
896 experts · 16 selected · 2 shared

Native quantization
MXFP4 weights · MXFP8 activations

The calculator links use the exact checkpoint as the weight input and leave cache at zero. Kimi K3 combines KDA and Gated MLA, so a familiar dense 2 × layers × KV heads × head dimension estimate would manufacture false precision. Validate context length, batch size, and prefix-cache behavior in vLLM or SGLang.

Primary-source inputs

Start with Moonshot's files and recommendation.

Checkpoint bytes and architecture metadata come from Moonshot's official Hugging Face repository. The 64-plus-accelerator recommendation, availability, API pricing, and deployment rationale come from Moonshot's Kimi K3 release note.

Open the GPU memory calculator → Compare GLM-5.2 hardware → Find models for smaller GPU budgets → Official Kimi K3 model card → Official checkpoint inventory → Official Kimi K3 configuration → Official Kimi K3 release note →

How much GPU memory does Kimi K3 need?

The official weight files total 1,453.74 GiB before runtime workspace or context memory. Moonshot separately recommends 64 or more accelerators for an efficient supernode deployment.

Can Kimi K3 run on eight H200 GPUs?

No straightforward full-checkpoint plan fits. Even all 1,128 GiB of physical memory across eight 141 GiB-class devices is 325.74 GiB below the files; a 90% planning limit is 438.54 GiB short.

What is the minimum H200 count for Kimi K3?

Twelve clears the artifact-only floor at 90% usable memory, leaving about 69.06 GiB. That is not enough evidence for a practical runtime and is not Moonshot's recommended topology.

Why does Moonshot recommend 64 or more accelerators for Kimi K3?

Kimi K3 routes among 896 experts and needs a large high-bandwidth communication domain. Moonshot frames 64-plus as an inference-efficiency recommendation, not a simple weight-capacity minimum.

Does Kimi K3 support a one-million-token context window?

Yes, the official model card lists 1,048,576 tokens. Actual full-window concurrency must still be proven in the chosen runtime because KDA and Gated MLA have model-specific state behavior.