当你是 LLM 时，没有什么是容易的：平坦延迟问题

人类走到厨房时几乎不需要费力，但解微分方程会消耗大量能量。人的能量消耗与任务难度成正比，大语言模型却恰恰相反：无论被问到“法国的首都是哪里”，还是要求解释量子计算的最新进展，模型生成每个 token 的代价都完全一样——每次都执行一次完整的前向传播，遍历所有层、注意力头和权重。预测“Paris”和“Qubit”在计算上是完全相同的事件。这不是效率问题，而是架构本身决定的，而这一特性渗透在人类与 LLM 的每一次交互中。

由于计算量完全均匀，模型在生成代码时也会出现荒诞的浪费：比如生成 Python 函数，在“for i in range(len(my_list”之后，下一个闭括号几乎是确定性的，任何在 GitHub 代码上训练过的模型都能以接近 100% 的概率预测到。但模型仍然要为这个闭括号、后面的冒号、换行和缩进等每个语法 token 支付全量的前沿模型计算成本。真正决定逻辑走向的关键 token 也只有同样的价格。在多智能体系统中，问题进一步放大：每个智能体都在为每一个 token 支付完整的模型成本，包括那些根本不需要前沿模型参与的简单 token。这就是所谓的“平坦延迟”问题，它无法通过堆硬件解决。

投机解码提供了一条混合路线。一个小而廉价的草稿模型先快速生成 K 个 token，大型验证模型再通过一次并行前向传播检查全部 K 个 token——不是 K 次，而是一次。如果草稿 token 与验证模型本应生成的内容一致，就相当于用一次验证的成本产出了 K 个 token。如果第 N 个 token 开始分叉，就接受前 N-1 个，用验证模型的修正 token 替换第 N 个，然后丢弃剩余草稿并继续。最终输出永远等于大型模型单独生成的结果，草稿模型不会污染输出质量。关键限制是草稿模型必须足够快且足够准：如果 10 个 token 能猜对 7 个，加速效果会非常明显；如果接受率低于约 60%，多跑一个模型只会增加复杂度，却换不回延迟收益。

投机解码本身并非新概念，HuggingFace 中早已支持，技术上只需要在 generate() 里传入一个 assistant_model 参数。真正的难点在于草稿模型的配对：草稿模型和验证模型必须共享同样的分词器和输出分布，实际只能使用同系列模型，或者验证模型自身的蒸馏/量化版本。选错配对，接受率就会崩溃，等于同时跑两个模型却没有收益。大多数组合都不适用，所以大多数团队选择放弃。Gemma 4 改变了这个局面。它内置的 MTP（多 token 预测）草稿器不是外挂的独立模型，而是直接训练进架构的预测头。它共享主模型的 KV 缓存和激活值，不需要重新计算已有上下文，因此无论是操作上还是架构上都远比 DIY 配对更高效。无需寻找兼容模型，没有分布漂移，也不必额外维护第二个模型，输出质量零下降的同时推理速度最高可提升 3 倍。

在作者看来，平坦延迟是所有 transformer 架构 LLM 与生俱来的结构性问题，投机解码是当前最具意义的体系性答案。Gemma 4 则是第一个把这种能力作为原生特性广泛交付的模型，而不是需要用户自行拼装的实验项目。不过这只是第一步，更深层的挑战——如何让模型根据任务实际难度动态分配算力——仍然悬而未决。游戏还没有结束，只是刚刚变得有趣。