加速AI思考：UC San Diego等机构研究出让大模型"一心多用"的推测解码新方法

这项由加州大学圣地亚哥分校、浙江大学、伊利诺伊大学厄巴纳-香槟分校、南京大学和StepFun联合开展的研究，以预印本形式于2026年6月25日发布，论文编号为arXiv:2606.18394v3，感兴趣的读者可通过该编号查询完整论文。

你有没有在餐厅等过一个特别慢的厨师？明明点了五道菜，但厨师坚持做完第一道才动手第二道，中间还要反复确认每个步骤。这就是今天大多数AI大模型在生成文字时的工作方式——一个字一个字地往外蹦，每次出一个字之前都要把整个"厨房"运转一遍。对于动辄写出几千字数学证明或者代码的现代AI来说，这种逐字生成的方式正在成为制约速度的最大瓶颈。

研究团队提出的JETSPEC方法，本质上是给这位慢厨师配了一个"助手"，而且这个助手不是随便乱猜菜单的那种，而是真正懂得整道菜的烹饪逻辑、能提前把最可能用到的食材准备好的聪明帮手。

一、"先猜后验"：AI加速的聪明捷径

要理解JETSPEC解决的问题，先要弄清楚现有的加速思路。现代大模型生成文字的过程，可以用餐厅出菜来类比：主厨（目标模型）每次只能确定一道工序，确定之后才能启动下一步。这个过程很精准，但很慢。

所谓"推测解码"（Speculative Decoding），就是在主厨身边安排一个助理厨师。助理先快速猜出接下来几步的操作，比如"接下来可能要加盐、翻炒、出锅"，然后把这串猜测一次性递给主厨检验。主厨只需扫一眼，确认哪些步骤猜对了，哪些猜错了。猜对的直接采用，从猜错的那步重新接手。由于主厨"一次验多个"的速度几乎和"一次验一个"一样快，只要助理猜得够准，整体效率就能大幅提升。

这个方法听起来很美妙，但藏着一个微妙的数学约束：助理猜的序列越长，猜对全部的概率就越低。假设助理每个位置猜对的概率是85%，连续猜对16个位置的概率只有8%左右。而且，如果助理自己运行一次也要花不少时间，那增加猜测长度带来的好处就会被助理的运行开销抵消掉。这就是研究团队所说的"规模化天花板"——推测解码的加速效果很难随着猜测长度的增加而持续提升。

研究团队给出了一个精确的数学公式来描述加速效果。设定每个位置的平均猜对率为α，助理每生成一个词的时间占主厨的比例为c，猜测长度为N，那么加速比大约等于"猜对词数之和"除以"助理总耗时加上一次主厨验证时间"。这个公式揭示了两个关键：第一，要让更长的猜测真正有用，就必须让每个位置的猜对率α保持高水平；第二，助理的每词开销c必须足够低。两者缺一不可，只改善其中一个往往会顾此失彼。

二、现有方法的两难困境：快而不准，还是准而不快

既然问题这么清晰，为什么之前的方法没能彻底解决？这里有一个根本性的矛盾，研究团队称之为"因果性与效率的两难困境"。

先说一种叫EAGLE的方法，它是一种"自回归助理"，也就是说助理生成第二个词的时候，已经知道自己刚才生成的第一个词是什么，所以能够基于前面的猜测来推断后面的猜测。这就像一个厨师助理，每决定下一步操作时都会先看看前一步做出来的效果，决策很连贯、很准确。但问题是，他每次只能做完一步才能开始想下一步，猜测序列越长，他花的时间就越多。

再说另一种叫DFlash的方法，它走的是完全不同的路。DFlash的助理不是一步步来的，而是"一口气"同时决定所有位置要填什么词，就像一个厨师直接扫一眼菜谱，同时给所有空白处填上答案。这种方式非常快，每个词的生成开销极低。但问题在于，这个助理在猜第二个词的时候，根本不知道自己刚刚在第一个位置猜了什么，所以第一个词和第二个词之间可能完全对不上。比如第一个位置猜了"given"，第二个位置猜了"told"，连在一起就成了"given told"，语义上完全讲不通，但在助理的评分体系里看起来很合理，因为每个词单独看都是高频词。

