这项由以色列理工学院（Technion）计算机科学系与电气及计算机工程系联合开展的研究，以预印本形式发布于2026年4月14日，论文编号为arXiv:2604.12989。有兴趣深入了解的读者可通过该编号查询完整论文。
一、先从一个日常场景说起
假设你在餐厅等待点餐，服务员一次只能处理一位顾客，然后走回厨房，等菜做好，再回来，再服务下一位。这种方式显然效率不高。而一位经验丰富的老服务员，不仅能预判你可能点什么菜，还能提前打招呼让厨房做好准备。如果预判准确，整桌的上菜速度就会大幅提升；哪怕偶尔猜错，也只不过是白忙了一小会儿，整体流程仍然比逐一等待快得多。
当今最强大的AI语言模型——也就是驱动各类智能对话产品的核心引擎——正面临着与那家低效餐厅完全相同的困境。每生成一个字，它都必须调动整个庞大模型走一遍完整流程。对于动辄数十亿甚至数百亿参数的大模型而言，这意味着每个字的生成都要付出高昂的计算代价，速度慢、延迟高，严重限制了实际使用体验。
以色列理工学院的研究团队正是针对这一痛点，提出了一种名为DDTree（扩散草稿树，Diffusion Draft Tree）的新方法。这项研究建立在一系列前沿工作之上，将"让AI提前猜测后续内容"的思路发挥到了新的高度，最终实现了在不改变AI输出质量的前提下，推理速度最高提升8倍以上的惊人成绩。
二、大模型推理速度慢，问题到底出在哪里
要理解DDTree的价值，需要先了解大型语言模型生成文字的基本方式。这类模型采用的是"自回归"生成机制，通俗来说，就是每次只预测并输出一个词，然后把这个词加入已有内容，再去预测下一个词，如此循环往复。
用一个更直观的比喻来说：这好比一位书法家，每写一个字，都要重新调整笔墨、审视全篇布局，然后才落笔写下下一个字。单字写得再快，这种一字一停的节奏本身就是瓶颈所在。对于动辄生成数百上千个词的复杂任务——比如解一道数学题、写一段代码，或者回答一个深度问题——这种逐词生成的方式会消耗大量时间。
研究者们意识到，大模型在生成每个词之前，其实已经在内部处理了大量关于"接下来可能出现什么"的信息。如果能把这些信息提前利用起来，哪怕只是有限度地"猜测"一批可能的后续词，再交由大模型一次性验证，效率就能成倍提升。这种思路被称为"推测解码"（Speculative Decoding），是目前学术界和工业界都在积极探索的加速方向。
三、推测解码：让小助手帮大模型"提前猜词"
推测解码的基本逻辑可以用一个团队协作的场景来理解：大模型是一位决策权威，判断最终准确但处理一件事需要较长时间；小模型则是一位反应迅速的助理，能在极短时间内提出几个候选方案。每一轮工作中，助理先快速草拟出一串候选词，然后权威一次性审阅全部草稿，逐一批准或否决。被批准的词直接纳入输出，遇到第一个不认可的词时，流程重置，进入下一轮。
关键在于，权威审阅多个候选词的时间，和审阅单个词的时间相差不大。这是因为大模型在做验证时可以并行处理所有草稿词，不需要像生成时那样一个一个来。只要助理猜对的比例足够高，整体速度就会显著提升。
近年来，一种被称为"块扩散"（Block Diffusion）的技术为这个助理角色提供了新的能力。传统的自回归助理模型仍然需要逐词生成草稿，效率有限。而块扩散助理模型能够在一次前向传播——也就是一次完整的计算流程——中同时预测接下来多个位置的词，相当于助理可以一口气写出一整段草稿，而不是一字一字地拼凑。
在这一方向上，DFlash是目前公认的领先方案。它利用一个轻量级的块扩散助理，结合大模型本身产生的中间特征作为辅助信息，实现了极高的草稿准确率，在多项测试中的表现已经超越了另一强劲方案EAGLE-3。可以说，DFlash已经是这一领域的"标杆"。
然而，DFlash有一个尚未充分利用的潜力：它的一次前向传播不只给出一串草稿词，而是给出每个位置上所有词的概率分布——换句话说，它不仅猜了"最可能的下一个词"，还附带了"第二可能、第三可能……"的完整排名。但DFlash目前只选取每个位置上最高概率的词，拼成一条单一草稿链送给大模型验证。这就像那位书法家助理每次只递出一幅草稿，而不是把几个备选方案同时摆出来供权威挑选。
这个局限，正是DDTree要解决的问题。
四、DDTree：把"一条草稿"变成"一棵草稿树"
DDTree的核心创意，是把块扩散助理给出的概率信息充分利用起来，构建一棵"草稿树"而非单一草稿链。
用一个更具体的场景来理解：假设助理要预测接下来三个位置的词。对于第一个位置，概率最高的是"因此"，其次是"所以"，再次是"于是"；对于第二个位置，概率最高的是"我们"，其次是"该"；对于第三个位置，概率最高的是"得出"，其次是"推断"。如果只选每个位置上概率最高的词，得到的草稿是"因此—我们—得出"这一条路径。但如果把这些备选项组合成一棵树，根节点出发，第一层有"因此""所以""于是"三个分支，每个分支之下再延伸出各自的第二层和第三层，就能同时覆盖"因此我们得出""因此我们推断""因此该得出""所以我们得出"等多条路径。
把这棵树一次性送给大模型验证，大模型就能在一次计算中检查所有这些路径，挑出其中最长的一条吻合路径。这样，每一轮验证能"命中"的词数大概率比单链验证更多，整体速度也就随之提升。
不过，这棵树不能无限扩张。树上的节点数量直接决定了大模型每次验证的计算量。节点太少，覆盖面不够广；节点太多，验证成本上升，反而可能得不偿失。因此，DDTree引入了一个"节点预算"（Node Budget）参数B，限制每棵树最多包含多少个节点，并在这一约束下尽可能构建出最有价值的树结构。
五、"最优草稿树"是如何被精确推导出来的
这正是这项研究的数学精华所在，也是DDTree区别于简单工程拼凑方案的关键：研究团队从理论上严格证明了，在节点预算约束下，什么样的草稿树是"最优"的，以及如何高效地找到这棵最优树。
首先需要明确一个前提：块扩散助理给出的概率信息有其特殊性。在自回归模型中，预测第二个词时是以已确定的第一个词为条件的；而块扩散模型在一次前向传播中同时预测所有位置，每个位置的预测彼此独立，均基于同一个"输入上下文"，而非基于树上的前驱节点。这意味着，助理给出的是每个位置的"边际分布"，而非"条件分布"。
研究团队以这种边际分布构建了一个代理目标函数：在助理的概率模型下，期望能验证通过多少个词。他们证明，这个期望值等于树中所有节点的路径概率之和。而路径概率的计算非常直接：把路径上每个位置所选词的概率相乘即可。
基于这一结论，最优草稿树的选法变得出乎意料地简单：在所有可能的路径前缀中，按路径概率从高到低排序，取前B个即可。而且，只要满足一个自然的"前缀封闭性"要求——即如果一条路径入选，它的所有上级路径也必须入选——这B个概率最高的前缀必然自动满足这一要求，构成一棵合法的树。
接下来的挑战是算法层面的：所有可能的路径前缀数量随着词表大小和路径深度指数级增长，根本无法逐一枚举。研究团队设计了一个"最优先堆"算法（Best-First Heap Algorithm）来高效解决这个问题。该算法的思路是：从概率最高的单步路径出发，每次从优先队列中取出当前概率最高的路径，同时将其两个自然"邻居"——同深度的下一个备选词（兄弟节点），以及延伸到下一位置的最优词（子节点）——加入队列。重复这一过程B次，就能精确找到概率最高的B条路径。整个算法的计算复杂度仅为O(B log B)，极为高效。
六、验证过程：一次搞定，经济高效
构建好草稿树之后，DDTree将这棵树"压平"成一个特殊排列的输入序列，送入大模型进行验证。为了让大模型能正确理解树形结构中的位置关系，研究团队采用了一种特殊的注意力机制——"树形注意力"（Tree Attention）。在这种机制下，树中的每个节点在计算时只能"看到"它的所有祖先节点以及自身，而不能看到同层或下层的其他分支。这就好比审阅草稿的权威，在评估某一条分支路径时，只参考这条路径自身的历史，而不受其他分支的干扰。
通过这种方式，大模型仅需一次前向传播，就能对树中所有节点同时给出评分。验证结束后，从根节点出发，沿大模型实际选择的词逐层向下走，每当大模型的选择与树中对应节点吻合，就接受这一步并继续往下；一旦出现分歧，走过程停止。被接受的路径直接追加到已生成的文本中，第一个不吻合的词则作为新一轮的"起始礼物词"，开启下一轮的草稿-验证循环。
七、实验结果：数字背后的真实意义
研究团队在8块H200显卡上，对三个不同规模的目标模型——Qwen3-4B、Qwen3-8B和Qwen3-Coder-30B-A3B-Instruct——进行了系统评测。测试覆盖了10个不同类型的基准数据集，包括数学推理类（MATH-500、GSM8K、AIME 2024/2025）、代码生成类（HumanEval、MBPP、LiveCodeBench、SWE-bench Lite），以及通用对话类（MT-Bench、Alpaca），并在0.0和1.0两种温度参数下各测一遍，共形成60组对比实验。
结果显示，DDTree在全部60组实验中均优于基准DFlash方案，没有任何例外。在表现最突出的场景中——以Qwen3-4B处理HumanEval代码任务、温度0.0为例——DDTree实现了相对于逐词生成方式8.2倍的速度提升，而DFlash本身已达到约5倍。即便在改善幅度最小的场景中，DDTree也稳定地提供了可观的加速。
从平均接受词数（即每轮验证平均能命中多少个草稿词）来看，DDTree相比DFlash有着显著提升。以MATH-500数据集、Qwen3-8B、温度0.0为例，DFlash的平均接受词数约为7.79，而DDTree（节点预算512）达到了约10.73。换句话说，平均每轮验证多通过了近3个词，意味着每生成相同数量的文字，需要的验证轮次更少，等待时间更短。
更直观的是接受词数的分布图。在DFlash的方案下，接受词数分布相对分散，很多轮次只命中了较短的路径。而DDTree的分布明显向右偏移：命中4个词以下的轮次大幅减少，命中整个16词完整块的轮次则变得相当常见——这在DFlash中是相对罕见的"幸运情况"，而在DDTree中几乎成为常态。
在节点预算的选择上，研究团队观察到一个典型的"先升后降"规律：随着预算从16增大到512，速度提升幅度持续增加；但继续增大到1024时，速度提升开始回落，因为验证阶段的计算开销已经超过了接受词数增加带来的收益。这意味着在实际部署中，存在一个最优预算点，而这个点可能因硬件环境和任务类型而有所不同。研究团队建议，最佳实践是针对具体场景进行简单调参，而不是无脑选取最大预算。
八、与其他方法相比，DDTree的独特之处
从更宏观的视角看，DDTree并非推测解码领域的第一个树形方案。此前已有多个研究团队探索过类似思路，其中与DDTree最相近的是另一项名为DART的近期工作，同样从一次性并行预测的概率信息中构建草稿树。
然而两者的实现路径有明显差异。DART在构建树时依赖一种额外的"N-gram连续性评分"机制，需要在运行时维护一个大型的N-gram查找表，引入了额外的外部组件。DDTree则完全依赖块扩散助理本身输出的概率信息，不引入任何外部评分工具，结构更为简洁。更重要的是，DDTree有严格的理论保证：所选的树在代理目标函数下是最优的，而非启发式的近似。
与需要多次前向传播才能构建树的自回归草稿方案（如EAGLE-2的动态树构建）相比，DDTree维持了块扩散方案的核心优势——一次前向传播搞定整棵树——同时通过树形结构充分利用了这一次传播产生的全部概率信息。
值得一提的是，由于树形注意力机制目前与FlashAttention-2（一种高效注意力计算库）不兼容，研究团队在验证阶段不得不使用标准的PyTorch注意力实现，速度相对较慢。为了保证对比的公平性，他们在评估DFlash基准时两种实现方式都测试了，并取其中较快的结果，也就是说，基准实际上使用了更优化的注意力实现。尽管如此，DDTree仍然全面领先，这也意味着一旦树形注意力与高效注意力库实现兼容，DDTree的速度优势将进一步扩大。
归根结底，DDTree做到的事情是：把块扩散助理一次前向传播产生的完整概率信息，通过一个有理论保证的最优算法，转化为一棵恰到好处的草稿树，再以最小的额外代价完成验证。它既没有改变助理模型的训练和推理方式，也没有改变大模型的输出分布，而是通过更聪明地"打包"和"使用"已有信息，把整个流程的效率推上了新台阶。
这对于正在大规模部署AI应用的企业来说意味着什么？简单来说，同样的硬件、同样的模型质量，每秒能处理的请求量可以提升数倍，服务成本随之大幅下降，用户等待时间也显著缩短。在AI推理成本仍然高昂的当下，这类效率提升的工作具有相当直接的实用价值。
有兴趣深入探究技术细节和完整实验数据的读者，可以通过arXiv编号2604.12989查阅这篇论文的完整版本。
Q&A
Q1：推测解码（Speculative Decoding）和普通的大模型推理有什么区别？
A：普通大模型推理是逐词生成，每生成一个词就要走一遍完整的大模型计算流程，速度慢。推测解码则引入一个轻量级的"助理模型"，先快速预测出一批候选词，再让大模型一次性批量验证，被大模型认可的词直接采用。由于大模型并行验证多个词的成本和验证单个词差不多，只要助理猜对率足够高，整体速度就能大幅提升，而且大模型的输出质量不受任何影响。
Q2：DDTree的节点预算应该怎么选？
A：根据论文的实验结果，节点预算存在一个"甜点区间"。预算太小时，草稿树覆盖的路径有限，速度提升不明显；预算太大时，大模型验证的计算量上升，收益开始被成本抵消。在论文测试的Qwen3-8B+MATH-500场景中，256到512是最优区间。由于最优预算受硬件平台、模型大小和任务类型影响，建议在实际部署时针对具体场景从预设的几个档位（如16、32、64、128、256、512、1024）中做一次简单测试，找到最佳点。
Q3：DDTree会改变大模型的输出内容或质量吗？
A：不会。DDTree属于"无损加速"方案，严格保留了目标大模型的输出分布。大模型在验证草稿树时，完全遵循自身的解码规则（无论是贪心解码还是温度采样），只有与大模型选择吻合的草稿词才会被接受。因此，使用DDTree和让大模型直接逐词生成，产生的文字内容在统计意义上完全一致，加速不以牺牲任何质量为代价。