引言：推理加速的瓶颈与突破口

大模型推理的延迟问题一直是部署中的核心挑战。自回归生成要求逐 token 计算，每一步都需要完整的前向传播——这意味着输出 100 个 token 就需要 100 次模型推理。GPU 在这种模式下利用率极低，大部分时间都花在从显存搬运权重到计算核心上，而非真正的浮点运算。

Karpathy 曾形象地解释过这个现象：让 GPU 同时解码 10 个 token，其实只比解码 1 个 token 慢一点点。原因在于推理的瓶颈是显存带宽，而非计算能力。权重一旦加载到缓存，多处理几个 token 的边际成本几乎可以忽略。这个洞察催生了连续批处理（continuous batching），也直接引出了推测解码（Speculative Decoding）的核心思路。

推测解码的本质是“猜 + 验”：用一个轻量草稿模型快速生成一串候选 token，然后让目标模型一次性批量验证。验证通过的前缀被保留，第一个分歧点之后的 token 被丢弃，并重新采样。数学上可以证明，这种拒绝采样机制保证输出分布与原始模型完全一致，无损加速。

DeepSeek 最近发布的 DSpark 框架，正是这一方向的最新进展。它已被部署在 DeepSeek-V4（Flash 和 Pro）的线上流量中，在维持相同吞吐量的前提下，单用户生成速度提升了 60%–85%。本文将从基础原理出发，逐步解析 DSpark 的设计思想、工程创新，以及配套开源框架 DeepSpec 的使用方法。

如果你对更广泛的推理加速技术感兴趣，可以阅读我们的 模型部署与推理优化 专题。

推测解码基础：从 GPU 访存到“猜+验”范式

GPU 的显存带宽瓶颈

大模型推理时，GPU 需要反复将模型权重从 HBM（高带宽显存）搬运到 SRAM（片上缓存）进行计算。搬运权重的耗时远大于计算本身。例如，一次前向传播中，权重搬运可能占用 80% 的时间，而矩阵乘法只占 20%。

连续批处理正是利用了这一特性：将多个请求的 token 打包成一个 batch，让每次显存读取服务更多计算。推测解码则更进一步——它把“猜出来的多个候选 token”也打包成 batch，让验证的边际成本远低于逐个生成。

推测解码的两步流程

Draft 阶段：草稿模型（通常很小，如 0.8B 参数）快速生成一串候选 token，长度为 \(K\)。

Verify 阶段：目标模型（如 400B 参数）对整块候选进行一次前向传播，计算每个位置的概率分布，然后通过拒绝采样决定接受哪些 token。

接受规则如下：

从第一个 token 开始，逐个检查目标模型分布与草稿模型分布是否匹配。

如果匹配，接受该 token；如果不匹配，在第一个分歧点重新采样一个 token，并丢弃后续所有候选。

额外生成一个基准 token 作为下一轮的起始。

单 token 平均延迟的公式为：

\[ L = \frac{T_{\text{draft}} + T_{\text{verify}}}{\tau} \]

其中 \(\tau\) 是每轮平均接受的 token 数。加速的三个杠杆一目了然：降低草稿耗时、提升接受长度、减少无效验证。

主流草稿模型方案：Eagle3 与 DFlash 的局限

自回归草稿：Eagle3

Eagle3 是当前最热门的自回归草稿方案之一。它复用目标模型最后一层的隐藏状态，在上面加 1–2 层 Transformer 头作为草稿器。由于直接站在目标模型的“肩膀”上（即利用其内部理解），Eagle3 的预测准确率较高。

问题：自回归生成要求逐 token 推理，草稿耗时随块长 \(K\) 线性增长。为了控制延迟，草稿网络只能做得很浅（1–2 层），导致首 token 的预测能力偏弱。而投机解码是前缀验证——第一个 token 一旦被拒，整块作废。因此 Eagle3 的整体接受长度 \(\tau\) 受限。

并行草稿：DFlash

DFlash 借鉴了扩散模型的思想，一次前向传播就输出所有候选位置的 logits，草稿耗时与块长无关。因此它可以搭建深层网络（如 5 层），生成更长的草稿块。

