大模型推理优化系列2:投机采样

01 背景

当前主流的大语言模型(如 GPT、Qwen、DeepSeek)几乎都采用 Decoder-Only Transformer 架构。整个推理过程可拆分为两个阶段:Prefill(预填充)与 Decoding(解码)。

Prefill 阶段:并行处理全部输入 token 并产出 KVCache,计算量大,属于计算密集型(Compute Bound)。

Decoding 阶段:逐 token 生成回复,每步计算量极小,却要把积累的 KVCache 完整加载一遍------GPU 大部分时间在等待数据搬运而非计算,属于访存密集型(Memory Bound),瓶颈在显存带宽,算力被严重浪费。

路线一:增大并发 ------ 通过增大 batch size 提升算力利用率,但受限于 KVCache 带来的显存带宽开销,扩展空间有限;

路线二:增大单次生成的 token 数 ------ 打破自回归的串行约束,在一次前向传播中同时生成多个 token,从根本上减少访存次数。

路线二的典型代表就是投机采样(Speculative Sampling):先用一个轻量的 Draft 模型快速自回归地生成多个候选 token,再由目标模型一次前向传播完成验证,接受其中最长的连续正确前缀。这样只需少量验证步骤即可产出多个 token,显著降低总访存量。近年来,围绕这一思路先后涌现出 EAGLE 系列、DFlash、DSpark 等多种方案。本文介绍投机采样的基本原理与主流实现方法,主线是:每一代方法的天花板在哪里,下一代如何突破。

02 基本原理

2.1 基本过程

投机采样的完整流程可分为三步:

1. Draft 模型快速预测候选 token

用小参数量模型(如 0.5B、1B)快速生成 K 个候选 token。

2. Target 模型并行验证所有候选

候选 token 交由目标模型一次前向传播完成验证,如图 1 所示。

图 1 并行验证阶段

3. Accept / Reject 拒绝采样

通过拒绝采样决定是否采纳草稿 token。设 P(x) 为目标模型对候选 token x 的预测概率,Q(x) 为草稿模型的预测概率:若 P(x) ≥ Q(x) 直接采纳;否则以概率 P(x)/Q(x) 接受。若被拒绝,则由目标模型基于修正后的分布 max(0, P(x)−Q(x)) 重新采样。

2.2 无损保证

从数学上可以证明:通过上述投机采样得到的 token,与直接从目标模型 P(x) 采样的分布完全相同------加速是"免费的",不牺牲任何生成质量。

然而,传统投机采样的天花板也很明显:草稿模型是一个独立的小型 LLM,它对目标模型的行为一无所知,只能靠自身能力去猜测,接受率往往不高。让草稿模型"借用"目标模型的知识来提升预测质量,正是 EAGLE 的出发点。

03 EAGLE 与 EAGLE-2

EAGLE(Extrapolation Algorithm for Greater Language-model Efficiency)提出于 2024 年,思路是不在词表空间预测下一个 token,而是在特征空间预测目标模型最后一层(LM Head 之前)的特征向量,再借助目标模型原有的 LM Head 采样出 token。特征向量处在连续空间,比离散 token 更容易建模,且复用 LM Head 省去了从零学习词表映射的负担,预测精度更高。

但该方法有一个绕不开的难点:采样不确定性会扰动特征轨迹------下一步特征严重依赖当前实际采样到的 token。如图 2 所示,给定上文 "I",下一步可能采样到 "am" 或 "always",两个 token 会引向完全不同的特征序列。

图 2 特征序列的不确定性

其中 Embedding Layer 和 LM Head 直接复用目标模型;唯一需要训练的 Autoregression Head 由一个 FC 层和一个 Transformer decoder 层构成:FC 层将拼接后的输入(特征 + shifted token Embedding,2 × hidden_dim)降维,decoder 层预测下一个特征向量,再经 LM Head 采样生成 token。

图 3 引入 shifted token 的消融实验

3.1 模型结构

图 4 EAGLE 模型结构

图 4 所示,EAGLE 的模型结构由三部分组成:Embedding Layer、LM Head 和 Autoregression Head。前两者直接复用目标模型;唯一需要训练的 Autoregression Head 由一个 FC 层和一个 Transformer decoder 层构成:FC 层将拼接后的输入(特征 + shifted token Embedding,2 × hidden_dim)降维,decoder 层预测下一个特征向量,再经 LM Head 采样生成 token。

3.2 Draft Tree 与并行验证

前面描述的是 EAGLE 单条路径的生成过程:预测特征 → 采样 token → 继续预测。但如果只沿一条路径走,一旦中间某个 token 采样错误,后续所有 token 都会被丢弃,浪费严重。

为此,EAGLE 引入了草稿树(Draft Tree)结构:在每一步预测时,不只采样一个 token,而是保留概率最高的 top-k 个候选,每个候选各自延伸出一条分支。多次重复后形成一棵多叉树------根节点是当前已确认的 token,每个内部节点是一个候选 token,从根到叶的每条路径代表一种可能的生成序列,如图 5 所示。

图 5 草稿树(Draft Tree)

验证时,目标模型一次前向传播即可并行验证所有路径:将树展平为 token 序列,通过树形注意力掩码保证每个节点只"看见"自己的祖先节点,按拒绝采样规则逐节点验证,取所有路径中最长的连续正确前缀作为输出。论文消融显示,树结构使 τ 提升约 0.6~0.8、加速比提升约 0.3~0.5,把 Vicuna 13B 在 MT-bench 上的加速比推到 3.07×(τ = 3.98)。

