先让实习生一口气写十句，再让主编一次性圈出哪几句能用。

像实习生起草，主编定稿

模型生成文字的方式是自左向右的——算出第一个词，用它当输入再算第二个，算完第二个再算第三个。生成 100 个词元，就是把整个大模型跑 100 遍。

慢就慢在这儿：每一步都得等上一步算完。哪怕显卡一次能同时算一百个位置，它也只被要求算一个。

这两年生成速度的大新闻，全都在攻这个「串行」。

推测解码（speculative decoding）——先用一个更快的小模型连猜好几个词元，再让大模型一次性把这几个一起验一遍。猜对几个就采纳几个，一步顶几步。

关键是：答案不变

这是我第一次读论文时最不敢信的地方，也是这套方法能落地的原因。

不是「差不多一样」，是采样分布完全一样。同样一个问题，同样的随机种子，输出和不开这个功能时一模一样。

做法上有个反直觉的细节：小模型不只负责猜，还负责报自己的信心。大模型验的时候，如果某一步的接受概率不等于 1，就不直接采信，而是从一个大模型和一个小模型混合出来的分布里重抽，把这个偏差补回去。

听起来像多此一举。为什么要费这么大劲保分布不变？因为一旦输出会变，你就没法拿它做翻译、做代码补全、做需要可复现结果的事。工程上这叫「免费的加速」。

快多少，取决于猜得准不准

加速倍数直接等于小模型草稿的接受率。猜得越准越快。

论文里 DeepSeek-V3 的技术报告给了个实测数字：平均吞吐提升 1.8 到 2 倍。听起来一般，但这已经是在真实生产负载上了。

那篇最早提出这个思路的论文（Leviathan 那篇）报的数字更高，在他们的设定里能到两到三倍。不过这类数字很吃场景，取决于草稿长度、批处理（batching）大小、硬件 —— 一次塞给模型多少条请求。换一批任务完全可能只有 1.3 倍。

我自己试过一次，效果比论文里温和。中文比英文慢，一个原因是小模型对中文的草稿质量明显差。我不确定这是普遍现象还是我选的草稿模型不对。

后来分成了两大派

草稿派。配一个小模型专门起草。上面那篇就是这个思路。好处是小模型可以选得很难用也没关系，只要比大模型快就行。

自推测派。不要额外模型，直接拿大模型自己的某些层当草稿机。比如 LayerSkip 那篇，提前退出前几层来生成草稿。2026 年 5 月一篇讲混合架构的论文给出了很直白的对比：内部自推测在结构是「并列混合」的模型上，草稿接受率能到 0.68；在「交错堆叠」的模型上只有 0.038，差了 18 倍。同一篇里还说了一句我挺认的判断——决定自推测能不能用的，是组件怎么组合，不是有没有备用的组件。

这个方向还在动。谁赢我不敢说。

延伸阅读

• Fast Inference from Transformers via Speculative Decoding（Yaniv Leviathan、Matan Kalman、Yossi Matias，2022，arXiv 预印本）—— Google 那三位。摘要里最直接的一句是「生成 K 个词元需要把模型串行跑 K 次」。他们提出的办法是让快模型起草、慢模型验证，并且发明了一种采样方法把分布差异补回来。arXiv: 2211.17192

• Speculative Decoding: Exploiting Speculative Execution for Accelerating Seq2seq Generation（Heming Xia、Tao Ge、Peiyi Wang et al.，2022，arXiv 预印本）—— 同期另一组人，把「投机执行」这个 CPU 里的老词直接搬过来了：小模型是提前跑、可以扔掉的投机执行，大模型是必须跑的主程序。他们报的是在翻译和摘要任务上约 5 倍，并且说这个结果推翻了一个此前的印象——大家原以为这套只能快 1.4 到 2 倍。代码在 GitHub 上公开了。arXiv: 2203.16487

动手试试

不用写代码也能看出这条路的形状。

在 transformers 的文档里搜「speculative decoding」，那一页有完整的最小示例：给定一个大模型和一个小模型，Assistant 循环里先让小模型连出草稿，再让大模型验。整段不到三十行。

跑通之后改一个数：把草稿长度从 4 改成 12，再改成 1。1 是「关掉加速」的极端情况，12 是在浪费。中间某个位置会最快——那个位置就是你这台机器上这个任务的最优草稿长度。

我第一次试的时候把长度拉到 12，反而比默认的 4 慢了一倍多。这件事不意外，但我当时确实没料到。

下一站

生成快了，可模型每写一个词，前面那一大段还得重新算一遍。这笔重复劳动，比串行本身还贵。