问题：并行生成时，各 token 之间没有依赖关系。例如，上下文同时支持 "of course" 和 "no problem" 两种续写，独立预测可能拼出 "of problem" 这种不通顺的组合。论文称之为多模态碰撞（multi-modal collision），导致块后半段的接受率急剧衰减（后缀衰减）。

两者对比

特性Eagle3（自回归）DFlash（并行）

草稿耗时随块长线性增长与块长无关 网络深度浅（1–2 层）深（可达 5 层） 首 token 接受率较低较高 尾部接受率稳定或上升快速衰减 整体接受长度中等中等（受尾部拖累）

DSpark 核心创新一：半自回归生成

DSpark 的核心思路是“两头都要”：保留 DFlash 的并行主干以获得高首 token 接受率和低草稿耗时，再叠加一个轻量串行头来修复尾部衰减。

架构设计

并行主干：基于 DFlash 改造，复用目标模型的多层隐藏状态（KV Injection），单次前向输出整块的隐藏状态和基础 logits。

轻量串行校正头：在并行输出的基础上，叠加一个局部依赖偏移项 \(B_k\)，让每个位置能感知块内已采样的前文。

默认采用 Markov 头：只依赖紧邻的前一个 token，通过低秩分解（rank=256）压缩转移矩阵，参数量极小。实验表明，串行循环带来的总草稿延迟仅增加 0.2%–1.3%，几乎可以忽略。

论文也尝试了 RNN 头（可追踪整个块的前缀信息），但收益有限，且实现复杂，因此线上默认不启用。

为什么并行主干反而更准？

直觉上，自回归应该比并行更连贯。但实测结果相反：并行草稿的首 token 接受率显著高于自回归。原因在于：

并行草稿可以做得很深（如 5 层），而自回归为了控制延迟只能做浅（1–2 层）。

首 token 是投机解码的“命门”——一旦被拒，整块作废。并行草稿凭借深层网络，在第一个位置上就建立了优势。

DSpark 的策略是：用深并行主干拿下高起点（数学首位置接受率可达 0.93），再用轻量串行头补平尾部衰减，实现全程高接受率。

离线评测结果

在 Qwen3-4B/8B/14B 和 Gemma4-12B 四个目标模型上，DSpark 全面超越 Eagle3 和 DFlash：

对比基线平均接受长度提升

比 Eagle3+26.7% ~ +30.9% 比 DFlash+16.3% ~ +18.4%

更惊人的是，2 层 DSpark 即可超越 5 层 DFlash，参数效率极高。

DSpark 核心创新二：置信度调度验证

草稿能写得很长，但并不意味着应该全部验证。在高并发场景下，验证并不免费——多验证一个大概率被拒的 token，就会占用宝贵的 batch 算力，挤压其他请求。

置信度预测头

DSpark 为每个草稿位置配备一个轻量线性 + sigmoid 层，输入并行主干的隐藏状态和前一 token 嵌入，输出该 token 的条件生存概率 \(c_k\)（即前文全部接受时，当前 token 能通过验证的概率）。

监督标签由草稿与目标模型分布的总变差距离计算：

\[ c_k^* = 1 - \frac{1}{2} \| p_d - p_t \|_1 \]

时序温度缩放校准（STS）

神经网络天生过度自信，直接使用原始置信度会导致调度偏差。STS 从左到右逐位置网格搜索最优温度，校准前缀累积生存概率 \(\prod_{i \leq k} c_i\)，将预期校准误差从 3%–8% 压至约 1%，同时保留相对排序。

硬件感知前缀调度器

调度器的优化目标是：给定并发请求池，动态分配每个请求的校验长度 \(\ell_r\)，最大化全局吞吐 \(\Theta = \tau \cdot SPS(B)\)，其中 \(B\) 是校验总 token 批量，\(SPS(B)\) 是硬件预采集的批量-单步吞吐曲线。

贪心执行逻辑：

将所有请求的待扩展 token 按累积生存概率降序排序。

