DSpark：投机解码与生产级 Serving 学习笔记

00 · Mental Model

先用一页把 DSpark 装进脑子

DSpark 不是“让 DeepSeek-V4 更聪明”的新基础模型架构。它是一套围绕 推理解码效率 设计的 speculative decoding 框架：既提高 Draft Token 的可接受长度，又减少高并发下无意义的验证计算。

目标模型DeepSeek-V4 / Qwen3 等

→

Draft先猜一块 token

→

Confidence估计前缀能活多久

→

Scheduler按负载决定验证长度

→

Target Verify一次并行验证

创新 A：Semi-Autoregressive Generation

重计算的部分保持并行，只在输出端加入极轻的顺序依赖模块，让 block 后部 token 不再“各猜各的”。目标是：保住 parallel drafter 的速度，同时缓解 suffix decay。

创新 B：Confidence-Scheduled Verification

不再把整个长 draft block 无脑送给大模型验证。先预测每个位置的条件接受概率，再结合当前引擎负载与吞吐曲线，为每个请求动态选择值得验证的前缀长度。

真正的关键词：不是“更长的 Draft”本身，而是 Draft Quality × Verification Budget × Serving Load 的联合优化。

01 · Inference Bottleneck

为什么大模型生成阶段天然慢？

标准自回归语言模型每生成一个新 token，都要在已经生成的上下文基础上继续做一次前向计算。Prefill 阶段可以高度并行，但进入 Decode 后，token 之间存在严格的时间依赖：

Prompt → token₁ → token₂ → token₃ → token₄ → ... ↑ 每一步都必须等前一步生成完

因此，哪怕 GPU 很强，单个请求在 decode 阶段也常常无法像训练时那样把大量 token 一次性并行算完。用户看到的“一个字一个字往外蹦”，背后就是这个序列依赖。

论文给出的核心延迟视角

L = ( T_draft + T_verify ) / τ

其中：

T_draft：draft model 生成候选 token 的时间；
T_verify：target model 验证这些候选 token 的时间；
τ：一轮里最终被接受的 token 数。

↓

Draft 更快

降低 T_draft

↑

猜得更准

提高 τ

↓

验证更聪明

减少无效 T_verify

很多投机解码方法主要优化前两项。DSpark 的重要之处是：它同时认真处理了第三项，而且把系统负载纳入决策。

02 · Speculative Decoding

投机解码到底在“投机”什么？

核心想法非常朴素：别让昂贵的大模型每次只产出 1 个 token。先用一个便宜的 draft model 猜一串候选，再让 target model 一次性并行验证。

为什么它可以做到“无质量损失”？

在标准 speculative sampling 中，Draft 只负责提议，真正决定是否接受的仍是 target model。论文采用的接受规则基于 target 与 draft 的概率分布比较，因此可以保持目标模型的输出分布，而不是把小模型的错误偷偷混进去。

理解重点：Draft model 的任务不是“替代大模型回答”，而是“猜大模型下一步可能想说什么”。猜中了就省计算；猜错了由大模型纠正。

最容易忽略的一点：接受是“前缀式”的

假设 Draft 猜了 8 个 token，第 4 个被拒绝，那么第 5～8 个即使单独看起来可能不错，也不能直接继续保留，因为它们是在错误前缀条件下得到的。

候选： x₁ x₂ x₃ x₄ x₅ x₆ x₇ 验证： ✓ ✓ ✓ ✗ - - - 接受： [──────── 前缀 ────────]

这也是为什么后缀位置的准确率非常关键：一旦中间某处出错，后面的验证预算往往全部浪费。

03 · Drafter Architectures

Draft Model 的两条路线：自回归 vs 并行

维度	Autoregressive Drafter	Parallel Drafter
生成方式	token 一个接一个生成	整块 token 一次并行预测
块内依赖	天然存在	通常较弱/独立
Draft 延迟	随 block size 近似线性增长	对 block size 不敏感得多
后部 token 一致性	通常较好	更容易出现 suffix decay
适合的 block	偏短	可以做得更长
典型思想	EAGLE 系列等	Medusa / DFlash 等

