这项由上海交通大学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%。**五、训练的两个关键决策为什么不能直接训练**模型设计好了怎么训练它同样大有讲究。研究团队在训练阶段遇到了两个不同的坑并分别给出了解决方案。第一个坑是因果编码器在训练时应该喂什么数据。一种自然的想法是让模型在训练时就模拟实际使用时的情况——先自己生成草稿词然后把这些自己生成的可能有错的草稿词喂给因果编码器学习如何修正。这种方式叫做训练时测试TTTEAGLE-3就是这么做的。然而研究团队选择了另一种方式教师强制Teacher Forcing也就是在训练时直接把正确答案的词喂给因果编码器而不是自己生成的词。理由有两个方面。第一自己生成的词在训练早期往往大量出错用错误的输入去监督正确的输出相当于在教模型从错误的前提出发推出正确的结论这个映射关系在真实数据中根本不存在会让因果编码器学偏。第二从推测解码的运作逻辑来看第i个位置的草稿词能否对最终接受长度作出贡献前提是前面所有位置的草稿词都已经被目标模型验证为正确。换句话说因果修正真正起作用的场合恰恰是前缀都是正确词的情况——这和教师强制训练时的输入分布完全吻合。实验证明教师强制相比TTT平均接受长度从3.80提升到3.96。第二个坑是教师强制引入的新问题。由于训练时因果编码器总是拿到干净的正确前缀修正分支学起来会特别轻松以至于它可以越俎代庖把并行骨干的功劳都抢过来——骨干输出的基础预测越来越差反正有修正分支兜底随便预测就行修正分支越来越强最终整个模型对骨干严重退化只靠修正分支单打独斗。这种现象叫做骨干崩溃从训练曲线上看就是并行骨干的损失值一路居高不下无法正常下降。为了解决这个问题研究团队设计了基础锚定课程Base-anchored Curriculum。训练目标被设计为两个损失的加权组合一个是针对基础预测的损失一个是针对最终经修正后预测的损失。权重随训练进程动态变化训练初期权重完全倾向于基础预测损失强制骨干先把基础分布学好随着训练推进权重线性从基础预测损失向最终预测损失过渡让修正分支逐渐接管精修任务。这就像教一个学徒厨师先让他把刀工、火候等基本功练扎实再教他各种调味技巧——而不是一开始就让他堆砌各种调料掩盖食材本身的问题。实验数据验证了这个设计的价值教师强制加上基础锚定课程TFCurr的平均接受长度达到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-316的平均加速比仅为1.97倍EAGLE-360为2.26倍DFlash16为4.66倍DART60为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-316在并发32时已经接近或低于基线水平0.8倍说明在高并发下自回归起草的顺序开销极大地拖累了整体吞吐量而并行起草类方法在高并发下优势更为明显。为了排除训练数据差异对结果的影响研究团队还专门做了同数据对比实验所有方法均在相同的ShareGPT数据集上训练使用相同的16词草稿预算。在这种严格控制的条件下Domino在GSM8K、HumanEval、LiveCodeBench三个任务上的低并发1个请求加速比分别为3.01倍、2.82倍、2.55倍均优于EAGLE-32.35/2.27/1.99倍、FR-Spec2.77/2.67/2.36倍和DFlash2.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上公开。---QAQ1推测解码Speculative Decoding是什么原理为什么能加速AI推理A推测解码的核心是用一个小模型提前猜测大模型接下来会输出的几个词然后让大模型一次性审核这批猜测审核多个词的时间和审核一个词差不多。如果猜对了就一次性推进多步相当于大模型的每次计算能产生更多输出整体速度因此提升。Q2Domino方法与EAGLE-3和DFlash相比分别在哪些方面做了改进AEAGLE-3是逐词顺序生成草稿因果建模准确但速度慢DFlash是一次性并行生成所有草稿词速度快但丢失了词与词之间的因果依赖准确率下降。Domino保留DFlash的并行骨干做快速初稿再用轻量级GRU编码器把因果信息以修正量的形式补回来兼顾了速度和准确率。Q3基础锚定课程训练策略解决了什么问题A在教师强制训练中因果修正分支拿到干净的正确前缀后很容易抢功导致并行骨干的基础预测退化。基础锚定课程通过动态调整损失权重训练初期强制骨干先把基础预测学好后期再逐步让修正分支发挥作用避免了骨干崩溃最终接受长度比单纯教师强制又提升了约5.8%。