让AI猜词的时候，猜不中第一个也没关系：给并行草稿装上一个「候选词修正器」

你有没有玩过那种接龙游戏，几个人同时写下自己猜的下一个词，然后拼在一起才发现根本连不成句子？

这其实就是现在大模型加速技术里正在发生的事情。

先说说为什么大模型说话这么慢。你跟ChatGPT聊天的时候，它是一个字一个字蹦出来的，这背后的原理是，大模型每生成一个词，都要把前面所有的内容重新过一遍自己的神经网络，算出下一个词是什么，再把这个词加进去，继续算下一个。这个过程像蚂蚁搬家，一次搬一粒米，稳当但是慢。

于是研究者们发明了一个取巧的办法，叫投机采样

**投机采样**：先用一个小而快的模型（草稿模型）猜出接下来可能的好几个词，再让大模型一次性检查这些猜测对不对，对的就直接采用，省去逐字计算的时间。

这个办法聪明在哪？大模型做检查这件事，可以把好几个词放在一起同时算，而不用一个一个算，这比它自己从零生成快得多。只要草稿模型猜得准，大模型就能一次吞下好几个词，省下大把时间。问题是，草稿模型从哪来，猜得准不准，直接决定了这套办法到底能省多少时间。

早期的草稿模型是个独立的小语言模型，一个字一个字往后猜，这样猜的好处是每一步都知道前面猜的是什么，猜得比较连贯，但慢的问题还是没根本解决，猜十个词也要算十次。后来出现了EAGLE这类方法，让草稿模型直接借用大模型的内部特征来猜词，猜得更准了，但本质上还是一步一步往后猜，没有摆脱这个"排队"的毛病。

真正的突破出现在最近，有一类叫做扩散草稿模型的方法，代表是DFlash，它干了一件很大胆的事：一次性把接下来十几个词全部猜出来，不用排队，并行计算。这就像一个法院开庭审案子，与其一个证人一个证人问话，不如把所有相关的人同时请进来，一轮问完。效率一下子提上来了。

但代价也随之而来。

这十几个词是同时猜出来的，意味着猜第五个词的时候，草稿模型根本不知道第四个词最终会被定成什么样子。这就好比几个人同时写接龙，谁也不知道别人写了啥，拼起来经常对不上。论文里举了个很形象的例子，模型可能同时觉得"纽约"和"圣地亚哥"都有道理，结果一不小心拼出"纽地亚哥"这种四不像的词。单独看每个词都挑得挺合理，拼在一起却乱了套。

这就是这篇论文要解决的核心矛盾：并行猜词快，但猜出来的词互相不搭；一个一个猜能保证连贯，但慢。鱼和熊掌，能不能都要？

草稿模型其实没那么笨，它只是没选对

在动手之前，研究者们先做了个很扎实的调查。他们想知道，草稿模型猜错的时候，是真的完全没想到正确答案，还是说正确答案其实就在候选名单里，只是没被排在第一名？

结果让人意外。

他们检查了Qwen3-8B这个模型，发现当草稿模型的首选猜错的时候，有59%的情况下，正确答案其实就藏在它给出的前16个候选词里面。换句话说，草稿模型大部分时候不是没猜到，而是没把猜到的那个词排到第一名

更细致的数据显示，这个现象越往后越明显。在一整块猜测里，第一个位置上，草稿模型的首选和前16候选覆盖率差距只有12%到14%，但到了这一块的最后一个位置，这个差距飙升到38%到45%。也就是说，猜得越靠后，草稿模型越容易"选错favorite"，但候选名单里其实一直都有正确答案在等着。

这个发现特别关键，因为它改变了问题的性质。

如果草稿模型真的不知道正确答案，那你能做的只有重新训练一个更聪明的模型，这个工程量很大，也不一定管用。但如果正确答案一直都在候选名单里，只是没被选中，那问题就变成了一个重新挑选的问题，而不是重新生成的问题。这个思路上的转变，决定了后面整个方法的设计方向。

打个比方，这就像一个学生做选择题，ABCD四个选项里他本来心里有数，正确答案往往就在他考虑过的几个选项里，只是最后涂卡的时候手一抖涂错了。如果你发现这个规律，你要做的不是重新给他补课，而是帮他在涂卡前多核对一下自己的几个候选项,看看哪个更站得住脚。如果你选择重新补课这条路，意味着要花大量时间从头教，而核对候选项这条路，几乎不需要额外的大动作，立刻就能见效。这个代价上的差异，正是这篇论文选择"重新挑选"而不是"重新生成"的根本原因。

同时，研究者还发现了另一个重要的结构性事实。