如果只看模型结构，这是一个经典矛盾：

自回归：知道前面生成了什么，所以更准；但必须排队。
并行：所有位置一起算，所以快；但彼此不知道对方最后选了什么。

DSpark 的第一个创新，就是尝试把这两个极端拼起来：大头并行，小头串行。

04 · Problem #1

痛点一：Suffix Decay —— 为什么 Draft 越往后越容易崩？

并行 drafter 的每个位置往往根据同一个上下文独立预测。问题在于自然语言存在大量“多模态”续写：

合理路径 A

of → course

合理路径 B

no → problem

如果第一个位置和第二个位置独立做边缘预测，就可能发生“跨模式拼接”：

of → problem ✗ no → course ✗

这不是因为每一个单独 token 的概率一定很低，而是因为组合后不连贯。当 block 变长，这种不一致会层层累积，后缀接受率迅速下降。

位置 1

高

位置 4

↓

位置 8

↓↓

位置 16

↓↓↓

上图是帮助理解的示意，不是论文中的具体数值。

关键：并行 Draft 能便宜地产生很长的 block，并不代表这些 token 都值得送去 target model 验证。长度能力和有效长度是两回事。

05 · Core Innovation A

Semi-Autoregressive Generation：大头并行，小头串行

DSpark 将 Draft 过程拆成两层：

Parallel Backbone一次生成整块 hidden states / base logits

Sequential Head注入块内 token 依赖

Better Draft保持速度，提升后缀一致性

5.1 并行主干：负责“重计算”

论文实例中，DSpark 建立在并行 drafter 的思路上。Parallel backbone 一次性对整个 block 产生基础 logits U₁…Uγ 和 hidden states h₁…hγ。这一步占据大部分计算量，因此必须保持并行。

5.2 串行输出模块：只负责“转移偏置”

在第 k 个位置，最终概率不只由并行 backbone 的 U_k 决定，还额外加上一个与前缀有关的偏置：

p_k(v | x<k) ∝ exp( U_k(v) + B_k(prefix, v) )

直观上可以理解为：

Parallel Backbone： “这个位置单独看，course / problem 都有概率。” Sequential Head： “但你前一个 token 已经选了 of，所以 course 应该加分，problem 应该减分。”

5.3 Markov Head：只看前一个 token

最简单的实现只建模一阶转移 B(x_k-1, x_k)。如果直接保存完整的词表×词表矩阵会非常大，于是论文采用低秩分解：

B ≈ W₁ W₂，默认 rank r = 256

这样每一步只需要做一个轻量 embedding lookup 和 projection，就可以用极低开销引入局部序列依赖。

5.4 RNN Head：让整个 block 前缀进入状态

Markov head 只能看一步，而 RNN head 维护一个 recurrent state，让位置 k 不只知道 x_k-1，还可以压缩地记住更早的 block 内历史。它的建模能力更强，但顺序模块必须足够轻，否则就会把 parallel drafter 好不容易省下来的时间重新花回去。

设计哲学：DSpark 没有试图把并行模型重新改回完整自回归，而是只补上“足够有用、足够便宜”的依赖。工程上这是典型的 Pareto 思路。

06 · Problem #2

痛点二：Verification Waste —— 猜得出来，不代表值得验证

假设并行 drafter 几乎免费地给你 16 个候选 token。最直觉的做法是全部扔给 target model：

Draft: [1][2][3][4][5][6][7][8][9]...[16] Verify: [============================] 全部验证

但如果位置 5 之后的存活概率已经很低，那么位置 6～16 所占用的 target batch capacity 可能几乎没有回报。

为什么单用户和高并发不是一回事？

轻负载

GPU 还有空槽

多验证几个 token 的边际成本可能很低。即使后缀最后没被接受，也未必挤占其他请求。