这个问题在研究团队的实验里有一个生动的案例。在一道数学题的第一步，DFlash的助理把"given told that"排在候选列表第一位，这三个词组合起来的目标模型真实概率是e的负63次方，几乎等于零，完全不可能出现在任何正常句子里。但助理的评分体系给它打了很高的分，因为它把每个位置的词单独评分再相乘，没有考虑前后词之间的依存关系。真正合理的"are given that the"虽然在候选列表里，但排在第三位，被淹没在一堆听起来"每个词都不错"但放在一起就驴唇不对马嘴的组合里。

三、JETSPEC的解法：一次出手，全程自洽

JETSPEC的核心创新，是在"一口气预测多个位置"的同时，保证每个后续位置的预测都基于同一条分支上已经确定的前序词。研究团队用的比喻是"树形候选"——助理不是猜一条线，而是同时猜出一棵分叉的树，每条从根到叶的路径都是一个完整的候选序列，而且每条路径内部的词与词之间，后面的词是"看着前面的词"被预测出来的。

具体实现上，JETSPEC训练了一个带有"树形因果注意力掩码"的草稿头。听起来很复杂，但原理其实很直观：在处理树上某个节点（也就是某个候选词）时，这个节点只能"看到"它在这条路径上的祖先节点，看不到兄弟分支的内容，也看不到它自己的后代。这样，每条路径内部的词依然保持着"后词依赖前词"的自然逻辑，就像读一篇完整的句子；而不同分支之间彼此独立，可以并行计算。整棵树上所有候选词的预测，通过一次前向传播就全部完成了，不需要像EAGLE那样逐步迭代。

更重要的是，JETSPEC并不是从零开始训练一个全新的助理，而是从主厨（目标模型）的中间层提取丰富的隐藏状态特征，把这些特征注入草稿头的计算过程中。对于Qwen3-8B这个目标模型，JETSPEC会从第1、9、17、25、33层分别提取隐藏状态，把它们拼接起来再压缩，作为草稿头的"情报来源"。这样草稿头虽然自身轻量，但每次预测都能借鉴主厨的大量先验知识，预测质量大幅提升。

在候选树构建完成后，主厨只需一次并行前向传播就能同时验证树上所有候选路径，沿着每条路径找到最长的连续接受前缀，最终采用接受长度最长的那条路径，继续下一轮。

四、训练方式：用"正确答案的分布"而非"正确答案本身"来教导助理

JETSPEC的训练过程有一个值得关注的细节：训练目标不是让助理猜出和主厨一模一样的答案，而是让助理猜出的概率分布尽量接近主厨的概率分布。

这里涉及两种不同的"距离度量"方式。研究团队测试了三种：第一种是直接监督微调，也就是告诉助理"正确答案是X，你猜错了就扣分"；第二种是前向KL散度，也就是让助理的概率分布尽量覆盖主厨认为可能的所有选项；第三种是反向KL散度，也就是让助理专注于主厨最确信的那几个高概率选项，忽略低概率的长尾。

实验结果非常清晰：直接监督和前向KL效果相当，而反向KL的表现要差得多，在MATH-500上相比前向KL下降了36%到46%。原因在于，树形推测解码需要助理对多条可能的路径都有合理的评分，如果助理只会押注在最可能的那几个词上，树上其他分支的评分就会严重失准，整棵候选树的质量就会大打折扣。前向KL通过保留主厨对所有词的相对偏好，让助理能够构建出更合理的多分支候选树。

训练数据的选择也有讲究。研究团队从NVIDIA的Nemotron后训练数据集V2中精选了78万条样本，涵盖编程、数学、STEM以及对话数据，并且让目标模型本身重新生成这些样本的续写内容，用目标模型自己生成的文本来训练草稿头。对比实验显示，使用目标模型再生成的数据比直接使用原始语料的效果强得多，即使是在同样的78万样本规模下，再生成版本在所有基准上的加速比均大幅领先。这说明草稿头必须学会模拟的是"这个特定主厨的思维方式"，而不是泛泛的语言统计规律。

五、树的建造：如何在有限预算里选最值得猜的分支

