vLLM 预览生产级 Kimi K3 支持
A Preview of Production-Scale Kimi K3 Support on vLLM
vLLM 发布博客,预览为 Moonshot AI 的 Kimi K3 提供 day-0 开源推理支持,涵盖模型实现、Docker 镜像、部署配方与生产验证。Kimi K3 为 2.8 万亿参数模型,具备原生视觉、100 万 token 上下文窗口、KDA 与 AttnRes 混合注意力及高度稀疏 MoE 架构,完整权重计划于 2026 年 7 月 27 日前发布。
vLLM 披露为 Kimi K3 做 day-0 支持的技术细节,读者可了解混合注意力模型在推理引擎侧带来的缓存与内核改造。
上周,Moonshot AI 推出了 Kimi K3,这是一个拥有 2.8 万亿参数的模型,具备原生视觉支持、100 万 token 上下文窗口、Kimi Delta Attention(KDA)、Attention Residuals(AttnRes)以及高度稀疏的混合专家架构。该发布立即引起了全球关注,开源社区对开放权重模型正快速追赶最佳专有模型感到极为兴奋。
Moonshot AI 已宣布,完整模型权重将于 2026 年 7 月 27 日发布。在此期间,vLLM、Moonshot AI、NVIDIA、AMD 以及更广泛的社区正在完成最后的集成与验证,以便开源社区能够从第 0 天起就部署 Kimi K3。
本文是一篇预览,性能优化仍在进行中,但核心模型路径、KDA 感知前缀缓存、多模态集成、工具调用解析器以及硬件特定优化已初具雏形。经 Moonshot AI 和 vLLM/Inferact 团队双方批准的精选可信合作伙伴,也已开始使用与即将开源相同的代码进行部署验证。
正如发布博客中所述,KDA 对传统前缀缓存提出了新的挑战,Moonshot AI 团队已向 vLLM 项目贡献了相应实现,将与模型权重一同发布。我们将在未来的博客文章中专门解释其设计。
TL;DR
- 第 0 天开源服务:vLLM 正在为 Kimi K3 权重发布准备模型实现、Docker 镜像、部署方案和生产验证。
- 全新混合架构:Kimi K3 将 KDA 主导的线性注意力与周期性全注意力层、跨深度的 AttnRes、Stable LatentMoE 以及原生视觉支持相结合。
- 前缀缓存需要核心改动:vLLM 现在将物理 KDA 状态块大小与前缀匹配粒度分离,从而在不于每个小注意力块存储循环状态的情况下,实现有用的部分前缀缓存命中。
- 全栈内核工作:发布分支包含 FlashKDA 集成、融合 KDA 解码、融合 KDA 投影与卷积、融合 AttnRes、重新实现的 MLA 模块、启用 SiTU 的 MXFP4 MoE 执行以及优化的专家路由。
- NVIDIA 和 AMD 支持:NVIDIA 专用内核正在进行最终调优,而采用 FlyDSL MoE 内核的初始 AMD 实现已经就位,并正在推进更广泛的验证。
Kimi K3 一览
Kimi K3 并非 Kimi K2 的放大版本。Kimi K3 同时在多个维度上改变了服务问题。
| 属性 | Kimi K3 配置 | 服务影响 |
|---|---|---|
| 模型规模 | 2.8T 参数 | 需要大规模专家并行和高带宽加速器域 |
| 上下文长度 | 100 万 token | 使缓存容量、前缀复用、分块预填充以及预填充/解码分离成为首要关注点 |
| 注意力 | 混合 KDA 与全注意力 | 要求循环状态缓存和分页 KV 缓存必须在完全相同的逻辑前缀上推进 |
| 深度 | Attention Residual | 增加了跨层表示读写,需要专用内核 |
| MoE | 896 个路由专家,每 token 激活 16 个,外加共享专家 | 使路由、调度、负载均衡和 MoE 内核成为端到端性能的核心 |
| 量化 | 提供的发布配置中的 MXFP4 权重 | 需要一条高效的 FP4 MoE 路径,并搭配 Kimi K3 的 SiTU 激活 |
| 多模态 | 原生视觉,配备视觉塔 | 需要多模态预处理(仅图像)以及稳健的视觉并行策略 |
对于推理系统而言,这些选择中的每一项都会将成本转移到新的地方。KDA 减少了对每个过去 token 保留传统 KV 对的需求,但引入了大型循环状态。AttnRes 减少了单一残差流的限制,但产生了额外的跨层内存流量。极端的 MoE 稀疏性避免了对每个 token 激活全部 2.8T 参数,但提高了路由和通信的风险。vLLM 的工作就是让所有这些部分在一个熟悉的 serving API 背后协同工作。
历经多代 Kimi 构建的合作
Kimi K3 延续了 Moonshot AI 与 vLLM 社区之间的长期合作。
- 在 GOSIM 2024 上,Moonshot AI 的工程师介绍了 vLLM 如何在 Moonshot AI 内部大规模使用,并讨论了 vLLM + Mooncake 的预填充/解码分离架构。
- Moonshot AI 随后在 vLLM 北京 Meetup 上分享了 Kimi K2 的训练和推理实践,包括在服务在线流量时严格遵守 SLO,以及支持强化学习工作负载。
- vLLM 一直是 Kimi K2、Kimi K2-Thinking、Kimi K2.5、Kimi Linear 等的 day-0 发布合作伙伴。
- vLLM 与 Moonshot AI 的工程师有着深入的技术合作,包括为正确性而进行的 Kimi K2 工具调用准确性、为开发而进行的 改进的 CUDA 调试、解码上下文并行、基于 Mooncake 的 PD 分离,以及大规模性能验证。Kimi K2.5 也出现在公开的 InferenceX 服务结果中。
这段历史很重要。Day-0 支持很少是发布公告后写的一个拉取请求。它来自模型和推理团队提前分享架构细节、在真实的并行条件下测试真实检查点、识别服务引擎中的差距,并向上游提交在发布后仍然有用的改进。vLLM 很自豪能成为 Moonshot AI 的长期合作伙伴,以及 Kimi 系列模型的热门推理引擎。
现在,让我们深入探讨我们遇到的最有趣的技术挑战之一。
最难的部分:KDA 的前缀缓存
传统的全注意力和 KDA 以非常不同的方式记住前缀。
在全注意力中,前缀由每个 token 的键和值向量表示。vLLM 将这些向量存储在分页块中,对完整的 token 块进行哈希,并可以为另一个请求重用匹配的块序列。
KDA 是循环的。KDA 不是为每个 token 保留传统的 KV 对,而是每个 KDA 层推进一个类似矩阵的循环状态,以及一个短卷积状态。为了从缓存的前缀恢复,引擎需要在确切的前缀边界处的 KDA 状态。重放较早的状态以到达该边界会抹去前缀缓存的大部分好处。

