大模型推理 MTP 算法 Survey

一、执行摘要与核心结论

DSpark 是什么。DSpark（全名 Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation）是 DeepSeek-AI 与北京大学于 2026 年 6 月 27 日联合开源的 LLM 推理加速框架。它不是新的基座大模型，而是挂载在已有 checkpoint 上的推理加速模块（draft model + scheduler）——DeepSeek-V4-Flash-DSpark / V4-Pro-DSpark 即「原 V4 权重 + DSpark 草稿模块」的组合包。^[1][2]

三大核心支柱（来自官方摘要原文）^[1]：

1. 半自回归生成（Semi-Autoregressive Generation）——用一个重并行骨干（parallel backbone）做大部分 draft 计算（T_draft ≈ O(1)，与 block size 无关），再叠加一个轻量串行头（Markov/RNN head）注入 block 内 token 依赖，解决纯并行 drafter 的 suffix decay（后置位置接受率快速衰减）。
2. 置信度调度验证（Confidence-Scheduled Verification）——一个 confidence head 估计每位置前缀存活概率，配合 hardware-aware prefix scheduler，把 verify 长度选择形式化为全局吞吐最大化问题，按实时 GPU 负载动态裁剪低置信后缀。
3. DeepSpec 开源基础设施——MIT 协议的统一训练/评测代码库，含 DSpark、DFlash、Eagle3 三种算法，附带 Qwen3-4B/8B/14B、Gemma4-12B 的 HuggingFace checkpoints。^[2]

"Speculative decoding accelerates Large Language Model (LLM) inference by decoupling draft generation from target verification. While recent parallel drafters efficiently propose long token sequences in a single forward pass, they suffer from rapid acceptance decay due to a lack of inter-token dependencies. Furthermore, indiscriminately verifying these extended blocks wastes critical batch capacity on tokens with high rejection risks, severely degrading throughput in high-concurrency serving systems. We introduce DSpark... To maintain draft quality, DSpark utilizes a semi-autoregressive architecture—coupling a parallel backbone with a lightweight sequential module... To optimize system efficiency, DSpark employs confidence-scheduled verification, dynamically tailoring the verification length for each request based on estimated prefix survival probabilities and engine-specific throughput profiles." — DSpark 论文摘要原文，arXiv 未收录，PDF 见 github.com/deepseek-ai/DeepSpec/DSpark_paper.pdf

核心结论（一句话）：DSpark 用「重并行骨干 + 轻量 Markov 串行头」在 T_draft ≈ O(1) 下逼近自回归 draft 的 coherence，再用 confidence head + hardware-aware scheduler 把 verify 从「固定长度」变为「按存活概率与引擎负载动态分配」——算法层解决 suffix decay，系统层解决高并发下静态多 token verify 的吞吐塌陷。它在 DeepSeek-V4 生产环境将 per-user 生成速度提升 60%–85%（同吞吐），并拓展了严格 SLA 下的服务能力前沿（Pareto frontier）。^[1][5]

二、MTP 算法基础：定义、训练目标与推理投机解码范式

2.1 投机解码（Speculative Decoding）基本循环

标准自回归解码每生成 1 个 token 需 1 次 target model 前向，延迟与输出长度近似线性。投机解码（Chen et al., 2023; Leviathan et al., 2023）将其拆为两阶段^[1]：

• Draft（草稿）：轻量 drafter 一次提出 γ 个候选 token x̂₁, …, x̂_γ
• Verify（校验）：target model 单次前向并行校验，按拒绝采样规则从左到右接受最长一致前缀，并附赠 1 个 bonus token

单轮平均每 token 延迟^[1]：

三条加速杠杆^[1]：

• 降 T_draft（draft faster）——如并行 drafter 把 T_draft 压到 O(1)
• 提 τ（draft better）——如 DSpark 的串行头提升后缀接受率
• 降有效 T_verify（verify smarter）——如 DSpark 的 confidence scheduler 动态裁剪

2.2 拒绝采样（Rejection Sampling）：无损校验的数学

无论 draft 来自 DSpark、EAGLE-3、内置 MTP 还是 Ngram，校验逻辑都遵循同一套投机解码框架，区别仅在 draft 如何产生、verify 前是否动态截断^[5]。对每个 draft 位置 k，target 计算自身分布 p_t^k，draft 分布为 p_d^k，接受 draft token x̂_k 的概率^[1]：

校验从左到右^[1][5]：

• 以概率 α_k 接受 x̂_k，继续检查 k+1
• 一旦在位置 k 拒绝，则 x̂_k, x̂_{k+1}, …, x̂_ℓ 全部丢弃（后缀再好也无效）
• 在拒绝位置 k，从调整分布重采样 1 个 token 作为纠正：q^k(v) = norm(max(0, p_t^k(v) − p_d^k(v)))

该性质保证：最终输出 token 序列的分布与 target 逐步自回归采样完全一致（无损 / lossless）。Greedy 解码（temperature=0）退化为简单比对——若 x̂_k = argmax p_t^k 则接受，否则拒绝并取 argmax 纠正。^[5]

Bonus token：Verify 结束后，除被接受的 draft 前缀外，target 额外产出 1 个 token——若 x̂₁,…,x̂_m 全被接受则 bonus 来自位置 m 的 target 分布；若在位置 k 拒绝则 bonus 为从 q^k 采样的纠正 token。因此单轮 τ = m + 1。^[5]

DSpark 的关键理论洞察（无损性前提）：CRF-NAT 也在并行 hidden states 上放串行模块，但其全局归一化 partition function 阻止精确 per-token 概率计算；CTC-drafter 因对齐路径的 latent marginalization 只能 greedy verify。DSpark 通过保持串行修正局部化，使 per-token 概率保持精确 softmax 求值，这是无损拒绝采样的前提。 — DSpark 论文 Section 6 Related Work，DSpark_paper.pdf

2.3 DeepSeek-V3 的 MTP 模块：权威定义（论文原文公式）

MTP（Multi-Token Prediction）一词在 DeepSeek-V3 论文中既是训练目标，也可复用为推理投机解码的 draft。以下为 DeepSeek-V3 技术报告 Section 2.2 的原文定义^[3]：