EAGLE-2 的改进是引入上下文感知的动态草稿树:根据当前上下文实时调整树的结构,把验证预算集中到最可能被接受的 token 上。这一改进不需要任何额外训练------草稿模型权重与 EAGLE 完全相同,仅解码策略变了,却带来 20%~40% 的速度提升。

图 6 置信度与接受率对比

动态调整的依据是草稿模型的置信度:真实接受率只能通过目标模型前向传播计算,开销过大,而 EAGLE-2 发现置信度与实际接受率强正相关图 6------置信度 < 0.05 的 token 实际接受率约 0.04,置信度 > 0.95 的约 0.98,论文称之为 well-calibrated。因此直接用置信度近似接受率指导树结构调整,几乎零额外开销。

3.3 动态草稿树的构建

EAGLE-2 将动态草稿树的构建分为三个阶段:扩展、重排与掩码。

1. 扩展阶段

每一轮扩展只选择全局接受率最高的 Top-K 个节点向下生长,而非对所有叶节点平铺展开,从而避免树的指数级膨胀。

为了衡量每个节点"最终被接受"的可能性,引入以下符号:

|----|--------------------------|
| 符号 | 含义 |
| | 从根节点到节点 的路径上所有节点的集合 |
| ​ | 目标模型对 token 的真实接受概率 |
| ​ | 草稿模型输出的 token 的置信度(用于近似) |
| | 节点 的全局接受率,即整条路径被完整接受的概率 |

由于一个 token 被接受的前提是其路径上的所有 token 均被接受,因此全局接受率定义为路径上各 token 接受概率的连乘:

示例(图 7):设 K = 2,token "a" 的全局接受率 R(a) = 0.48 最高,与次高的 "to" 一同被选为下一层的父节点继续扩展。

图 7 动态草稿树扩展与重排阶段

2. 重排阶段

由于 R(t) 是路径概率连乘积,越深的节点 R(t) 必然越小,按树层序选取并不公平。重排阶段对所有已扩展节点统一按 R(t) 降序排列选出 Top-M,并保证子节点 R(t) 不大于父节点(连通子树约束),如图 7 所示。

3 掩码阶段

图 8 掩码阶段示意图

经过重排后,草稿子树中的节点被"压平"成一维序列送入目标模型批量验证,沿用前述树形注意力掩码(每个节点只能看见其祖先节点,不同分支完全隔离,图 8),使批量验证在数学上严格等价于对每条路径逐一单独验证。

EAGLE-2 通过动态草稿树解决了验证预算的分配问题,但训练侧的瓶颈随之暴露:草稿模型的训练约束使其难以从大规模数据中获益。如何在移除特征约束的同时保持多步预测能力,是 EAGLE-3 要解决的问题。

04 EAGLE-3

EAGLE 的训练损失由特征预测损失 L_feat 与 token 预测损失 L_lm 两部分构成。特征预测损失是草稿模型获得多步预测能力的关键------它迫使草稿模型的输出逼近目标模型的真实特征,使该输出被用作下一步输入时输入分布仍接近训练分布,多步生成不会严重失真。

4.1 EAGLE-2 的瓶颈

LLM 社区普遍依赖扩大训练数据提升模型能力(如 LLaMA 从 1T 到 15T tokens),但实验发现 EAGLE 从额外训练数据中获得的收益极为有限。根本原因在于:token 预测才是最终目标,特征预测只是中间约束,限制了草稿模型的表达能力。论文的对照实验(图 9)验证了这一点:移除特征预测损失并扩大训练数据后,第 1 个草稿 token 的接受率显著提升,第 2 个却大幅下降------草稿模型第一步的输出偏离目标模型真实特征,导致第二步的输入严重偏离训练分布,多步预测能力崩溃。

图 9 对照实验图

4.2 训练时测试

EAGLE-3 的思路是:既然多步预测能力会因分布偏移而崩溃,那就在训练时直接模拟这种偏移------将草稿模型自身的输出作为下一步的输入,继续训练第二步、第三步......的 token 预测损失,训练时的注意力掩码相应调整为树形结构,与推理时的真实输入分布对齐(图 10)。

图 10 EAGLE-3 训练时测试示意

这一"训练时测试"(Training-Time Test)技术让草稿模型在训练阶段就见过自己的预测误差。采用此方法后,随着训练数据规模增大,加速比呈现持续增长的 Scaling Law------这在此前的投机采样方法中从未被观察到。EAGLE-3 实际使用了约 8 倍于 EAGLE 的训练数据(ShareGPT 68K + UltraChat-200K 共 464K,响应由目标模型自身采样生成)。

4.3 模型结构

EAGLE 及 Medusa 等方法均只复用目标模型顶层(LM Head 前一层)的隐藏向量,而顶层特征本质上只编码了"下一步"的信息,对"下下个 token"的预测能力天然受限。EAGLE-3 移除特征预测损失后,输入不再被强制约束为顶层特征,于是同时提取目标模型的三层隐藏向量------低层(局部句法、n-gram 模式)、中层(中间语义)、高层(对齐词表分布)------拼接后经 FC 降维得到融合向量,如图 11 所示。

三者拼接后,经全连接层(FC)降维至与目标模型隐藏维度相同的维度,得到融合向量,如图 11 所示。

图 11 EAGLE-3 模型结构

4.4 推理流程

