Kimi K3推理吞吐提升1.68倍

英伟达今天披露的一项 vLLM 上游优化，将 Kimi K3 在 GB300 NVL72 上的单用户解码吞吐推到了 423 tok/s/user，达到原方案的 1.68 倍。按照这一比例反推，优化前的吞吐约为 252 tok/s/user，对应增幅约 68%，而不是增加了 168%。

这次优化的核心不是换一套更激进的量化格式，也不是简单扩大批次，而是为解码阶段编写了一个约 1.2 万行的 Megakernel。根据 SemiAnalysis 10 月 18 日披露、IT之家转述的信息，这项工作由英伟达 CentML 工程师 Benjamin 完成，新内核使用 CuTe DSL 编写，并已经作为上游优化进入 vLLM 体系。

**Megakernel 是把原本需要多次启动、分散执行的 GPU 算子融合进一个大型持久化内核的执行方式。**它试图减少算子之间的中间数据读写、同步和 kernel launch 开销，让数据尽可能留在寄存器、共享内存与 GPU 片上执行路径中。对解码这种每一步只生成少量 token、却要反复调用大量小算子的任务来说，这类优化尤其有效。

423 tok/s/user意味着什么

**tok/s/user 是单个并发用户平均每秒获得多少输出 token 的吞吐指标。**它比整个集群每秒生成多少 token 更接近用户体感，但仍不等同于端到端响应速度，因为用户还会受到首 token 延迟、提示词预填充时间、网络延迟和调度排队的影响。

公开数字可以整理为下表：

| 对比项 | 优化前方案 | vLLM Megakernel方案 | 变化 | |---|---:|---:|---:| | 硬件 | GB300 NVL72 | GB300 NVL72 | 相同 | | 模型 | Kimi K3，2.8万亿参数 | Kimi K3，2.8万亿参数 | 相同 | | 单用户解码吞吐 | 约252 tok/s/user | 423 tok/s/user | 达到1.68倍 | | 相对增幅 | 基线 | 约+68% | 约多171 tok/s/user | | 核心手段 | 常规拆分算子执行 | 约1.2万行Megakernel融合 | 减少启动、同步与中间读写 | | 内核描述方式 | 未披露 | CuTe DSL | 面向GPU线程与张量布局 |

**423 tok/s/user 已经明显高于人类阅读文本的速度，因此它的价值主要不在“让聊天窗口滚得更快”。**更现实的受益场景是代码智能体、多轮工具调用、长链路研究任务和批量内容处理：一个智能体如果需要连续生成数千个 token，并在多个步骤间反复规划，解码吞吐提高 68% 可以直接缩短任务占用 GPU 的时间，也能让同一套硬件承接更多任务。

**这组结果目前仍不足以证明所有 Kimi K3 服务都能获得 1.68 倍提升。**现有报道没有完整披露并发数、输入与输出长度、采样参数、张量并行和专家并行布局，也没有给出首 token 延迟与整机总吞吐。423 tok/s/user 应被理解为特定 GB300 NVL72 配置下的推理结果，而不是可以直接套用到 H100、H200、B200或其他集群上的固定速度。

为什么解码阶段适合Megakernel

**大模型推理通常可以分成预填充和解码两个阶段。**预填充阶段一次处理整段输入提示词，矩阵规模较大，GPU 更容易吃满；解码阶段则逐步生成 token，每一步都要读取模型权重和缓存，并执行大量尺寸较小、相互依赖的运算。

**解码阶段的瓶颈经常不是GPU缺少理论算力，而是算力无法被连续、饱满地调用。**传统执行方式会把归一化、矩阵乘法、激活函数、路由、缓存更新等操作拆成多个 kernel，每个 kernel 都需要启动和调度，结果还可能写回显存，再由下一个 kernel 读取。单次开销看起来很小，但每生成一个 token 都重复一遍，累计损耗就会变得可观。

**Megakernel 的思路类似把多道短工序放进一条连续生产线。**GPU 不必在每道工序完成后把半成品搬回仓库，也不必反复等待新的调度指令，而是在一个更大的内核中持续推进解码计算。模型越大、跨设备通信越复杂、单步小算子越多，消除这些碎片化开销的收益就越值得争取。

**CuTe DSL 是英伟达 CUTLASS 体系中用于描述张量布局、线程映射和数据搬运的领域专用语言。**它比直接手写底层 CUDA 更强调布局组合与硬件映射，又比通用图编译器保留了更细的控制能力。开发者仍需处理寄存器占用、共享内存、warp 分工和访存合并，但不必把所有细节都固化成难以维护的模板代码。

**约1.2万行代码说明这不是一次普通的算子融合。**大型融合内核需要同时处理不同批次形态、数据类型、张量布局和边界条件，还要避免寄存器压力过高导致 occupancy 下降。融合并非越多越好：如果一个内核塞入过多分支和状态，GPU 的并行度可能下降，编译时间、调试难度和硬件适配成本也会迅速上升。

AI辅助写内核比跑分更值得看

**这次优化更重要的信号，是AI辅助生成高级GPU计算内核开始触及万行级工程。**SemiAnalysis 将这项工作视为 AI 辅助生成高级计算内核的未来方向，但“AI辅助”不应被误读成模型输入一句提示词就自动产出完整内核。性能边界、数值正确性、调度策略、基准设计和回归验证，仍然需要经验丰富的工程师把关。