"Inspired by Gloeckle et al. (2024), we investigate and set a Multi-Token Prediction (MTP) objective for DeepSeek-V3, which extends the prediction scope to multiple future tokens at each position. On the one hand, an MTP objective densifies the training signals and may improve data efficiency. On the other hand, MTP may enable the model to pre-plan its representations for better prediction of future tokens... Different from Gloeckle et al. (2024), which parallelly predicts D additional tokens using independent output heads, we sequentially predict additional tokens and keep the complete causal chain at each prediction depth." — DeepSeek-V3 Technical Report, Section 2.2，arXiv:2412.19437

MTP 模块结构

DeepSeek-V3 的 MTP 用 D 个顺序模块预测 D 个额外 token。第 k 个 MTP 模块包含四部分^[3][8]：

• 共享 embedding 层 Emb(·)（与主模型共享）
• 共享 output head OutHead(·)（与主模型共享）
• 一个 Transformer block TRM_k(·)
• 投影矩阵 M_k ∈ ℝ^{d×2d}

对于第 i 个输入 token t_i，在第 k 个预测深度，先组合第 (k−1) 深度的表示 h_i^{k-1} 与第 (i+k) 个 token 的 embedding Emb(t_{i+k})（公式 21）^[3]：

（k=1 时 h_i^{k-1} 为主模型给出的表示。）组合后的 h'_i^k 作为第 k 深度 Transformer block 的输入（公式 22）^[3]：

再由共享 output head 算第 k 个额外预测 token 的概率分布（公式 23）^[3]：

MTP 训练目标

每个预测深度计算交叉熵损失（公式 24-25）^[3]：

"MTP in Inference. Our MTP strategy mainly aims to improve the performance of the main model, so during inference, we can directly discard the MTP modules and the main model can function independently and normally. Additionally, we can also repurpose these MTP modules for speculative decoding to further improve the generation latency." — DeepSeek-V3 Technical Report, Section 2.2，arXiv:2412.19437

这是理解 DSpark 的关键起点：DeepSeek 的 MTP 模块在训练时是提升主模型性能的辅助目标，在推理时可选择性地复用为投机解码的 draft。DeepSeek-V3 论文明确指出其保持因果链的原则与 EAGLE 类似，但 EAGLE 的首要目标是投机解码，而 DeepSeek 用 MTP 主要是为改进训练^[3]。

2.4 "MTP"一词的两种含义（对比 DSpark 时必须区分）

业界"MTP / Multi-Token Prediction"常指两类不同设计，对比 DSpark 时必须分开^[5]：

DSpark 属于外置 draft model路线，论文中的生产基线 MTP-1 则是 DeepSeek 内置的单 token MTP（静态 verify 2 token），二者不应混为一谈^[5]。

2.5 投机解码的简要历史脉络

"The idea did not appear out of nowhere... A key precursor came in 2018, when Mitchell Stern, Noam Shazeer and Jakob Uszkoreit proposed blockwise parallel decoding for deep autoregressive models... The research line became more explicit in 2022. Heming Xia, Tao Ge and co-authors introduced SpecDec... Later that year, Yaniv Leviathan, Matan Kalman and Yossi Matias posted 'Fast Inference from Transformers via Speculative Decoding'... DeepMind researchers followed in 2023 with a closely related method called speculative sampling." — VentureBeat，venturebeat.com/.../deepseek-open-sources-dspark

DSpark 论文 Section 6 也指出，现代投机解码建立在早期 blockwise 方法（Ge 2022, Stern 2018, Sun 2021, Xia 2023）之上，通过拒绝采样精确保持 target 分布（Chen 2023, Leviathan 2023）^[1]。

三、DeepSeek MTP 演进：V3 内置 MTP → MTP-1 → DSpark

3.1 第一阶段：DeepSeek-V3 内置 MTP（训练目标 + 可选 draft）

如第 2.3 节所述，DeepSeek-V3（671B 总参 / 37B 活跃 MoE）在预训练时设置 MTP 目标，主要 densify 训练信号、提升数据效率与表征 pre-plan 能力。推理时既可丢弃 MTP 模块让主模型独立运行，也可复用为投机解码 draft^[3]。AMD ROCm 教程实测在 SGLang + 8×MI300X 上，DeepSeek-V3 启用 MTP（NEXTN 算法，lmsys/DeepSeek-V3-NextN draft，num-steps=2, num-draft-tokens=3）后，延迟与吞吐提升 1.2 到 2.1 倍^[8]。

3.2 第二阶段：MTP-1 生产基线（保守的静态单 token）

尽管 V3 的 MTP 模块支持多 token draft，DeepSeek 在生产环境长期使用的是 MTP-1——仅 draft 1 个 token（+静态 verify 共 2 token）。DSpark 论文 Section 5.4 给出了原因^[1]：

"This single-token setup was historically maintained in production because deploying a static multi-token drafter (e.g., MTP-3/5) strictly degrades aggregate throughput under high concurrency due to excessive verification overhead." — DSpark 论文 Section 5.4，DSpark_paper.pdf

即：静态多 token MTP（MTP-3/5）在高并发下因 verify 开销过大严格降低聚合吞吐，故生产长期保守用 MTP-1。MTP-1 并非"劣化版 DSpark"，而是 DeepSeek 在吞吐与延迟权衡下选的保守基线^[5]。

3.3 第三阶段：DSpark 替换 MTP-1

"MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release." — DSpark 论文 Section 5.4，DSpark_paper.pdf

DSpark 在 DeepSeek-V4-preview 发布两周后即上线替换了 MTP-1。社区评论指出：若效果没有显著差距，DeepSeek 不会在生产环境做这种替换^[7]。DSpark 的价值在于同时提高 acceptance 并控制 verify 浪费——在保持吞吐前提下解锁长 block（生产 γ=5，低并发扩到 4–6 token verify）^[1]。

3.4 DeepSeek-V4 模型规格（生产载体）

^[6]两者均支持最高 100 万 token 上下文窗口。DSpark 在这两个模型上的生产实测见第 6 节。

3.5 演进时间线

