Kimi K3是一个拥有2.8万亿参数的多模态MoE（每个token激活896个专家中的16个），上下文窗口高达100万token。其架构在多个方面与标准Transformer有所不同，每一处变化都改变了推理引擎的运作方式。本文将探讨Kimi K3的架构以及vLLM如何为其提供推理服务。

K3部署推理引擎指南

我们非常高兴地宣布，vLLM在Day-0即支持Kimi K3，这是迄今为止最强大的开源权重模型之一。上周，我们预览了生产级集成工作；今天，Moonshot AI的权重已公开，相关支持也已上线。

Kimi K3是一个2.8万亿参数的混合专家模型（每个token激活16/896个专家），基于Kimi Delta注意力（KDA）和注意力残差（AttnRes）构建，支持100万token的上下文窗口和原生视觉能力。K3的挑战在于，如何将KDA、MXFP4 MoE执行、KV缓存管理、前向填充/解码分离、推测解码以及长上下文部署方案，整合到一个实际可运行的推理引擎中。本文就是一份实用指南。

主要看点

Kimi K3是一个2.8万亿参数的多模态MoE（每个token激活16/896个专家），上下文窗口高达100万token，基于Kimi Delta注意力、注意力残差、Stable LatentMoE设计以及原生MXFP4（4位）权重构建。

🔷每用户最高370 token/秒：vLLM在NVIDIA GB300 NVL72上以118 token/秒的速度服务Kimi K3，启用DSpark推测解码后达到370 token/秒（提升了3.14倍）。

🔷发布即支持广泛功能：推测解码、前向填充/解码分离、基于Mooncake的代理KV缓存、工具调用、推理输出和结构化输出，支持NVIDIA（B200、B300、GB200、GB300）和AMD ROCm。

🔷vLLM支持DSpark，这是针对Kimi K3的最先进的推测解码算法，由Inferact使用vLLM训练并开源。

🔷为服务K3的混合循环加注意力设计，vLLM新增了核心基础设施：对循环（KDA）状态进行前缀缓存——这一改变使所有混合线性模型都受益。

Kimi K3的架构以及vLLM如何服务它

K3在四个方面偏离了标准Transformer，每一项都改变了推理引擎的职责。

Kimi K3架构创新，来自原始发布博文 https://www.kimi.com/blog/kimi-k3

Kimi K3架构创新，来自原始发布博文 https://www.kimi.com/blog/kimi-k3

Kimi Delta注意力：混合循环加全注意力栈。K3的大部分层是KDA，一种线性注意力机制，它维护固定大小的循环状态而非不断增长的KV缓存，并穿插定期的全注意力层以保留精确的全局回忆。这使得100万token的上下文变得经济实惠。

一个单一的混合KV缓存管理器在同一调度器下管理两种内存：用于全注意力层的分页KV块，以及用于KDA层的紧凑循环状态块。最困难的部分是对循环状态进行前缀缓存：KDA层没有每个token的KV可供哈希，因此vLLM将物理状态块大小与前缀匹配粒度分离，并在块边界重用状态快照，这样长的共享提示仍然可以命中缓存。

Kimi K3将Kimi Delta注意力（线性）层与定期的全注意力层交错排列；vLLM的混合缓存同时管理循环状态和分页KV。

Kimi K3将Kimi Delta注意力（线性）层与定期的全注意力层交错排列；vLLM的混合缓存同时管理循环状态和分页KV。

注意力残差：AttnRes将前几层的输出与softmax注意力混合，允许每个token的表示在整个网络深度上根据其内容进行自适应。vLLM实现了一个融合的CUDA内核，在单次启动中计算logits、跨前几层的softmax并进行聚合，将残差加法和输出RMSNorm折叠到同一内核中。

Stable LatentMoE：每个token被路由到896个专家中的16个。专家通过专家并行进行分片；vLLM提供两种针对不同拓扑优化的MoE后端：TRT-LLM-Gen用于张量并行（TP>1），MegaMoE用于分离/专家并行（DEP），以及可选的专家并行负载均衡（EPLB）。

MXFP4权重和原生视觉。K3的权重在训练时进行了4位MXFP4量化感知训练，因此低精度是原生的，而非事后转换。

服务语义：K3未附带Jinja聊天模板；其tokenizer通过Python程序渲染消息。vLLM在Python和Rust前端都实现了相同的渲染程序，因此工具调用、推理输出和结构化输出在两者之间行为一致。

为生产而构建

良好地服务2.8T混合MoE意味着：对单个用户快，对数千用户高效，对代理程序粘性好。vLLM提供的Kimi K3在这三方面都准备就绪。