EAGLE-3 的推理与前代的区别在草稿阶段的输入构造(图 11):目标模型完成 prefill 后记录三层特征,与采样 token 的 Embedding 拼接、经 FC 降维送入单层 Transformer Decoder,输出特征经 LM Head 采样得到草稿 token;后续每一步都用草稿模型自身的输出特征代替无法获取的目标模型特征,继续扩展草稿树。这一流程与"训练时测试"完全对应。

验证阶段与 EAGLE-2 完全一致:沿用上下文感知的动态草稿树与树形注意力掩码,一次前向完成批量验证。由于接受率显著提升,工程实现中通常配置更深的草稿树与更多草稿 token(如 SGLang 默认 5 步 × top-8),以充分发挥接受率提升带来的收益。最终,EAGLE-3 在 Vicuna 13B 的 MT-bench 上取得 5.58× 加速(τ = 6.65),在 LLaMA-Instruct 3.1 8B 上取得 4.40×(τ = 6.13),代码类任务最高 6.47×;在大 batch 场景下依然有效------基于 vLLM 的吞吐测试中,EAGLE-3 的吞吐增益峰值出现在 batch=56(1.01×),而 EAGLE 在 batch=24 后即转为负收益。

EAGLE-3 通过"训练时测试"与多层特征融合,在加速比上实现了显著提升,并首次展现出投机解码的 Scaling Law。但草稿模型依然是自回归的,草稿阶段的串行开销成为新的瓶颈------用一次前向传播直接并行生成整块草稿 token,就是 DFlash 的切入点。

05 DFlash

5.1 自回归草稿的瓶颈

DFlash 的突破来自一个关键观察:目标模型在生成当前 token 时,其隐藏层特征已经隐含了未来多个 token 的信息。与其让草稿模型从零开始预测,不如直接提取目标模型的多层特征并注入草稿模型,让它直接利用目标模型已学到的知识。DFlash 在此基础上更进一步:将草稿模型从自回归预测器替换为块扩散模型(Block Diffusion Model),以单步去噪的方式一次性并行生成整块 token(默认块大小为 16),消除草稿阶段的串行依赖。

如图 12 所示,DFlash 在 Qwen3-8B 上实现了最高 6.08× 的无损加速(MATH-500),七个基准平均 4.86×,比 EAGLE-3 快约 2.4 倍,在数学、代码等多个基准上均一致领先。

图 12 DFlash 和 EAGLE-3 加速效果对比

5.2 架构设计

DFlash 将训练范式从自回归预测切换为去噪(Denoising):从目标模型生成的响应中随机采样 anchor token 作为每个块的首位置,其余位置替换为 mask token,训练草稿模型在目标模型特征的约束下并行恢复整块 token。这种"随机 anchor"的块构造与推理时行为对齐------推理时总是以上一轮验证产出的干净 token(bonus token)为锚点向后预测。

DFlash 的草稿模型在架构上做了三处关键设计:

1.多层特征注入(KV Injection) :从目标模型第 2 层到倒数第 3 层之间均匀抽取 5 层隐藏特征,拼接后经一次共享投影(RMSNorm(W_c·))压到草稿维度,再注入草稿模型每一层的 K/V 投影并缓存复用。相比 EAGLE-3 仅在首层输入目标特征(信号往深层会逐渐稀释),DFlash 的每一层都能获得完整的目标上下文,接受率随网络深度扩展的能力显著增强------消融显示 3 层换 5 层特征注入、5 层草稿换 8 层,接受长度均持续提升。

2.块扩散并行起草:在注入上下文与 anchor token 的约束下,草稿模型以单步去噪的方式一次性预测整个 token 块,无需逐步展开。这使得 5 层草稿网络生成 16 个草稿 token 的延迟,反而低于 1 层的 EAGLE-3 生成 8 个 token 的延迟。深度消融显示 8 层的 τ 更高,但 5 层在"起草耗时 × 接受长度"的权衡下端到端加速比最优。

3.轻量参数复用:草稿模型直接复用目标模型的 Embedding 层与 LM Head 并冻结,仅训练中间的 Transformer 层;训练数据为约 800K 样本(Nemotron Post-Training V2 + CodeAlpaca 混合,响应由目标模型自身生成)。损失按块内位置指数衰减加权 w_k = exp(−(k−1)/γ)------块内越靠前的位置出错,整块报废得越彻底,因此早期位置的预测准确性格外重要。

图 13 DFlash 模型结构图

这项工作的思路是把扩散 LLM 用在刀刃上:不训练巨大的扩散模型去追赶自回归模型的生成质量,而是训练轻量扩散适配器专门承担快速、准确的块预测,输出质量由自回归目标模型的投机验证兜底。

不过,DFlash 的加速效果与任务类型高度相关:数学、代码等模板化任务优势最大(MATH-500 最高 6.08×),开放对话(MT-Bench)仅 2.75×------并行起草的每个位置相互独立预测,无法建模块内 token 间的依赖,当上下文存在多种合理续写时容易拼出 "of problem" 这类跨模式碰撞,接受率沿块位置快速衰减。此外,块大小训练与推理可以不对称(大块训练可直接用于小块推理,反向则不行),为运行时按负载动态调整留出空间。在 SGLang 生产框架(单卡 B200)上,Qwen3-8B 的 Math500 任务并发 1~32 全程保持 2.8×~5.1× 加速。

