上交大突破：多米诺推理策略实现AI推理速度近6倍能力提升

这项由上海交通大学EPIC实验室主导，联合华中科技大学软件工程学院、电子科技大学、复旦大学以及华为的研究团队共同完成的工作，于2026年5月28日以预印本形式发布，论文编号为arXiv:2605.29707。有兴趣深入了解的读者可以通过该编号查询完整论文。

**一、AI对话为什么有时候慢得像打字机？**

每次你和一个大型AI助手聊天，不知道有没有注意到一个现象：它回答问题的时候，文字是一个一个蹦出来的，就像有人在一旁慢慢打字。这不是AI在卖关子，而是它真实的工作方式——大语言模型（也就是GPT、Qwen这类AI的底层技术）在生成文字时，天生就是"一个字一个字往外蹦"的串行结构，每蹦出一个字，都需要经历一次完整的计算。

这个设计有一个严重的问题：现代GPU（显卡）是为大规模并行计算而生的，就像一个可以同时开动几千条流水线的工厂，但大语言模型的工作方式偏偏只用其中一条流水线，其余几千条全部闲置。结果就是：算力浪费严重，回答速度慢。

为了解决这个问题，研究人员发明了一种叫做"推测解码"（Speculative Decoding）的加速技术。核心思路可以用一个"快递打包"的比喻来理解：正常情况下，你每次下单，仓库都要单独打包、发货，一次只发一件；推测解码则是，先让一个"见习员工"预测你接下来可能买的几件商品并提前打好包，然后让"资深员工"一口气审核这批包裹，如果预测对了就统一发出，错了就从出错的地方重新来过。由于"资深员工"审核多件商品的速度和审核一件差不多，整体效率就大幅提升了。

然而，这套方法在实践中遇到了一个棘手的困境，正是这篇论文要正面解决的核心问题。

**二、"见习员工"的两难困境：质量与速度不可兼得**

继续用"快递打包"的比喻。"见习员工"（负责草拟答案的小模型，称为"草稿模型"）需要预测接下来几个字，这件事做得好不好，决定了整套流程能快多少。

做得好意味着什么？意味着"见习员工"每次猜对的字越多，"资深员工"就能一口气确认越多，效率越高。研究人员把"见习员工"平均每轮能猜对多少个字叫做"接受长度"——这个数字越大，加速效果越好。

那么怎样才能猜得准？关键在于，见习员工在猜第二个字的时候，必须知道第一个字是什么；猜第三个字的时候，必须知道前两个字是什么……这种"后一个字依赖前一个字"的链式关系，叫做"因果依赖"。顺着这条链子一步步猜，准确率高，这就是"自回归起草"方法（以EAGLE系列为代表）——它让见习员工像真人一样，一字一字顺序往下写，后面的字都参考前面的字。

但问题来了：这种方式虽然准，却慢。要预测16个字，就要让见习员工跑16次完整的计算，而且每次都要再经过一次庞大的"词典查找"（LM Head投影，即把内部计算结果映射到几万个词汇上选出最可能的字），这个步骤本身就很费时间。计算的时间开销随着预测字数线性增长，最终把省下来的时间又吃掉了一大半。

另一条路是"并行起草"——让见习员工一次性把所有字都预测出来，不管前后依赖，全部并行计算（以DFlash为代表）。这样只需要跑一次计算，速度快很多。但代价是，因为没有考虑前后字的关系，猜测的准确率下降，接受长度缩短，加速效果也因此打折扣。

具体数字可以说明这个两难局面：在同等条件下，EAGLE-3（自回归方法）的平均接受长度达到4.86个字，但最终加速比只有3.28倍；DFlash（并行方法）加速比提升到3.42倍，但接受长度却降到了4.03个字。两种方法各有明显短板，谁也无法做到又快又准。

这就引出了这篇论文的核心问题：有没有可能把并行起草的速度，和自回归起草的准确率，同时拿到手？

**三、"多米诺骨牌"的灵感：分开做两件事**

