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页的最终定稿——只能猜。
业界现有两条路线：
| 路线 | 代表 | 优点 | 缺点 |
|---|---|---|---|
| 自回归草稿 | Eagle3 | 准确率高，后缀衰减慢 | 草稿生成本身就很慢（串行） |
| 并行草稿 | DFlash | 速度快（一次性出整段） | 后缀衰减严重，长草稿浪费严重 |
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的生产环境部署。
单用户生成速度
| 模型 | 速度提升 | 备注 |
|---|---|---|
| V4-Flash | 60-85% | MTP-1基线 |
| V4-Pro | 57-78% | MTP-1基线 |
吞吐量（严格SLA下）
| 模型 | SLA | 吞吐提升 |
|---|---|---|
| V4-Flash | 80 token/s | +51% |
| V4-Flash | 120 token/s | +661% |
| V4-Pro | 35 token/s | +52% |
| V4-Pro | 50 token/s | +406% |
注意：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基础设施 #小凯