DSpark 是 Novita 发布的一种推测解码方法。我们为 Kimi-K2.6 和 Kimi-K2.7-Code 训练并发布了面向生产的 DSpark 推测器，将它们集成到 vLLM 中，并评估了其并行块生成方法在推测窗口增长时的扩展性。
这些检查点旨在在不改变目标模型的情况下加快 Kimi 的服务速度。一个轻量级的草稿模型提出一组候选 token，然后完整的 Kimi 模型在候选 token 被接受之前对其进行验证。
在我们 batch-size-1 的 vLLM nightly 评估中，使用 num_speculative_tokens=7 的 DSpark 在 Kimi-K2.6 上实现了平均吞吐量加速比 2.55 倍，在 Kimi-K2.7-Code 上实现了 2.36 倍。当推测窗口从 n=3 增加到 n=7 时，DSpark 将额外的草稿 token 转化为吞吐量的能力比可用的 Eagle3-MLA 基线更稳定。
已发布的检查点如下：
- novita/kimi-k2.6-dspark 适用于 Kimi-K2.6
- novita/kimi-k2.7-code-dspark 适用于 Kimi-K2.7-Code
Kimi-K2.6 和 Kimi-K2.7-Code 的 DSpark 基准测试结果
在 batch size 为 1 时，将 num_speculative_tokens 从 3 增加到 7，使得 DSpark 在 Kimi-K2.6 上的平均加速比从 2.17 倍提升到 2.55 倍，在 Kimi-K2.7-Code 上从 2.12 倍提升到 2.36 倍。列出的 Eagle3-MLA 基线平均而言几乎保持不变。
| 目标模型 | 草稿模型 | n=3 平均加速比 | n=7 平均加速比 | 从 n=3 的变化 |
|---|---|---|---|---|
| Kimi-K2.6 | DSpark | 2.17x | 2.55x | +17.8% |
| Kimi-K2.6 | Eagle3-MLA | 2.01x | 2.01x | +0.2% |
| Kimi-K2.7-Code | DSpark | 2.12x | 2.36x | +11.7% |
| Kimi-K2.7-Code | Eagle3-MLA | 2.04x | 2.05x | +0.3% |
这些值是跨 GSM8K、MATH500、AIME、HumanEval、LiveCodeBench 和 SPEED-Bench Coding 基准测试的加速比的简单未加权平均值；未按提示数量加权。更大的草稿窗口并不会自动提高吞吐量：额外的提议必须被足够频繁地接受，以抵消草稿和验证的开销。
LiveCodeBench 使差异更加具体。对于 Kimi-K2.6，DSpark 从 n=3 时的 1.86 倍提升到 n=7 时的 1.87 倍，而 Eagle3-MLA 从 1.67 倍下降到 1.48 倍。对于 Kimi-K2.7-Code，DSpark 从 1.75 倍增加到 1.78 倍，而 Eagle3-MLA 从 1.69 倍下降到 1.52 倍。在 SPEED-Bench Coding 上，DSpark 在 Kimi-K2.6 上从 2.19 倍增加到 2.41 倍，在 Kimi-K2.7-Code 上从 2.15 倍增加到 2.31 倍。
评估设置： batch size 为 1，在线 vLLM nightly 推测解码，贪心解码，TP=8，max_model_len=20000，启用 CUDA graphs，以及 fuse_allreduce_rms=false。更高的 token/秒和加速比更好。Batch size 为 1 隔离了单请求解码行为；在连续批处理或更高并发生产工作负载下，结果可能有所不同。完整结果可在 Kimi-K2.6 DSpark 和 Kimi-K2.7-Code DSpark 的 Hugging Face 页面上找到。
为什么 DSpark 改进了 Kimi 推测解码
我们的检查点将 DSpark 应用于 Kimi-K2.6 和 Kimi-K2.7-Code，作为 vLLM 服务的草稿模型。
相对于 DFlash 并行草稿生成主干，DSpark 增加了两个轻量级头部：一个用于块内低秩 token 依赖的 Markov logit 偏置头，以及一个用于接受预测的逐位置置信度头。DSpark 并行提出完整的草稿块，然后使用这些头部提高块级草稿质量，并估计验证器可能接受哪些位置。
我们使用 vLLM 的 Speculators 框架的 vendored 分支训练了草稿模型。在训练期间，草稿模型消耗从 vLLM 中运行的实时 Kimi 验证器流式传输的隐藏状态，使推测器与它在服务时将遇到的验证器行为保持一致。
我们发布的表格使用可用的开源 Eagle3-MLA 检查点作为草稿模型基线，采用相同的验证器和服务配置。核心结果是这些方法如何随更大的推测窗口扩展：从 n=3 到 n=7，DSpark 在 Kimi-K2.6 上的平均加速比提高了 17.8%，在 Kimi-K2.7-Code 上提高了 11.7%，而列出的 Eagle3-MLA 基线平均而言几乎保持不变，并且在两个 LiveCodeBench 评估中都变慢了。这表明 DSpark 在窗口增长时更有效地保持了有用的草稿质量。该比较特定于此处测试的检查点、batch-size-1 工作负载和服务配置。
如何在 vLLM 中使用 DSpark 服务 Kimi-K2.7-Code
DSpark 支持目前需要 vLLM nightly 构建版本。对于 Kimi-K2.7-Code，请使用以下推测解码配置：
uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly
vllm serve moonshotai/Kimi-K2.7-Code \
--tensor-parallel-size 8 \
--max-model-len 20000 \
--trust-remote-code \
--compilation-config='{"pass_config": {"fuse_allreduce_rms": false}}' \
--speculative-config '{
"model": "novita/kimi-k2.7-code-dspark",
"num_speculative_tokens": 7,
"method": "dspark"
}'
对于 Kimi-K2.6，使用相同的配置，并将 speculative_config.model 指向 novita/kimi-k2.6-dspark。
已知的 nightly 构建注意事项： 草稿端 FA3 AOT 调度可能需要传递 fast_build=True 来构建草稿注意力元数据，并且 CUDA graph 捕获可能会遇到 FlashInfer 全规约工作空间大小错误。测试的配置禁用了 fuse_allreduce_rms；请参阅链接的 Hugging Face 页面以获取当前的解决方法。
DSpark 在不改变目标 Kimi 模型的情况下更改了解码路径。我们建议从 num_speculative_tokens=7 开始，然后根据代表性生产流量验证吞吐量、接受长度、token 间延迟和端到端延迟。最佳配置将取决于工作负载形状、批处理和服务硬件。