研究团队给出的答案是"Domino"框架，名字本身就是一个绝妙的比喻。多米诺骨牌的精妙之处在于：每一块牌倒下时，都会推动下一块，前后之间有严格的因果依赖链——但如果你想知道这排骨牌会不会全部倒下，你不必等着它们一块一块倒，你可以先把整排骨牌的摆放情况（初步预测）一次性扫描清楚，然后再做一个轻量级的"因果修正"，检查每块牌受前面那块牌影响之后会如何变化。

Domino框架正是如此运作的。它把整个草稿生成过程分成两个阶段，这两个阶段各司其职，互不干扰。

第一个阶段叫做"并行草稿骨干"（Parallel Draft Backbone）。这个阶段直接沿用DFlash的架构，做的事情就是：给定当前已经确认的文字前缀，一次性并行生成整个草稿块的初步预测分布。技术上讲，模型接收目标大模型的上下文特征，以及一个"遮罩草稿块"（把待预测位置都用MASK标记遮住），然后一次性并行跑完所有层，输出每个位置的隐藏状态，再经过目标大模型冻结的LM Head得到每个位置的"基础概率分布"（base logits）。这一步非常快，因为整个草稿块只需要一次前向计算。

第二个阶段就是Domino的核心创新，叫做"Domino头"（Domino Head）。这是一个轻量级的"因果修正模块"，专门负责把因果依赖信息注入到第一阶段生成的初步预测里，而且开销极小。

**四、Domino头是怎么工作的？**

Domino头由两个部分构成：因果编码器和低秩修正头。

因果编码器用的是一种叫做GRU（门控循环单元）的轻量级神经网络结构，隐藏维度只有1024。GRU本身就是为了处理序列信息而生的——它就像一个小小的记事本，每读入一个新的词，就把之前所有词的信息压缩成一个"状态摘要"记录下来，供下一个词参考。在Domino中，因果编码器从草稿块的第一个位置开始，依次读入每个已经采样出的草稿词的嵌入表示，不断更新这个"状态摘要"，到了第i个位置时，记事本里就存储了前i-1个草稿词的因果信息。这个过程确实是顺序的，但GRU极其轻量，顺序开销远比跑一次完整的大模型小得多。

低秩修正头负责把因果信息转化为对初步预测的"修正量"。具体做法是：把第一阶段输出的隐藏状态，和GRU输出的因果摘要状态拼接在一起，先用一个矩阵W1压缩到一个低维瓶颈空间（维度只有256），经过SiLU激活函数后，再用矩阵W2映射回词汇空间，得到一个"修正逻辑值"（correction logits）。这个修正值直接加到第一阶段的基础逻辑值上，得到最终的草稿分布。

关键的设计决策在于：修正是在"逻辑值空间"完成的，而不是在"隐藏状态空间"。如果在隐藏状态空间做修正，每次修正后还需要重新跑一遍完整的LM Head投影，又把昂贵的全词汇投影计算引回来了。而在逻辑值空间做修正，只需要一次低秩的矩阵运算，计算量极小。

最终的效果非常显著：和DFlash相比，Domino只增加了5600万参数（参数量增幅仅5.3%），总的起草加验证延迟只增加2.8%，但平均接受长度提升了16.6%，端到端加速比提升了12.3%。

**五、训练的两个关键决策：为什么不能直接训练？**

模型设计好了，怎么训练它同样大有讲究。研究团队在训练阶段遇到了两个不同的"坑"，并分别给出了解决方案。

第一个坑是：因果编码器在训练时应该喂什么数据。一种自然的想法是，让模型在训练时就模拟实际使用时的情况——先自己生成草稿词，然后把这些自己生成的（可能有错的）草稿词喂给因果编码器，学习如何修正。这种方式叫做"训练时测试"（TTT），EAGLE-3就是这么做的。