最直接的解决方案——在每个小的注意力缓存边界处存储 KDA 状态——成本太高。KDA 状态比一个普通 token 的 KV 条目大得多,因此实现上会使用相对较大的物理状态块来分摊存储开销。在此项工作之前,该物理块大小也限制了前缀缓存命中可以落在哪里。在数千 token 的状态块下,两个几乎共享整个提示词的请求仍可能错过可复用的前缀,因为它们的公共边界没有填满同一个物理块。
新的 vLLM 设计将过去一起变动的三个概念分离开来:
- 物理块大小:KDA 状态和全注意力 KV 在 GPU 上如何分配。
- 调度器对齐:执行必须在哪里停止,以使所有缓存组保持一致。
- 前缀匹配单元:共享前缀被哈希并可能被匹配的更细粒度 token 区间。

这使 vLLM 能够在更大的物理状态块内的细粒度边界处注册有效的 KDA 状态。当后续请求命中该部分块时,缓存的状态会在请求扩展它之前被复制到私有目标位置。这条写时复制规则保留了共享的缓存前缀,同时允许新请求安全地继续生成。
该实现还处理了一些容易被忽略的细节:
- 调度器在正确的块和哈希边界处停止,以便所注册的循环状态确实对应于所声明的 token 前缀。
- 全注意力和 KDA 缓存组在一个
num_computed_tokens上达成一致,即使它们的物理块大小不同。 - 部分缓存条目使用链式、细粒度的哈希,因此边界标识的是整个前缀,而不仅仅是尾部 token。
- 同一步复用会被推迟到状态复制安全之后,避免缓存注册与扩展之间的竞态。
- 缓存传输和分离式预填充/解码路径可以在不同 worker 之间携带相同的逻辑前缀。
这项工作受到 Kimi K3 和许多其他混合注意力模型的启发,但它是 vLLM 的核心基础设施,而非特定于模型的捷径。vLLM 团队和 Moonshot AI 团队在设计上进行了深度合作。两个团队将另行发布一篇文章,更详细地介绍设计、不变量和基准测试。
性能工作:消除新的瓶颈
我们目前的进展可以总结为下表:
| 领域 | 当前状态 |
|---|---|
| 模型与配置 | Kimi K3 语言和视觉模型定义已集成,在硬件路径不同的地方分别提供 NVIDIA 和 AMD 实现 |
| 面向原生 PD 分离部署的优化 MLA 模块 | 优化后的 MLA 模块,包含手动内核融合以及独立的预填充/解码路径。门控投影与注意力并行运行,解码中支持多流,预填充中采用融合尾声——针对 PD 分离部署进行了高度优化。 |
| 服务语义 | Kimi K3 聊天渲染、tokenizer 集成、流式解析、工具调用、推理输出和结构化输出路径均已实现,并处于最终端到端验证中 |
| KDA 预填充 | FlashKDA 和 Triton 路径已集成;最终后端选择和数值验证正在进行中 |
| KDA 解码 | 集成了融合的 NVIDIA 解码内核,覆盖卷积、循环 KDA 更新、门控和归一化,并保留了可移植的回退路径 |
| 前缀缓存 | 集成了针对混合全注意力 + 循环状态缓存的细粒度部分前缀命中;分离式与卸载场景正在验证中 |
| 注意力残差 | 集成了 Triton 和 NVIDIA 内核,包括在支持的形状上将残差加法与输出 RMSNorm 融合 |
| MoE | Kimi K3 的 SiTU 激活已接入 MXFP4 TRTLLM-Gen 和 DeepGEMM 路径;优化后的分组 top-k 路由已集成。AMD 实现了 FlyDSL 的 MLIR 内核栈,包含硬件调优的 A16W4/A8W4 融合算子和 SiTU 激活 |
| 生产栈 | 非分离式服务已可运行;Dynamo + vLLM + Mooncake 分离式服务、专家并行和厂商验证正处于最终验证环节 |
Kimi K3 改变了热路径,因此团队优化的不只是注意力内核本身。以下是各领域进展的详细信息。
KDA 预填充与解码
预填充路径集成了 FlashKDA 和 Flash Linear Attention(FLA)。围绕核心循环,vLLM 融合了输入投影和因果卷积,并在一次操作中收集初始循环状态。
解码在支持的架构和形状上使用融合的 NVIDIA 内核。融合路径不再为每个生成的 token 分别启动短卷积、KDA 状态更新、输出门控和归一化的独立操作,而是一次性完成它们。这一点尤为重要,因为 Kimi K3 包含许多 KDA 层;每层微小的启动或内存开销很快就会变成巨大的 TPOT 开销。
注意力残差
AttnRes 从更早层块写入的表示中检索,而不是仅依赖单一均匀累积的残差流。朴素实现会在整个 93 层网络中产生额外的读取、写入、归约和归一化启动。
发布分支包含一个 Triton 实现和一个 NVIDIA 内核,在支持的场景下融合残差更新、AttnRes 混合和输出 RMSNorm。序列并行工作还将注意力残差流量分片到各 rank 上。早期的内核级结果令人鼓舞,而端到端收益仍在跨预填充长度和并行配置进行测量。
面向原生 PD 分离部署的优化 MLA 模块
Kimi K3 仍然每四层使用一次 MLA 注意力。在上一代模型中,vLLM 严重依赖 torch.compile 自定义融合路径将小内核映射为融合内核,这拖慢了启动速度,并且仍有许多内核未被融合。在此版本中,我们实现了一个新的 MLA 模块,手动融合这些内核。MLA 还要求预填充和解码采用不同的内核启动顺序,因此我们实现了两条具有不同融合模式的代码路径,专门针对 PD 分离部署。此外,Kimi K3 引入了可与主注意力路径并行执行的门控投影。我们在解码路径中可选地为门控投影添加多流支持,而在多流重叠并非最优的预填充路径中,我们将逐元素乘法和 sigmoid 融合到门控投影的尾声(epilogue)中。
MXFP4 MoE
Kimi K3 的发布配置使用 MXFP4 权重和 SiTU 激活。在这项工作之前,MXFP4 TRTLLM-Gen 路径不支持 SiTU,会回退到较慢的实现。vLLM 现在将 Kimi K3 的 SiTU 参数映射到优化的 FP4 专家路径中,并通过安全地对工作负载进行分块来处理大型 token-by-top-k 启动网格。
这已在 16-GPU DP16+EP16 配置上得到验证,其中所有 rank 都选择了优化的 MXFP4 后端并通过了正确性检查。
在 AMD 方面,Kimi K3 MoE 在 FlyDSL 的 MLIR Python 内核栈上得到支持。这包括硬件调优的 A16W4/A8W4 量化融合算子以及 SiTU 激活实现,全部构建在 FlyDSL 的模块化抽象之上。
开源日可以期待什么
计划中的 day-0 包包括:
- vLLM 模型、解析器、缓存和内核集成;
- 初始开源 Docker 镜像;
- 针对 NVIDIA 配置的经过验证的启动配方;
- 带有 FlyDSL MoE 内核的初始 AMD 路径,后续会有更多 ROCm 调优;
- 多模态、工具使用、推理和结构化输出示例;
- 初始性能结果。
受信任的部署合作伙伴已经在 Moonshot AI 和 vLLM/Inferact 的双重审批流程下测试候选发布版本。这提供了真实的生产反馈,而无需广泛分发预发布模型工件。这也让我们有机会测试完整的服务系统——前端语义、批处理、缓存传输、专家并行、可观测性和故障处理——而不仅仅是孤立的内核。
致谢
Kimi K3 day-0 支持是模型供应商、推理引擎和硬件社区共同努力的成果。
我们感谢 Moonshot AI 团队 创建了 Kimi K3,在权重发布前分享架构细节,贡献了初始模型集成和 KDA 前缀缓存工作,并在正确性和生产验证方面密切合作。
我们感谢 Inferact 团队 将模型集成到 vLLM 中,扩展核心缓存管理器以支持部分混合前缀命中,实现服务语义和多模态支持,构建部署配方,并推动端到端性能优化。
我们感谢 NVIDIA 团队 提供 KDA 解码和 Attention Residual 内核、MXFP4 MoE 协作以及全面的性能工作。
我们感谢 AMD 团队 提供初始 day-0 ROCm 支持,并继续在 AMD GPU 上扩展 Kimi K3。
最重要的是,我们感谢更广泛的开源社区对 Kimi K3 的期待、测试和反馈。我们期待将权重和推理引擎支持交到您手中。
还有一件事:为什么公告和开源发布是分开的
Kimi K3 还采用了一个我们希望更多模型供应商考虑的发布流程:先发布模型公告,然后再发布权重和推理引擎支持。
vLLM 团队提出了这种分离,Moonshot AI 同意并执行了。原因很实际。前沿模型的公告存在不可避免的最后一刻不确定性。模型团队同时在稳定自己的产品、API、评估、安全工作、文档和商业发布。如果开源权重和开源支持必须在同一时刻落地,像 vLLM 这样的社区项目就会受到截止日期变动的影响。
将两个时间线分开为双方提供了更好的契约:
- 模型供应商可以专注于其产品发布,并冻结最终检查点、配置、分词器和服务语义。
- 开源推理引擎团队获得一个稳定的集成窗口,用于正确性测试、性能调优、Docker 构建和配方验证。
- 社区获得一个公开且有明确边界的预期,而不是含糊的“即将推出”。
这种分离并非放弃 day-0 支持。它是一种更可持续的方式,针对用户实际会下载的产物提供 day-0 支持。我们鼓励更多模型供应商效仿!
来源:vLLM Blog · vllm.ai