Kimi K3 vLLM 优化：NVIDIA 解码速度提升 1.68×

NVIDIA 已向 vLLM 贡献了一种专用的 Kimi K3 解码实现，再次展示了软件如何在现有硬件上提升推理速度。IT Home 报道称，SemiAnalysis 于 10 月 18 日发布的内容显示，这款 2.8 万亿参数模型每位用户可达到 423 tokens per second，并且在同一 GB300 NVL72 硬件上的速度提升了 1.68×。

需要特别说明的是，这里的指标有其适用范围。随附图表的横轴标注为 P90 interactivity in tok/s/user。这是衡量单用户流式性能的指标，并不代表机架的总 token 输出量、不保证每个请求都能达到该表现，也不意味着服务流水线的每个环节都提升了 68%。

报告结果及其基准测试背景

SemiAnalysis 的图片对比了标注为 Dynamo vLLM 的 GB300 NVL72 配置，并列出了 10 月 18 日和 9 月 15 日两个日期。图中以预计总拥有成本对应的每美元总 token 数为参照，展示了单用户交互性能指标。

IT Home 转载的 SemiAnalysis 结果及图表。

本文查看的 InferenceX 实时仪表盘选择的是 Kimi K3 2.8T、Agentic、FP4，运行日期为 10 月 18 日。其表格显示，GB300 NVL72 的最高 P90 交互性能为 424 tok/s/user。这是之后查看到的实时页面数据，不能据此擅自将原帖中的 423 改为其他数值。

仪表盘还单独报告了每芯片吞吐量。这些指标不应合并或相互替代：针对单个数据流速度进行优化的配置，可能会牺牲总体吞吐量；而高吞吐量配置对每位用户的数据流输出速度可能较慢。

在审阅的材料中，原帖所突出展示的数据点对应的确切并发数以及提示词/输出长度尚未得到确认。具体来说，仪表盘初始静态 HTML 中显示的是通用的 8K/1K 选择，而完全加载后的页面则选择了 Agentic。不能把静态默认值说成报告结果对应的工作负载规格。

CuTeDSL 专用解码路径

SemiAnalysis 的帖子将这一实现归功于 NVIDIA CentML 工程师 Benjamin，并称其使用 CuTe DSL 完成了约 12,000 行的 megakernel 工作。上游实现可直接追溯至 vLLM pull request #61867，标题为 Kimi K3 Specialized Decode: CuTeDSL Optimized GB300 (1.5–2x)。

该 PR 介绍了一种由 NVIDIA 开发、适用于 GB300 的实现，并于 10 月 16 日合并。它添加了针对特定模型的专用运行时，而不是修改 Kimi K3 的权重。NVIDIA 的 CUTLASS 项目将 CuTe DSL 描述为一种原生 Python 的底层工具，可利用 CuTe 的布局、张量和硬件抽象编写 GPU 内核。

其工程思路是针对特定模型与硬件组合，优化解码过程中的操作和执行模式。这比加速所有加速器上的所有模型阶段更为狭窄。该 PR 支持的路径包括 8 或 16 的张量并行，以及指定的投机和非投机解码配置。

上游测试实际展示了什么

与简短的新闻报道相比，该 PR 给出了更明确的测试条件。其中一项非投机测试使用 GB300 上的 TP16、输入序列长度为 1、输出长度为 1,024，并采用贪心解码，同时使用 FP8 KV cache、FP32 SSM cache 和模型提供方的权重。

其解码步耗时是中位数 token 间延迟，不包括预填充；测量时使用了明确标注数量的运行中请求。作者报告了三次运行，每个批处理设置使用四个提示词，并通过图重放计时进行交叉验证。

这些是开发者单独开展的测试，并非对仪表盘中 423 tok/s/user 数据点的复现或解释。它们的价值在于明确给出了并发数、序列长度和所测量的阶段。

该 PR 也包含投机解码测试。部分性能测量使用合成或强制的草稿接受长度，不能误认为每种工作负载都能自然达到这样的接受长度。在一项输入为 32K、使用 DSpark DL7、合成接受长度为 3.78 并启用解码上下文并行的测试中，仅解码部分的收益大于包含其他请求预填充工作的输出吞吐量收益。作者报告称，在该对比中，首 token 延迟持平。

