DSpark = 一个让大模型“写得快、写得准”的推理加速模块

DSpark的全称来自论文标题：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation。

翻译成人话就是：一种“先打草稿、再批量审稿”的加速技术。

关键信息速览：

维度	说明
发布方	DeepSeek × 北京大学联合发布
本质	推测性解码（Speculative Decoding）加速框架
部署位置	DeepSeek-V4-Flash 和 DeepSeek-V4-Pro 预览版
速度提升	Flash模型提升60%-85%，Pro模型提升57%-78%
开源状态	论文、训练代码、模型权重已在GitHub DeepSpec项目开源

重点强调：DeepSeek-V4-Pro-DSpark 并非全新架构模型，而是在原有版本基础上引入了推测性解码模块。更新重点在于工程落地，而非模型能力本身的迭代。

二、核心原理：从“一个字一个字写”到“打草稿+批量审稿”

2.1 传统方式为什么慢？

想象一下：老师让你写一篇作文，你每写一个字都要举手问老师“这个字对不对？”老师点头你才写下一个——写100个字要举手100次。

这就是传统大模型的工作方式：每生成一个Token都要做一次完整计算。

2.2 推测性解码的基本思路

推测性解码的思路很巧妙：让一个小模型先打草稿，再让大模型批量审稿。

打个比方：传统方式是“写一个字、查一次字典”；推测解码是“先写一段草稿，再一次性校对” 。

但现有的推测解码方案有两个致命问题：

2.3 两大瓶颈：为什么以前的方案不够好？

瓶颈一：自回归草稿模型（如Eagle3）——草稿写得慢

自回归草稿模型像正常语言模型一样，一个Token接一个Token地生成候选内容。优点是候选质量高（前后关系自然），缺点是草稿本身写得慢——候选Token越多，打草稿阶段越耗时。

瓶颈二：并行草稿模型（如DFlash）——草稿质量差

并行草稿模型可以一次性生成多个候选Token，速度很快。但问题在于，候选块内部的Token之间缺少足够的依赖关系。

论文里举了个很直观的例子：模型面对某个上下文时，可能同时存在“of course”和“no problem”两种合理续写。并行草稿模型因为没有真正按顺序生成，很容易把两条续写路径混在一起，生成 “of problem”或“no course” 这种前后不一致的组合。

结果就是：开头几个Token还不错，但越往后，被接受的概率下降越快——论文把这种现象称为后缀衰减（Suffix Decay） 。

三、DSpark的两大创新：把两个方案的优点结合起来

DSpark针对上述两个瓶颈，提出了两项互补机制。

3.1 创新一：半自回归架构（Semi-Autoregressive）——“草稿写得又快又好”

DSpark采用半自回归生成架构：把生成任务拆成两部分：

逐层拆解：

• 并行主干网络：基于DFlash改进，一次性产出全部候选位置的隐藏状态和基础logits。这个主干包含3个MoE层和滑动窗口注意力，最大候选块长度设为5。

• 轻量级顺序模块：逐Token注入前缀依赖信息。提供两种实现：

  • 马尔可夫头（Markov Head） ：仅依赖前一个Token，轻量高效

  • RNN头：通过循环状态累积完整前缀信息，更精确但稍重

效果有多夸张？ 实验表明，仅2层Transformer深度的DSpark，就能在所有测试领域上超过5层DFlash的接受长度。用更少的参数，取得了更好的效果。

3.2 创新二：置信度调度验证（Confidence-Scheduled Verification）——“只审该审的稿”

以往的推测解码方案有个通病：不管草稿质量如何，一股脑全部送去验证。

这在高并发场景下问题很大——系统忙的时候，验证那些大概率会被拒绝的Token，白白浪费宝贵的GPU算力。

DSpark的解决方案是引入置信度调度验证机制：

核心机制：

1. 置信度头（Confidence Head） ：模型在每个候选位置输出一个置信度分数，预测该Token在给定此前所有Token均被接受的条件下的“存活概率”

2. 硬件感知前缀调度器：将验证长度选择建模为全局吞吐量最大化问题——给定一批并发请求及其各位置置信度，结合预先实测的引擎吞吐量曲线，为每个请求动态决定验证多长的候选前缀

3. 异步调度：采用异步机制，利用前两步的历史预测来决定当前的动态截断长度，隐藏了调度延迟，避免了GPU流水线停顿

白话总结：DSpark不是傻乎乎地验证所有草稿，而是先给每个候选词打分，只验证那些“有希望被通过”的词，把算力用在刀刃上。