四、DSpark 深度拆解：半自回归 + 置信度调度

DSpark 单轮解码循环（来自论文 Figure 1 描述）^[1][5]：

Target Model → 生成 anchor token D（上一轮 bonus token）
      ↓
[Parallel Backbone (DFlash 风格)]
   单次前向 → 全 block 隐状态 h₁…hγ + 基础 logits U₁…Uγ
      ↓
[Sequential Head (Markov / RNN)]
   自左向右采样，注入 token 间依赖 → 修正分布 p_k(·|x₀,x<k)
      ↓
[Confidence Head] → 每位置条件存活概率 c₁…cγ
      ↓
[Hardware-Aware Prefix Scheduler] → 动态截断 verify 长度
      ↓
Target Model 并行 verify 被保留的前缀 → 接受/拒绝 + bonus

4.1 半自回归生成（Semi-Autoregressive Generation）

4.1.1 动机：Parallel Drafter 的 Suffix Decay

纯并行 drafter（如 DFlash）在一次前向内独立预测 block 内各位置。当上下文存在多种合理续写（如 "of course" vs "no problem"）时，各位置对所有可能前驱做边缘化，易产生 multi-modal collision（如 "of problem"），导致 block 后部 acceptance 快速衰减^[1][5]。

"实际数字：DFlash 在对话任务上，第 1 个位置猜对率大概 72%，到第 7 个位置掉到 63%。前面猜错一个，后面全部连带作废。" — wiselychen 技术解析，ai-coding.wiselychen.com/.../dspark-...（转述论文 Figure 2 数据）

纯自回归 drafter（如 Eagle3）依赖建模强，但 T_draft ∝ γ，只能用浅层网络和小 block。DSpark 的折中：重并行 + 轻串行^[5]。

4.1.2 Parallel Stage（并行骨干）

基于 DFlash 架构，主要机制（论文 Section 2.2 + 3.1）^[1]：

• 从 target 若干层 {l₁,…,l_m} 抽取 hidden states，拼接投影后作为 KV 注入 draft 各层：H_ctx = RMSNorm(W_c[H(l₁);…;H(l_m)])
• 注入方式：K_i = [W^K_i H_ctx ; W^K_i H_d], V_i = [W^V_i H_ctx ; W^V_i H_d]（沿 sequence 维拼接）
• 全 block 双向注意力 + target context 注入
• 共享 target 的 embedding 与 LM head（冻结）
• 输入：anchor token embedding + (γ−1) 个 mask token embedding

相对原版 DFlash 的小改动：将 anchor 本身作为 block 第 1 个预测位，γ 个输入 token（anchor + γ−1 masks）产出 γ 个 draft logits，略减 draft 计算量^[1]。

4.1.3 Sequential Stage（轻量串行头）

在并行骨干输出的 base logits U_k 上，叠加前缀相关的 transition bias B_k(x₀, x<k, x_k)，通过自回归因子分解得到 block 内因果分布（论文公式 4）^[1]：

其中 x₀ = 上一轮 anchor，U_k = 并行骨干在位置 k 的 base logit，V = 词表。推理时按 p_k(·|x₀,x<k) 自左向右采样；因采样过程本身是序列的，串行模块必须计算轻量（T_sequential ≪ T_parallel）以保证整体 draft 延迟仍由并行阶段主导^[1]。

4.1.4 Markov Head（默认，生产用）

B_k 仅依赖前一 token：B(x_{k-1}, x_k)。原理上是完整 V×V 矩阵，用低秩分解近似（论文公式 5）^[1]：

低秩分解使存储与每步计算都很小，大词表也可高效。论文举例：一旦位置 1 采样 "of"，Markov head 在位置 2 提升 "course" 抑制 "problem"，缓解 cross-mode collision^[1]。

额外开销：约 0.2%–1.3% 相对 DFlash baseline^[5]；wiselychen 转述论文实测为整体延迟仅增加 0.6%–1.3%^[7]。

4.1.5 RNN Head（可选）

Markov head 超过一步即无记忆，RNN head 通过维护循环状态 s_k 累积 block 内完整前缀历史（论文公式 6）^[1]：

RNN head 在长 block 上 acceptance 略优，但部署复杂，论文默认 Markov^[5]。值得注意的是，论文 Section 6 提到并发工作 Domino 引入的 CausalEncoder 概念上类似 DSpark 的 RNN Head^[1]。

4.1.6 效果与关键对照实验

效果（Qwen3-4B）：DSpark 在 position 1 继承 deep parallel drafter 的高 acceptance（Math 约 0.93），同时在 position 2–7 抑制 DFlash 的快速衰减，曲线接近 Eagle3 的稳定性^[5]。

4.2 置信度调度验证（Confidence-Scheduled Verification）

4.2.1 问题：固定长度 Verify 的浪费

即使 draft 质量好，盲目 verify 整个 block 在高并发下会浪费 target batch 容量：尾部低置信 token 几乎必被拒，却占用与其他请求共享的算力。领域差异也显著：Code/Math acceptance 高，Chat 低（论文 Table 1：Qwen3-4B 上 Math τ ≈ 5.57，Chat τ ≈ 3.49）^[5]。

论文将瓶颈归因于两个相互作用因素（Section 3.2）^[1]：

• 数据侧：draft acceptance 跨域变化——结构化文本（code）acceptance 高，开放式 chat 显著低
• 系统侧：verify 额外 token 的实际成本严格依赖引擎负载——轻负载下额外 verify 即使被拒也近乎免费；高并发下每个不必要 verify 都占用本可服务其他请求的 target batch 容量

4.2.2 Confidence Head

对每个 draft 位置 k 输出标量 c_k ∈ (0,1)，表示在前缀全部已接受条件下，位置 k 的 token 能通过 target verify 的条件概率（论文公式 7-8）^[1]：

其中 h_k = 骨干 hidden state，W₁[x_{k-1}] = 上一 draft token 的 Markov Embedding。^[1]

4.2.3 Sequential Temperature Scaling (STS) 校准

因为 hardware-aware scheduling 需要累积接受概率的绝对幅度（而非仅排名）来计算期望 τ，而神经置信度估计常过自信，直接使用会扭曲吞吐估计。STS 引入逐位温度校准（论文 Section 3.2.1）^[1]：