依次尝试增加校验长度，实时计算全局吞吐。

一旦吞吐不再提升，立即停止（早停机制）。

早停机制的关键在于：它仅依赖当前前缀信息，不泄露未来 token，因此严格满足无损分布保证。

线上收益

在 DeepSeek-V4 生产环境中，对比上一代 MTP-1 基线：

同等吞吐下，单用户生成速度提升 57%–85%。

在高交互、严格 SLA 场景（如要求 120 tok/s/user），基线出现吞吐断崖，而 DSpark 通过动态收缩校验长度，将服务承载上限大幅提升，外推了吞吐-延迟帕累托前沿。

工程落地：DeepSpec 开源框架

DSpark 配套的 DeepSpec 是一个全栈推测解码训练与评测库，已开源在 GitHub（MIT 协议）。它集成了数据制备、模型训练、性能评测的完整流水线，并原生支持 DSpark、DFlash、Eagle3 三种算法。

三个执行阶段

数据准备：下载提示词数据集，调用目标模型生成标准答案，构建目标缓存（Target Cache）。注意：默认 Qwen3-4B 配置下，缓存体积可达 38 TB，需充分评估存储资源。

模型训练：通过 bash scripts/train/train.sh 启动，默认适配单节点 8 卡。配置文件在 config/ 目录下，可通过 --opts 覆盖任意参数。

性能评测：通过 bash scripts/eval/eval.sh 启动，覆盖 GSM8K、HumanEval、MT-Bench 等主流基准集，核心指标为 token 接受率。

算法与模型支持

算法来源特点

DSpark本仓库主推半自回归 + 置信调度 DFlash独立开源项目（MIT）纯并行草稿 Eagle3改编自 SpecForge（Apache-2.0）自回归草稿

目标模型目前支持 Qwen3 和 Gemma 系列。社区可在此基础上扩展至 Llama、Mistral 等。

硬件门槛

存储：38 TB（默认配置）

训练：单节点 8 卡 GPU

评测：单卡即可运行

对于个人开发者，建议先在小模型（如 Qwen3-0.5B）上尝试，或使用预训练好的草稿模型权重直接进行评测。

关于更深入的工程实践，可以参考 大模型推理加速与 vLLM 部署 的相关内容。

总结与展望

DSpark 的成功在于系统工程与模型设计的协同创新。它没有发明全新的草稿范式，而是巧妙地将并行生成、串行修正、置信度预测、硬件感知调度融合为一个自适应系统。

未来方向包括：

自适应草稿：让草稿模型根据任务难度动态决定是否提前停止，避免在低接受率请求上浪费前期计算。

多目标模型支持：扩展 DeepSpec 以支持 Llama、Mistral 等主流基座。

轻量化存储：通过缓存压缩或在线生成降低 38 TB 的存储门槛。

对于希望在自己的模型上应用推测解码的团队，DeepSpec 提供了一个标准化的起点。你可以直接训练定制草稿模型，然后对接 vLLM、TensorRT-LLM 等推理引擎，实现线上加速。

如果你对智能体与推理的结合感兴趣，可以进一步了解 AI Agent 与多智能体系统。

FAQ

推测解码一定会降低模型输出质量吗？ 不会。推测解码通过拒绝采样机制保证输出分布与原始目标模型完全一致，数学上无损。只要草稿模型的候选被正确验证，最终输出质量没有变化。

DSpark 相比 Eagle3 和 DFlash 的优势具体在哪里？ DSpark 融合了并行草稿的高首 token 接受率和自回归草稿的尾部连贯性，同时通过置信调度避免无效验证。离线测试中，平均接受长度比 Eagle3 提升约 30%，比 DFlash 提升约 18%。

DeepSpec 必须使用 8 卡 GPU 吗？ 默认配置面向单节点 8 卡，但可以通过修改 CUDA_VISIBLE_DEVICES 环境变量减少可见 GPU 数量。不过训练速度会相应下降。存储方面，38 TB 的缓存要求较高，建议先评估硬件资源。