10月19日消息，英伟达工程师于当地时间10月16日在vLLM官方博客发文称，通过Agent辅助开发，在英伟达GB300（Blackwell架构）硬件上构建了专用CuTe DSL解码链路，对2.8T参数的Kimi K3模型进行优化，使解码吞吐量和交互延迟均获得显著改善，这一成果已通过新的上游vLLM优化实现。
在相同硬件条件下，速度提升至1.68倍，同时提出了一套兼顾迭代速度与工程可靠性的模型优化工作流。
核心性能成果。
此次优化针对8卡、16卡GB300多GPU部署场景，支持1‑64解码batch，并兼容长上下文解码上下文并行DSpark推测解码。
1. Batch‑1单请求解码（开启DSpark推测解码）：在16张GB300环境下，解码速度达到842 tokens/s，相比原版vLLM提速1.73倍；
2. 通用解码吞吐量：多种测试配置下整体解码吞吐量提升1.5‑2倍。在无推测解码场景中，TP16在batch1‑64区间可获得1.62‑1.88倍加速，TP8获得1.31‑1.58倍加速；
3. Agent真实业务负载（AgentX）：16卡GB300部署下，P90交互性能最高提升1.8倍，单用户可达403.2 tokens/s，而基线8卡GB300为223.7 tokens/s。
从内核时间来看，原版vLLM每一层需要23个内核、耗时130μs；经过定制优化后仅需13个内核，每层耗时压缩至69μs。
四大技术优化手段。
整套优化几乎全部替换、融合原有算子，使用CuTe DSL手写定制GPU内核，包含四项关键技术：
1. 面向业务调优算子形状。
针对不同batch选择不同矩阵计算内核：小batch（1‑2）使用小矩阵专用内核，大batch启用split‑K矩阵乘法；KDA注意力内核、长上下文解码上下文并行（DCP）均做适配调优，充分压榨GPU算力与访存能力。
2. 计算与通信重叠执行。
将注意力输出投影、all‑reduce规约、残差计算做算子融合；GPU直接向NVLink共享缓冲区写入中间结果，接收端内核直接接续运算；大batch采用两阶段规约，降低多卡之间数据搬运开销，实现无栅栏低开销数据交换。
3. MoE专家调度与重叠优化。
把路由打分、隐层输入投影计算拆分到各个张量并行rank上，多卡通过NVLink合并结果，消除重复计算与重复权重读取；共享专家运行在独立流上，和路由、普通专家计算并行执行，精细调度GPU资源避免资源争抢，提升并行均衡度。
4. 权重预取进缓存。
小batch推理场景经常受限于内存带宽。在通信等GPU带宽未占满的阶段，通过独立侧流内核提前预加载后续算子权重，大幅提高缓存命中率，缓解内存瓶颈。
兼顾速度与稳定性：Fast‑Track模型优化原则。
文章提出一个现实工程矛盾：AI Agent辅助生成内核代码的速度已经远超人工代码审查维护的速度；直接上线容易产出线上故障，但逐行人工审核又会严重拖慢迭代。
为此社区提出fast‑track RFC，制定4条原则，实现快速优化同时管控风险：
1. 变更隔离：模型专属优化收敛在模型代码内部；运行时可追踪优化路径的启用与退出，不改动vLLM全局公共模块（KV缓存、采样逻辑等），避免影响其他模型部署。
2. 限定适用范围，但保留完整业务特性：优化可以限定特定硬件、并行方式、batch区间，但不能阉割生产必备功能，长上下文、采样、结构化输出等能力必须完整保留并纳入验证。
3. 系统性正确性校验：既要做内核单元测试，也要跑完整模型评估；必须真实触发优化后的代码路径；长上下文、长生成任务可以暴露单元测试无法发现的数值稳定性缺陷。
4. 广泛性能校验：不能只看单一场景的亮眼跑分，要遍历batch、上下文长度、并行配置；MoE测试使用真实提示词；同时社区推进“自带GPU评测RFC”，让贡献者可以在自己硬件复现结果，降低项目CI的GPU资源压力。
后续规划。
这套Kimi K3的优化架构已经复用到其他模型：
- DeepSeek‑V4.1‑Flash：复用`latency_specialized`解码后端，支持最高64并发请求，融合all‑reduce算子，替换MoE与矩阵乘内核，把CPU上的步骤迁移到CUDA Graph；
- Meta Muse Spark Open：短时间内拿到早期结果，7个draft token推测解码下单用户可达950 tokens/s；
- GLM5.3：即将推出面向低并发场景的同类低延迟解码优化，后续会公开细节与跑分。
vLLM团队后续会持续遵循这套范式：追求真实可复现的性能收益、保障生产功能完备、落实正确性与性能自动化验证，把Agent辅助内核优化模式推广到更多大模型。