集成、准确性检查与限制

该路径通过可选参数 --additional-config '{"decode_backend": "latency_specialized"}' 启用。这是该合并贡献中记录的配置方式；它不是一条完整的服务器启动命令，也不意味着每个已发布的 vLLM 软件包都已包含该功能。

在预填充、混合批次和大批次场景中，专用运行时可以回退到标准 vLLM 执行路径。因此，用户不应假设只针对解码的速度提升在长提示词处理、混合流量或所有并发级别下都能保持不变。

开发者报告称，他们在 AIME25、GPQA-Diamond、GSM8K 和 MRCR v2 等任务上进行了评估，并执行了数值检查。这些检查有助于在已公布的条件下比较不同实现，但不能证明每次采样运行都会生成完全相同的文本，也不能证明所有应用中的行为都保持不变。

来源报道还称，NVIDIA 正在为 DeepSeek V4.1 和其他模型开发 vLLM 优化。这一说法应作为正在进行的工作来描述。Kimi K3 的结果并不能证明其他模型也已获得相同的提升，或具有相同的部署要求。

常见问题

这篇报道中的 423 tok/s/user 是什么意思？

SemiAnalysis 随附图表将该指标标注为 P90 交互性能，单位是每位用户每秒生成的 token 数。这是流式性能指标，与系统总吞吐量和首 token 延迟不同。

1.68× 的提升是硬件升级带来的吗？

报告中的对比使用了相同的 GB300 NVL72 硬件。报告将提升归因于软件路径，但这不意味着该硬件上的每种工作负载都会获得相同幅度的提升。

该优化已在上游 vLLM 中提供了吗？

审阅的 pull request #61867 已于 10 月 16 日合并。实际部署仍取决于所使用的构建版本是否包含该改动，以及是否满足该实现对模型、硬件和配置的要求。

它会同时加速预填充和解码吗？

该贡献是一种专用解码实现。其说明指出，预填充、混合批次和大批次可以使用原版路径，因此不应把解码步的测量结果宣传为整个流水线的速度提升。

PR 中批次为 1 的数据与 423 这一数据点来自同一基准测试吗？

目前尚未确认两者完全相同。PR 发布的微基准测试明确列出了序列长度和并发数，而本文未能确认 SemiAnalysis 重点展示的数据点对应的完整工作负载设置。

投机解码测试能保证现实场景中获得相同的速度提升吗？

不能。草稿接受情况、上下文长度、并发数和预填充流量都会影响结果，而且 PR 中的部分性能测试使用了合成接受值。应采用适用的测试方案，并先评估实际工作负载，再推断性能表现。

相关工具

• vLLM：提供接收该专用解码实现的推理和服务框架。
• NVIDIA CuTe DSL：提供报告中所述优化使用的 GPU 内核编程工具。
• InferenceX：展示 Kimi K3 在不同硬件和服务配置下的性能曲线。

相关链接

• 已合并的 Kimi K3 专用解码 PR：记录支持的配置、可选集成方式、基准测试和验证范围。
• SemiAnalysis 的原帖：展示报告中的 423 tok/s/user 和 1.68× 结果。
• Kimi K3 InferenceX 仪表盘：提供实时基准测试图表，以及单用户和单芯片的独立指标。
• InferenceX 基准测试代码库：介绍公开基准测试项目及其方法资源。
• NVIDIA CUTLASS 代码库：介绍 CuTe DSL 编程模型及相关 GPU 内核基础设施。
• CuTe DSL 快速入门：提供内核编程环境的官方入门指南。
• AI 推理术语表：解释交互性能、并发数及相关基准测试术语。
• IT Home 原始报道：提供中文原始报道及查看过的结果截图。

总结

NVIDIA 已合并的 CuTeDSL 贡献为 Kimi K3 在 GB300 上提供了专用解码路径。开发者在明确的测试条件下观察到了显著的延迟改善。SemiAnalysis 则另行报告称，在相同硬件上，性能提升了 1.68×，达到 423 tok/s/user。

务必将阶段和指标与数值一同说明：单用户解码交互性能不等于系统总吞吐量，也不代表普遍适用的端到端速度提升。