跳到正文
vLLM Blog· vLLM Team·· 2026-07-22精选AI 评分74

vLLM 预览生产级 Kimi K3 支持

A Preview of Production-Scale Kimi K3 Support on vLLM

AI 导读

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 支持的技术细节,读者可了解混合注意力模型在推理引擎侧带来的缓存与内核改造。

正文 · AI 翻译

上周,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增加了跨层表示读写,需要专用内核
MoE896 个路由专家,每 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 状态。重放较早的状态以到达该边界会抹去前缀缓存的大部分好处。

How conventional attention and KDA represent cached prefixes
传统注意力和 KDA 如何表示缓存的前缀

最直接的解决方案——在每个小的注意力缓存边界处存储 KDA 状态——成本太高。KDA 状态比一个普通 token 的 KV 条目大得多,因此实现上会使用相对较大的物理状态块来分摊存储开销。在此项工作之前,该物理块大小也限制了前缀缓存命中可以落在哪里。在数千 token 的状态块下,两个几乎共享整个提示词的请求仍可能错过可复用的前缀,因为它们的公共边界没有填满同一个物理块。

新的 vLLM 设计将过去一起变动的三个概念分离开来:

  • 物理块大小:KDA 状态和全注意力 KV 在 GPU 上如何分配。
  • 调度器对齐:执行必须在哪里停止,以使所有缓存组保持一致。
  • 前缀匹配单元:共享前缀被哈希并可能被匹配的更细粒度 token 区间。
Fine-grained prefix matching inside a larger physical KDA state block
在更大的物理 KDA 状态块内进行细粒度前缀匹配

这使 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 融合
MoEKimi 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 这样的社区项目就会受到截止日期变动的影响。

将两个时间线分开为双方提供了更好的契约:

  1. 模型供应商可以专注于其产品发布,并冻结最终检查点、配置、分词器和服务语义。
  2. 开源推理引擎团队获得一个稳定的集成窗口,用于正确性测试、性能调优、Docker 构建和配方验证。
  3. 社区获得一个公开且有明确边界的预期,而不是含糊的“即将推出”。

这种分离并非放弃 day-0 支持。它是一种更可持续的方式,针对用户实际会下载的产物提供 day-0 支持。我们鼓励更多模型供应商效仿!

来源:vLLM Blog · vllm.ai