高并发

Batch capacity 很宝贵

每多塞一个高拒绝风险 token，就可能挤掉另一个真实用户请求的一步解码，整体吞吐可能下降。

所以“最优 verification length”不是常数，而同时取决于：

当前这条请求是什么类型：代码、数学、开放聊天……
这一块候选 token 自己到底有多靠谱；
当前 batch 里一共有多少活跃请求；
GPU / serving engine 在不同 batch size 下的实际性能曲线。

DSpark 的第二个核心观点：Verification 本身也是一种稀缺资源，需要调度，而不是固定规则。

07 · Confidence Head

先预测：这个前缀究竟能活多久？

DSpark 为每个 draft 位置 k 预测一个置信度 c_k。注意它不是简单地问“第 k 个 token 对不对”，而是：

c_k ≈ 在前面所有 token 都已被接受的条件下，第 k 个 token 继续通过 target verification 的概率。

论文使用一个轻量线性层 + sigmoid 产生置信度。训练监督信号来自 draft distribution 与 target distribution 的总变差距离：

c*_k = 1 − ½ || p^d_k − p^t_k ||₁

从单点置信度到前缀存活概率

因为 speculative decoding 接受的是连续前缀，所以第 j 个位置真正值得验证的概率是前面条件概率的乘积：

a_j = ∏_i≤j c_i

举例：

位置	条件接受概率 c	前缀存活概率 a
1	0.96	0.960
2	0.93	0.893
3	0.86	0.768
4	0.70	0.538
5	0.42	0.226

表中数值为教学示例。重点是：前缀存活概率会以乘积方式快速衰减。

为什么还要做 Sequential Temperature Scaling？

神经网络的 confidence 往往会“自信过头”。如果系统只用 confidence 做排序，偏一点还不致命；但 DSpark 要拿这个绝对概率去估计多验证一个 token 能带来多少期望收益，概率失真就会直接让调度器做错决定。

因此论文对累计的 prefix survival probability 做逐位置温度校准，让“预测的 70%”更接近“现实中真的约 70% 能通过”。

08 · Core Innovation B

Hardware-Aware Prefix Scheduler：把验证预算给最值钱的 token

有了每个请求各位置的 prefix survival probability 之后，还差最后一步：在当前负载下，验证到哪里最划算？

8.1 为什么不能只设一个固定阈值？

例如规定“a_j > 0.5 就验证”。这在单请求环境可能还行，但在线 serving 中，0.4 的 token 在系统空闲时可能值得算，在系统爆满时则可能完全不值得。

8.2 SPS(B)：硬件真实吞吐曲线

论文调度器利用预先 profiling 得到的 SPS(B)——可以理解为在 batch size 为 B 时，引擎每步的运行速率。随着 batch 变大，吞吐和步速并不是线性变化。

空闲时

多塞几个 verification token，可能几乎不降低步速 → 验证长一点。

拥堵时

额外 token 会显著拖慢整批请求 → 只保留高 survival probability 的前缀。

8.3 调度器在优化什么？

论文将它写成一个全局 throughput maximization 问题。概念上可以理解成：

Expected Throughput ≈ Expected Accepted Tokens × SPS(Batch Size)

调度器将所有请求的候选前缀位置按照“存活概率”排序，逐步尝试把更多 token 纳入 verification batch；如果加入下一个 token 后，预计总吞吐继续上升，就保留；一旦开始下降，就停止。

for 每个 request r: 计算 a[r,j] = Π c[r,i] 把所有候选 (request, position) 按 a 从高到低排列从当前 batch 开始逐个加入候选 token: 新 batch size = B + 1 新 expected accepts += a[r,j] throughput = expected_accepts × SPS(B) 如果 throughput 继续增加: 接受这个更长前缀否则: 停止

最重要的系统观：DSpark 不只是“每条请求自己决定长度”，而是把同一批活跃请求放在一起看，把 GPU batch capacity 当成全局资源来分配。

