DSpark
DSpark 是建立在 DFlash 块并行骨干上的半自回归投机解码框架。它用轻量顺序头补回块内 token 依赖,再根据候选前缀的存活概率和实时硬件成本动态分配验证预算。
这两个组件解决不同问题:顺序头提高 Draft 质量,置信度调度减少 Target Model 对低价值后缀的验证开销。最终输出仍由标准投机验证校正,DSpark 不替代 Target Model。
1. 两个瓶颈
1.1 并行预测的后缀衰减
DFlash 一次 Forward 产生所有位置的基础 logits,但位置
投机解码只接受连续前缀。设位置
一轮含 bonus token 的期望产出为:
后部位置的
1.2 固定验证长度浪费 Batch 容量
验证更多候选在低并发、Memory-bound 阶段可能接近免费;高并发下,每个低接受率候选都会占用 Target Model 的 Batch token 容量。代码、数学等结构化任务通常比开放对话更容易预测,同一个静态长度无法同时适配任务难度与系统负载。
DSpark 因此把问题拆成两层:先改善
2. 半自回归 Draft
2.1 并行骨干
DSpark 复用 DFlash 的 Target Context Feature 与 KV 注入。并行骨干对整个查询块做一次 Forward,得到隐藏状态
DSpark 对查询布局做了一项重要调整:论文实现用 anchor + γ-1 masks 产生
2.2 顺序修正
顺序阶段不重跑 Transformer,只在基础 logits 上添加依赖已采样前缀的转移偏置:
于是块分布保持自回归分解:
每个
2.3 Markov Head
默认实现只依赖前一个 token,并把完整的
论文和公开 Qwen3 配置默认
2.4 RNN Head
RNN 变体维护块内状态
论文在 Batch Size 128、上下文长度 512~4096 的测试中报告:相对 DFlash,把候选长度从 4 扩展到 16 时,顺序头只增加整轮 0.2%~1.3% 延迟。这个比例依赖“Target 验证占主导”的测试条件,不代表顺序循环在所有模型、Batch 和硬件上都可忽略。
3. 置信度建模
3.1 条件接受概率
DSpark 的置信度头同时读取骨干隐藏状态与前一 token 的 Markov Embedding:
训练标签不是某次随机验证的 0/1 结果,而是 Draft 分布
它等于两分布概率质量的重叠程度,直接对应标准拒绝采样在该位置的期望接受率。
3.2 STS 校准
调度器需要的是累积存活概率
论文在 Alpaca 上报告,原始置信度头的 ECE 约为 3%~8%,STS 后各位置约为 0.4%~2.0%。这属于论文训练与部署流程;使用第三方 checkpoint 时,应确认其校准数据和运行时是否包含对应变换。当前 vLLM 通用实现直接消费 checkpoint 输出的 sigmoid 概率,没有暴露独立的 STS 运行时配置。
4. 硬件感知前缀调度
4.1 优化目标
对
期望产出为:
若预先 profiling 得到 Batch Size 为
由于同一请求中的 (request, position) 按
4.2 无损调度的非预见性
验证长度不能回看未来候选再决定是否验证更早的 token。DSpark 的
论文算法在吞吐首次下降时立即停止搜索,使位置
4.3 生产异步调度
DeepSeek 的生产系统需要提前准备下一步 Batch 与 CUDA Graph,无法同步等待当前步的完整调度结果。论文中的生产适配使用两步前的置信度估计总预算
当前 vLLM 主线采用相似的双层思路:CPU 侧使用滞后的置信度与启动时 profiling 的 Draft/Verify 成本选择总预算,GPU 侧再按当前累积置信度把预算分给各请求。它优化的是“期望接受 token / 实测耗时”,与论文的
5. 训练目标
Target Model、共享 Embedding 与 LM Head 保持冻结;只训练并行骨干、顺序头和置信度头。三个损失都使用前部权重
论文默认权重为
6. 开源实现边界
6.1 DeepSpec
DeepSeek 开源的 DeepSpec 覆盖数据生成、Target Cache、DFlash/DSpark/EAGLE-3 训练和离线评测。它可以用固定候选长度评估接受长度,也可以用静态置信度阈值提前截断;论文中的生产级硬件感知调度器并不在这条离线 evaluator 路径中。
训练成本不可忽略。DeepSpec README 估计,默认 Qwen3-4B 数据准备配置的 Target Cache 约为 38 TB;实际规模取决于样本数、缓存字段、精度和层数。
6.2 vLLM
截至 2026-08-19,vLLM 已包含 DSpark Markov 顺序采样与可选 Adaptive Verification:
vLLM:在并行基础 logits 上逐位置添加 Markov Bias
prev = self.input_buffers.input_ids[self._anchor_idx[:num_reqs]]
for i in range(n_spec):
markov_embed = self.model.markov_embed(prev)
bias = self.model.markov_bias(markov_embed)
logits_i = base_logits[:, i] + bias
draft_sampled_i = self._sample_logits(
logits_i, idx_map[:, i], sample_pos[:, i], i
)
self.draft_tokens[:num_reqs, i] = draft_sampled_i
prev = draft_sampled_i启用自适应验证需要带 Confidence Head 的 DSpark checkpoint,并设置 enable_adaptive_verification=true。当前实现还要求支持设备端可变 Query Length 的 Attention Backend 和 Full CUDA Graph;不支持 LoRA、Pipeline Parallelism 或输出 logprobs。固定长度验证不受这些额外约束。
7. 实验结果如何解读
7.1 离线 Draft 质量
论文 Table 1 在 temperature 1、固定 block size 7、关闭 Confidence Scheduler 的条件下,对所有方法使用相同训练框架和数据。Qwen3 系列 9 个任务的宏平均结果为:
| Target | EAGLE-3 | DFlash | DSpark | DSpark vs DFlash |
|---|---|---|---|---|
| Qwen3-4B | 3.61 | 4.06 | 4.73 | +16.3% |
| Qwen3-8B | 3.80 | 4.07 | 4.81 | +18.4% |
| Qwen3-14B | 3.68 | 4.04 | 4.78 | +18.3% |
这些数值是每轮平均产出
论文还报告,在 Qwen3-4B、5 层 Draft 的消融中,候选长度从 4 增加到 16 后,DSpark 相对 DFlash 的接受长度增益从数学 16%、代码 15%、对话 18%,扩大到 30%、26%、22%。这与“顺序依赖主要改善长块后缀”一致。
7.2 生产 Serving
DeepSeek 在 V4-Flash/Pro preview 的生产引擎与真实流量上,将最大 Draft 长度为 5 的 DSpark 与原 MTP-1 配置比较:
| 场景 | 论文报告结果 |
|---|---|
| V4-Flash,匹配系统吞吐 | 单用户生成速度提高 60%~85% |
| V4-Pro,匹配系统吞吐 | 单用户生成速度提高 57%~78% |
| V4-Flash,80 tok/s/user SLA | 聚合吞吐提高 51% |
| V4-Pro,35 tok/s/user SLA | 聚合吞吐提高 52% |
更严格 SLA 下出现的 661% 和 406% 名义吞吐差异来自 MTP-1 已进入极低并发区。论文也明确建议把它理解为“DSpark 扩展了可行的交互速度边界”,而不是常规负载下可复现的倍数加速。
8. DFlash 与 DSpark 对比
| 维度 | DFlash | DSpark |
|---|---|---|
| 并行骨干 | 块并行 + KV 注入 | 复用 DFlash |
| 块内依赖 | 候选位置独立 | Markov Head 或 RNN Head |
| Draft Forward | 1 次块 Forward | 1 次块 Forward + 轻量顺序采样 |
| 验证长度 | 通常固定 | 可按置信度和硬件成本动态分配 |
| 主要收益 | 降低 Draft 串行开销 | 缓解后缀衰减与无效验证 |
| 新增风险 | 长块后缀质量下降 | 置信度校准、因果调度和后端适配更复杂 |
DSpark 不是用自回归替换并行 Draft,而是在最便宜的位置补入有限顺序依赖。其核心价值也不只是接受长度更高,而是把 Draft 质量、请求差异和 Serving 负载放进同一个验证预算决策中。