**GPU内核开发是代码生成模型最可能产生高价值的领域之一。**这类代码的目标相对明确，可以用吞吐、延迟、显存占用和数值误差直接评价；失败样本也容易通过编译器、分析器和基准测试暴露。与普通业务代码相比，内核优化更适合形成“生成实现、自动编译、运行基准、分析瓶颈、继续搜索”的闭环。

**万行级Megakernel也带来了明显的维护风险。**硬件从 Hopper、Blackwell 演进到后续架构时，最优线程布局和数据搬运方式可能变化；模型版本稍微调整算子结构，原有融合路径就可能失效。把这类优化提交到 vLLM 上游，价值正在于让实现、测试和后续适配进入公共工程体系，而不是停留在某个服务商的私有分支中。

vLLM正在变成模型优化的第一落点

**vLLM 是一个面向大语言模型高吞吐推理与服务的开源框架。**它最初凭借 PagedAttention 降低 KV Cache 的显存碎片和浪费，随后逐步加入连续批处理、分块预填充、前缀缓存、推测解码、量化与多种分布式执行能力，目前已经成为开源模型部署的重要基础设施之一。

**英伟达把专用优化直接推向vLLM上游，反映出推理竞争已经从硬件峰值算力转向软硬件共同设计。**GB300 NVL72 提供了大规模互联和显存资源，但如果框架仍以大量零碎 kernel 调用模型，硬件规格无法自动转化成应用吞吐。芯片厂商亲自优化开源推理框架，实际上是在补齐“理论性能到可售卖 token”之间的最后一段距离。

**Kimi K3的2.8万亿参数规模放大了推理系统的工程难度。**参数规模越大，权重读取、跨卡通信、缓存容量和调度策略就越容易互相制约。即使模型采用稀疏激活结构，总参数也会影响权重分布与部署拓扑；如果某个阶段让部分 GPU 等待通信或小算子执行，整套 NVL72 系统的昂贵算力都会被闲置。

**专用内核的收益不能与量化、推测解码和调度优化简单相加。**这些技术可能作用于同一段耗时路径：量化降低计算和带宽成本，推测解码减少主模型实际执行的解码步数，Megakernel 则压缩每一步内部的调度与数据移动成本。三者叠加后的端到端收益取决于新的瓶颈落在哪里，不会自然等于各项百分比之和。

对开发者和服务商的实际影响

**对使用官方托管产品的普通用户来说，这项优化短期内大概率是“无感降本”，而不是界面上新增一个功能。**如果服务方保持相同并发和硬件规模，用户会看到输出更快、排队更短；如果服务方优先提高资源利用率，用户体感可能基本不变，但单位 GPU 时间能够处理更多请求。

**对自建推理集群的团队来说，上游合并比单次跑分更有现实意义。**一个只存在于特定演示环境中的内核很难进入生产系统，而 vLLM 上游实现可以接受持续集成、社区审查和版本回归。不过，团队仍需确认该路径是否覆盖自己的模型版本、精度格式、并行配置和 GPU 架构，不能只看到“1.68倍”就直接修改容量规划。

**评估这项优化时至少应观察四类指标。**第一是单用户 tok/s，判断长输出任务速度；第二是集群总 tok/s，判断硬件利用率；第三是 TTFT，也就是从请求提交到首个 token 返回的时间；第四是不同并发水平下的 P50、P95 与 P99 延迟。只有四组数据同时改善，才能说明优化真正覆盖了生产负载，而不只是特定解码基准。

**数值正确性也必须和性能同时验证。**内核融合可能改变浮点运算顺序，低精度格式会进一步放大误差，因此需要比较基准任务质量、输出稳定性和关键算子的误差范围。对于代码生成、数学推理和智能体任务，偶发的数值偏差未必立刻表现为跑分下降，却可能在长链路执行中改变工具选择或最终答案。

下一站是DeepSeek等更多模型

**英伟达已经在为vLLM中的其他前沿模型开发类似优化。**IT之家援引的信息提到，后续对象包括 DeepSeek V4.1 等模型，这意味着 Kimi K3 并不是一次孤立展示，而可能是围绕新模型结构持续建设专用解码路径的开始。

**未来的推理框架不会只提供一套通用执行图。**更可能的形态是框架负责请求调度、缓存管理和分布式编排，再根据模型架构、GPU代际、批次大小与精度格式选择不同的专用内核。通用性仍然重要，但真正拉开成本差距的部分，会越来越像编译器后端：表面使用同一个 vLLM，底层执行路径却高度定制。

**Kimi K3达到423 tok/s/user证明了软件优化仍能从顶级硬件中挖出可观余量。**在硬件完全相同的前提下，吞吐达到原来的1.68倍，相当于用内核工程换回了一大块原本闲置的系统能力。对于按 token 规模运营的大模型服务，这种提升往往比单纯增加 GPU 更便宜，也更容易转化为并发容量。

**这次结果真正值得保持克制的地方，是公开测试条件仍不完整。**423 tok/s/user 是一个亮眼数字，但只有在并发、上下文长度、输出长度、精度、功耗和总吞吐全部公开后，外界才能判断它是普遍可复现的生产收益，还是针对特定负载精心调优的峰值结果。

参考来源

• IT之家：英伟达优化Kimi K3模型推理速度，提升1.68倍：本次423 tok/s/user、GB300 NVL72、1.2万行Megakernel及后续模型优化信息的主要中文来源。
• vLLM GitHub仓库：vLLM源代码、版本更新、上游提交与推理框架实现的官方公开入口。
• NVIDIA CUTLASS GitHub仓库：CUTLASS与CuTe相关实现、示例和技术说明的官方开源来源。