大模型推理的"免费加速"还能怎么卷？DSpark 深度解读

> 核心直觉：推测性解码就像考试时的"先写草稿再誊正"。传统的并行草稿器写得快但前后句不连贯（越往后越错）；自回归草稿器写得顺但太慢。DSpark 的 trick 是——用一个大模型并行出骨架，再用一个轻量顺序头给骨架"加肌肉"，同时让系统根据实时负载动态决定"誊多少"，绝不浪费墨水。

---

一、为什么大模型推理这么慢？

想象你正在和一个AI聊天。你发了一句话，AI开始回复：

> "今天" → "天气" → "不错" → "适合" → "出去" → "走走"

每个词（token）的生成都需要把前面所有词喂给模型，做一次完整的前向传播。这就是自回归生成——像多米诺骨牌，必须一块一块倒。

问题很明显：

• 生成100个token = 100次前向传播
• 每次传播都要加载庞大的权重矩阵
• GPU利用率极低（大部分时间花在加载权重，不是计算）

推测性解码（Speculative Decoding）是解决这个问题的经典方案：

> 用一个轻量级的"草稿模型"（Draft Model）快速预生成一堆候选token，然后用重型"目标模型"（Target Model）一次性批量验证。

就像考试时先快速写草稿，再誊写到答题卡上。草稿写得越快越准，整体效率就越高。

但这里有两个致命矛盾：

矛盾1：并行草稿 → 写得快但前后不连贯

并行草稿器（如DFlash）一次前向传播生成γ个token，每个位置独立预测。问题是——

token之间没有依赖关系。

位置1预测"天气"，位置2独立预测"晴朗"。但如果位置1实际被接受了"气候"，位置2的"晴朗"就大概率错了——因为它从来没看过"气候"这个上下文。

结果是：越往后的token，被接受的概率越低。 论文里叫"后缀衰减"（suffix decay）。

矛盾2：自回归草稿 → 写得顺但太慢

自回归草稿器（如Eagle）逐个生成token，每一步都依赖前一步。接受率高，但生成本身就和目标模型一样慢——抵消了推测解码的收益。

矛盾3（更隐蔽）：高并发下的"无效验证"

生产环境里，系统同时服务成百上千个用户。每个用户都发了一堆草稿token让目标模型验证。

但那些置信度很低的尾部token（大概率会被拒绝的），也占用了宝贵的batch容量。在高负载时，这些"几乎注定被拒绝"的token严重拖累整体吞吐量。

论文原话：

> "When the system is under high load, these low-confidence tail tokens waste valuable batch processing compute power."

---

二、DSpark 的双核解法

DSpark 用两个设计同时解决了上述三个矛盾。

设计一：半自回归生成（Semi-Autoregressive Generation）

核心思想：保留并行主干的高速度，只加一个轻量级顺序头注入局部依赖。

架构像三明治：

输入: Anchor token（上一轮目标模型生成的bonus token）
      ↓
┌─────────────────────────────┐
│  Parallel Backbone (5层MoE) │  ← 重型并行主干，单次前向传播
│  输出: base logits + hidden │     产生γ个位置的初始预测
└─────────────────────────────┘
      ↓
┌─────────────────────────────┐
│  Sequential Head (Markov)   │  ← 轻量顺序头，逐token修正
│  输入: 前一个token的embedding│     注入一阶依赖
│  输出: 修正后的logits       │
└─────────────────────────────┘
      ↓
输出: γ个draft tokens + 置信度分数

Markov Head 的数学：

B(x_{k-1}, ·) = W_1[x_{k-1}] W_2

W_1: V × r 的嵌入查找表 (r=256)
W_2: r × V 的logit投影
总参数量: 2 × r × V

翻译成人话：

• 位置1采样了"of" → Markov head 给"course"加分、给"problem"减分
• 位置2采样了"the" → Markov head 给"best"加分、给"worst"减分

这就是一阶马尔可夫依赖——每个token只看前一个token，但累积起来，整个序列就有了连贯性。

论文还对比了RNN Head（维护循环状态，记忆完整前缀），但实验发现Markov Head已经够好了，部署更友好。

效果对比（论文图2）：

位置	Eagle3	DFlash	DSpark
位置1	0.53	0.72	0.93
位置2	0.63	0.69	0.89
位置3	0.68	0.66	0.85
位置4	0.71	0.64	0.82
位置5	0.73	0.63	0.79

