Kimi K3.1 Pro Open Weights: 2.8T MoE, 1M Context and Day-0 vLLM Support

Moonshot AI announced Kimi K3.1 Pro on October 24, 2026, and said the full weights would follow by November 4. They did: the Hugging Face repo moonshotai/Kimi-K3.1-Pro was created on November 2 and last updated on November 5, and vLLM published day-0 serving support on November 4.

Kimi K3.1 Pro is a 2.8T-parameter mixture-of-experts model with 104B parameters active per token and a 1,048,576-token context window. Moonshot’s model card puts it at 65.7 on Terminal-Bench 4.0, just under Claude Opus 5.5 at 66.4 and ahead of GPT-6 Astra at 58.2. The weights are downloadable, but the license has a revenue clause that large API resellers need to read first.

What Moonshot released and when#

Moonshot’s announcement calls Kimi K3.1 Pro the first model in the K3.1 series and its most capable 3T-class model so far. It is a post-trained version of Kimi K3, and Moonshot says post-training compute went up sharply, with large-scale joint reinforcement learning across hundreds of downstream domains.

The announcement also introduced Kimi K3.1 Pro Highspeed, which Moonshot describes as the same intelligence at about 2 to 3 times the output speed. Both models are available in kimi.com, the Kimi app, Kimi Work, Kimi Code and the Kimi API. The Hugging Face repo covered here is Kimi K3.1 Pro.

Kimi K3.1 Pro specs from the model card#

The model card describes a natively multimodal model that takes text and images. These are the numbers that matter for anyone sizing hardware or comparing it with Kimi K3:

Hugging Face reports about 1.56 TB of stored files for the repo, with 96 safetensors shards. The MXFP4 weights come from quantization-aware training, so the release is already in its low-precision serving format rather than a BF16 checkpoint you quantize yourself.

What changed from Kimi K3#

The architectural change is in attention. The card says K3.1 Pro replaces Kimi K3’s full-attention Gated MLA layers with Gated DeepSeek Sparse Attention (Gated DSA) layers for more efficient long-context modeling. The layer count, expert count and 1M context stay the same.

vLLM’s post explains how the sparse layers work. Each of the 24 full-attention layers gets a small indexer with 32 heads of 128 dimensions. The indexer stores one FP8 key per token (132 bytes with its scale), scores every earlier token, and keeps the top 2,048. MLA attention then runs exactly, but only over those 2,048 tokens.

Dense MLA reads 576 bytes of FP8 latent per context token per layer. With DSA, a decode step still scans the whole context, but only through the 132-byte index keys, and then reads full latents for just 2,048 tokens. vLLM puts that at about 23% of the bytes dense MLA reads per layer at long context. Long-context decode is bound by memory bandwidth, so that is where the saving shows up.

Kimi K3.1 Pro benchmarks, with the caveats#

All of these numbers are Moonshot’s own, from the model card, at reasoning effort max, temperature 1.0 and top-p 0.95. The card notes that Kimi K3.1 Pro ran Terminal-Bench 4.0, SWE Marathon and DeepSWE through the Claude Code harness, and that competitor scores come from their own reports or leaderboards. Treat the table as vendor-reported, not independent testing.

The coding picture is mixed. K3.1 Pro is close to Opus 5.5 on Terminal-Bench 4.0 and ahead on SWE Marathon, but well behind both closed models on Program Bench and Terminal-Bench-Science. DeepSeek-V4.1-Flash-1017 edges it on DeepSWE.

Moonshot’s announcement adds one internal number: on Kimi Code Bench 3.0 Long-horizon, K3.1 Pro scores 61.2 against 55.95 for Kimi K3. That benchmark is internal, so there is no outside way to check it.

Serving Kimi K3.1 Pro with vLLM#

The model card recommends three inference engines: vLLM, SGLang and TokenSpeed. vLLM’s day-0 post covers NVIDIA GPUs, AMD GPUs, Google TPUs and Alibaba T-Head Zhenwu PPUs, and gives this NVIDIA quick start:

# See the Kimi K3.1 recipe for the Docker image and multi-node commands.
vllm serve moonshotai/Kimi-K3.1-Pro \
  --tensor-parallel-size 8 \
  --trust-remote-code \
  --load-format fastsafetensors \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3 \
  --speculative-config '{"model":"Inferact/Kimi-K3.1-Pro-DSpark-preview","num_speculative_tokens":5,"method":"dspark","draft_sample_method":"probabilistic"}'

The --speculative-config line points at a DSpark speculator checkpoint that vLLM itself labels a preview. vLLM says a more accurate speculator is in training, so expect that flag to change.

The hardware vLLM used tells you the class of machine this needs:

• NVIDIA: most measurements are on 8x GB300. At TP8 with FP8 KV cache, the cache holds about 3.04M tokens, or 2.9 concurrent 1M-token requests.
• AMD: Instinct MI355X at TP8, with an MXFP4 indexer option that cuts index-cache storage by 48.5%.
• Google: a 16-chip TPU v7x slice through vllm-torchtpu.
• Alibaba T-Head: Zhenwu PPU 810E on two nodes and M890 on four nodes, through the vllm-sail plugin.

KV cache choices for long context#

vLLM packs each block’s MLA latent, indexer keys and KDA state into one cache row, and the latent and index keys can be quantized separately. On 8x GB300 at TP8, FP8 for both holds about 3.04M tokens, and an NVFP4 latent with MXFP4 index keys holds about 1.7 times as many. Decode context parallelism (DCP8) shards the cache by token and holds 21.8M tokens of FP8 KV. The trade-off is per-step latency. At concurrency 1 and 32K context, vLLM measured 11.48 ms per output token with DCP8 against 9.35 ms with TP8. Its fused decode path brings DCP8 down to 5.96 ms. vLLM’s advice is to use DCP when KV capacity is the limit, such as very long contexts or many long-lived agent sessions.

Using the kimi-k3.1-pro API instead#

Moonshot serves the model on https://platform.kimi.ai as kimi-k3.1-pro, with OpenAI- and Anthropic-compatible APIs. Two details from the model card trip people up when they move an existing client over:

1. Reasoning effort. The top-level reasoning_effort field accepts "low", "high" and "max", and "max" is the default. If you don’t set it, every request runs at the highest effort level.
2. Preserved thinking. For multi-turn chats and tool calls, you must pass the complete assistant message back in messages, including reasoning_content and tool_calls, not just content.

A minimal request with the OpenAI Python SDK looks like this. Take the base URL and key from your platform.kimi.ai console:

import os
import openai

client = openai.OpenAI(
    base_url=os.environ["KIMI_BASE_URL"],  # from platform.kimi.ai
    api_key=os.environ["KIMI_API_KEY"],
)

response = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=[{"role": "user", "content": "Summarize the failing test output in ci.log"}],
    reasoning_effort="high",
    max_tokens=4096,
)
print(response.choices[0].message.content)

When the next turn goes back to the API, append the whole assistant message object, not a copy with only content. A client that strips reasoning_content breaks the preserved-thinking behavior the model card describes.

If you already run earlier Kimi models in Claude Code, start from the setup in Run Kimi K3 With Claude Code on Windows or WSL. Kimi K3 and K2.7 Code API pricing covers how Moonshot bills its API.

The Kimi K3.1-Pro License in plain terms#

The license grants permission to use, copy, modify, fine-tune, distribute and sell the weights and code, free of charge, with two added conditions:

The license defines Model as a Service as giving a third party access to inference or fine-tuning, for example via API, with meaningful control over inputs, parameters or training data. It excludes end-user products where the model only powers specific features, and simple relaying of requests to models hosted by others. An internal coding assistant that never exposes the model or its outputs to third parties looks like the internal use the exemption describes. A public inference API is the kind of business the MaaS clause describes, so check the wording with your own counsel before you build one on these weights.

Should you pull the weights?#

Kimi K3.1 Pro is worth a look if you already run multi-GPU inference and want an open-weight model whose vendor-reported Terminal-Bench 4.0 score sits within a point of Claude Opus 5.5. The MXFP4 release format and vLLM’s day-0 work on four hardware families make it practical on that class of hardware now.

For everyone else, the hosted kimi-k3.1-pro API is the route. Set reasoning_effort on purpose instead of taking the max default, and send the full assistant message back on every turn. Check the license before you resell access.