09 · End-to-End Cycle

一轮 DSpark 到底怎么跑？

Target model 上一轮产生一个 anchor/bonus token；
Parallel backbone 一次得到整块位置的基础表示；
Markov/RNN 等轻量串行模块按顺序采样，修复块内依赖；
Confidence head 为每个位置输出条件接受概率；
累乘得到 prefix survival probability；
Hardware-aware scheduler 根据整批请求和实际引擎曲线确定每个请求的 verification length；
Target model 只验证被保留的高价值前缀；
遇到第一个 rejection 后由 target model 修正，并进入下一轮。

10 · Results

论文结果应该怎么看？

10.1 Offline：先看“平均能多接受多少 token”

论文在 Qwen3-4B / 8B / 14B 上评估数学、代码和日常对话等不同领域。相对于 autoregressive drafter Eagle3，DSpark 的 macro-average accepted length 分别提升：

+30.9%

Qwen3-4B · vs Eagle3

+26.7%

Qwen3-8B · vs Eagle3

+30.0%

Qwen3-14B · vs Eagle3

相对于 parallel drafter DFlash，论文报告的提升分别为：

+16.3%

Qwen3-4B · vs DFlash

+18.4%

Qwen3-8B · vs DFlash

+18.3%

Qwen3-14B · vs DFlash

10.2 Online：真正重要的是生产系统 Pareto Frontier

离线 accepted length 高并不自动意味着线上更快。生产 serving 要同时考虑：

单用户 token generation speed；
总体 aggregate throughput；
并发请求数；
延迟 SLA；
GPU batch capacity。

DeepSeek-V4-Flash

60–85%

论文报告：在匹配总体吞吐能力条件下，相较既有 MTP-1 production baseline，单用户生成速度加速约 60%–85%。

DeepSeek-V4-Pro

57–78%

论文报告：在匹配总体吞吐能力条件下，单用户生成速度加速约 57%–78%。

论文进一步强调，在更严格的交互速度档位下，baseline 会出现明显 capacity degradation，而 DSpark 通过减少 verification overhead 扩展了可运行区域。因此作者使用了一个很重要的表述：shift the Pareto frontier。

怎么读这个结果：不要理解成“模型算力凭空减少 85%”，也不要直接等价成“所有用户真实体验固定快 85%”。这是论文在特定生产服务系统、匹配吞吐等条件下的 serving 指标。

11 · Positioning

DSpark 和 MTP、MoE、KV Cache、Serving 到底是什么关系？

技术	所在层	主要解决	与 DSpark 的关系
MoE	模型架构 / 计算路由	每 token 只激活部分专家，扩大参数容量同时控制 FLOPs	不是一类问题；DSpark 位于解码加速/Serving 层
MTP	模型训练 + 多 token 预测	让模型训练时预测多个未来 token，也可服务投机解码	论文线上对比基线是既有 MTP-1
KV Cache	推理系统	避免每一步重复计算历史 token 的 K/V	与 speculative decoding 可同时存在，是不同维度优化
Continuous Batching	Serving 调度	动态把不同用户请求合并进批次	DSpark 的 verification scheduling 会直接与 batch capacity 互动
Speculative Decoding	解码算法	先 draft，再 target verify，一轮接受多个 token	DSpark 就属于这一大类
DSpark	Draft + Verification + Scheduler	提高长 draft 有效性，并减少高并发验证浪费	模型与 serving 的联合设计

不要把 DSpark 误解成 DeepSeek-V4 的“主网络架构”

它更接近下面这层：

┌──────────────────────────────┐ │ Agent / App / API │ ├──────────────────────────────┤ │ Serving Scheduler │ ← DSpark scheduler ├──────────────────────────────┤ │ Decoding / Speculation │ ← DSpark drafter ├──────────────────────────────┤ │ Target LLM (DeepSeek-V4) │ ├──────────────────────────────┤ │ MoE / Attention / FFN ... │ ├──────────────────────────────┤ │ GPU / Cluster / Network │ └──────────────────────────────┘