大模型检查草稿的时候,是从前往后一个一个看的，只要遇到第一个不满意的词，后面所有的词无论多好都直接被扔掉，不会被看到。这意味着，如果你把力气都花在改善第十个词的质量上，而第一个词还是错的，那第十个词的改善根本没有意义，因为检查根本不会走到那里。

这就像面试官看简历，一旦看到第一条工作经历就觉得不靠谱，直接pass，后面写得再精彩的项目经历，面试官压根不会往下翻。所以简历的开头几行，重要性要远远高于后面的内容。如果求职者把精力都放在美化简历末尾的细节，而开头漏洞百出，那所有后面的努力都是白费的。这也正是为什么这篇论文最后设计选词策略时，坚持要"从前往后，一步一步来"，而不是看整体打分哪个方案最高。

DCOCO：给候选词搭一个评分擦子

基于上面两个发现，研究者设计了一个叫DCOCO的修正模块，全称是DFlash Contextual Corrector，意思是"给DFlash用的上下文修正器"。

**DCOCO**：一种轻量级的修正机制，它不改变草稿模型并行生成候选词的方式，而是在候选词定下来之后，重新打分、重新挑选，让挑选过程考虑到相邻位置之间的搭配关系。

它的核心思路可以拆成两步。

第一步，给每个位置保留多个候选词，而不是直接拍板用第一名。每个位置原来只能看到自己的首选，现在变成保留前16个候选，这16个词连同它们各自的打分和模型内部状态，一起留着备用。

第二步，给相邻两个位置的候选词之间打一个"搭配分"，衡量它们放在一起到底顺不顺。比如第一个位置的候选是"这把"和"钥匙"，第二个位置的候选是"钥匙"和"锁头"，那"这把钥匙"这个组合就应该打分更高，"这把锁头"这个组合打分就要低一些。这个打分不是凭空算的，而是用草稿模型本身已经产出的隐藏状态和候选词身份信息，喂给一个很小的神经网络去计算。

这里有个很巧妙的设计，所有这些搭配分是一次性批量算完的，不需要再让草稿模型跑一遍。这就好比一场晚会上，所有嘉宾提前把自己准备讲的内容交上来，主持人一次性把所有可能的搭配顺序都列出来，并打好分，而不是一个嘉宾讲完才决定下一个嘉宾讲什么。前者可以提前并行准备好，后者就得临时等待，一个一个来。如果采用后者的方式，相当于每次挑选都要重新等一轮计算，这正是DSpark和Domino这两个同类方法的做法，它们都引入了一个要一步一步跑的修正模块，这个模块跑在每一轮猜词的关键链路上，拖慢了整体速度。DCOCO选择把打分这件事提前做完、一次做完，就是为了避开这个"等待"的代价。

打分做完之后，就到了挑选阶段。前面说过,检查是从前往后进行的，第一个词错了后面全部作废。所以DCOCO的挑选规则也是从前往后：第一个位置先用草稿模型自己的首选，然后从第二个位置开始，每一步都看"跟上一个选定的词搭配起来，哪个候选分最高"，就选哪个。这个规则论文里叫**前缀优先的贪心选择**。

**贪心选择**：每一步只根据当前已经确定的前面结果，挑出当下最优的选项，不去提前权衡后面可能发生的变化。

研究者还试过另一种更"全局"的选词方式，叫做对整条路径的总分求和，挑总分最高的那条路径。听起来似乎更合理，因为它综合考虑了整条链路的得分。但实验结果显示，这种全局求和的方式反而效果更差，准确接受的词数更少，速度也更慢。原因还是回到那个检查规则,后面位置的高分如果要靠前面位置的低分来凑，这个高分压根没机会被用上,因为检查早就在前面被打断了。这就像一场接力赛，你不能让第四棒跑得特别快来弥补第一棒摔倒的损失，比赛规则是摔倒了直接取消成绩，第四棒跑多快都没用。

这个模块设计得足够小巧，整个打分网络只有两百多万个参数，而且不需要给草稿模型增加一次额外的运算，几乎是"白捡"的收益。初始状态下，这个修正模块是不起作用的，它的输出层被初始化为零，这意味着刚开始训练时，它完全不会改变草稿模型原本的选择，相当于一个全新的学生刚上岗，先原样复述老师教的内容，然后在训练过程中慢慢学会独立判断。

实验结果：全面跑赢的加速效果

研究者在四种不同的大模型骨架上做了测试，包括Qwen3的4B、8B版本，Qwen3-Coder的30B版本，还有Llama-3.1的8B版本。测试覆盖了数学题、代码题和一般对话这十个评测集，既有确定性的贪心解码，也有带随机性的采样解码，还分别测了开启和关闭"深度思考"模式的情况。