但 DFlash 在离线评测之外还面临两个问题。第一个在算法侧:如前所述的块内依赖缺失,首 token 处的容量优势被后缀的快速劣化不断侵蚀。第二个在系统侧:并行起草可以轻松产出 16~70 token 的长草稿,但"一刀切"地把整块全部送去验证,会在高并发场景下白白占用目标模型宝贵的 batch 容量去验证大概率被拒绝的后缀 token;而静态阈值截断又忽略了系统负载------低负载时多验几个 token 几乎免费,高负载时每个验证名额都需要权衡。DSpark 针对这两个问题给出了系统级的解决方案。

06 DSpark:半自回归 + 置信度调度

DSpark(DeepSeek-AI 与北大,2026)是一个统一"高质量并行起草"与"负载感知验证"的投机解码框架,也是 DFlash 路线的最新生产级演进,其两个组件分别解决上述两个问题。

6.1 半自回归生成

DSpark 的草稿模型采用"重并行骨干 + 轻量串行头"的两段式结构:

并行阶段:沿用 DFlash 的并行骨干(5 层),一次前向产出整块 hidden states 与基础 logits,起草延迟与块大小几乎无关;仅做一处微调------将 anchor token 本身也作为首个预测位置,γ 个输入 token 产出 γ 个草稿 logit。

串行阶段:在并行 logits 之上叠加轻量的"前缀依赖转移偏置" B_k,使每个位置以自回归方式条件于块内已采样的前缀,从左到右采样。默认实例化为 Markov 头:B 只依赖上一个 token,用秩 r=256 的低秩分解逼近完整 V×V 转移矩阵,每步仅需一次 embedding 查表加一次 logit 投影;更复杂的 RNN 头只在极长块上有边际收益,默认不用。

这样设计的依据来自论文的位置级接受率分析(Qwen3-4B 实测):并行草稿在位置 1 有显著容量优势------O(γ) 延迟的自回归草稿(如 EAGLE-3)被迫压成单层浅网,而 O(1) 的并行草稿可以用深得多的网络,Math 上首位置条件接受率 0.88 vs 0.81、Chat 上 0.72 vs 0.53;但由于缺乏块内依赖,DFlash 后缀衰减明显(Chat 从 0.72 跌到 0.63),EAGLE-3 反而随位置走高(0.53 升至 0.74)。DSpark 同时获得了两者的优势:继承并行骨干的高首 token 容量,又用串行头抑制后缀衰减,全程保持高而平稳的条件接受率。串行头的延迟开销极小------batch=128 下,每轮端到端延迟仅增加 0.2%~1.3%(相对 DFlash),却换来最高 30% 的接受长度提升。

图 14 DSpark 架构与解码循环

图 15 位置级条件接受率对比

6.2 置信度调度验证

第二个组件解决"验证侧"的系统级浪费:

置信度头 :对每个草稿位置输出标量 c_k,建模"给定前缀全部被接受,位置 k 存活"的条件概率,用解析接受率 c*ₖ = 1 − ½‖p_d − p_t‖₁ 做软标签监督(注意与 EAGLE-2 的关键差异:EAGLE-2 只要求置信度排序正确,DSpark 的调度需要绝对概率值准确)。由于神经置信度普遍过_confident_,训练后用 STS(Sequential Temperature Scaling) 在验证集上从左到右逐位置做温度校准,将 ECE 从 3%~8% 压到约 1%。

硬件感知前缀调度器:把验证长度选择形式化为全局吞吐最大化------令每个 (请求 r, 位置 j) 的前缀存活概率 a_{r,j} = ∏c_{r,i},引擎初始化时离线 profile 一次"前向 batch 大小 → 每秒步数"的容量曲线 SPS(B),然后贪心地把验证预算只路由给存活概率最高的 token,最大化 Θ = τ · SPS(B)。贪心过程带早停以严格保持无损性(避免"看未来 token 决定截断"引入选择偏差);生产部署中进一步用两步前的历史预测做异步近似,与 CUDA Graph / 零开销调度兼容。

6.3 效果:从离线基准到生产 Pareto 前沿

离线评测(Qwen3-4B/8B/14B、Gemma4-12B,训练数据与 baseline 严格对齐,链式草稿温度 1.0)中,DSpark 的宏平均接受长度相比自回归的 Eagle3 提升 30.9%/26.7%/30.0%,相比并行的 DFlash 提升 16.3%/18.4%/18.3%;且块越大优势越大(γ=7 时 math +16%,γ=15 时扩大到 +30%)。2 层 DSpark 即可超过 5 层 DFlash,说明"注入一点自回归"的参数效率极高。

生产环境的数据更能说明问题:DSpark-5 已部署于 DeepSeek-V4-Flash / V4-Pro 的线上服务,替代了原有的 MTP-1 基线。同等总吞吐容量下,单用户生成速度提升 60%~85%(Flash)/ 57%~78%(Pro),中等 SLA 下聚合吞吐提升约 51%~52%;在基线严重退化的严格交互 SLA 下仍能维持有效吞吐,把吞吐---交互性 Pareto 前沿外推。其负载自适应行为符合预期:低负载时自动放宽验证预算(从 MTP-1 的静态 2 token 扩展到 4~6),高负载时平滑收缩。

图 16 DSpark 生产 Pareto 前沿

回看这条技术主线:EAGLE 解决"草稿看不见目标",EAGLE-2 解决"树结构静态浪费",EAGLE-3 解决"训练测试不一致",DFlash 解决"起草串行瓶颈",DSpark 补齐了最后两个环节------块内依赖与验证调度,把投机解码做成了生产系统级的调度问题。"更快地起草"与"更聪明地验证"两条战线,至此都有了完整的方法论。

