DeepSeek DSpark：把推测解码从草稿质量推进到系统调度

论文：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
机构：北京大学 + DeepSeek | 开源：MIT (github.com/deepseek-ai/DeepSpec)
arXiv: 2606.19348 | 发布：2026-06-27
一句话：并行草稿的"后缀衰减"被马尔可夫头干掉，验证长度由置信度头按需调度——推理速度+80%，吞吐+600%，无损。

一、先搞懂：为什么大模型生成这么慢？

想象你在写一封邮件。正常人脑子里已经把整句话想好了，手指在键盘上飞。但Transformer不是人——它只能一个字一个字往外蹦。

更具体地说：每生成一个token，模型必须把所有已生成的token再过一遍（KV缓存虽然避免了重复计算，但内存带宽瓶颈依然严重）。对于DeepSeek-V4 Pro这种1.6T参数、每token激活49B的MoE巨兽，这意味着大部分时间GPU都在等内存，而不是在算。

行业术语叫：memory-bound，not compute-bound。你的GPU算力利用率可能不到10%，因为它被困在"把权重从HBM搬到SM"这件事上。

推测解码（Speculative Decoding）就是来解决这个问题的。

二、推测解码："老板-实习生"模型

核心思路出奇地简单：

用小模型快速生成一串候选token（草稿），然后让大模型一次性并行验证这串token。大模型说"对"的，直接输出；说"错"的，从错的位置重新生成。

因为大模型验证一串token的时间 ≈ 生成一个token的时间（并行计算），所以只要草稿质量够高，整体速度就能起飞。

这就像：

• 实习生（小模型）先写一版方案草稿
• 老板（大模型）扫一眼，红笔打勾的照用，打叉的退回去重写
• 实习生写得越准，老板的工作量越轻

但这里有个致命问题：草稿质量会随着序列长度迅速衰减。

推测解码的"后缀衰减"困境

草稿token的接受率（acceptance rate）通常呈现这样的规律：

• 第1个token：95%被接受 ✓
• 第2个token：85% ✓
• 第3个token：70%...
• 第5个token以后：暴跌到50%以下

为什么？因为并行生成草稿时，后面的token看不到前面token的具体取值（只能看到前面的隐状态），导致误差累积。这就像让实习生写一份10页报告的第5页，但他还没看到前4页的最终定稿——只能猜。

业界现有两条路线：

DeepSeek的DSpark想同时吃掉两边的好处。

三、DSpark 的两个核心设计

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

DSpark的架构是**"重型并行骨架 + 轻量级顺序头"**的组合：

并行主干（Parallel Backbone）: 一次性生成长度为γ的整块草稿的隐状态表示
         ↓
马尔可夫头（Markov Head）: 每个位置只看前一个token，注入局部依赖
         ↓
采样出最终草稿token

关键洞察：并行骨架负责"快"，马尔可夫头负责"准"。

马尔可夫头有多轻？它只依赖于前一个token（而不像完整自回归那样依赖全部历史），通过低秩分解把额外延迟压到极低。它的作用是：在并行生成的隐状态基础上，给每个位置的logits加一个前缀依赖的偏置，让后面的token能"感知"到前面token的具体取值。

结果很暴力：

• 2层DSpark模块 > 5层传统并行草稿架构
• 离线测试：接受长度比DFlash高16-18%，比Eagle3高26-31%

RNN头的变体：论文还提到了一个RNN头版本（比马尔可夫头多看更多前缀历史），在部分任务上表现更好，但延迟稍高。生产部署选的是马尔可夫头版本。

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

这是DSpark最"工程"、也最被低估的设计。

传统推测解码的验证是盲目标量：不管草稿质量如何，每次固定验证γ个token。后果是：

• 草稿质量好的时候，验证长度不够，浪费了加速潜力
• 草稿质量差的时候，硬要验证长序列，浪费大模型的batch容量

DSpark的做法是：让草稿模型自己预测"这个token能不能过审"。

置信度头（Confidence Head）：训练一个小的二分类头，对每个草稿token输出一个置信度分数——表示"大模型会接受这个token的概率"。

硬件感知调度器（Hardware-Aware Scheduler）：

