推测解码Speculative Decoding通过将“草稿生成”和“目标模型验证”解耦来加速大型语言模型LLM的推理过程。尽管近期的并行草稿生成器能够在一次前向传播中高效提出长token序列但由于缺乏token之间的依赖建模它们的接受率会迅速下降。此外对这些扩展的token块进行不加区分的验证会浪费批处理容量在高拒绝风险的token上在高并发服务系统中严重降低吞吐量。我们提出了 DSpark一种推测解码框架将高吞吐的并行生成与自适应、负载感知的验证机制统一起来。为了保持草稿质量DSpark 采用半自回归架构——将并行主干网络与轻量级的顺序模块结合引入块内intra-block的依赖建模从而缓解“后缀退化”问题。在系统效率优化方面DSpark 使用基于置信度调度的验证策略根据每个请求的前缀存活概率估计以及引擎特定的吞吐特性动态调整验证长度从而实现更高效的计算分配。1引言大型语言模型LLMs采用自回归方式生成文本每生成一个新 token 都需要基于所有已生成的前缀进行一次完整的前向传播因此推理延迟与输出长度成正比。这种机制导致 GPU 利用率较低同时用户感知的等待时间较长成为生产环境中 LLM 服务的主要瓶颈尤其是在实时对话助手和多轮智能体工作流等对延迟敏感的场景中。推测解码Speculative DecodingChen et al., 2023Leviathan et al., 2023提供了一种有理论依据的解决方案一个轻量级的草稿模型先生成一段候选 token 序列而完整的大模型则在一次前向传播中对整个序列进行验证并通过拒绝采样机制接受与目标分布一致的最长前缀同时额外附加一个“奖励 token”。且接受规则能够严格保持目标分布不变因此推测解码在不损失生成质量的前提下加速了文本生成过程。草稿模型Draft Model参数量小例如 1B-3B运行极快但准确率一般。目标模型Target Model参数量大例如 70B正是我们实际想要使用的高质量大模型。小模型“盲猜”草稿模型连续自回归地生成 K 个 Token比如 K5。因为小模型极快这个过程耗时很短。 大模型“并行验证”将这 K 个 Token 以及原本的上下文一次性喂给大模型。大模型利用其强大的并行计算能力在单次前向传播Forward Pass中同时计算出这 K 个位置的概率分布。 接受与拒绝大模型根据拒绝采样Rejection Sampling来决定接受小模型猜对的前几个 Token。 - 如果小模型猜对了前 3 个第 4 个猜错了那么前 3 个被保留。 - 大模型在拒绝第 4 个的同时会利用刚才单次前向传播顺便算出的正确概率直接修正并输出第 4 个正确的 Token。 - 第 5 个及之后的草稿直接作废。 循环往复从被修正的那个位置开始小模型继续往下猜 K 个进入下一轮循环。草稿模型的设计决定了“生成速度drafting latency”与“接受率acceptance rate”之间的权衡关系。早期的草稿模型采用自回归方式Cheng et al., 2024Li et al., 2024b即每个位置的 token 都依赖于之前已采样的 token。这种设计的问题在于草稿生成的延迟会随着块大小block size的增加线性增长因此这类方法通常只能使用较短的生成块并且依赖较浅的模型结构。为了突破这一顺序依赖的瓶颈近年来出现了并行草稿模型Cai et al., 2024Chen et al., 2026Liu et al., 2026a。这类方法的核心特点是在一次前向传播中同时生成所有草稿位置使得草稿生成的延迟几乎与块大小无关。这种结构上的优势使得并行草稿模型在理论上能够高效生成更长的草稿 token 块从而提升整体推测解码的效率上限。然而要充分释放大规模并行草稿块的潜力会带来两个关键瓶颈——一个来自生成质量另一个来自系统效率。首先由于并行草稿模型在每个位置上是独立预测的它们无法建模块内 token 之间的相互依赖关系。这种独立性会导致多模态冲突multi-modal collisions并使得序列后段的接受率快速下降acceptance decayGu et al., 2018Huang et al., 2022b。其次如何确定最优的验证长度仍然是一个难题。虽然并行生成可以轻松产生较长的草稿块但如果对所有提出的 token 都进行不加区分的验证会降低系统吞吐量尤其是在高并发负载下Hu et al., 2026Liu et al., 2024c。理想的验证长度实际上受到两个维度的影响在数据层面不同类型的请求会显著影响接受率。例如结构化任务如代码生成通常能够维持更高的接受率而开放式对话任务chat则更容易出现较低的接受率Abramovich et al., 2026Xia et al., 2024。在系统层面当负载较轻时额外验证 token 的成本几乎可以忽略但在高负载情况下验证那些具有较高拒绝风险的 token 会占用关键的 batch 计算资源从而挤占其他正在处理的请求Liu et al., 2024bWu et al., 2025。为了解决上述两个瓶颈我们提出 DSpark一种将高吞吐并行生成与自适应、负载感知验证统一起来的推测解码框架。其核心设计通过两个互补机制来系统性缓解草稿生成与验证过程中的固有权衡。首先为了克服 token 之间缺乏依赖建模的问题DSpark 采用半自回归semi-autoregressive架构。该方法保留了计算开销较高的草稿主干网络的完全并行结构仅在其后附加一个轻量级的串行输出头用于注入局部的序列转移信息。这种设计在保持并行模型生成速度优势的同时有效缓解了“后缀退化”suffix decay问题。其次为了解决系统层面的瓶颈DSpark 引入了基于置信度调度的验证机制confidence-scheduled verification。该机制通过一个置信度预测头估计每个位置对应的前缀存活概率并结合一个感知硬件负载的调度器动态调整每个请求的验证长度。该调度器会利用实时推理引擎的吞吐状态将验证预算优先分配给那些预期收益最高的 token从而提升整体系统效率。2背景【推测解码】自回归语言模型在每一次前向传播中仅生成一个 token因此推理延迟与输出长度成正比。推测解码Speculative DecodingChen et al., 2023Ge et al., 2022Leviathan et al., 2023通过使用一个轻量级草稿模型​ 来加速目标模型​ 的推理过程。在每个解码循环中草稿模型会首先生成个候选 token随后目标模型在一次前向传播中对这些候选 token 进行整体验证并接受与其自身分布一致的最长前缀从而实现高效的序列生成加速。具体来说在每一个草稿位置目标模型会计算自身的概率分布并将其与草稿模型的分布​ 进行比较。对于该位置生成的 token​其被接受的概率为验证过程是从左到右依次进行的一旦在位置出现第一个拒绝该位置之后的所有 token即都会被全部丢弃而不论它们本身的质量如何。设表示每个解码周期中被接受的 token 数量和分别表示草稿阶段和验证阶段的实际运行时间wall-clock time。那么平均每生成一个 token 的延迟可以表示为因此提升加速效果可以归结为三个关键手段降低让草稿生成更快、提高让草稿更“准”即每轮能被接受的 token 更多或者减少有效的​让验证过程更“聪明”避免浪费计算在低价值 token 上。大模型 单次前向传播只读写一次显卡耗时无论输入 1 个还是 5 个 Token耗时都差不多让小模型一次猜 4 个 Token即平均接受率 75%小模型 因为参数量极小比如只有大模型的 1/50单次自回归耗时。【传统自回归】【推测解码】【草稿模型】草稿模型的设计决定了与之间的权衡关系。目前的方法主要分为两类。自回归草稿模型自回归草稿模型按顺序生成草稿 token每个位置都以先前已采样的 token 为条件。这种显式依赖结构具有较强的建模能力但其草稿生成成本会随着 block size 线性增长。这迫使自回归草稿模型必须使用较小的和较浅的网络结构以保持​ 较低。为弥补短 block 的不足一些方法采用基于树的验证tree-based verificationMiao et al., 2024将候选扩展为一棵树并通过 tree attention 验证多条路径但大量验证 token 会降低整体服务吞吐量。并行草稿模型并行草稿模型在一次前向传播中生成全部个草稿 token使得几乎与 block size 无关因为头 2 在预测的时候根本不知道头 1 预测了啥因为是并行的没有因果关系这种“盲猜”导致草稿的连贯性较差大模型容易拒绝掉后面的 Token。这使得可以在不显著增加延迟的情况下使用更大的 block size例如。DFlash 的小模型像画油画一次性把整块区域比如未来 $K$ 个 Token的画布铺开通过一个非因果Non-causal的注意力掩码让整块 Token 互相能看到彼此。不是孤立地预测第和第而是把这个位置当成一个整体去协同“去噪Denoise”。这使得它在单次前向传播Single Forward Pass中就能吐出连贯性极高的一整块草稿。DFlash 认为大模型Target Model才是真正理解上下文的“最强大脑”。因此DFlash 并不让小模型孤立地去猜而是直接把大模型刚刚计算好的深度特征Hidden States/KV Cache提取出来注入到小模型的输入中。在 prefill预填充阶段来自目标模型的一组层的隐藏状态会被拼接起来并投影到草稿模型的隐藏空间中其中是一个共享的投影矩阵。这些上下文特征会被注入到草稿模型的每一层中通过在 key 和 value 的序列维度上将其与草稿块的表示进行拼接从而完成信息融合。在一个 block 内部所有位置之间以及它们与注入的目标模型上下文之间都采用双向注意力bidirectional attention进行交互。草稿模型与目标模型共享词嵌入层和语言模型头两者均为冻结参数。其输入为一个“锚点 tokenanchor token¹”的 embedding后接个 mask token 的 embedding并在一次前向传播中为所有 mask 位置同时生成 logits。由于草稿生成在任何 block size 下都只需要一次前向传播因此在相同的延迟预算下DFlash 相比自回归草稿模型可以使用更深的网络结构以及更大的 block size。3架构DSpark 的架构概述如图 1 所示。由公式 1 可知投机解码speculative decoding的单 token 延迟为。表示每个解码周期中被接受的 token 数量和分别表示草稿阶段和验证阶段的实际运行时间wall-clock time。自回归草稿模型autoregressive drafters能够实现较高的但其付出的代价是并行草稿模型parallel drafters虽然能将压缩至单次前向传播但由于每个位置都是独立预测的因此牺牲了。与此同时固定长度的验证机制会将浪费在低置信度的后缀 token 上而这些 token 几乎注定会被拒绝。【固定长度】为了追求速度并不是改完第 1 步再去读第 2 步。相反它是同时把这 5 个步骤一起放进脑子里并行计算进行审阅的。也就是说大模型在发现第 2 步错误之前其实已经把验证第 3、4、5 步的算力和时间。明知道并行草稿小模型在后面已经开始胡言乱语了低置信度大模型还是不得不把这整段胡话全部读完并验证一遍。针对这些局限性DSpark 通过两个互补的组件进行了解决半自回归生成第 3.1 节。一个并行骨干网络backbone负责处理大部分的草稿计算draft computation这使得几乎独立于。随后一个轻量级的串行模块在草稿 Token 之间注入依赖关系从而在增加极少额外延迟的情况下提升了。基于置信度调度的验证第 3.2 节。置信度头confidence head用于评估每个位置的接受概率而一个感知硬件的调度器则利用这些评估结果来剪枝低置信度的后缀 Token从而减少不必要的验证计算。图 1 | DSpark 架构与解码周期。给定提示promptTokenABC目标模型执行一个步骤来生成下一个 TokenD该 Token 将作为草稿阶段的锚点anchor。DSpark 以D作为输入利用一个重型并行骨干网络和一个轻量级串行头来生成草稿 TokenEFGH及其相应的置信度得分。随后感知硬件的前缀调度器Hardware-Aware Prefix Scheduler通过评估这些得分保留前缀EFG并丢弃低置信度的 TokenH。最后目标模型并行验证经过调度的前缀。如图所示E和F被接受而G被拒绝从而促使模型生成一个修正后的 TokenG*来完成当前轮次。3.1半自回归生成并行草稿器parallel drafter在单次前向传播中生成所有个草稿 logit因此每个预测都无法以该块中其他位置采样出的 Token 为条件。当上下文存在多种合理的后续衔接时例如“of course”和“no problem”并行草稿器可能会产生不连贯的组合如“of problem”或“no course”。这是因为每个位置都对所有可能的先导 Token 进行了边缘化marginalize处理而不是以实际采样出的那一个为条件Gu 等2018Huang 等2022a。因此接受率会在块内迅速衰减从而浪费了草稿计算和验证计算。因此我们采用了一种半自回归结构将草稿生成分为两个阶段这里属于并行拿到隐态和基础logit不涉及关联。后面串行用RNN关联因果。属于是并行进行了一半降低了延迟串行进行了一半增加准确度。【并行阶段】一个并行骨干网络在我们的具体实现中为 DFlashChen 等2026在整个块上运行单次前向传播生成隐藏状态和基础 logit。我们仅对原始的 DFlash 骨干网络进行了微小的改动我们不再是输入一个锚点anchorToken 加上个掩码maskToken 并仅预测掩码位置而是将锚点本身视为第一个预测位置因此个输入 Token锚点 个掩码会产生个草稿 logit。这在保持相近草稿质量的同时减少了草稿阶段的计算量。【串行阶段】串行阶段通过引入一个依赖于前缀的转移偏置transition bias来对基础 logit 进行补充从而允许每个草稿位置都以该块内先前已采样的 Token 为条件。串行阶段并没有定义一个全局归一化的能量模型而是通过自回归因式分解autoregressive factorization来引出因果块分布causal block distribution在此处表示来自上一个验证周期的锚点anchorToken是并行骨干网络在位置处产生的基础 logit 向量而则表示词表。在推理时串行模块按照从左到右进行采样。由于这一采样过程本质上是串行的因此该模块在计算上必须非常轻量化即以确保整体的草稿延迟仍由并行阶段主导。马尔可夫头Markov head。最简单的具体实现是将限制为仅依赖于紧邻的前一个 Token从而将其简化为一阶转移。原则上这是一个完整的矩阵我们通过低秩因式分解来对其进行近似其中且。给定前一个 Token位置的转移偏置为其中用作嵌入查找表embedding lookup table用作 logit 投影。低秩因式分解默认使得存储开销和每步计算量都保持在极小的水平从而让串行循环即使在大词表下也能高效运行。回到先前的例子一旦位置 1 采样出“of”马尔可夫头就会在位置 2 提升“course”的概率并抑制“problem”从而缓解了跨模态冲突cross-mode collision。RNN 头RNN head。马尔可夫头在超过一步之后是无记忆的——即位置无法访问之前的 Token。RNN 头通过维持一个循环状态来放宽这一限制该状态能够累积块内完整的历史前缀信息。在每一步中该模块将当前状态、前一个 Token 的嵌入向量以及骨干网络的隐藏状态拼接成一个输入向量然后执行单次门控更新gated update其中通过单个线性投影进行联合参数化该线性投影被拆分为门控gate、候选candidate和输出output三个组件。状态初始化为零。3.2基于置信度调度的验证半自回归架构使得 DSpark 能够高效地生成大型草稿块draft blocks。然而产生更多的草稿 Token 并不一定会自动转化为更高的端到端加速比。不加区分地验证整个草稿块实际上可能会降低整个系统的吞吐量尤其是在高并发场景下Hu 等2026Liu 等2024c。这种性能瓶颈源于两个相互作用的因素在数据端草稿接受率在不同领域之间本质上是不同的例如代码等结构化文本自然会带来高接受率而开放式对话的接受率则显著较低Abramovich 等2026Xia 等2024。在系统端验证一个额外 Token 的实际成本严格取决于引擎的负载。在系统负载较轻时即使额外的验证被拒绝其带来的惩罚也微乎其微。然而在高并发部署下每一次不必要的验证都会占用目标模型的批处理容量batch capacity而这些容量本可以用来服务其他活跃的请求Liu 等2024bWu 等2025。因此要充分释放大草稿块的潜力需要一种统一的机制将目标模型的计算资源仅路由到那些具有正向预期收益positive expected return的 Token 上。DSpark 通过将用于预测前缀存活概率的置信度头confidence head第 3.2.1 节与根据当前系统负载动态决定最佳验证长度的感知硬件的前缀调度器hardware-aware prefix scheduler第 3.2.2 节相结合从而实现了这一目标。【置信度头】受到 Huang 等人 (2024) 和 Wang 等人 (2026) 的启发置信度头为每个草稿位置输出一个标量估计值。至关重要的一点是​ 建模的是一个条件概率即在当前块中所有先前 Token 均已被接受的条件下位置处的草稿 Token 能够通过目标模型验证的概率。其架构采用了一个轻量级的线性投影后接一个 Sigmoid 函数其中是骨干网络的隐藏状态是来自上一个草稿 Token 的马尔可夫嵌入Markov Embedding。我们使用每步的解析接受率analytical acceptance rate来监督。该接受率由草稿分布与目标分布之间的全变差距离total variation distance所决定事后校准Post-hoc Calibration。诸如基于阈值的验证启发式方法Huang 等2024Li 等2024bZhang 等2026b仅需要置信度得分来正确对草稿 Token 的质量进行排序。与此不同我们的感知硬件的调度方法详见第 3.2.2 节精确地需要累积接受概率的绝对大小来计算预期接受长度。由于神经网络的置信度估计往往过于自信Guo 等2017Ovadia 等2019直接使用原始置信度得分会扭曲吞吐量估计从而导致次优的调度决策。为了解决这个问题我们引入了串行温度缩放Sequential Temperature Scaling简称 STS。因为每个建模的都是一个条件概率根据概率的链式法则一个草稿前缀被整体接受的联合概率可以因式分解为累积乘积。STS 利用一个留出的验证集held-out validation set从左到右依次对该联合概率进行校准。具体而言在每个位置处我们在保持先前所有位置已校准得分固定的情况下进行简单的 mid一维网格搜索以寻找最优的温度标量从而最小化该累积乘积的预期校准误差Expected Calibration Error, ECENaeini 等2015。至关重要的一点是温度缩放是一种保序变换order-preserving transformation它在纠正预测概率以匹配经验接受率的同时不会破坏置信度头所学到的草稿 Token 之间的相对排名。【感知硬件的前缀调度器】先前的方法Huang 等2024Li 等2024b通常对置信度得分采用静态阈值来决定验证长度。虽然这种方法在孤立的单请求假设下行之有效但在高并发的生产系统中可能并非最优因为在这些系统中验证一个草稿 Token 的效用严重依赖于当前的系统负载。为了解决这个问题我们将验证长度的选择建模为一个全局吞吐量最大化问题算法 1。考虑包含个活跃请求的批次batch。对于请求令为每个位置的置信度估计值并令表示调度的验证长度。由于投机解码speculative decoding动态接受草稿 Token 时仅将其视作一个连续的前缀因此位置 $j$ 处的 Token 的存活概率为累积乘积。在单次验证步骤中发送给目标模型的总批次大小以 Token 数量衡量为而预期成功接受的 Token 数量为。令表示在给定前向传播批次大小的情况下引擎的吞吐量以每秒执行的步数衡量。至关重要的一点是该性能曲线在引擎初始化期间仅需分析profile一次并作为一个轻量级的开销表cost table进行存储。随后我们的调度器旨在通过动态选择验证长度来最大化预期系统级 Token 吞吐量。