07 工程落地实践

前六章沿着"每一代方法的天花板在哪里、下一代如何突破"的主线讲完了技术演进,但技术先进不等于工程可行------论文里的加速比换到自己的模型、自己的流量、自己的并发水位上,数字往往对不上。本章把这条技术主线接到工程现场,沿一条决策链回答四个问题:收益有多大→ 方案与参数怎么定→ 什么条件下收益消失→ 线上效果如何。全部实测在同一台机器(单卡 A800 80GB)、同一 vLLM serving 环境下完成,实验口径与指标定义见附录。

7.1 收益有多大:论文口径与内部实测对照

决策链的第一环是收益量级。先明确两个指标(定义详见附录):τ (平均接受长度)是每轮"起草 + 验证"实际采纳的 token 数,τ=1 等价于普通解码;论文中的加速比为 batch=1 延迟口径,本章 batch=1 实测同为延迟口径,7.2/7.3 的满并发实测为吞吐口径,两类口径不可直接比较。

论文数字与内部实测(★ 标记)汇总如下:

|-----------------------|---------------------------|------------------|-------------------------|----------------------------|-------------------------|
| 目标模型 | 方案 | 数据集 | τ | 加速比 | 数据来源 |
| Vicuna 13B | EAGLE-1 | MT-bench | 3.98 | 3.07× | 论文(EAGLE Table 1,T=0) |
| Vicuna 13B | EAGLE-2 | MT-bench | 4.83 | 4.26× | 论文(EAGLE-2 Table 1,T=0) |
| Vicuna 13B | EAGLE-3 | MT-bench | 6.65 | 5.58× | 论文(EAGLE-3 Table 1,T=0) |
| LLaMA-3.1-8B | EAGLE-3 | MT-bench | 6.13 | 4.40× | 论文(EAGLE-3 Table 1,T=0) |
| Qwen3-8B | DFlash | MT-bench | 6.49 | 4.86× | 论文(DFlash Table 1,T=0) |
| Qwen3-8B | DFlash | MATH-500 | 7.87 | 6.08× | 论文(DFlash Table 1,T=0) |
| Qwen3-8B | DFlash | MT-bench | 4.24 | 2.75× | 论文(DFlash Table 1,T=0) |
| Qwen3-8B | DSpark | MT-bench(链式,T=1) | 3.72 | 接受长度较 EAGLE-3 +26.7%(τ 口径) | 论文(DSpark Table 1) |
| DeepSeek-V4-Flash | DSpark(vs MTP-1) | 生产流量 | --- | 单用户速度 +60%~85% | 论文(生产实测) |
| DeepSeek-V4-Pro | DSpark(vs MTP-1) | 生产流量 | --- | 单用户速度 +57%~78% | 论文(生产实测) |
| DeepSeek-V3 | 原生 MTP | 官方评测 | 单 token 接受率 85%~90% | ~1.8× | 官方技术报告 |
| Qwen2.5-7B-Instruct ★ | baseline | MT-bench | 1.0 | 1.0× | 实测 |
| Qwen2.5-7B-Instruct ★ | EAGLE-3(官方 draft 权重) | MT-bench | 3.5 | 3.8× | 实测 |
| Qwen2.5-7B-Instruct ★ | EAGLE-3(编程类切片) | MT-bench 编程类 | 4.2 | 4.1× | 实测 |
| Qwen2.5-7B-Instruct ★ | EAGLE-3(角色扮演类切片) | MT-bench 角色扮演类 | 2.6 | 2.4× | 实测 |
| Qwen3-8B ★ | baseline(/no_think) | MT-bench | 1.0 | 1.0× | 实测 |
| Qwen3-8B ★ | EAGLE-3(/no_think,spec=3) | MT-bench | 2.34 | 1.92× | 实测(并发 1,见 7.3) |
| Qwen3-8B ★ | DFlash | MT-bench | 4.24 | 2.75× | 引用论文(未单独复测 batch=1) |
| Qwen3-8B ★ | DSpark | MT-bench | ≈5.0 | ≈3.1× | 实测(batch=1,原始记录待归档) |
| Qwen3-8B ★ | EAGLE-3(/think,分段 τ) | MT-bench | think 段 ≈4.6 / 正文段 ≈2.8 | 整体 ≈2.9× | 实测(分段口径) |

图 17 不同模型与方案下的加速比对比(柱状图,按数据来源分色:论文公开 / 实测)

对照表中三个值得注意的规律:

任务确定性决定收益上限。 同一模型同一配置下,编程类切片 τ=4.2,角色扮演类切片 τ=2.6,相差 1.6 倍。任务越接近"有标准答案",草稿命中率越高;开放生成天然难预测,收益相应收窄。论文侧 DFlash 在 MATH-500(6.08×)与 MT-bench(2.75×)上的差距也源于此。选型前应先分析自身流量的任务构成。

换方案的收益量级大于调数据。 Qwen2.5-7B 上从 baseline 到 EAGLE-3 是 1.0× → 3.8×,而蒸馏数据调优的预期增益在 10%~20% 量级。资源有限时,优先完成方案选型与参数扫描,训练优化放后。

