vLLM 将 DSpark 带到 Kimi K3：GB300 上的推测解码实践

导语

推测解码的关键，不只是让小模型“猜得快”，还要让目标模型尽可能多地一次性接受这些猜测。vLLM 最新实践将 Speculators 训练库扩展到 Kimi K3，并在 GB300 NVL72 环境中完成 DSpark 草稿模型的训练与部署，展示了大模型推理优化从论文算法走向工程系统的一条路径。

DSpark 解决了什么问题

传统推测解码由轻量模型自回归地产生候选 token，再交给目标模型批量验证。EAGLE-3 属于这一思路，但生成多个候选 token 仍需要多次串行步骤。DFlash 则通过一次非因果骨干网络前向传播，预测一个完整 token 块，减少草稿阶段的串行开销。

问题在于，并行预测的不同位置无法充分依赖彼此。前面一个位置预测错误，可能导致后续 token 全部失效，形成“后缀衰减”。DSpark 保留 DFlash 的并行骨干，同时增加三类机制：

• Markov logit-bias head：根据已选 token 修正后续位置的概率分布，补回部分局部依赖。
• Confidence head：估计每个候选 token 被目标模型接受的可能性。
• 硬件感知调度：低负载时尝试验证更长前缀，高并发时主动裁剪低可信度后缀。

因此，DSpark 在减少草稿前向次数的同时，试图提高候选序列的连贯性。原文援引的跨 Qwen3 测试显示，其接受序列长度高于 DFlash 和 EAGLE-3；不过这些结果不应直接等同于所有模型或负载下的固定加速比。

Kimi K3 的测试结果

此次发布的 Kimi K3 草稿模型包含五层、约 50 亿参数，每轮提出 8 个 token。在九类评测领域中，宏平均接受长度为 4.11 个 token；数学推理达到 6.42 个，HumanEval 为 4.96 个，翻译为 4.65 个。长上下文同样是重点：在 378K token 的 LongBench-v2 提示词上，最高可达到每次解码迭代接受 5.31 个输出 token。

并发测试中，请求数从 1 增至 16 时，聚合输出吞吐由每秒 177 token 提升至 683 token；首 token 中位延迟仅从 379 毫秒升至 479 毫秒。针对数学推理，文章还报告单流交互速度约从 110 提升至 435 token/秒，并称在相同交互水平下，输出吞吐最高可提升约 3.5 倍。具体收益仍取决于目标模型、批大小、上下文长度和硬件配置。

工程意义

这项工作的价值不只在于一个更快的草稿模型。Speculators 将训练、打包和部署流程统一到 Hugging Face 兼容格式，vLLM 可以直接加载；配合 Mooncake、多节点张量并行、FP8 KV 缓存以及针对 MLA 的后端配置，研究者无需为每个模型重新搭建整套推理链路。

同时，GB300 NVL72 提供了验证大规模推理系统的真实环境。对开发者而言，DSpark 的启示是：推测解码的效果由算法、草稿训练、调度策略和集群通信共同决定。未来评估这类方案时，除了峰值 token/s，还应同时关注接受长度、首 token 延迟、并发扩展性和长上下文稳定性。

来源：vLLM Blog