Kimi K3.1 Pro Requirements: 2.8T MoE at ~1.4TB (Est.), API $2/$10

Kimi K3.1 Pro is a roughly 2.8T-parameter Mixture-of-Experts model announced by Moonshot AI on October 23, 2026 (US time), a post-trained upgrade of Kimi K3 from July. Self-hosting it needs about 1.4TB for the weights alone even at 4-bit (estimate) ⏳ Pending weights, which means a multi-node GPU cluster, so for most people the practical route is the official API at $2 input / $10 output per 1M tokens.

Values marked ⏳ Pending weights are estimates based on K3's published figures, and we will replace them with confirmed values after the weights and model card are published (promised by November 4). Pricing and Moonshot-reported benchmarks are official figures and carry no marker. For background, see What is Kimi K3 and Kimi K3 open weights and self-hosting requirements.

These are theoretical values derived from the 2.8T parameter count. In practice you also need room for the KV cache, routing, buffers, and the vision encoder.

If you want to check quickly whether a model fits your GPU or Mac, our free VRAM calculator (no sign-up) estimates required VRAM from the model, quantization, and context length. Kimi K3.1 Pro is available in the model list (numbers are estimates until the weights are released).

It is available immediately in the Kimi apps, Kimi Code, and the API. The API offers a Zero Data Retention option, and free-plan usage is limited. Highspeed requires the Pro plan or higher in Kimi Code, and so does the 1M-token context there.

K3.1 Pro is described as K3 with substantially more post-training compute and additional reinforcement learning focused on coding, knowledge work, and agent tasks. Before the open release, Moonshot also removed cyberattack-related data from training to limit misuse; the test score dropped from 90.5% before removal to 81.0% for the released model. Note that the K3 repository and the K3.1 Pro checkpoint are separate artifacts, so K3 files cannot be reused.

Most of these numbers are Moonshot's own measurements; independent verification so far comes mainly from Artificial Analysis. Cyber benchmarks trail Claude Opus 5.5 and GPT-6 Astra. VentureBeat also reported allegations that some influencers promoted the model without disclosing paid relationships, which is one more reason to lean on independent benchmarks and your own test data. On the Kimi API, output speed is about 57.5 tokens per second with a time to first token of about 3.07 seconds (as of October 26).

Per 1M tokens, Kimi official API.

K3.1 Pro is about one-third cheaper than K3. Artificial Analysis puts the blended price (7:2:1 input, cache, output) at $1.54 per 1M tokens and the cost per Intelligence Index task at $2.11. However, the model is verbose: it produced about 150M output tokens on the index versus a median of 87M, so output-heavy workloads cost more than the headline price suggests. Highspeed doubles the unit price and Moonshot claims it is 2-3x faster, so reserve it for latency-sensitive uses such as interactive coding assistants and run batch jobs on the standard model.

An MoE model uses only 16 of its 896 experts per token, so compute scales with the active parameters. But which experts get picked depends on the input, so every expert must stay resident in memory. A small active count lowers compute cost, not the memory requirement. At 4 bits (0.5 bytes) per parameter, 2.8T parameters come to about 1.4TB, which is the basis of our estimate. K3 was trained with quantization-aware training for native MXFP4 weights, and its roughly 1.4TB distribution size reflects that. Whether K3.1 Pro ships in the same MXFP4 format is ⏳ Pending weights; a different format would change the real size considerably.

For K3, Moonshot recommended an expert-parallel plus tensor-parallel "supernode" of 64 or more accelerators with InfiniBand or NVLink-class interconnect. The same is likely for K3.1 Pro, but that is ⏳ Pending weights.

Even an M3 Ultra with 512GB cannot hold the 4-bit weights of ~1.4TB (estimate) ⏳ Pending weights. Two 512GB Macs (1TB total) still fall short at 4-bit. A 2-bit build (~700GB) might fit across two Macs, but its quality and speed are unknown, so any practical verdict has to wait for post-release testing. For now, assume there is no realistic way to run Kimi K3.1 Pro locally on a Mac.

For K3, Moonshot contributed its KDA implementation (including prefill caching) to the vLLM community alongside the weights; check SGLang support separately. If K3.1 Pro uses the same attention, similar support is likely, but you must verify the supported versions ⏳ Pending weights. An engine without KDA support may start up yet produce wrong output. Also, because the K3 and K3.1 Pro checkpoints are separate artifacts, converted files and configs prepared for K3 cannot be reused as is. Engine support can lag right after release, so read the release notes and open issues before settling on a setup.

The main reason to self-host is data sovereignty, not cost. Buying and running a 64-class GPU cluster tends to cost orders of magnitude more than API usage. Unless your data cannot leave your environment, the realistic order is to validate quality and real cost on the API first, then decide whether self-hosting is justified.

If your goal is to run a model locally, the shortest path is to pick one that fits your VRAM. See How to choose a GGUF quantization for guidance. As a reference point, the WASTE inference engine ran K3 on 29GB of RAM by streaming from SSD, but it is experimental and very slow, not suitable for production. Whether it works for K3.1 Pro is ⏳ Pending weights.

- Full license text (commercial use, redistribution, usage restrictions)
- Active parameter count (about 104B, or K3-like ~50B equivalent)
- Weight format and file size (MXFP4 or something else)
- vLLM and SGLang versions that support KDA
- Which providers offer day-0 hosting
- Vision encoder size and the extra memory image input needs

- OOM at load: first confirm the weights fit in total memory, with headroom for the KV cache and vision encoder; retry with a shorter context length
- Wrong output on an engine without KDA: check the engine version and upgrade to a KDA-capable release; do not reuse K3 configs or checkpoints
- Slow because of cross-node bandwidth: expert-parallel traffic becomes the bottleneck; redesign around InfiniBand or NVLink-class interconnect
- Cost overrun from verbose output: cap output length, ask for concise answers in the prompt, and measure output tokens to see real cost
- Hitting limits on the free plan: you have reached the usage cap; Highspeed and the 1M-token context need the Pro plan or higher in Kimi Code

If you are considering how to handle data when using a Chinese model's API internally, or running open-weight models on your own infrastructure, we also take inquiries through our AI consulting service.