• 因 c_k 建模条件概率，链式法则下前缀被接受的联合概率 = 累积乘积 ∏_{i≤k} c_i
• 用 held-out 验证集，自左向右逐位做 1D grid search 找最优温度，最小化累积乘积的 Expected Calibration Error (ECE)
• 已校准的前序位置分数保持固定
• 温度缩放是保序变换：修正概率幅度匹配经验接受率，但不破坏 confidence head 学到的相对 token 排名

知乎解析指出：STS 将 ECE 从 3%–8% 压到约 1%^[5]。

4.2.4 Hardware-Aware Prefix Scheduler（Algorithm 1）

将 verify 长度选择形式化为全局吞吐最大化问题（论文 Algorithm 1）^[1]。对请求 r，前缀存活概率与系统指标定义如下：

贪心解法（论文 Section 3.2.2）^[1]：因为 a_{r,j} 随 j 单调非增，扩展请求 r 从 j−1 到 j 的边际增益恰为 a_{r,j}。这一单调性保证了全局按 a_{r,j} 降序排序候选 token 自然尊重 block 内前缀依赖。算法按 a_{r,j} 全局降序贪心扩展各请求的 verify 前缀，每次 O(1) 查表更新 Θ，在 Θ 不再上升时 early stop。

无损性保证：lossless speculative decoding 严格要求 non-anticipating property——admission 决策不依赖未来候选 token^[1]。被 scheduler 保留并送入 target 的前缀仍按 §2.2 拒绝采样规则校验——调度只影响「验多少」，不改变「怎么验」，因此输出分布仍然无损^[5]。

4.2.5 生产适配（Section 5.2 工程妥协）

线上 SPS 曲线非平滑、与 Zero-Overhead Scheduling (ZOS) / CUDA Graph 冲突，论文做了工程适配^[5]：

• SPS 曲线非平滑 → 去掉 early stop，做全局搜索
• 与 ZOS / CUDA Graph 冲突 → 异步调度：用 2 步之前的 confidence 预测近似下一 step 的 batch 容量 K，当前 step 仍按实时 a_{r,j} 排序，形成因果屏障

"对话任务的验证通过率从 45.7% 提到 95.7%。不是猜得更准了，而是把没把握的猜测在送去验证之前就砍掉了，不浪费大模型的计算资源。" — wiselychen 转述 DSpark 论文，ai-coding.wiselychen.com/.../dspark-...

五、训练与工程实现：DeepSpec 全流程

5.1 DeepSpec 仓库定位

"DeepSpec is a full-stack codebase for training and evaluating draft models for speculative decoding. It contains data preparation utilities, draft model implementations, training code, and evaluation scripts." — DeepSpec 官方 README，github.com/deepseek-ai/DeepSpec（MIT License，6.2k stars）

DeepSpec 把 DSpark、DFlash、Eagle3 三种算法纳入统一训练/评测栈，便于公平对比^[2]。工作流分三阶段，每阶段输出喂入下一阶段^[2]：

1. Data Preparation——下载 prompt → 用 target 重生成 answer → 构建 target cache
2. Training——对 cached target outputs 训练 draft model
3. Evaluation——在 benchmark 任务上测投机解码 acceptance

5.2 训练目标（Target 全程冻结）

Target model 全程冻结；可训练部分为 parallel backbone、sequential block、confidence head。Embedding 与 LM head 与 target 共享且冻结^[5]。

位置权重 w_k = exp(−(k−1)/γ)，强调 block 前部（prefix verify 下前部贡献更大）。总损失（论文）^[5]：

5.3 典型配置（Qwen3-4B，论文 Table 1 对齐）

来自 config/dspark/dspark_qwen3_4b.py^[5]：

训练数据：Open-PerfectBlend（130 万条），分布为 math 39.4%、code 38.9%、chat 17.6%，训练 10 epoch^[5][7]。

5.4 DeepSeek-V4 生产配置（DSpark-5）

论文生产部署用的是 DSpark-5（γ=5）^[1][5]：

• Parallel backbone：3 层 MoE + mHC + 128 sliding window attention
• γ = 5，Markov head
• Confidence head 端到端训练 + STS 校准
• 训练优化：hidden state 通信（不传全词表 logits，只传 LM head 前 hidden）；anchor-bounded sequence packing

5.5 评测基准

DeepSpec eval_datasets/ 覆盖 9 项基准^[2]：gsm8k, math500, aime25, humaneval, mbpp, livecodebench, mt-bench, alpaca, arena-hard-v2。

5.6 Released Checkpoints（论文 Table 1 直接产物）

每个 checkpoint 用对应 target 模型在 non-thinking mode 下生成的 open-perfectblend 数据训练，是对应 config/ 下训练配置的直接输出^[2]：

所有权重前缀 deepseek-ai/，托管于 HuggingFace^[2]。

"Important. If you cite these results in a new paper, align your setup with the training settings in this repository; otherwise, the comparison is not meaningful. For domain-specific use, fine-tune the draft model again for better results, especially if the target model is expected to run in thinking mode." — DeepSpec README，github.com/deepseek-ai/DeepSpec

5.7 开源侧训练/评测命令示例

# 1. 环境
git clone https://github.com/deepseek-ai/DeepSpec
cd DeepSpec && pip install -r requirements.txt

# 2. 训练 DSpark draft（编辑 train.sh: config_path=config/dspark/dspark_qwen3_4b.py）
bash scripts/train/train.sh

# 3. 离线评测 accepted length
#   编辑 eval.sh:
#   target_name_or_path=Qwen/Qwen3-4B
#   draft_name_or_path=deepseek-ai/dspark_qwen3_4b_block7
bash scripts/eval/eval.sh

^[5]注意：DSpark 当前未进入 vLLM/SGLang 主线；生产部署走 DeepSeek 官方 serving + DeepSeek-V4-*-DSpark 权重包；开源侧用 DeepSpec 训练/评测^[5]。

六、实验结果：离线 accepted length 与生产 Pareto 前沿