模型换代意味着参数重测。 同为 EAGLE-3,Qwen2.5-7B 上 3.8×,Qwen3-8B 上 1.92×(并发 1,spec=3)。原因有两层:其一,Qwen3 的生成分布更难预测------即便关闭 thinking(/no_think),其正文风格仍比 Qwen2.5 更发散,τ 从 3.5 降至 2.34;其二,Qwen3-8B 的模型规模与结构(GQA 配置、词表)使单步前向开销更高,草稿与验证的固定开销同步上升,τ 下降与开销上升叠加,加速比被双向压缩。开启 thinking 后问题更突出:/think 段 τ≈4.6(推理链确定性高),正文段仅 2.8,两段差异大,单一 spec 无法同时适配。模型升级时投机参数必须重测,不能沿用旧参数。

还要说明一点:上表的 batch=1 数字是理想负载下的收益上限,直接拿去做容量规划会严重高估。7.2 的满并发实测(加速比 1.1×~1.4×)与本表差距明显,成因有三------其一,80 并发满载下加速比显著衰减(量化见 7.3);其二,7.2 加速比按吞吐口径计算,数值低于延迟口径;其三,7.2 的 τ(1.752.56)显著低于本表论文口径行(3.726.65),与并发负载下深位置草稿大量被拒有关(位置级数据见 7.3)。收益量级要按自身并发水位打折评估,这正是 7.2/7.3 要解决的问题。

7.2 方案与参数怎么定:三方案 × 投机步数实测

确认收益量级后,第二个决策是方案与参数。方案与参数不能分开选:三个方案的起草机制不同------EAGLE-3 单层串行、DFlash 并行出块、DSpark 并行骨干加串行头------对投机步数的响应也不同,同一 spec 在不同方案上意味着完全不同的开销结构。先明确 spec 的含义:对 EAGLE-3 是自回归起草步数(每步产出一个草稿 token),对 DFlash 是单次并行起草的块内 token 数,对 DSpark 是草稿长度 γ(并行骨干一次产出的整块规模)------三者数值相同不代表开销相同,这正是三方案拐点错位的原因。在 Qwen3-8B 上扫描 spec ∈ {3, 5, 7}(MT-bench 80 题,80 并发满载,T=0,每配置单次运行;DSpark 组未启用置信度调度,仅测并行骨干 + 串行头的起草质量,调度收益见 7.4 生产数据):

|----------|------|-----------|-------|----------|----------|--------|------|
| 方案 | spec | 吞吐(tok/s) | 加速比 | TPOT(ms) | TTFT(ms) | 接受率(%) | 接受长度 |
| baseline | --- | 1161.85 | 1.00× | 14.89 | 185.91 | --- | --- |
| EAGLE-3 | 3 | 1649.99 | 1.42× | 16.80 | 340.82 | 37.54 | 2.13 |
| EAGLE-3 | 5 | 1573.59 | 1.35× | 19.45 | 358.81 | 26.87 | 2.34 |
| EAGLE-3 | 7 | 1335.25 | 1.15× | 26.59 | 357.44 | 18.36 | 2.29 |
| DFlash | 3 | 1348.83 | 1.16× | 22.27 | 273.75 | 25.03 | 1.75 |
| DFlash | 5 | 1251.90 | 1.08× | 25.51 | 255.65 | 17.45 | 1.87 |
| DFlash | 7 | 1529.12 | 1.32× | 24.40 | 259.93 | 22.29 | 2.56 |
| DSpark | 3 | 1600.35 | 1.38× | 19.83 | 259.12 | 33.18 | 2.00 |
| DSpark | 5 | 1368.12 | 1.18× | 22.87 | 473.51 | 21.80 | 2.09 |
| DSpark | 7 | 1369.53 | 1.18× | 22.08 | 450.12 | 18.33 | 2.28 |

注:本次测试为 80 并发请求(num-prompts=80, request_rate=inf),高并发下投机解码收益衰减为已知规律(见7.3 Q1:batch=64 时 EAGLE-3 仅 1.5×)。

图 18 三方案投机步数扫描四联图:(a) 加速比、(b) TPOT、© 接受率、(d) 接受长度随投机步数变化

EAGLE-3:拐点在 spec=3。 spec 3→5→7 加速比 1.42×→1.35×→1.15×,TPOT 从 16.8ms 升至 26.6ms。单层草稿串行执行,步数增加使草稿耗时线性增长,验证收益无法覆盖。该负载下推荐 spec=3。

DFlash:spec=7 最优,但曲线非单调,需谨慎解读。 加速比 1.16×→1.08×→1.32×,spec=7 时 τ=2.56 为九组中最高。两点需要说明:其一,spec=5 的凹陷(1.08×)与两侧差距在单次运行的波动量级内,本组实验未做重复测量,该点不宜过度解读。可以确认的机制性结论是:并行起草延迟与块大小基本无关,块增大只增加验证 token 数,不增加起草步数;TTFT 在 255~274ms 间基本不变,同样印证起草开销与块大小解耦。该负载下倾向 spec=7,以复测数据为准。

DSpark:拐点在 spec=3,TTFT 需单独评估。 加速比 1.38×(spec=3),TPOT 波动最小(19.8→22.1ms);但 spec=5/7 时 TTFT 升至 450ms 以上,spec=3 仅 259ms------串行头与置信度头的首轮开销随草稿长度增长。TTFT 敏感的场景应固定 spec=3。

无论选哪个方案,调参时需区分两个指标:接受率随 spec 增大必然下降(分母增大),τ 才是收益指标。以 EAGLE-3 spec=7 为例:接受率降至 18.36%,τ 与 spec=3 基本持平(2.29 vs 2.13)------draft token 数增加 2.2 倍仅换来 τ +0.16,加速比随之下降。调参依据是"τ 增量 ÷ 草稿开销增量",而非接受率绝对值。