结果是，在所有这些配置里，DCOCO的平均吞吐量都是最高的。

拿Qwen3-8B不开思考模式的情况来说，跟原始的朴素解码相比，DCOCO在数学和代码任务上能跑到3.7倍到6.1倍的速度,在日常对话类任务上也有1.8到1.9倍的提速。跟同类的修正方法比，DCOCO比表现最好的竞争对手Domino还要再快14.3%左右。如果看整体十个测试集的平均成绩，DCOCO在十二种不同的模型和模式组合里，全部拿到了最高的加速比，领先幅度在8%到19%之间。

更有意思的是在并发场景下的表现。

真实的服务场景里，一台机器往往同时处理好几十个用户的请求，这叫并发。随着并发数从4涨到32，DFlash本身的速度优势会被摊薄，因为大家都在抢计算资源。这时候，DCOCO跟Domino、DSpark这两个同类修正方法比起来，表现出了完全不同的走势。

Domino和DSpark都是"一步一步算"的修正方式，并发压力一上来，它们额外花的计算时间就被放大了，最后甚至比完全不用修正的DFlash还慢。而DCOCO因为打分过程是一次性并行完成的，不管并发多高，它额外付出的时间成本都基本稳定。数据显示，在32个并发请求的情况下，DCOCO比最强的竞争对手还要快19%到23%，而Domino和DSpark这时候已经掉到比原始DFlash更慢了。

这就好比一个餐厅，服务员如果是一个一个顾客轮流去后厨跟厨师核对订单细节,人多了以后这个核对过程就会排起长队,越忙越慢。而DCOCO更像是提前把所有可能的菜品搭配表打印好贴在墙上，服务员扫一眼就知道怎么搭配,不管来多少顾客，这张表都不需要重新制作，核对的时间几乎不随顾客数量增加而变长。如果餐厅选择前一种方式，意味着高峰期反而成了最慢的时候，这正是Domino和DSpark在高并发下翻车的原因。

论文里还做了拆解实验，验证修正模块里的两个关键信息来源到底有没有用。去掉其中一个叫"位置对状态"的信息通道，接受长度掉了7.3%；去掉候选词自身的表示信息，接受长度掉了4.8%。两个都挺重要，缺一个都不行。研究者还试过把草稿模型本身冻住不训练，只单独训练修正模块,这样仍然比完全不用修正模块好4.4%,但远不如两者一起联合训练的效果好，联合训练能再多拿到约15%的提升。

写在后面

读完这篇论文,最让我意外的其实是那个59%的数字。

我们总觉得模型"猜错"是因为它不够聪明,但这篇论文告诉你,很多时候模型根本不是不知道答案,而是不知道该把答案排在第一名。这个发现挺有意思,因为它把一个看起来是"能力"问题的东西,拆解成了"排序"问题,而排序问题往往比能力问题好解决得多。

这也让我想到一个更大的问题,我们在评价一个模型"错没错"的时候,是不是经常只看它的第一名答案,而忽略了它整个候选名单里到底藏着什么？如果换个角度去看模型的候选分布,可能会发现很多所谓的"错误"其实没有那么离谱。

另一个值得琢磨的地方是,这篇论文反复强调的那个前缀优先原则,其实是在提醒我们,很多系统的瓶颈不在整体质量,而在某个关卡的通过规则。检查是从前往后、一步错步步错的,这个规则一旦确定,所有优化都必须服从它,否则就是在一个错误的目标上做无用功。这种"先搞清楚规则再谈优化"的思路,其实在很多工程问题里都适用,只是容易被忽略。

论文里没有细说的是,如果换一个检查规则,比如允许后面的高分弥补前面的小瑕疵，这个修正模块是不是需要完全重新设计？这个问题留在那儿,挺值得继续想下去的。

Q&A

Q1：DCOCO是什么？

A：DCOCO全称DFlash Contextual Corrector，是一种给并行草稿模型用的轻量级修正机制，它不改变并行猜词的速度优势，而是在候选词定下来后重新打分和挑选，让相邻位置的词搭配更合理，从而提高大模型推理速度。

Q2：DCOCO相比其他同类修正方法有什么优势？

A：DCOCO的打分过程是一次性并行完成的，不需要像Domino、DSpark那样一步一步跑修正模块。这让它在高并发场景下依然保持稳定的加速效果，而其他方法会因为计算排队变得比不用修正还慢。

Q3：为什么草稿模型猜错了，正确答案却经常还在候选名单里？

A：研究发现在Qwen3-8B上，草稿模型首选猜错时有59%的情况正确答案就藏在前16个候选词里，说明问题不是模型不知道答案，而是没把它排到第一名，这也是DCOCO选择重新挑选而非重新生成候选词的原因。