• 当置信度低于阈值时，提前终止草稿
• 当GPU负载低（空闲）时，多验证几个token
• 当GPU负载高（高峰）时，保守验证，保障并发

这相当于：实习生交草稿时，自己先过一遍，觉得不靠谱的地方主动标红，让老板只看有把握的部分。

调度器的效果：

• 聊天场景：接受率从45.7% → 95.7%
• 数学推理：接受率从76.9% → 92.5%

四、实测：数字说话

DSpark已经在DeepSeek-V4的生产环境部署。

单用户生成速度

吞吐量（严格SLA下）

注意：SLA越严格，DSpark的优势越明显。因为在严格的延迟要求下，传统方法几乎没有空间做推测解码——验证太长会超时。DSpark的置信度调度恰好解决了这个矛盾：只在有把握的时候才多验证。

质量

无损。DSpark是精确的推测解码变体，保持目标模型的输出分布完全一致。没有任何质量损失。

五、为什么这事值得重视？

1. 推理成本的大头不是模型，是serving

训练一个模型很烧钱，但推理才是真正的大头——你每天调用ChatGPT/Claude/DeepSeek的次数，乘以每次的token数，乘以并发用户数，这才是账单的主体。

DSpark不是新模型，是** serving层优化**。它把已有模型的服务效率提升了6倍，这意味着：

• 同样的硬件，服务6倍的用户
• 或者同样的用户，省下80%的GPU成本

2. 资源受限团队的工程智慧

DeepSeek的团队规模和算力资源远不如OpenAI/Anthropic/Google。但他们一直证明一件事：当算力不够时，工程效率就是最硬的壁垒。

DSpark的每一个设计选择都在说"我们没资源浪费"：

• 马尔可夫头只看前一个token（最小依赖）
• 低秩分解压缩额外延迟
• 置信度头按需调度（不做无用功）
• 硬件感知调度器（把GPU负载也当输入）

这不是"大力出奇迹"，这是精益工程。

3. 开源生态的良性信号

DSpark以MIT协议开源，训练代码（DeepSpec repo）也一并放出。更重要的是：

• 支持vLLM和SGLang集成
• 已有DeepSeek-V4-Pro/Flash的DSpark权重可直接下载
• 通用性强：论文测试了Qwen3和Gemma4系列，不限于DeepSeek自家模型

这对整个开源推理社区是大利好——任何跑vLLM/SGLang的团队都能受益于这个技术。

六、局限与未解问题

1. 草稿模型的训练成本

虽然DSpark的推理是零成本的（无损），但草稿模型本身需要训练。论文提到用Open-PerfectBlend 2数据集训练10个epoch。对于没有训练基础设施的团队，直接拿DeepSeek放出的checkpoint更实际。

2. 马尔可夫 vs RNN头的取舍

马尔可夫头更快但信息更少，RNN头更准但更慢。论文没有给出一个普适的选择标准，需要按任务特性调。

3. 对非自回归生成模型的兼容性

DSpark假设目标模型是自回归的。对于扩散模型（如DFlash的block diffusion路线）或其他非自回归架构，框架需要调整。

4. 长上下文场景的扩展

当上下文长度达到百万token级别时，草稿模型的KV缓存本身也会成为瓶颈。DSpark没有涉及这个层面的优化（虽然DeepSeek在KV缓存方面已有其他工作如Mooncake）。

七、一句话总结

DeepSeek DSpark的核心不是提出了什么惊天新理论，而是在"快但糙"的并行草稿和"准但慢"的自回归草稿之间，找到了工程上的最优折中点——用马尔可夫头注入刚好够用的顺序依赖，用置信度头避免做无用的验证。

结果：推理速度+80%，系统吞吐+600%，零质量损失，已开源。

对于任何做大模型 serving 的人来说，这都是一个值得仔细研究并接入现有技术栈的方案。

参考信息

• 论文：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation (arXiv:2606.19348)
• 代码：github.com/deepseek-ai/DeepSpec (MIT)
• 权重：huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark
• 部署：支持vLLM、SGLang
• 相关：DFlash (Chen et al., 2026), Eagle3 (Li et al., 2026), Mooncake (DeepSeek KV serving)

#论文解读 #DeepSeek #推测解码 #LLM推理 #AI基础设施 #小凯