6.1 离线 Accepted Length（论文 Table 1，γ=7，禁用 scheduler，含 bonus token）

论文在 Qwen3-4B/8B/14B、Gemma4-12B 上对比 DSpark 与 DFlash（并行 drafter）、Eagle3（自回归 drafter）。DeepSpec 对三者使用相同训练数据、相同 target 层特征、相同 block size（γ=7）重训，对比具有直接可比性^[5]。

Qwen3-4B 各任务 τ（含 bonus token）

^[5]（数据来自知乎对论文 Table 1 的转述）

三模型 macro-average 汇总

^[1][5][7]官方摘要原文："across the Qwen3-4B, 8B, and 14B target models, it improves the macro-average accepted length over the autoregressive Eagle3 by 30.9%, 26.7%, and 30.0%, and over the parallel DFlash by 16.3%, 18.4%, and 18.3%"^[1]。

6.2 生产 Pareto 前沿（论文 Section 5.4 + Figure 7，DSpark-5, γ=5）

部署于 DeepSeek-V4-Flash (preview) 与 V4-Pro (preview) 生产 serving 引擎，对比 MTP-1 基线。散点为真实用户流量原始遥测数据，实线为拟合性能前沿^[1]。

"At the moderate 80 tok/s/user SLA, DSpark improves aggregate throughput by 51% over the MTP-1 baseline. The stricter 120 tok/s/user SLA represents a qualitatively different regime: under this constraint, the single-token MTP-1 baseline approaches its operational boundary and can sustain only a very small concurrent batch. Consequently, the relative throughput ratio at this point is numerically large, with DSpark achieving a nominal 661% higher aggregate throughput. We therefore interpret this high-SLA point primarily as evidence that DSpark extends the feasible interactivity frontier, rather than as a representative multiplicative speedup over a well-utilized baseline." — DSpark 论文 Section 5.4，DSpark_paper.pdf

6.3 负载自适应机制（论文 Figure 8）

Figure 8 同时绘制聚合吞吐（上）与动态 verification budget（下）随系统并发的变化^[1]：

• 中等并发（V4-Flash <200 并发，V4-Pro <150 并发）：scheduler 利用可用 target 算力分配更长 verify budget，从 MTP-1 静态 2 token 扩到约 4–6 token/请求 → 每次前向接受更多 token，直接贡献 Pareto 前沿吞吐增益
• 高并发（target 容量饱和）：scheduler 动态收缩 budget，平均 verify 长度随负载平滑下降，低置信 draft token 在消耗关键 batch 容量前被剪枝

"This load-aware behavior stabilizes production deployment: DSpark maximizes the utility of idle compute under light traffic, while effectively preserving critical batch capacity under heavy traffic." — DSpark 论文 Section 5.4，DSpark_paper.pdf

6.4 社区独立实测

"开发者 Rafael Caricio 在 GitHub PR 中记录了单流 DeepSeek-V4-Flash DSpark 工作：预热基准锚点为无投机 26.33 tok/s、MTP-1 39.88 tok/s、DSpark 约 60 tok/s——相对 MTP-1 约 1.5x，相对无投机约 2.3x。后续 commit 记录五次运行均值 60.31 tok/s，1.51x over MTP-1，2.29x over 非投机。" — VentureBeat 报道 Rafael Caricio 的 GitHub PR，venturebeat.com/.../deepseek-open-sources-dspark

七、横向对比：DSpark vs MTP-1 / Qwen3.5 MTP / EAGLE-3 / DFlash / Ngram

7.1 方法分类总览

投机解码 Draft 来源
├─ 无模型：Ngram / Prompt Lookup（历史/提示串匹配）
├─ 外置 Draft：DSpark / DFlash / EAGLE-3（独立训练小网络）
│   ├─ EAGLE-3：全自回归 + TTT
│   ├─ DFlash：全并行（O(1) 单次 forward）
│   └─ DSpark：半自回归 + confidence scheduler
└─ 内置 MTP 头：DeepSeek MTP / Qwen3.5 MTP（预训练时嵌入 target）

^[5]

7.2 同类外置 drafter 速览（DSpark vs DFlash vs EAGLE-3）

^[5]DSpark 的设计目标：在 draft 质量上吸收 EAGLE-3 的后缀 coherence，在 draft 延迟上保持 DFlash 的 O(1) 并行优势，并在 verify 侧补上二者均缺的系统级调度。

7.3 DSpark vs EAGLE-3（详细对比）

EAGLE-3（NeurIPS 2025）是当前最强的自回归外置 drafter 代表，也是 DSpark 论文 Table 1 的主要 baseline。官方摘要^[4]：

"In this paper, we introduce EAGLE-3, which abandons feature prediction in favor of direct token prediction and replaces reliance on top-layer features with multi-layer feature fusion via a technique named training-time test. These improvements significantly enhance performance and enable the draft model to fully benefit from scaling up training data. Our experiments... show that EAGLE-3 achieves a speedup ratio up to 6.5x, with about 1.4x improvement over EAGLE-2. In the SGLang framework, EAGLE-3 achieves a 1.38x throughput improvement at a batch size of 64." — EAGLE-3 论文摘要，arXiv:2503.01840

EAGLE-3 相对 EAGLE-1/2 的两项核心改进^[5]：

• 放弃 feature-level 预测，改为 direct token prediction
• Training-Time Test (TTT)：训练时模拟推理阶段的多步自回归 draft，使 draft 模型适应"用上一步自己采样结果作为输入"的分布偏移

DeepSpec 训练配置对比（Qwen3-4B，公平设定）

二者共享：target 冻结、相同 Open-PerfectBlend 数据、10 epoch、相同 target_layer_ids^[5]。

机制层面对比（论文 Figure 2 解读）

^[5]

论文核心论点：EAGLE-3 和 DFlash 代表两种极端——AR 后缀好但首 token 弱且慢，Parallel 首 token 强但后缀衰减。DSpark 用半自回归在 acceptance 曲线上同时取两者之长；这是其相对 EAGLE-3 离线 +27–31% 的根本原因，而非单纯堆更多 draft 层。^[5]

选型建议