有了能产生可靠候选树的草稿头，下一个问题是：在固定的节点数预算内，应该怎么展开这棵树才能最大化被主厨接受的概率？

JETSPEC采用一种"最优先扩展"策略，用一个优先队列来管理候选节点。每个节点的优先级由该节点所在路径的累积对数概率决定——简单说就是这条路径上所有词的概率取对数后相加，值越大说明这条路径越可信。算法每次从队列里弹出分数最高的可扩展节点，给它生出最多W个子节点（W是分叉宽度），然后把这些子节点加入队列，继续下一轮扩展，直到总节点数达到预算上限B为止。

研究团队还测试了其他评分方式，比如用"每个位置的信息熵"作为优先级，或者把累积概率和熵加权混合。结果显示，纯熵评分会导致加速比从8.15倍暴跌到4.76倍，损失将近一半；而混合评分在低权重时与纯累积概率接近，但随着熵的权重增大，效果单调下降。这说明候选树的质量最终取决于哪些路径更可能被主厨接受，而累积概率恰好是对这个可能性最直接的估计。

六、实验结果：从理论跳入现实的速度飞跃

研究团队在Qwen3-8B和Qwen3-30B-A3B两个模型上做了系统评测，覆盖数学（GSM8K、MATH-500、AIME25）、编程（HumanEval、MBPP、LiveCodeBench）以及开放对话（MT-Bench）七个基准，并与EAGLE-3和DFlash两个强基线进行了对比，所有方法使用相同的训练数据和超参数。

在低预算场景（只猜16个词）下，JETSPEC和DFlash表现几乎持平，两者都大幅领先EAGLE-3。这说明当猜测数量很少时，是否保持因果连贯性差异不明显，因为短序列的分支结构还不够复杂。然而当预算增加到32个词时，DFlash的加速比在多个基准上开始停滞甚至下降，而JETSPEC继续提升。这个分歧正是"分支一致性"开始发挥决定性作用的拐点。

在高预算场景（256个词）下，差距变得非常显著。在MATH-500上，JETSPEC的加速比达到9.64倍，平均每轮接受长度τ为10.76个词，而DDTree（DFlash的树形版本）是8.78倍、τ=9.81，EAGLE-3只有2.36倍。在GSM8K、AIME25、HumanEval、MBPP、LiveCodeBench上，JETSPEC同样全面领先DDTree，幅度从5%到15%不等。即使在更难的开放对话任务MT-Bench上，JETSPEC也达到了4.58倍加速、τ=5.94，而DDTree是4.26倍。

在非贪心解码（温度为1的随机采样）设置下，所有方法的加速比均有所下降，但JETSPEC与DDTree的相对差距依然保持稳定，说明因果树结构带来的优势不依赖于确定性解码假设。

在MoE架构的Qwen3-30B-A3B模型上，JETSPEC同样优于DDTree：MATH-500达到9.45倍对8.61倍，AIME25达到9.35倍对9.01倍，其他基准上也保持类似优势。这表明JETSPEC的方法不依赖于特定的模型架构，泛化能力良好。

七、接近真实部署：在vLLM服务引擎中的表现

实验室里的加速比固然好看，但真实的AI服务场景要复杂得多。研究团队把JETSPEC集成进了vLLM这个工业级推理引擎，并在不同并发请求数下进行了评测。

集成本身并不简单。树形验证要求注意力机制能够处理非线性的父子关系，而标准的分页注意力（Paged Attention）是为线性序列设计的。研究团队开发了一个自定义的SM90架构分页树注意力核，使用NVIDIA CuTe DSL实现，通过共享内存进行树形掩码暂存和树尾掩码处理，让树形验证可以在不展开成密集掩码矩阵的情况下高效完成。

在单H100 GPU的Math-500评测中，当批次大小为1时，把树预算从16增加到128，吞吐量从每秒224个词提升到553个词，加速比从1.75倍升到4.33倍；继续增加到256个词预算时，不同基准下最高可达6.75倍。但随着批次大小增加，大预算的优势逐渐收窄：在批次大小16时，预算256的加速比降至4.51倍，几乎与预算128持平。到批次大小32时，两者都接近3倍，差距进一步缩小。