Eagle3从低到高上升（自回归优势，前缀越长越准），DFlash从高到低衰减（并行独立预测的后遗症），DSpark两者兼得——高初始接受率 + 稳定保持。

设计二：置信度调度验证（Confidence-Scheduled Verification）

这是DSpark的工程杀手锏。

传统推测解码：不管置信度高低，所有草稿token一股脑发给目标模型验证。高负载时，那些"明显会被拒绝"的尾部token占用了宝贵的batch容量，拖累整体吞吐量。

DSpark的做法：给每个位置打上"存活概率"标签，系统根据实时负载动态决定验证多少。

#### Confidence Head

c_k = σ(w^T [h_k; W_1[x_{k-1}]])

输入: backbone hidden state h_k + 前一个token的Markov embedding
输出: 条件接受概率 c_k ∈ (0,1)

监督目标：

c_k* = 1 - (1/2)||p_k^d - p_k^t||_1

= draft分布与target分布的总变分距离

简单说：confidence head 学会预测"这个位置有多大可能被目标模型接受"。

#### Sequential Temperature Scaling (STS) 校准

神经网络的置信度通常过自信（overconfident）。直接用会扭曲吞吐量估计。

DSpark在held-out验证集上逐位置校准：

• 位置1：搜索最优温度，最小化ECE
• 位置2：固定位置1的温度，只调位置2
• 位置3：固定位置1-2，只调位置3
• ...

效果：ECE从3-8%降到~1%。

#### Hardware-Aware Prefix Scheduler

核心优化目标：最大化系统级token吞吐量

Θ = τ · SPS(B)

B = Σ(1 + ℓ_r)    ← 总验证batch size（token数）
τ = Σ(1 + Σ a_{r,j})  ← 期望接受token数
a_{r,j} = Π c_{r,i}   ← 前缀生存概率
SPS(B) = 引擎profiled的吞吐量（steps/second）

贪心算法： 1. 计算所有前缀生存概率 2. 全局排序所有候选扩展（按a_{r,j}降序） 3. 贪心准入：逐个尝试扩展验证长度 4. 每步查表得 Θ = τ* · SPS(B) 5. Θ不再增加时break

关键保证：非预期性（Non-anticipating）

break决策只依赖已处理到当前步的前缀，与未采样的未来token隔离。这保证了目标模型的输出分布完全无损恢复——推测解码最核心的理论约束。

---

三、生产环境的工程艺术

论文最令人 impressed 的不是算法，而是工程——把理论算法塞进真实线上系统的技巧。

挑战1：调度延迟

理论算法要求每步动态决定验证长度，但生产系统的Zero-Overhead Scheduling（ZOS）要求提前知道下一步batch size。矛盾。

DSpark的解法：异步调度

Step t-2: 生成置信度，预测Step t的容量K
Step t-1: 正常执行
Step t:   用t-2的历史预测确定截断长度
          当前候选token按实际置信度排序
          执行dynamic top-K选择

因果屏障：准入决策与当前token的实现隔离——保证无损。

挑战2：非平滑SPS曲线

理论假设SPS(B)平滑单峰，实际引擎的吞吐量曲线是离散、阶梯式下降的。

DSpark的解法：

• 移除early-stopping break
• 无约束全局搜索
• ZOS异步设计自然防止信息泄露

挑战3：可变长度验证的物理执行

标准decode kernel针对固定query长度优化，可变长度导致padding和负载不均。

DSpark的解法：

• 逻辑序列追踪与物理执行解耦
• 所有token展平为独立元素
• 通过marker tensor在稀疏attention中表达序列内依赖
• DeepSeek-V4上仅需修改：index-attention kernel + compress kernel

---

四、实测数据有多硬

离线实验（Qwen3系列）

目标模型	方法	Math	Code	Chat
Qwen3-4B	Eagle3	4.56	3.87	2.40
	DFlash	4.80	4.44	2.95
	DSpark	5.57	5.12	3.49

宏观平均提升：

• vs Eagle3: +30.9% (4B), +26.7% (8B), +30.0% (14B)
• vs DFlash: +16.3% (4B), +18.4% (8B), +18.3% (14B)

在线生产部署（DeepSeek-V4真实流量）

引擎	SLA锚点	吞吐量提升	每用户速度提升
V4-Flash	80 tok/s/user	+51%	+60%
	120 tok/s/user	+661%*	+85%
V4-Pro	35 tok/s/user	+52%	+57%
	50 tok/s/user	+406%*	+78%

*注：高SLA点基线进入低并发退化区，数值为扩展可行前沿的证据