^[5]结论：EAGLE-3 在单用户低 batch 场景生态成熟、draft 更轻、独立评测最高 ~6.5×；DSpark 在 DeepSpec 公平设定下 accepted length 稳定领先约 27%–31%，并独有 confidence scheduler，优化目标（生产吞吐-延迟前沿 vs 单用户延迟）并不完全重合^[5]。

7.4 DSpark vs Qwen3.5 内置 MTP

Qwen3.5 在主干（如 64 层 hybrid：48 Gated-Delta-Net + 16 full attention）之上附加 1 个 MTP 层（layer index 64），推理框架（vLLM/SGLang/llama.cpp）将其作为 draft 做 native speculative decoding^[5]。

Qwen3.5 MTP 架构要点

• 输入：target 的 pre-norm hidden + 上一 token 的 embedding（非 mask 并行）
• 结构：单层 Transformer block（attn + SwiGLU FFN）
• Draft 方式：自回归——通常先 draft 1 个 bonus token，verify 后与 target 并行再 draft 下一步
• 典型配置：num_speculative_tokens=2（vLLM qwen3_next_mtp），SGLang speculative-num-draft-tokens=4
• 加速预期：约 1.5–2×^[5]

对比表

^[5]

本质差异：Qwen3.5 MTP 走 DeepSeek-V3 开创的「内置 auxiliary head」路线——优点是无额外模型文件、draft 与 target 表征天然对齐、部署简单；缺点是 draft 深度受限、多 token 静态 verify 在生产高并发下成为瓶颈、改进需重训整个模型族。DSpark 走「外置 + 系统协同」路线——draft 可更深、block 更长、TV/confidence 专优化 acceptance、scheduler 解耦系统负载；缺点是需单独训练维护 draft checkpoint、显存与工程复杂度更高。二者正交：Qwen3.5 理论上也可用 DeepSpec 训 DSpark draft 替代或补充内置 MTP。^[5]

7.5 DSpark vs DeepSeek MTP-1（生产基线）

^[5]

7.6 DSpark vs Ngram（Prompt Lookup）

^[5]结论：Ngram 是零成本插件，在重复文本场景极有效，但 acceptance 上界低且无法处理"首次出现"的续写；DSpark 是通用学习型 drafter，acceptance 显著更高并带系统级 scheduler，适合作为默认生产方案。Ngram 与神经 drafter 并非互斥——部分引擎可先尝试 n-gram 命中，未命中再回退 DSpark/MTP^[5]。

7.7 部署命令速查（vLLM / SGLang）

# vLLM
vllm serve Qwen/Qwen3-8B --speculative-config '{
  "method": "ngram",
  "num_speculative_tokens": 4,
  "prompt_lookup_min": 2,
  "prompt_lookup_max": 5
}'

# SGLang（仅 CUDA；禁用 overlap scheduler 与 mixed chunked prefill）
python3 -m sglang.launch_server --model Qwen/Qwen3-8B \
  --speculative-algorithm NGRAM \
  --speculative-num-draft-tokens 16 \
  --speculative-ngram-max-match-window-size 12

# vLLM
vllm serve Qwen/Qwen3.5-27B --tensor-parallel-size 8 --max-model-len 262144 \
  --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'

# SGLang（NEXTN，eagle-topk 必须为 1）
python3 -m sglang.launch_server --model-path Qwen/Qwen3.5-27B --tp-size 8 \
  --speculative-algo NEXTN --speculative-num-steps 3 \
  --speculative-eagle-topk 1 --speculative-num-draft-tokens 4

# vLLM
vllm serve deepseek-ai/DeepSeek-V3 --tensor-parallel-size 8 \
  --speculative-config '{"method":"deepseek_mtp","num_speculative_tokens":1}'

# SGLang
python3 -m sglang.launch_server --model-path deepseek-ai/DeepSeek-V3 --tp 8 \
  --speculative-algorithm EAGLE --speculative-num-steps 1 \
  --speculative-eagle-topk 1 --speculative-num-draft-tokens 2

# vLLM
vllm serve Qwen/Qwen3-8B --speculative-config '{
  "method": "eagle3",
  "model": "deepseek-ai/eagle3_qwen3_8b_ttt7",
  "num_speculative_tokens": 3
}'

# SGLang
python3 -m sglang.launch_server --model Qwen/Qwen3-8B \
  --speculative-algorithm EAGLE3 \
  --speculative-draft-model-path deepseek-ai/eagle3_qwen3_8b_ttt7 \
  --speculative-num-steps 3 --speculative-eagle-topk 4 \
  --speculative-num-draft-tokens 16

vllm serve Qwen/Qwen3-4B --speculative-config '{
  "method": "dflash",
  "model": "deepseek-ai/dflash_qwen3_4b_block7",
  "num_speculative_tokens": 7
}' --attention-backend flash_attn --max-num-batched-tokens 32768

# 生产部署（DeepSeek-V4）：使用官方 DSpark 捆绑权重
#   HuggingFace: deepseek-ai/DeepSeek-V4-Flash-DSpark
#                deepseek-ai/DeepSeek-V4-Pro-DSpark
# 推理入口：DeepSeek 官方 serving 栈（含 confidence scheduler）
#
# 开源侧：训练与评测（DeepSpec）
git clone https://github.com/deepseek-ai/DeepSpec
cd DeepSpec && pip install -r requirements.txt
# 编辑 scripts/train/train.sh: config_path=config/dspark/dspark_qwen3_4b.py
bash scripts/train/train.sh
bash scripts/eval/eval.sh

方法对照速查表

^[5]

八、系统与芯片视角：batch capacity、SPS 曲线、硬件适配

本节面向系统与芯片研究人员，从 GPU 算力-访存-kernel launch 角度解析 MTP/投机解码的硬件影响，以及 DSpark 的系统级设计如何与硬件特性耦合。

8.1 为什么投机解码能加速：算力-访存的不对称

LLM 自回归解码的瓶颈通常不是算力而是访存带宽。每次生成 1 个 token 都需把整个模型权重（和 KV cache）从 HBM 读到 SM，而每个参数只参与极少 FLOPs——GPU 算力大量闲置。投机解码的本质是^[6]：