7.3 什么条件下收益消失:并发度扫描

7.2 的九组数据全部落在 80 并发满载这一个点上,而7.1 的 batch=1 又是另一个极端------收益随并发如何变化,是决定"要不要常开投机"的关键变量。本节单独扫描:Qwen3-8B + EAGLE-3(spec=3,7.2 中该方案的推荐配置),baseline 同场对照:

|-----|--------------------|-------------------|-------|----------------|------------------|------------------|
| 并发度 | baseline 吞吐(tok/s) | EAGLE-3 吞吐(tok/s) | 加速比 | EAGLE-3 接受率(%) | EAGLE-3 TPOT(ms) | EAGLE-3 TTFT(ms) |
| 1 | 89.23 | 171.38 | 1.92× | 44.78 | 6.25 | 27.18 |
| 4 | 332.65 | 582.65 | 1.75× | 43.97 | 6.71 | 38.06 |
| 8 | 556.91 | 962.41 | 1.73× | 44.27 | 6.95 | 42.05 |
| 16 | 817.77 | 1393.86 | 1.70× | 44.76 | 7.62 | 50.93 |
| 32 | 1085.86 | 1740.51 | 1.60× | 44.33 | 10.04 | 95.11 |

图 19 加速比与吞吐随并发度的变化

三个结论:

衰减不改变净收益。 并发 1→32,加速比从 1.92× 降至 1.60×,但 EAGLE-3 绝对吞吐从 171 升至 1740 tok/s------投机解码始终为正收益,衰减的原因是 baseline 的算力利用率随并发增长更快,压缩了相对优势。

衰减与草稿质量无关(并发 1~32 区间内)。 接受率全程稳定在 ~44%;位置级接受率同样稳定(并发 1 与并发 32 的位置 0/1/2 分别为 63.3/42.9/28.1% 与 63.6/42.6/26.8%)。衰减根源在系统侧:高并发下各请求的 KVCache 读取竞争显存带宽,验证开销被放大。需要说明边界:该结论仅覆盖并发 ≤32;7.2 的 80 并发满载下,EAGLE-3 spec=3 的接受率降至 37.5%,说明满载点已越过"草稿质量不变"的稳定区------满载时调度行为变化(batch 组装、抢占)会干扰草稿接受,属于另一重衰减机制。

TTFT 劣化快于 TPOT。 并发 1→32,TPOT 从 6.25 升至 10.04ms(+60%),TTFT 从 27 升至 95ms(+250%)。流式对话等 TTFT 敏感业务的降级阈值应基于 TTFT 而非 TPOT 设定。

论文口径呈同样趋势:EAGLE-3 基于 vLLM 的吞吐增益峰值在 batch=56,超过后转为负收益(见第五章);DFlash 在 SGLang 上并发 1~32 保持 2.8×~5.1×(见第六章)。对应的线上策略是低负载开启投机、高负载自动降级,不做全局常开。

7.4 线上效果如何:生产 A/B 验证

在 DeepSeek-V4-Pro 线上服务做整晚同流量回放 A/B:DSpark(spec=5)替换普通自回归,硬件、副本、路由、流量完全一致,业务为长上下文推理。数据由网关 Prometheus 按路由分组采集,与看板同源。两点说明:其一,该业务瓶颈在吞吐而非首字延迟(原版组首字 P95 高达 58.7 秒,主要由排队贡献),spec=5 的 τ 优势大于其 TTFT 代价,故未采用 8.2 面向 TTFT 敏感场景的 spec=3 建议;其二,A/B 期间对双跑流量做逐 token 抽样比对,一致率 100%,无损性成立。

|--------------|---------|---------------|--------|
| 指标 | 原版(无投机) | DSpark spec=5 | 变化 |
| 平均吞吐量(tok/s) | 3,470 | 6,130 | +76.7% |
| 请求平均处理时间 | 100.2 s | 23.2 s | -76.8% |
| 首字延迟 P95(s) | 58.7 | 27.8 | -52.6% |
| 504 超时(整晚累计) | 4,965 | 959 | -80.7% |
| 平均 RPM(次/分钟) | 20 | 29 | +45% |

图 20 整晚同流量 A/B 关键指标对比(吞吐 / 处理时间 / 首字延迟 / 504,归一化到原版=100)

吞吐 +76.7% 的成因:过载系统的排队消散。 该数字与 DSpark 论文生产口径(V4-Pro 单用户速度 +57%~78%)量级相当------注意两者指标不同(本文为聚合吞吐,论文为单用户速度),过载系统中吞吐收益通常高于单用户速度收益,故不直接比较。它与 7.3 的衰减规律并不矛盾------7.3 的前提是系统不过载,而本次回放系统整晚过载(原版组 504 近五千次、请求平均驻留 100 秒),排队是主要矛盾。投机解码将单请求处理时间压至 23.2 秒后队列消散,GPU 在更高有效 batch 上运转,收益被放大而非衰减。这补全了 7.3 没有覆盖的场景:不过载时收益随并发缓降,过载时收益反而被排队放大。

504 与首字延迟是连带收益。 处理时间缩短 4.3 倍,系统内驻留请求数大幅下降,队列收缩、超时锐减、首字延迟随之减半。RPM +45% 低于吞吐 +76.7%,说明更多请求在超时前完整返回。评估线上收益时,除单请求速度外,同等硬件的流量上限提升是更直接的容量收益。