然而研究团队选择了另一种方式：教师强制（Teacher Forcing），也就是在训练时直接把正确答案的词喂给因果编码器，而不是自己生成的词。理由有两个方面。第一，自己生成的词在训练早期往往大量出错，用错误的输入去监督正确的输出，相当于在教模型"从错误的前提出发，推出正确的结论"，这个映射关系在真实数据中根本不存在，会让因果编码器学偏。第二，从推测解码的运作逻辑来看，第i个位置的草稿词能否对最终接受长度作出贡献，前提是前面所有位置的草稿词都已经被目标模型验证为正确。换句话说，因果修正真正起作用的场合，恰恰是前缀都是正确词的情况——这和教师强制训练时的输入分布完全吻合。实验证明，教师强制相比TTT，平均接受长度从3.80提升到3.96。

第二个坑是教师强制引入的新问题。由于训练时因果编码器总是拿到干净的正确前缀，修正分支学起来会特别"轻松"，以至于它可以越俎代庖，把并行骨干的功劳都抢过来——骨干输出的基础预测越来越差（"反正有修正分支兜底，随便预测就行"），修正分支越来越强，最终整个模型对骨干严重退化，只靠修正分支单打独斗。这种现象叫做"骨干崩溃"，从训练曲线上看就是并行骨干的损失值一路居高不下，无法正常下降。

为了解决这个问题，研究团队设计了"基础锚定课程"（Base-anchored Curriculum）。训练目标被设计为两个损失的加权组合：一个是针对基础预测的损失，一个是针对最终（经修正后）预测的损失。权重随训练进程动态变化：训练初期，权重完全倾向于基础预测损失，强制骨干先把基础分布学好；随着训练推进，权重线性从基础预测损失向最终预测损失过渡，让修正分支逐渐接管"精修"任务。这就像教一个学徒厨师：先让他把刀工、火候等基本功练扎实，再教他各种调味技巧——而不是一开始就让他堆砌各种调料掩盖食材本身的问题。

实验数据验证了这个设计的价值：教师强制加上基础锚定课程（TF+Curr）的平均接受长度达到4.19，比单纯教师强制（TF）的3.96又进一步提升，比TTT的3.80更是提升明显。

此外，在实现层面，Domino头的顺序修正循环采用了融合Triton内核和CUDA Graph技术进行优化，将内核启动和Python层面的调度开销大幅压缩，Domino头的实际延迟从2.64毫秒降低到1.20毫秒。

**六、实验结果：数字说话**

研究团队在Qwen3-4B和Qwen3-8B两个目标模型上进行了全面评测，任务覆盖数学推理（GSM8K、MATH-500、AIME25）、代码生成（HumanEval、MBPP、LiveCodeBench）和开放对话（MT-Bench、Alpaca）三大类别。对比方法包括自回归起草的EAGLE-3（树大小16和60两种配置）、并行起草的DFlash和DART，以及词汇裁剪方法FR-Spec。

在Transformers后端的低并发场景下，Domino的表现相当突出。以贪婪解码（温度为0）为例，在Qwen3-8B上，Domino在GSM8K上实现了7.92倍加速，在MATH-500上实现了7.38倍，在HumanEval上实现了5.89倍，在MBPP上实现了5.53倍，在LiveCodeBench上实现了5.27倍，在MT-Bench上实现了3.29倍，在Alpaca上实现了2.78倍，八个任务的平均加速比达到5.49倍。而同等条件下，EAGLE-3（16）的平均加速比仅为1.97倍，EAGLE-3（60）为2.26倍，DFlash（16）为4.66倍，DART（60）为2.29倍。即便与最接近的竞争者DFlash相比，Domino也多出了近一个百分点。在Qwen3-4B上，Domino的平均加速比进一步达到5.47倍，同样优于DFlash的4.70倍。

在采样解码（温度为1，输出更随机）的条件下，Domino同样保持领先：Qwen3-8B上的平均加速比为4.46倍，高于DFlash的3.96倍；Qwen3-4B上为4.61倍，高于DFlash的4.03倍。