这也是它值得学习的地方：现代大模型性能越来越不是“一篇架构 paper 就解释全部”，而是 Model × Decoding × Serving × Hardware 共同决定。

12 · Open Source

DeepSpec：论文不是只给结果，也给了训练框架

DeepSeek 开源的 DeepSpec 是一个训练与评测 speculative decoding draft model 的 full-stack codebase，当前 README 列出了三种算法：

DSpark DFlash Eagle3

代码工作流

Data Preparationprompt → target answers

→

Target Cache缓存教师模型输出

→

Draft Training训练 DSpark drafter

→

Evaluation测 accepted length 等

从官方配置可以看到什么？

以公开的 Qwen3 DSpark 配置为例，可以看到诸如：

block_size = 7
num_draft_layers = 5
markov_rank = 256
包含独立的 confidence head 设置
训练损失包含 CE 与 L1 类权重设置

这能帮助你把 paper 中的抽象结构对应到真实工程代码，而不是只停留在图里。

官方 README 特别提醒：默认 target cache 的数据体量可能非常大，示例 Qwen3-4B 设置可达到约 38 TB。所以“代码开源”不等于“普通单卡电脑可以轻松完整复现”。

如果你真想动手，建议顺序

先读 README，理解 data → cache → train → eval；
读 config/dspark/，看模型超参；
读 deepspec/modeling/dspark/common.py，理解输出张量与 block 组织；
再进入 Markov / confidence / loss 相关实现；
最后才考虑跑完整训练，而不是一上来下载几十 TB 数据。

13 · Critical Reading

这篇论文不能被夸张成什么？

① “速度快 85%” ≠ 模型所有场景统一快 85%

论文的线上数字有明确测试条件：DeepSeek-V4 serving、真实流量、与 MTP-1 对比、匹配总体吞吐能力。换模型、换硬件、换 batch 策略、换请求分布，数字都可能变化。

② Accepted length 高 ≠ End-to-end 一定更快

最终速度还取决于 draft latency、verification latency、batch 扩张、通信开销、kernel 效率等。DSpark 的价值恰恰在于它没有只追 accepted length。

③ “并行 + 串行”不是免费的

Sequential head 虽然很轻，但仍有额外依赖和实现复杂度。它之所以成立，是因为串行部分相对 parallel backbone 足够小。

④ Scheduler 依赖引擎 profile

Hardware-aware 的代价就是你需要了解实际 serving engine 的性能曲线。换 GPU、kernel、parallelism 或 batch 策略后，最优调度可能需要重新 profiling。

⑤ 生产系统结果最有价值，也最难完全外部复现

论文给出的 live traffic 结果非常重要，但外部研究者很难拥有完全相同的模型、流量结构、集群和 SLA，因此应把它看成生产证据，而不是对所有部署环境的普适常数。

14 · AI Systems Worldview

把 DSpark 放进你的 AI 技术世界观

如果你最近同时在学 MoE、Agent、Harness、推理框架，这篇论文最值得建立的不是某个公式，而是分层思维。

模型层

Transformer、Attention、MoE、RMSNorm、训练目标……解决“模型怎么表示和计算”。

推理解码层

KV Cache、Speculative Decoding、MTP、Draft Model……解决“同一个模型怎么更快吐 token”。

Serving 层

Continuous batching、scheduler、prefill/decode 分离、负载管理……解决“几万人同时用时怎么跑”。

Agent / Harness 层

工具调用、MCP、Skills、Memory、Sandbox、ReAct loop……决定模型如何完成复杂任务。

硬件层

GPU、HBM、NVLink/网络、kernel、并行策略……决定所有上层设计的真实成本边界。

DSpark 横跨的是 推理解码层 + Serving 层 + Hardware-aware 调度。这类工作代表了一个很明显的趋势：