四、性能数据：到底快了多少？

4.1 单用户生成速度提升

在维持相同总体吞吐量的情况下：

模型	速度提升
DeepSeek-V4-Flash	60% - 85%
DeepSeek-V4-Pro	57% - 78%

4.2 吞吐量提升（真实线上数据）

在实际生产部署中，不同服务等级协议（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%

注意：高速度要求下吞吐量提升特别大，说明DSpark在高并发、高压力场景下优势更明显。

4.3 跨模型泛化能力

DSpark不仅给DeepSeek自己用，还能给其他模型加速。在Qwen3系列上的测试：

目标模型	相比Eagle3提升	相比DFlash提升
Qwen3-4B	+30.9%	+16.3%
Qwen3-8B	+26.7%	+18.4%
Qwen3-14B	+30%	+18.3%

五、DSpark适合谁用？

5.1 适用人群

人群	为什么适合
AI应用开发者	想让自己的AI产品响应更快、用户体验更好
大模型运维工程师	需要在有限GPU资源下支撑更多并发请求
开源社区贡献者	代码已开源，可以学习、修改、二次开发
AI框架研究者	论文公开了完整技术细节，是推测解码方向的前沿工作
云服务提供商	可以用DSpark优化自己的模型推理服务

5.2 不适合谁用

• 只想“开箱即用”的普通用户：DSpark是技术框架，需要一定的工程能力才能部署

• 不需要高并发的场景：如果只是偶尔调用API，感受不到明显差异

• 对延迟不敏感的场景：比如批量离线任务，加速收益有限

六、实战：如何获取和使用DSpark

6.1 获取方式

DSpark已在GitHub的DeepSpec项目中开源：

# 克隆DeepSpec仓库
git clone https://github.com/deepseek-ai/DeepSpec.git

# 进入DSpark目录
cd DeepSpec/DSpark

# 查看论文
# DSpark_paper.pdf 包含了完整的技术细节

DeepSpec是一个全栈推测性解码代码库，包含：

• 数据准备工具

• 草稿模型实现（DSpark、DFlash、Eagle3）

• 训练代码

• 评估脚本

• 模型检查点

6.2 DeepSpec的三个阶段

DeepSpec将整体流程拆分为三个阶段，需要按顺序运行：

阶段1: 数据准备
   ↓
阶段2: 训练草稿模型
   ↓
阶段3: 评估性能

阶段1：数据准备

• 下载提示词数据

• 使用推理引擎对目标模型重新生成答案

• 构建目标缓存（target cache）

阶段2：训练

• 使用准备好的数据训练DSpark草稿模型

• 支持DSpark、DFlash、Eagle3三种架构

阶段3：评估

• 在数学推理、代码生成、日常对话等任务上评估性能

• 计算接受长度、加速比等指标

6.3 代码示例：训练DSpark草稿模型

以下是一个简化的训练流程示意（基于DeepSpec框架）：

# 这是一个简化的示例，展示DSpark训练的核心逻辑
# 完整代码请参考DeepSpec仓库

import torch
import torch.nn as nn
from transformers import AutoModelForCausalLM

class DSparkDraftModel(nn.Module):
    """
    DSpark草稿模型
    包含：并行主干（3个MoE层）+ 轻量级顺序模块
    """
    def __init__(self, target_model, num_moe_layers=3, block_size=5):
        super().__init__()
        # 并行主干：基于目标模型的特征提取层
        self.backbone = target_model.model.layers[:num_moe_layers]
        # 顺序模块：马尔可夫头（轻量级）
        self.markov_head = nn.Linear(target_model.config.hidden_size, 
                                      target_model.config.vocab_size)
        # 置信度头：评估每个Token的存活概率
        self.confidence_head = nn.Linear(target_model.config.hidden_size, 1)
        self.block_size = block_size
    
    def forward(self, input_ids):
        """
        半自回归生成：
        1. 并行主干一次性产出全部候选位置的特征
        2. 顺序模块逐Token注入依赖关系
        3. 置信度头输出每个位置的存活概率
        """
        # Step 1: 并行主干 - 一次性计算所有位置
        hidden_states = self.backbone(input_ids)
        
        # Step 2: 顺序模块 - 逐Token注入依赖
        # 使用马尔可夫头，每个位置只依赖前一个Token
        logits = []
        for i in range(self.block_size):
            # 取当前位置的隐藏状态
            pos_hidden = hidden_states[:, i, :]
            # 马尔可夫依赖：结合前一个位置的输出
            if i > 0:
                pos_hidden = pos_hidden + 0.3 * hidden_states[:, i-1, :]
            logits.append(self.markov_head(pos_hidden))
        
        # Step 3: 置信度头 - 评估每个Token的存活概率
        confidence_scores = torch.sigmoid(
            self.confidence_head(hidden_states)
        )
        
        return torch.stack(logits, dim=1), confidence_scores