这个规律揭示了一个实用原则：在请求量少、GPU相对空闲时，大预算能充分利用计算资源减少验证轮次；而当请求量大、GPU已经很忙时，大预算带来的额外验证开销和内存压力会抵消增加接受长度的收益，此时中等预算反而更合适。研究团队指出，未来可以根据服务负载动态调整预算，这将是一个值得探索的方向。

八、细节决定成败：关键参数的逐一验证

为了确认JETSPEC的每个设计选择都是必要的，研究团队进行了多组对照实验。

在学习率方面，从0.00005到0.001的五个设置中，0.0003和0.0006表现最好（MATH-500加速比分别为8.30倍和8.23倍），过低学习率欠拟合，过高学习率轻微下降但仍在0.02以内。

在架构层面，最关键的对比是"因果头"与"扩散头"在不同γ值下的表现。γ是DFlash训练目标里的一个参数，用来控制位置越靠后的词在训练损失中的权重衰减速度——γ=0表示所有位置等权重，γ越大表示越靠前的位置权重越高。对于扩散头来说，γ的选取极为敏感：γ=7时达到最佳的8.36倍，但γ=0时只有5.46倍，γ=15时也跌到6.17倍，两端都崩了。而因果头对γ完全不敏感：从γ=0的8.29倍到γ=3的8.50倍，再到γ=7的8.40倍、γ=15的8.41倍，波动不超过3%。这个对比表明，因果掩码从结构上保证了分支一致性，使得训练不再依赖于权重衰减这个"外部拐杖"。

从50道MATH-500题目的第一步候选树分析来看，扩散头在γ=0时有26%的题目出现了"排名第一的候选路径概率接近零"的极端失败，而因果头这个比例是0%；扩散头排名第一的路径平均"分数虚高"（代理评分与目标模型真实对数概率的差值）为+62.81 nat，因果头只有+12.36 nat，约为前者的五分之一。这些数字直接对应到了宏观上1.52倍的加速比差距（9.46个词对4.84个词的平均接受长度）。

说到底，JETSPEC证明了一件并不显然的事：在"一次性预测多个词"的快速草稿生成框架里，保留词与词之间的因果依存关系，并不需要付出逐步迭代的时间代价。通过树形因果掩码和冻结目标模型的特征注入，JETSPEC在一次前向传播里同时实现了快（低每词开销）和准（高分支一致性），打破了之前认为这两者无法兼得的假设。

对于普通用户来说，这意味着你和AI对话、让AI做数学题、写代码的等待时间有望大幅缩短，而且缩短的幅度会随着任务越难、生成越长而越明显——因为正是在这些场景下，JETSPEC的加速比能够发挥到极致。从2.72倍到9.64倍的跨越，背后是一个关于"智慧助理如何真正理解主厨意图"的精妙设计。

这项研究目前以预印本形式公开，完整代码和模型已在GitHub发布，感兴趣的读者可通过arXiv编号2606.18394查阅论文全文，进一步了解实现细节和更多实验数据。

Q&A

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

A：推测解码是一种让AI生成加速的技术：先用一个轻量助理模型快速猜出接下来多个词，再让主模型一次性并行验证这些猜测，接受猜对的部分、从猜错处重新接手。由于主模型"一次验多个"几乎和"验一个"一样快，只要猜得够准，整体速度就能大幅提升。

Q2：JETSPEC和DFlash的主要区别是什么？

A：两者都能一次性预测多个候选词，但DFlash的各位置预测相互独立，不知道同一序列里其他位置猜了什么，导致组合起来的句子可能语义不通。JETSPEC通过树形因果注意力掩码，让后续位置的预测"看着"同一路径上前面的词，保证每条候选路径内部逻辑自洽，验证时被主模型接受的概率更高。

Q3：JETSPEC在实际服务中适合什么场景？

A：JETSPEC在请求量少、GPU相对空闲时效果最显著，可以用大预算（如128或256个词）大幅减少验证轮次，加速比可超过6倍。当并发请求增多、GPU负载上升时，建议使用中等预算，避免验证开销抵消收益。数学推理和代码生成等长输出任务的收益尤为突出。