大模型优化正在从“只把模型做得更聪明”，走向算法与系统协同设计：相同的 target model，只要解码方式、批处理策略和硬件调度更聪明，用户体验和部署成本也能出现数量级很可观的变化。

如果只记住 5 句话

Speculative decoding：先让便宜模型猜多个 token，再让大模型一次验证。
Parallel drafter 快，但 block 内缺少依赖，容易 suffix decay。
DSpark 用“重并行 + 轻串行”补回 token 依赖。
长 draft 不代表都值得验证；高并发时 target batch capacity 很宝贵。
DSpark 用 confidence + hardware profile 动态选择 verification prefix，目标是提升整个 serving 系统的 Pareto frontier。

15 · Review

复习卡片：看完以后你应该能回答这些问题

什么是 speculative decoding？

用更便宜的 draft model 提议多个候选 token，再让 target model 并行验证，从而让一次昂贵的 target forward 有机会接受多个 token。

为什么 parallel drafter 的 block 不能无限加长？

虽然 draft latency 对 block size 不敏感，但后部 token 因缺少块内条件依赖而越来越不可靠，而且全部送去验证会占用 target batch capacity。

DSpark 的 semi-autoregressive “semi” 在哪？

重计算的 backbone 对整个 block 并行，而最终采样阶段使用轻量顺序 head，把前面已经采样的 token 信息注入后续位置。

Markov head 和 RNN head 有什么区别？

Markov head 主要依赖前一个 token 的一阶转移；RNN head 用 recurrent state 累积更长的 block 内前缀信息。

Confidence head 预测的到底是什么？

在前面的 token 已通过验证这一条件下，当前位置继续通过 target verification 的条件概率。

为什么 prefix survival probability 要相乘？

因为第 j 个 token 能被真正用到，要求 1…j 每个位置都连续通过验证，所以根据链式法则是条件概率的累积乘积。

为什么需要 calibration？

Scheduler 依赖概率绝对值来估算期望收益，而不是只看排序；confidence 若系统性过高或过低会导致错误调度。

Hardware-aware 在哪里？

Scheduler 读取引擎在不同 batch size 下的 SPS 性能 profile，比较“多验证 token 的收益”和“增大 batch 的代价”。

这篇论文最重要的系统思想是什么？

优化 LLM 推理不能只看单条请求或单个模型指标，而应围绕整个在线 serving 系统的吞吐—延迟 Pareto 前沿做联合优化。

为什么对 Agent 时代尤其重要？

Agentic workflow 往往包含大量连续模型调用、工具调用前后的短轮次生成以及多用户并发。单次 decode 省下来的延迟会在链式调用中反复累积，Serving 效率直接决定产品体验和成本。

自测标准：如果你能不用术语，向别人解释“为什么不能把 16 个 draft token 全都交给大模型验证”，基本就真正抓住了 DSpark 的核心。

16 · Primary Sources

原始资料与继续阅读

论文

DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
Xin Cheng et al., submitted 6 Jul 2026 · arXiv:2607.05147

https://arxiv.org/abs/2607.05147

DeepSeek 官方代码：DeepSpec

用于训练和评估 speculative decoding draft models 的代码库，包含 DSpark、DFlash、Eagle3。

https://github.com/deepseek-ai/DeepSpec

本笔记的来源策略

核心技术描述、公式逻辑、离线结果和 DeepSeek-V4 线上结果均以原论文为主；开源实现信息以 DeepSpec README 与官方配置为主。B 站视频用于发现主题，而不是作为最终技术事实的唯一依据。

整理日期：2026-09-28 · 学习用途。论文与代码后续若更新，具体数字和实现细节应以最新官方版本为准。

一句话总结：
DSpark 的厉害之处不是单独发明一个“更会猜的 draft model”，而是把“怎么猜、猜多长、哪些值得验证、当前 GPU 忙不忙”统一放进一个生产级推理解码框架里。