30 秒快速回答

推测解码（Speculative Decoding）是一种”用小模型猜、用大模型验”的推理加速技术。 它用一个轻量级「草稿模型」提前生成候选 token，再由主模型并行验证——猜对了就批量采纳，猜错了只丢弃错误部分。最终输出与主模型原生生成数学等价，但速度提升 2-3 倍。2026 年 7 月 DeepSeek 开源的 DSpark 框架正是基于此技术，让 V4 系列模型生成速度提升 60%-85%。

核心价值一句话：不改模型、不换硬件、不损失质量，就能让 AI 回复快 2 倍以上。

一、为什么大模型生成速度这么慢？

要理解推测解码，先要理解大模型是怎么”写”出文字的。

大语言模型的生成过程叫自回归解码（Autoregressive Decoding）：一次只生成一个 token（词元），然后把新 token 拼回输入，再生成下一个。这个过程串行执行，像串珠子——必须做完上一颗才能开始下一颗。

问题出在硬件利用率上：

在 decode 阶段，每生成一个 token 都要从显存读取整个模型权重——模型越大，显存读取开销越大。这就是所谓的 “memory-bound” 困境：GPU 计算能力绰绰有余，但数据喂不进来。

推测解码的思路就是：既然 GPU 算力闲着，不如让它一次多干点活。

二、推测解码的核心原理：猜与验

推测解码的流程分为三步，非常直观：

步骤1：草稿模型快速猜 K 个候选 token
        ↓
步骤2：主模型一次性并行验证这 K 个 token
        ↓
步骤3：采纳匹配的 token，丢弃不匹配的，继续下一轮

2.1 为什么”猜”不会影响输出质量？

这是推测解码最精妙的地方。主模型在验证时，会对草稿模型生成的每个候选 token 计算自己的概率分布——如果主模型认为这个 token 不该出现在这里，它会被直接拒绝。只有被主模型认可的 token 才会被保留。

数学上可以证明：推测解码的最终输出分布与主模型原生自回归解码完全等价——它不是近似加速，而是精确加速。

2.2 草稿模型的要求

草稿模型需要满足两个条件：

• 足够小、足够快：通常是主模型的 1/10 甚至更小的参数量，推理开销可忽略
• 与主模型”对齐”：使用相同的 tokenizer，且在大多数情况下能猜中主模型的选择

常见做法是直接使用同系列的小模型（如用 DeepSeek-V4-Flash 作为草稿、V4-Pro 作为主模型），或用蒸馏出来的小模型。

2.3 加速比取决于什么？

推测解码的实际加速比取决于草稿模型的接受率（acceptance rate）——即草稿猜中的 token 比例。接受率越高，加速越明显。

在代码生成、翻译等结构化任务中接受率通常很高（80%-90%）；在创意写作等开放性任务中略低（60%-70%），但仍然有显著加速。

三、手写一个最简实现

以下是用 PyTorch 伪代码实现的一个最小版推测解码循环，帮助理解核心逻辑：

def speculative_decode(
    draft_model,   # 草稿模型（小）
    target_model,  # 主模型（大）
    prefix_ids,    # 输入 token ids
    K=5,           # 每次猜 K 个 token
    max_new=512    # 最大生成 token 数
):
    generated = []
    current = prefix_ids

    while len(generated) < max_new:
        # 步骤 1：草稿模型猜 K 个 token
        draft_output = draft_model.generate(
            current, max_new_tokens=K, do_sample=False
        )
        draft_tokens = draft_output[-(K+1):]  # 含输入最后 1 个作为锚点

        # 步骤 2：主模型并行验证
        with torch.no_grad():
            target_logits = target_model(draft_tokens).logits  # [K+1, vocab]

        # 步骤 3：逐 token 比对，决定采纳/拒绝
        accepted = 0
        for i in range(K):
            target_token = target_logits[i].argmax(dim=-1).item()
            draft_token = draft_tokens[i + 1]  # 跳过锚点

            if target_token == draft_token:
                accepted += 1
                generated.append(draft_token)
            else:
                # 拒绝：采纳主模型的 token，本轮结束
                generated.append(target_token)
                accepted += 1
                break

        # 更新输入继续下一轮
        current = current + generated[-accepted:]

        if accepted < K:
            # 遇到拒绝，本轮提前结束
            continue

    return generated

关键点说明：

• 每次主模型只需一次前向传播，验证 K 个 token——比原生解码快 K 倍的计算密度
• 拒绝时采纳主模型自己的选择，保证输出质量不打折
• do_sample=False（贪心解码）时逻辑最简单；带温度的采样版本需要额外处理概率匹配

四、业界实践：DSpark 与主流方案对比

4.1 DeepSeek DSpark（2026.07）

2026 年 7 月，DeepSeek 开源了 DSpark 推理加速框架，这是一个 MIT 许可的即插即用方案：

• 无需重新训练：直接使用已有的 V4-Flash 作为草稿模型、V4-Pro 作为主模型
• 无需升级硬件：在现有 GPU 上即可获得 60%-85% 的加速
• 自适应草稿长度：根据实时接受率动态调整 K 值，接受率高时多猜、低时少猜

# DSpark 使用示例（一行命令开启加速）
dspark serve --target deepseek-v4-pro --draft deepseek-v4-flash

4.2 各方案对比

DSpark 的优势在于零训练成本和即插即用——直接利用已有的小模型作为草稿，而不需要像 Medusa 那样额外训练多个预测头。

五、适用场景与局限

适用场景

• 对话式 AI / Chatbot：用户等待回复的延迟直接影响体验，推测解码可大幅降低首 token 延迟
• 代码补全 / IDE 插件：代码结构规律性强，接受率高，加速效果显著（通常 3x+）
• 翻译任务：源语言与目标语言的 token 序列高度对齐，接受率极高
• 批量 API 服务：高吞吐场景下，推测解码是降低单次调用成本的有效手段

局限性

• 显存开销：需要同时加载两个模型（草稿+主模型），显存占用增加约 10%-20%
• 小 batch 最优：推测解码在 batch size=1 时效果最好；大 batch 场景下 GPU 本身计算利用率已较高，加速有限
• 草稿模型选择：需要一个与主模型使用相同 tokenizer 的小模型——如果没有合适的，需要额外训练或蒸馏

总结

推测解码是大模型推理加速领域最优雅的方案之一：不改模型权重、不损失输出质量、不做近似妥协，仅通过”猜测-验证”的并行化策略，将串行的自回归解码变为批量并行验证。 随着 DSpark 等即插即用框架的开源，这项技术正从实验室走向生产环境。

核心要点：

1. 推测解码 = 小模型猜 + 大模型验，输出与原生解码数学等价
2. 加速比取决于草稿模型的接受率，代码/翻译等任务通常 2-3x
3. DeepSeek DSpark（2026.07）实现了零训练成本的即插即用方案
4. 最适合对话、代码补全、翻译等低延迟场景

延伸阅读：

• DeepSeek DSpark 官方仓库：github.com/deepseek-ai/DSpark
• 原始论文：Leviathan et al., “Fast Inference from Transformers via Speculative Decoding” (ICML 2023)
• 本系列相关教程：《什么是推理模型？o1/R1 慢思考原理全解析》《什么是模型量化？把大模型变小的核心技术》