超低延迟：要在2.8T模型上实现超低延迟且不损失精度，推测解码是自然的选择。这就是为什么vLLM从第一天起就支持DSpark，以及我们为K3训练并发布了我们自己的DSpark推测模型。DSpark使用块扩散骨干在单次并行传递中生成多个推测token，因此随着块加深，推测成本保持不变。我们使推测模型原生支持MLA，镜像了K3自身的注意力，因此推测模型和目标模型具有相似的KV布局。

Kimi K3 DSpark在各数据集上的位置接受率

Kimi K3 DSpark在各数据集上的位置接受率

使用相同的构建、提示和方法测得：每用户118 → 370 token/秒，在16块NVIDIA GB300 NVL72 GPU上提升了3.14倍（TP8上从111提升到331 token/秒）。提升幅度取决于输出的可预测性——对于编码和其他低熵任务，DSpark每步接受约4.73个token；对于创意写作等高熵任务，约为2.61个——因此加速比是在标准设置下的测量结果，并非普遍常数。推测模型和推理支持均在本次发布中开源。

大规模服务（前向填充/解码分离）：对于高吞吐量集群，vLLM通过跨节点的专家和数据并行来服务K3，并采用前向填充/解码（PD）分离，将前向填充密集型和解码密集型工作负载运行在不同的副本上，每个副本针对其瓶颈进行优化。经过验证的拓扑是TEP8前向填充 → DEP16解码，KV/状态通过NIXL在阶段之间移动。

前向填充/解码分离流程

前向填充/解码分离流程

代理型服务：代理型工作负载（长时间的多轮会话、工具循环、大型共享系统提示）需要精细的KV重用。vLLM的Mooncake集成允许K3在轮次和请求之间卸载和重用KV，因此重复的代码库、文档或代理草稿板不必在每次轮次中支付完整的前向填充费用。结合K3对循环状态的前缀缓存，这使得长代理会话在上下文累积时保持响应迅速。

性能与基准测试

以下所有测试均通过已发布的解析器，通过OpenAI兼容端点进行服务。

🔷GSM8K：0.976

🔷GPQA-Diamond：0.939

🔷OCRBench：0.889

🔷MMMU Pro Vision：0.818

在推理和知识方面，vLLM紧密跟踪Kimi K3报告的精度，这意味着内核、解析器和缓存端到端地保持了模型质量。

Kimi K3在批大小为1时的解码吞吐量，在2个GB300托盘、8块GB300 GPU上测量。

Kimi K3在批大小为1时的解码吞吐量，在2个GB300托盘、8块GB300 GPU上测量。

一个现场注意事项：K3在回答之前会进行大量推理。当评分较低时，请先检查是否存在被截断的答案，再假设答案错误，并考虑慷慨地增加max_tokens预算。

部署

快速启动（2.8T MoE至少需要一个8×B300节点才能运行）：

vllm serve moonshotai/Kimi-K3 \

–tensor-parallel-size 8 \

–trust-remote-code \

–load-format fastsafetensors \

–enable-prefix-caching \

–max-num-seqs 512 –max-model-len 32768 \

–enable-auto-tool-choice –tool-call-parser kimi_k3 \

–reasoning-parser kimi_k3

启用DSpark推测解码：

–speculative-config ‘{“model”:“Inferact/Kimi-K3-DSpark”,“method”:“dspark”,“num_speculative_tokens”:7,“attention_backend”:“FLASHINFER_MLA”,“draft_sample_method”:“probabilistic”,“rejection_sample_method”:“block”}’

部署说明，均来自实际事件：

🔷–enable-prefix-caching 开启前缀缓存，对于K3默认未开启。

🔷工具调用：请根据自身流量验证；生产代理应在tool_calls返回空时重试或回退，并考虑使用严格/结构化工具调用。

🔷–moe-backend：DEP环境使用deep_gemm_mega_moe，TP>1使用flashinfer_trtllm。

🔷–all2all-backend：NVLink使用flashinfer_nvlink_one_sided，RDMA使用deepep_v2。

常见问题

我需要多少块GPU？至少需要一个8×B300（或GB300）节点才能运行；大多数生产部署运行多节点，并采用专家和数据并行，通过RDMA或NVLink连接。

K3是否支持前缀缓存，默认是否开启？它支持对全注意力KV和循环KDA状态进行前缀缓存，但默认不开启——需要传递–enable-prefix-caching。

vLLM是否在AMD GPU上支持K3？是的。ROCm支持在发布时即提供，更广泛的调优已在路线图中。

完整配方、内核和完整文档：

🔷模型：huggingface.co/moonshotai/Kimi-K3

🔷DSpark推测模型：huggingface.co/Inferact/Kimi-K3-DSpark

🔷配方和Docker镜像：recipes.vllm.ai/moonshotai/Kimi-K3

🔷完整博文：vllm.ai/blog/2026-07-27-k3

为K3构建的基础设施现已成为后续每个模型的基础。

我们迫不及待地想看到您部署的成果。