在高并发场景下，研究团队使用SGLang推理服务框架测试了吞吐量。以Qwen3-8B、GSM8K任务为例，在并发数为2时，Domino达到942 tokens/秒（约为基线的5.1倍），并发32时达到3650 tokens/秒（约为基线的2.1倍）。同等条件下，DFlash在并发2时为672 tokens/秒（3.7倍），并发32时为2801 tokens/秒（1.6倍）。EAGLE-3（16）在并发32时已经接近或低于基线水平（0.8倍），说明在高并发下，自回归起草的顺序开销极大地拖累了整体吞吐量，而并行起草类方法在高并发下优势更为明显。

为了排除训练数据差异对结果的影响，研究团队还专门做了同数据对比实验：所有方法均在相同的ShareGPT数据集上训练，使用相同的16词草稿预算。在这种严格控制的条件下，Domino在GSM8K、HumanEval、LiveCodeBench三个任务上的低并发（1个请求）加速比分别为3.01倍、2.82倍、2.55倍，均优于EAGLE-3（2.35/2.27/1.99倍）、FR-Spec（2.77/2.67/2.36倍）和DFlash（2.68/2.58/2.36倍）。这说明Domino的增益来自模型设计本身，而非数据优势。

消融实验进一步拆解了Domino头的具体贡献：在同一个训练好的模型上，关闭因果修正分支时，平均接受长度为3.49，平均加速比为2.84倍；开启因果修正分支后，平均接受长度提升至4.19，平均加速比提升至3.31倍。GSM8K上的提升最为明显，接受长度从3.82提升到4.80，加速比从3.17倍提升到3.84倍。这证明轻量级因果修正是Domino超越纯并行骨干的关键所在。

**七、客观看待这套方案的边界**

研究团队在论文末尾也坦诚地指出了这项工作目前的局限。Domino当前的实现主要适配SGLang推理框架，在其他推理框架（例如vLLM等）上的兼容性尚未系统评估。此外，实际加速效果受硬件平台差异的影响较大——不同GPU的显存带宽、计算能力和内核效率各不相同，在不同硬件环境下部署时可能需要针对性的优化调整。这项研究聚焦于推理阶段的加速，并不涉及模型训练或微调成本的降低。

归根结底，Domino给出了一个清晰的技术答案：并行起草和因果建模并不是非此即彼的选择，完全可以通过架构设计把两者的优势叠加起来。用极小的参数开销和极低的时延代价，把遗漏的因果依赖信息补回来，最终实现"鱼和熊掌兼得"。随着大语言模型在越来越多的实际场景中部署，这类面向推理效率的精细化工程探索，可能比单纯追求更大模型更具现实意义——毕竟，同样的算力资源，如果能多服务几倍的用户，本身就是一件很有价值的事。对这个课题有兴趣的读者，可以通过arXiv编号2605.29707查阅完整论文，代码和模型权重也已在GitHub和Hugging Face上公开。

Q&A

Q1：推测解码（Speculative Decoding）是什么原理，为什么能加速AI推理？

A：推测解码的核心是用一个小模型提前猜测大模型接下来会输出的几个词，然后让大模型一次性审核这批猜测，审核多个词的时间和审核一个词差不多。如果猜对了，就一次性推进多步，相当于大模型的每次计算能产生更多输出，整体速度因此提升。

Q2：Domino方法与EAGLE-3和DFlash相比，分别在哪些方面做了改进？

A：EAGLE-3是逐词顺序生成草稿，因果建模准确但速度慢；DFlash是一次性并行生成所有草稿词，速度快但丢失了词与词之间的因果依赖，准确率下降。Domino保留DFlash的并行骨干做快速初稿，再用轻量级GRU编码器把因果信息以"修正量"的形式补回来，兼顾了速度和准确率。

Q3：基础锚定课程训练策略解决了什么问题？

A：在教师强制训练中，因果修正分支拿到干净的正确前缀后很容易"抢功"，导致并行骨干的基础预测退化。基础锚定课程通过动态调整损失权重，训练初期强制骨干先把基础预测学好，后期再逐步让修正分支发挥作用，避免了骨干崩溃，最终接受长度比单纯教师强制又提升了约5.8%。