最关键的突破：在严格交互时延约束下，DSpark避免了吞吐率大幅滑坡，实现了以往无法达成的性能档位——推高了整套服务系统的帕累托最优边界。

置信度头诊断（最有意思的发现）

领域	阈值0接受率	阈值0.8接受率	修剪效果
Math	76.9%	92.5%	温和
Code	67.6%	92.0%	中等
Chat	45.7%	95.7%	显著

高熵任务（开放式对话）受益最大——因为对话的token分布更分散，很多位置本身就是"猜的"，剪掉这些猜的token对吞吐量提升最明显。

---

五、DeepSpec：不只是论文，是完整的开源基建

DSpark 同步开源了：

组件	内容
DSpark checkpoints	DeepSeek-V4-Flash/Pro preview
DeepSpec 训练框架	数据准备、草稿模型实现、训练代码、评估脚本
基线实现	Eagle3, DFlash, DSpark 全都有

训练目标函数：

L = 0.1·L_ce + 0.9·L_tv + 1.0·L_conf

L_ce:  交叉熵，预测正确token
L_tv:  总变分距离，匹配目标分布（直接优化接受率）
L_conf: BCE，校准置信度估计

权重设计很巧妙——90%的权重放在匹配目标分布上，而不是预测正确token。因为推测解码的核心指标是"被目标模型接受多少"，不是"草稿模型自己猜对多少"。

---

六、更大的图景：推理加速的军备竞赛

DSpark 的发布时间点很有意思——DeepSeek刚完成500亿元融资，第一次放出开源新成果，选择的不是新模型，而是推理加速的工程方案。

这传递了一个信号：当模型能力差距缩小时，推理效率就是护城河。

看看推测解码的技术演进：

时间	方法	核心思想
2022	Speculative Decoding	草稿+验证基础框架
2023	Lookahead / Medusa	并行草稿，树形验证
2024	Eagle / EAGLE-2	自回归草稿，高接受率
2024	DFlash	并行草稿，深层主干
2025	Eagle-3	自回归+特征重用
2026	DSpark	半自回归+置信度调度

DSpark 的 unique 在于：它不是"更快"或"更准"的二选一，而是同时做到了"又快又准，还会看系统脸色行事"。

半自回归解决了"快和准"的矛盾，置信度调度解决了"质量和效率"的矛盾——这是推测解码从"算法玩具"走向"生产利器"的关键一步。

---

七、局限与思考

论文没有明确讨论的局限：

1. Markov head的一阶限制：只依赖前一个token，对于需要长距离依赖的推理任务（如多步数学证明），增益可能有限。RNN head实验显示边际增益不大，说明这个问题本身就很难。

2. 异步调度的两步延迟：用t-2的预测决定t的容量，在负载快速波动时可能有滞后。论文提到"负载自适应行为"图显示在重负载时平滑收缩，但极端瞬态场景下可能有挑战。

3. DeepSeek-V4特定的工程优化：index-attention kernel + compress kernel的修改是MoE架构特定的，其他架构（如Dense LLaMA）可能需要不同的工程适配。

---

结语：梁文锋为什么选择这篇论文作为融资后的首秀

500亿融资后的第一个开源成果，不是更大的模型，不是更强的能力，而是让现有模型跑得更快。

这很 DeepSeek。

当整个行业在卷参数规模、卷 benchmark 分数时，DeepSeek 始终盯着最实际的问题：推理成本。

模型能力决定了你能做什么，推理成本决定了你能服务多少人。

DSpark 的 60%-85% 速度提升，意味着同样的GPU集群，可以服务 1.6-1.85 倍的用户。在to-C的免费聊天场景中，这就是生死线。

而且这次开源不只是论文——DeepSpec 提供了完整的训练框架，DSpark checkpoints 可以直接用。这不是"秀肌肉"，是"送工具"。

梁文锋署名，联合北大，开源权重，开源训练代码。

这个组合本身就在说：推理加速不是某个公司的独门秘籍，而是整个行业的基础设施。我们来搭第一块砖，大家一起来盖房子。

> "当行业在讨论谁的模型更聪明时，DeepSeek仍然把目光投向更现实的问题：如何让模型更快。"

---

参考来源：

• Cheng, X., et al. (2026). "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation." DeepSeek-AI & Peking University.
• GitHub: https://github.com/deepseek-ai/DeepSpec
• Hugging Face: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

#论文解读 #费曼风格 #AI #DeepSeek #推理加速 #推测解码 #DSpark #开源 #小凯