"GPU 算得很快，但大部分时间都在等内存搬数据，像是一台跑车被困在红绿灯，油门踩不下去... 大模型一次验证 7 个字跟生成 1 个字的成本差不多（都是一次 forward pass），所以只要猜对率够高，速度就能翻好几倍。" — wiselychen 技术解析，ai-coding.wiselychen.com/.../dspark-...

即：verify γ 个 token 的单次前向，与生成 1 个 token 的单次前向，其权重访存成本几乎相同（都是一次模型 forward），但前者可产出最多 γ+1 个 token。只要 acceptance 够高，单位访存换取的有效 token 数大幅提升——这是投机解码在带宽受限场景下高效的根因，也是 MTP/DSpark 对芯片设计的核心启示：解码阶段的瓶颈是带宽而非算力，任何能"用算力换带宽利用率"的机制都有价值。

8.2 DSpark 的系统级核心：把 verify 长度变为调度变量

传统投机解码的 verify 长度是固定的（num_speculative_tokens 静态）。DSpark 的关键系统创新是把 verify 长度从"超参数"变为"在线调度变量"，并形式化为全局吞吐最大化^[1]：

其中 SPS(B) 是引擎吞吐曲线（给定 forward batch size B 时的 steps/s），在引擎初始化时 profile 一次存为 cost table^[1]。这是一个硬件感知的设计：scheduler 直接读取该硬件/引擎组合的实际 SPS 曲线来做决策，而非假设理想线性扩展。

SPS 曲线的硬件含义

SPS(B) 本质反映了硬件的 batch 扩展特性^[1]：

• 小 B（轻负载）：算术强度低，SM 利用率不足，SPS 近似常数——此时额外 verify token 几乎免费（边际成本趋零），故 scheduler 把 budget 从 2 token 扩到 4–6
• 大 B（高并发）：接近算力或显存带宽饱和，SPS 开始下降——此时每个 verify token 都有真实机会成本（占用可服务其他请求的 batch 容量），故 scheduler 收缩 budget

这意味着 DSpark 的收益高度依赖硬件 SPS 曲线的形状——曲线越平缓（小 B 区间越长），可激进扩展 verify 的空间越大；曲线越早饱和，scheduler 越早收缩。不同 GPU 代际（A100 vs H100 vs H800）、不同芯片（MI300X、国产芯片）的 SPS 曲线不同，DSpark 的实际收益会随之变化。

8.3 高并发下的 batch capacity 竞争

论文反复强调的核心矛盾^[1]：高并发下，verify token 与活跃请求共享 target 的 batch 容量。

"Under high-concurrency deployments, every unnecessary verification occupies target model batch capacity that could otherwise serve other active requests." — DSpark 论文 Section 3.2，DSpark_paper.pdf

这是为什么静态 MTP-3/5 在高并发下严格降低聚合吞吐——每个请求盲目 verify 3–5 个 token，会把 target 的 batch 填满低质量候选，挤掉其他请求的 admission。DSpark 的 confidence scheduler 通过在 verify 前剪掉低置信后缀，把宝贵的 batch 容量留给"最可能被接受"的 token，等效于一个准入控制（admission control）机制^[1]。

8.4 与 continuous batching / KV cache 的交互

• Continuous batching：投机解码的 verify 阶段在 continuous batching 框架下表现为"一个请求一次前向处理 ℓ+1 个 token"。verify 长度动态化意味着 batch 内不同请求的 token 数不同，需要引擎支持变长 verify 的批处理。DSpark 的 scheduler 显式管理总 batch token 数 B = Σ(1+ℓ_r)^[1]，与 continuous batching 的 token-level 调度天然契合。
• KV cache：draft model 的 KV cache（尤其 DFlash 式多层 KV 注入）需要额外显存。DSpark 用 5 层 parallel backbone + Markov head，显存开销中等。hybrid 模型（如 Qwen3.5 MoE + GDN）在特定硬件上 DFlash 可能触发 KV cache page size 对齐问题，需调 --max-num-seqs^[5]。
• Tree attention：EAGLE 系支持 tree-based verification（多路径并行 verify），但论文指出"大量 verify token 数降低整体服务吞吐"^[1]。DSpark 论文 offline 评测统一用 chain-based drafting（单链、无树）以公平对比^[5]。

8.5 与引擎优化（ZOS / CUDA Graph）的冲突与妥协

现代推理引擎广泛使用 Zero-Overhead Scheduling (ZOS) 与 CUDA Graph 来消除调度开销、提升 GPU 利用率。但 DSpark 的 dynamic scheduler 与之冲突^[5]：

• CUDA Graph 要求静态 shape/计算图，而 DSpark 每步 verify 长度可变 → 直接冲突
• ZOS 期望调度决策在 kernel 启动前确定，而 DSpark 的 confidence 依赖当前 step 的 draft 输出 → 时序冲突

论文的工程妥协：异步调度——用 2 步之前的 confidence 预测近似下一 step 的 batch 容量 K，当前 step 仍按实时 a_{r,j} 排序，形成因果屏障^[5]。这是一个算法动态性 vs 系统静态性的典型权衡，对芯片/引擎协同设计有启示：未来硬件若能原生支持变长 batch 的高效 CUDA Graph 或动态调度，DSpark 类方法的工程妥协成本将大幅降低。

8.6 硬件代际与芯片适配

8.7 模型规模与收益关系

"模型越大收益越高。Speculative decoding 的原理是'大模型验证的边际成本低'，所以 target model 越大、drafter 跟 target 的速度差距越大，收益越明显。在小模型（7B 以下）上，drafter 本身的开销可能吃掉大部分收益。" — wiselychen 技术解析，ai-coding.wiselychen.com/.../dspark-...

这解释了 DSpark 在 DeepSeek-V4-Pro（1.6T/49B 活跃）与 V4-Flash（284B/13B 活跃）这类大 MoE 上收益显著——target 验证的单步成本远高于 draft 生成，加速比被放大。也意味着中小模型（≤7B）部署 DSpark 需谨慎评估 draft 开销占比^[7]。

九、局限、未来方向与对开源生态的影响

9.1 论文自述局限（Section 5.4 Limitations）