# 训练循环（简化）
def train_dspark(train_dataloader, target_model, num_epochs=3):
    draft_model = DSparkDraftModel(target_model)
    optimizer = torch.optim.AdamW(draft_model.parameters(), lr=1e-4)
    
    for epoch in range(num_epochs):
        for batch in train_dataloader:
            input_ids = batch['input_ids']
            target_logits = batch['target_logits']  # 从目标模型预生成的logits
            
            # 前向传播
            draft_logits, confidence = draft_model(input_ids)
            
            # 损失函数：让草稿模型逼近目标模型的输出分布
            loss = nn.KLDivLoss()(
                nn.LogSoftmax(draft_logits, dim=-1),
                nn.Softmax(target_logits, dim=-1)
            )
            
            # 置信度损失：让置信度分数与实际接受率对齐
            # （这里简化，完整实现见DeepSpec）
            
            loss.backward()
            optimizer.step()
    
    return draft_model

# 推理时使用DSpark加速
def inference_with_dspark(target_model, draft_model, prompt, max_tokens=100):
    """
    DSpark推理流程：
    1. 草稿模型生成候选Token块
    2. 目标模型批量验证
    3. 置信度调度决定验证长度
    """
    input_ids = tokenizer(prompt, return_tensors="pt").input_ids
    
    for _ in range(max_tokens // draft_model.block_size):
        # Step 1: 草稿模型生成候选块
        draft_logits, confidence = draft_model(input_ids)
        draft_tokens = torch.argmax(draft_logits, dim=-1)
        
        # Step 2: 置信度调度 - 决定验证多长
        # 根据置信度分数动态截断
        threshold = 0.7  # 可动态调整
        verify_length = 0
        for i, score in enumerate(confidence[0]):
            if score > threshold:
                verify_length += 1
            else:
                break
        
        # Step 3: 目标模型批量验证
        if verify_length > 0:
            verified_tokens = target_model.validate(
                input_ids, draft_tokens[:, :verify_length]
            )
            input_ids = torch.cat([input_ids, verified_tokens], dim=-1)
        else:
            # 如果所有候选都被拒绝，用目标模型生成一个Token
            next_token = target_model.generate(input_ids, max_new_tokens=1)
            input_ids = torch.cat([input_ids, next_token], dim=-1)
    
    return tokenizer.decode(input_ids[0])

代码解析：

• DSparkDraftModel是草稿模型的核心实现，包含并行主干（3个MoE层）和马尔可夫头（顺序模块）

• confidence_head输出每个位置的置信度分数，用于动态决定验证长度

• 训练时，草稿模型学习逼近目标模型的输出分布，保证最终输出质量无损

• 推理时，置信度调度根据分数动态截断，只验证高置信度的Token

七、总结：一张表看懂DSpark

维度	说明
本质	基于推测性解码的推理加速模块
核心技术	半自回归架构 + 置信度调度验证
并行主干	3个MoE层 + 滑动窗口注意力
顺序模块	马尔可夫头 或 RNN头（二选一）
最大候选块	5个Token
速度提升	Flash: 60%-85% | Pro: 57%-78%
吞吐量提升	高并发下最高可达661%
开源地址	https://github.com/deepseek-ai/DeepSpec
适用场景	高并发、低延迟要求的AI生产环境

DSpark是一个让大模型“先打草稿、再批量审稿”的推理加速模块——通过半自回归架构让草稿写得又快又好，通过置信度调度让审稿只审该审的，最终让AI回答速度提升60%以上，高并发场景下吞吐量提升数倍。

小编建议

1. 如果你在运营高并发的AI服务：DSpark是值得认真研究的方案，尤其是论文中提到的置信度调度机制

2. 如果你想学习推测解码：DeepSpec是很好的学习资源，包含了DSpark、DFlash、Eagle3三种方案的完整实现

3. 如果你想二次开发：代码已开源，可以在自己的模型上训练DSpark草稿模型

4. 注意适用边界：DSpark主要解决推理速度问题，不改变模型本身的“聪明程度”