TTFT 的场景依赖。 离线低负载下,草稿模型首轮前向抬高 TTFT(投机组均高于 baseline 的 185.9ms);过载系统中排队时间为数十秒量级,草稿前向为百毫秒量级,TTFT 反而大幅改善。TTFT 预算需分场景设定:空闲系统关注草稿开销,过载系统关注排队消散。

7.5 小结

投机解码的工程落地,重点不是追求论文里的最高加速比,而是按任务、模型、并发和延迟预算动态选型调参,按真实场景重新评估收益。

收益会缩水:论文数字不能直接用于容量规划。任务越开放、模型越新、并发越高,收益越低;batch=1 是理想上限,满并发下明显衰减。

方案和参数必须实测:EAGLE-3、DFlash、DSpark 的投机步数含义不同,最优 spec 也不同;调参看 τ 增量与草稿开销的比值,模型换代后必须重测。

并发下要动态开关:低负载开启、高负载降级。收益衰减多来自系统侧资源竞争,且 TTFT 比 TPOT 更容易劣化。

生产收益要看场景:过载系统中,投机解码可通过缩短请求处理时间、消散排队,连带改善吞吐、超时和首字延迟;但仍需保证输出无损、可灰度、可回滚。

工程落地关键是按任务、模型、并发和延迟预算动态选型调参,论文加速比只是参考

附录 评测方法与指标定义

平均接受长度 τ:每轮投机(一次起草 + 一次验证)平均产出并被采纳的 token 数;τ=1 表示退化为普通自回归。

TPOT(Time Per Output Token):输出阶段平均每 token 耗时,P99 为长尾口径。

加速比:论文口径为相同请求(同输入、同采样参数、同硬件)下,普通解码端到端延迟 ÷ 投机解码端到端延迟(batch=1);本文 batch=1 实测(7.1)同为延迟口径,满并发实测(7.2/7.3)为吞吐口径(投机方案吞吐 ÷ baseline 吞吐),两类口径不可直接比较。

无损判定:同随机种子下,投机解码与普通解码输出逐 token 一致,且 logit KL 散度 < 1e-3。

测试环境口径:硬件型号 / 卡数、框架版本、最大 batch、上下文长度需随报告一并注明,避免跨环境误读。

内部实测统一口径:分两组。代际对照(7.1):Qwen2.5-7B-Instruct(ruipeterpan draft 权重)与 Qwen3-8B(RedHatAI / mgoin speculator 权重),MT-bench 80 题,batch=1,每配置 3 次取中位数。并发负载(7.2/7.3):vLLM serving benchmark(vllm bench serve),Qwen3-8B + RedHatAI speculator 权重,MT-bench 80 题(ShareGPT 格式),T=0,num-prompts=80, request_rate=inf(满并发);并发扫描另设 max-concurrency ∈ {1,4,8,16,32}。原始输出、可视化脚本与汇总见 figs/bench_results/。

分段 τ(thinking 模型):Qwen3 类模型的输出由 推理段与正文段构成,两段分别统计 τ;整体 τ 按段内 token 占比加权。段级口径是 thinking 模型收益评估的必要补充。

参考

1.EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty(ICML 2024,arXiv 2401.15077)

2.EAGLE-2: Faster Inference of Language Models with Dynamic Draft Trees(EMNLP 2024,arXiv 2406.16858)

3.EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test(2025,arXiv 2503.01840)

4.DFlash: Block Diffusion for Flash Speculative Decoding(ICML 2026,arXiv 2602.06036)

5.DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation(2026,arXiv 2607.05147,DeepSeek-AI)

6.Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads(ICML 2024)

7.DeepSeek-V3 Technical Report(2024,原生 MTP 模块与接受率数据来源)

8.vLLM / SGLang 官方文档:投机解码支持矩阵

360智汇云是企业智数云底座,以"智-数-云"三大核心底座为支柱,以贯穿全程的 "观测与管控" 为神经中枢,全链路赋能企业数智基建在 "用、运、管、看、维" 五维生命周期中实现价值闭环。提供数据库、中间件、存储、大数据、人工智能、计算等多种产品服务以及一站式解决方案,让每一份IT投入都转化为智能生产力。

官网:https://zyun.360.cn

相关推荐
Hello.Reader3 小时前
Computer Use 实战在 Antigravity、Cursor 中接入浏览器与桌面自动化
ai
Dr_Fourier3 小时前
AWQ量化
c++·人工智能·pytorch·ai
my_styles3 小时前
ai开发-langchain4j-进阶-05-提示词工程
ai·langchain4j
子非鱼eva3 小时前
昇腾开源仓Issue分析解答-mindspore精选(二)·mindformers深耕与三大户续采
人工智能·ai·gitcode
ShineWinsu15 小时前
对于Coze—AI:SDK的解析
人工智能·python·ai·sdk·项目·coze·字节跳动
代码方舟15 小时前
零信任架构实战:基于天远名下企业A构建自动化B2B供应链准入网关
人工智能·ai·工具分享
右耳朵猫AI15 小时前
Python周刊2026W38 | 标准流编码修复、PEP 845/846 草案、解析器提速 10%、集合字典二次复杂度
python·ai·数据科学
东姬AI16 小时前
语音抢着实时,视频也抢着实时:两条赛道同时冲刺,交汇点却还差一步
ai·数字人·多模态·视频生成·语音大模型
等待_迷失的Linux19 小时前
嘉信国际的8位账号
ai