vLLM Kimi-K3 DSpark 推测解码实现

概述

vLLM 已成功为 Kimi K3（一个拥有 2.8T 参数的前沿模型）训练并部署了 DSpark 推测器。通过利用 Speculators 训练库和 GB300 NVL72 硬件，该实现将数学推理工作负载的单流交互性从约 110 提高到 435 tok/s/user，并在并发负载下提供高达 3.5 倍的输出吞吐量。

DSpark 算法

DSpark 是 DFlash 块级推测解码算法的扩展，旨在解决“后缀衰减”问题，即并行预测块中的单个错误会导致剩余 token 被失效。 DSpark 保留了 DFlash 的并行骨干结构，但引入了两个特定组件以提高 token 间的连贯性：

  • Markov logit-bias head：该组件按顺序采样 token，并使用低秩转移矩阵根据先前选择的 token 来调整 logits，从而在不需要额外 transformer pass 的情况下恢复局部依赖性。
  • Confidence head：该 head 估计 token 被接受的概率，允许硬件感知调度器在低负载期间验证更长的前缀，并在高系统负载期间修剪不太可能的后缀。

与 DFlash 相比，DSpark 在 Qwen3 目标模型上报告了 16–18% 更长的接受序列，且比 EAGLE-3 的序列长度长 27–31%。

推理性能与能力

Kimi K3 DSpark 推测器使用一个五层、50 亿参数的草稿模型（draft model），在每个解码步骤中提出 8 个 token。

基准测试与吞吐量

在九个评估领域中，该模型实现了每个验证轮次 4.11 个 token 的宏平均接受长度。性能在结构化任务中最高：

  • Mathematical reasoning：6.42 tokens
  • HumanEval：4.96 tokens
  • Translation：4.65 tokens

长上下文性能

在 LongBench-v2 数据集上，该推测器在 378K-token 的提示词下，每个解码迭代达到了高达 5.31 个输出 token。前 10% 的 请求保持了至少 3.76 tokens 每迭代，这表明推测解码在极端上下文长度下仍然有效。

并发与延迟

随着并发量从 1 增加到 16，总输出吞吐量从每秒 177 个 token 增加到 683 个 token。尽管并发请求增加了 16 倍，中位首字延迟（TTFT）保持稳定，仅增加了 100 毫秒（从 379 ms 增加到 479 ms）。

硬件与训练基础设施

GB300 NVL72 配置

训练是在 GB300 机架上进行的，使用了 Ubuntu 24.04.4 LTS 和 NVIDIA 的 64K-page kernel 6.14。环境利用了 NVIDIA 的 610.57.04 open-kernel GPU 驱动程序 (R610) 和 CUDA 13.4.0 Developer Preview，这是第一个包含 Rubin 支持 (sm_107) 的工具包。

Mooncake Hidden-State 传输

由于草稿模型通常需要目标模型的隐藏状态（hidden states）来对齐预测，vLLM 实现了 MooncakeHiddenStatesConnector。该系统支持解耦训练和隐藏状态提取，这对于像 Kimi K3 (2.8T 参数) 这样即使在 4-bit 量化下也超过了单节点配置 VRAM 限制的模型是必需的。

  • 机制：一个主 Mooncake 代理进程管理 vLLM 与训练实例之间的通信。训练进程通过 vLLM 前端请求隐藏状态，接收一个 Mooncake store key，然后 Mooncake master 通过 RDMA 或 TCP 进行传输。
  • 拓扑结构：为 Kimi K3 找到的最佳配置涉及三节点组：两个节点专门用于 vLLM 推理，一个节点专门用于训练。

部署

Kimi K3 DSpark 推测器可通过 Hugging Face (RedHatAI/Kimi-K3-speculator.dspark) 获取，并可以使用 vLLM 配合以下推测配置进行部署：

{
  "model": "RedHatAI/Kimi-K3-speculator.dspark",
  "num_speculative_tokens": 8,
  "num_speculative_tokens": 8,
  "method": "dspark",
  "draft_sample_method": "probabilistic",
  "rejection_sample_method": "block"
}

Sources