"Although the prefix scheduler minimizes wasted target-model verification, DSpark still incurs a fixed draft-side cost to generate the initial γ-token block via the parallel backbone. For complex queries with inherently low acceptance rates, this upfront drafting compute is unrecoverable. Future optimizations could introduce difficulty-aware early exiting within the draft model, enabling such requests to bypass full-block generation." — DSpark 论文 Section 5.4，DSpark_paper.pdf

即：低 acceptance 的复杂查询，parallel backbone 的前期 draft 计算是固定且不可回收的浪费。未来方向是 difficulty-aware early exit，让难题跳过完整 block 生成^[1]。

9.2 工程视角的补充局限（社区解析）

9.3 与内置 MTP 的关系

DSpark 未取代 MTP 预训练目标，而是 serving 层的替代或增强；V4 仍保留 MTP 模块，生产选用 DSpark 外挂^[5]。二者正交——Qwen3.5 理论上也可用 DeepSpec 训 DSpark draft 替代或补充其内置 MTP^[5]。

9.4 对开源生态与产业的影响

"过去 speculative decoding 的问题不是理论不成熟，而是工程门槛太高... 结果就是：论文很多，但真正在生产环境用起来的主要就是 Google（Gemini）跟 DeepSeek。DeepSpec 把大部分工作打包开源了，而且默认支援的就是社群最常用的 Qwen3 跟 Gemma4。落地门槛从'需要一个推理团队'降到'下载 checkpoint + 改配置'。" — wiselychen 技术解析，ai-coding.wiselychen.com/.../dspark-...

核心影响^[6][7]：

• 跨模型通用：DSpark 不绑 DeepSeek 自家模型，Qwen3、Gemma4 均有现成 checkpoint；企业可为自己托管的开权重模型（Llama、Mistral、Granite、Command 等）训练 DSpark-style draft^[6]。
• 开源 vs 闭源：DSpark 适用于企业控制权重和 serving 栈的场景；对纯 API 客户（无法访问 token verify loop、logits、batching、scheduler）无法从外部启用^[6]。这强化了开权重/自托管 AI 基础设施的理由。
• 推理优化成新战场：VentureBeat 评述"decoding efficiency is becoming another major battleground"——Faster generation 意味着更低用户延迟、更高 provider 吞吐、更好经济性^[6]。
• 填平护城河："推理加速过去一直是闭源厂商的护城河。DSpark 把护城河填平了一块。"^[7]
• 生态集成预期：若 vLLM/SGLang 集成 DSpark（考虑 MIT 协议，"只是时间问题"），开源模型推理速度将集体提升^[7]。

9.5 未来研究方向（综合论文 + 社区）

1. Difficulty-aware early exit：低 acceptance 请求跳过完整 block 生成（论文明确）^[1]
2. Scheduler 近似改进：异步 2-step 延迟、非平滑 SPS 曲线的工程妥协，理论最优与线上实现存在 gap^[5]
3. 多级 proposer：Ngram 命中 → 回退 DSpark/MTP，需框架支持^[5]
4. thinking mode 适配：reasoning 模型需重新 fine-tune draft^[2]
5. draft tree + scheduler 融合：DSpark 论文用单链公平对比，生产可探索 draft tree 与 scheduler 结合^[5]
6. 芯片协同设计：原生支持变长 batch CUDA Graph / 动态调度的硬件，可消除异步调度妥协（见 §8.5）

十、参考资料与可溯源链接

一手来源（论文 / 官方仓库）

[1] DSpark 论文（33页，权威核心）
Xin Cheng, Xingkai Yu, Chenze Shao, Jiashi Li, Yunfan Xiong 等. DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation. 北京大学 + DeepSeek-AI.
🔗 github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf（arXiv 未收录，PDF 在仓库内）

[2] DeepSpec 官方仓库（MIT License，6.2k stars）
DeepSpec: a full-stack codebase for training and evaluating speculative decoding algorithms. 含 DSpark/DFlash/Eagle3 + checkpoints.
🔗 github.com/deepseek-ai/DeepSpec

[3] DeepSeek-V3 技术报告（MTP 算法根基，Section 2.2 公式 21-25）
DeepSeek-AI. 671B 总参/37B 活跃 MoE，MTP 训练目标.
🔗 arXiv:2412.19437 | HTML: arxiv.org/html/2412.19437v2

[4] EAGLE-3 论文
EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test. NeurIPS 2025. direct token prediction + TTT，最高 6.5×.
🔗 arXiv:2503.01840

二手深度解析（技术媒体 / 社区）

[5] 知乎专栏《DeepSeek新作——DSpark 技术解析与常见MTP方法对比》
最详尽的对比分析，含 vLLM/SGLang 部署命令、Table 1 细节、Algorithm 解读.
🔗 zhuanlan.zhihu.com/p/2054952750140612858

[6] VentureBeat 报道（2026-06-29，Carl Franzen）
生产数据、V4 模型规格、投机解码历史脉络、社区实测（Rafael Caricio PR）.
🔗 venturebeat.com/.../deepseek-open-sources-dspark

[7] wiselychen 技术解析（2026-07-02）
工程视角、坦诚局限、Open-PerfectBlend 数据分布、Markov 开销数据.
🔗 ai-coding.wiselychen.com/.../dspark-...

[8] AMD ROCm MTP 教程（DeepSeek-V3 MTP 部署实操）
SGLang + 8×MI300X 跑 DeepSeek-V3 MTP，吞吐/延迟提升 1.2–2.1×.
🔗 rocm.docs.amd.com/.../mtp.html

其他参考链接

• HuggingFace (V4-Pro-DSpark): huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark
• 百度百科 DSpark: baike.baidu.com/en/item/DSpark
• 富途牛牛报道: news.futunn.com/.../75194149
• vLLM 投机解码文档: docs.vllm.ai/features/speculative_decoding
• SGLang 投机解码文档: docs.sglang.io/.../speculative_decoding
• EAGLE 代码: github.com/SafeAILab/EAGLE
• DFlash 论文（知乎引用）: arXiv:2602.06036
• DeepSeek-V4（知乎引用）: arXiv:2606.19348