深度与广度抉择：边缘推测解码如何提升大语言模型推理吞吐量？

[←2026年7月2日](/)
[推理 API](https://app.doubleword.ai "Doubleword 推理 API")
这有一个有趣（这里对 "有趣" 有非通用的定义）的面试问题：假设在单 GPU 上以批量大小 111 运行 Qwen3.6 - 35B - A3B，想提高吞吐量，可引擎一次只能处理 222 个 token，有两个选择（假设草稿模型的前向传播免费，无需为批量预填充任何内容，序列足够短，KV 缓存移动无影响）：
1. 将 222 个随机用户序列批量处理，以批量大小 222 运行。
2. 以批量大小 111 运行，提前推测 111 个 token —— 验证时处理 222 个位置，即刚采样的 token 加一个草稿 token，每个 token 接受率为 α。
若只关心每秒输出的 **总** token 数，哪种方法更好呢？
这里有个合理答案：
> 假设一切受内存限制，当 α < 1 时，批量处理总是更好，因为增加批量大小添加到工作集中的 token 不会被拒绝。
但建模时会发现：
> 即便 α = 0.9，将两个位置用于一个推测序列，从全局看，每秒产生的输出 token 比用于批量为 2 的序列更多。
这是为啥呢？

故事一：深度可能比广度更划算

为找答案，得查看数据（数据收集自[上一篇文章](https://fergusfinn.com/blog/adaptive-speculation/)）：两个草稿模型各进行五十万次草稿轮次，记录草稿生成器在每个深度的置信度和实际提交的 token 数量，还分别记录每个 token 路由到的专家 —— 以及 DeepSeek - V4 - Flash 的相同路由记录（所有数据都以 [`specdec - calibration`](https://huggingface.co/datasets/Doubleword/specdec - calibration) 形式发布）。答案就在 Mixture of Experts（MoE）路由，它是大语言模型（LLM）性能分析里比较奇特的部分：数据的语义内容会影响实际执行的工作。原则上，它可能导致一些令人困惑的情况，比如让基于随机数据的基准测试失去代表性。
先看路由专家的经验分布（之前只是假设均匀路由，这涉及[优惠券收集者数学问题](https://fergusfinn.com/blog/economics-of-speculative-decoding/#the - expert - tax)）：
各层平均值：层 0、层 1、层 2……层 39
模型：Qwen3.6 - 35B - A3B、DeepSeek - V4 - Flash
基准测试：HumanEval、SPEED - Bench（所有类别、编码、写作、问答、检索增强生成、数学、推理、STEM、人文、总结、多语言、角色扮演）
结果惊人，分布并不均匀！拟合排名与份额的曲线后发现，它大致随排名呈指数衰减：最繁忙的专家处理的工作量是其应得份额的数倍（不禁想，这里是否存在衡量数据分布的代理指标：在使用专家负载均衡损失进行预训练时，能否根据不同类型数据上专家的均衡程度确定训练数据的分布？）。这种分布会因领域、模型和层的不同而变化。
这本身解释不了什么。但看看决定选择广度还是深度时，两种选择的差异：处理两个随机选择的 token，还是处理两个连续的 token。
随着 N 增长，一次验证前向传播涉及的不同专家数量，有三种情况：N 个独立序列（广度）、一个序列的 N 个连续位置（深度），以及均匀的优惠券收集者情况。
各层平均值：层 0、层 1、层 2……层 39
模型：Qwen3.6 - 35B - A3B、DeepSeek - V4 - Flash
基准测试：HumanEval、SPEED - Bench（所有类别、编码、写作、问答、检索增强生成、数学、推理、STEM、人文、总结、多语言、角色扮演）
答案就在这儿。当批量大小为 1 时，受内存限制，验证一个两个位置的推测运行所移动的专家权重，比添加第二个序列要少。这通过 "共同激活" 实现 —— 推测运行比随机选择的数据更相似，所以会激活更多相同的专家（Josh 在[这里](https://blog.doubleword.ai/moe - expert - coactivations)为批量处理恢复共同激活做了很棒的工作）。即便在 α = 0.9 的情况下丢弃 10% 的推测 token，深度仍优于广度。
不过，这只是个简单问题，思考如何利用这一见解很有意思（在实际引擎中，草稿模型的成本会掩盖这种效果。处理长序列，受 KV 读取限制时，这种效果会再次出现，但同时控制深度和广度来阐述问题就变难了）。实践中，以更大的批量大小运行，专家激活在批量中会达到饱和，这种效果应该会被消除。但 α 损耗不会消失：每个推测的 token 仍有被拒绝的风险。我们必须对每个序列平等承担这种损耗吗？或者能否只在可能有回报的地方使用深度呢？

故事二：我们应该在哪里使用深度

推理引擎运行形成的批量并非同质：有些解码请求比其他请求更易推测。若了解草稿生成器的置信度，就可只在需要的地方使用深度，从而节省草稿生成器（对于像 EAGLE 这样按顺序提出 token 的草稿生成器系统，使用 DFlash 时，无论如何都会得到所有 token）和验证器的计算资源 —— 节省的资源可用于在其他地方进一步推测，或向批量中添加更多序列。
注意
一周前写了这部分框架并进行模拟。结论是，这是个好主意，但不想去实现。然后 DeepSeek 出现了，他们以更复杂的方式实现了这个想法，并在生产环境中用 [DSpark](https://arxiv.org/abs/2602.06036) 进行验证（结果显示吞吐量显著提升，同时表明本文主张的简单置信度校准方法（直接读取对数概率）会使性能有所损失。他们还在 DFlash 风格的草稿生成器中加入因果关系，以提高其生成优质草稿的能力，很有意思）。
第一个问题是，不同序列间被接受的 token 数量差异有多大 —— 若没有差异，就完全不值得这么做。结果发现差异很大。实际提交的 token 数量并非集中在平均值附近：给定一轮中，草稿生成器要么几乎对其生成的所有内容判断正确，要么几乎立即判断错误。轮次分为 "大多错误" 和 "全部正确" 两类（有个问题值得探索：在最大草稿长度处的峰值是否表明模型本可继续生成，但做不到？）：
SPEED - Bench（所有类别、编码、写作、问答、检索增强生成、数学、推理、STEM、人文、总结、多语言、角色扮演）、HumanEval
在整个批量中使用单一固定深度，必须在这两类情况间权衡：深度要足够大，以便在容易的轮次中有所收获；深度又要足够小，以免在几乎所有 token 都会被拒绝的请求上浪费过多验证时间。
实际上，验证器运行前，草稿生成器已对这是哪种轮次有了自己的判断。下面，绘制草稿生成器自身按深度的置信度所暗示的接受长度（即它们的累积乘积之和）与实际提交的总长度的对比图。对角线表示 "完全校准"，即实际接受的 token 与草稿生成器的置信度预测相同。对角线下方表示草稿生成器过于自信；上方表示不够自信。
SPEED - Bench（所有类别、编码、写作、问答、检索增强生成、数学、推理、STEM、人文、总结、多语言、角色扮演）、HumanEval
MTP
DFlash
对角线上有很多蓝色区域，这是可用来改进草稿策略的免费信号。
该如何利用这个信号呢？
根据第 i 轮草稿生成器自身按深度的置信度 $a_k^i$，写出在深度 γ 处预期提交的 token 数量：
$m_i(\gamma) = 1 + \sum_{d=1}^{\gamma} \prod_{k=1}^{d} a_k^i$
同质策略将整个批量限制在一个深度，并使提交的 token 数量相对于 $C(B,\gamma)$（该步骤的实际时间成本，参考[这里](https://fergusfinn.com/blog/adaptive-speculation/)）最大化：
$\gamma^\star = \arg\max_\gamma \frac{\sum_i m_i(\gamma)}{C(B, \gamma\mathbf{1})}$
置信度门控的想法是，由于批量中每个序列都有自己的置信度，所以可以做得更好。对于每个序列的门控，目标是深度向量 $\mathbf{\gamma} = (\gamma_1,\ldots,\gamma_B)$：
$\mathbf{\gamma}^\star = \arg\max_{\mathbf{\gamma}} \frac{\sum_i m_i(\gamma_i)}{C(B, \mathbf{\gamma})}$
因此，每一步根据草稿模型分布下未来 token 的可能性对其适当折扣，求解 $\mathbf{\gamma}$ 向量。实际上，完全求解这个最大值问题非常困难：从实时置信度中选择一个全局的 γ，然后根据截断某个序列是否有利于预期吞吐量，对每个序列进行贪婪修剪。使用这样选择的 $\mathbf{\gamma}$ 运行[模拟](https://github.com/doublewordai/inference - lab)：
相对于最佳同质深度的增益，分三个阶段：从实时置信度中选择一个全局深度、每个序列的（不规则）深度，以及完美校准 —— 即理想情况，策略只生成预先知道会被接受的 token。模拟环境：在 B200 上运行 Qwen3.6 - 35B - A3B，仅进行解码。
MTP —— 不规则验证 + 草稿
DFlash —— 仅不规则验证
单宽度门控 + 不规则宽度 + 完美校准
小批量情况下，增益非常显著，因为专家优惠券收集问题使错误推测的成本很高。随着批量增大，批量平均信号会被冲淡，从置信度中选择的全局 γ 不再优于固定的 γ，因为更大的批量更加异质。然后，在[计算受限的临界点](https://fergusfinn.com/blog/economics - of - speculative - decoding/#the - expert - tax)附近，增益会再次出现，此时只有模型中仍受内存限制的部分进行推测才会有回报。
模拟结果表明，置信度门控推测在不同操作点都能带来实际的吞吐量提升。但问题是，引擎必须支持高效的不规则推测 —— 即在一次验证中使用不同的草稿深度。目前 vLLM 和 SGLang 还不能很好地实现这一点。
所以，该在哪里使用深度的答案是：根据草稿生成器的判断，不均匀地使用深度。

结论

推测解码真的是[你所需要的一切](https://modal.com/blog/spec - is - all - u - need)：推理优化方面，没有什么能与调优良好的推测器带来的吞吐量提升相媲美。
而且这个机会不会消失。现代大语言模型解码时的设计几乎就是为给硬件带来挑战：MoE、注意力机制和自回归采样都限制了充分利用硬件的浮点运算能力。即便训练逻辑表明要构建有足够浮点运算余量的模型，解码时还是会再次遇到[内存墙](https://dl.acm.org/doi/10.1145/216585.216588)[问题](https://newsletter.semianalysis.com/p/the - memory - wall)。
人们对这一点的认识正在迅速加深 —— 快到一周前还可行的想法，如今已经过时了。
关于 Doubleword
Doubleword 是一家推理服务提供商，为开源和定制模型提供高效的推理服务。通过从硬件到推理引擎的全栈优化提高吞吐量，提供了市场上成本较低的 token 服务。这意味着为后台代理、数据处理、批量推理和嵌入提供丰富且经济实惠的 token。
[使用免费额度开始构建→](https://app.doubleword.ai)
你是否有兴趣帮助我们将推理效率提高 100 倍？我们正在招聘 —— 请通过 [careers@doubleword.ai](mailto:careers@doubleword.ai) 联系我们。
引用本文

@misc{doubleword - speculating - on - the - margin, title = {Width vs. depth: speculating on the margin}, author = {Fergus Finn}, year = {2026}, howpublished = {Doubleword Blog}, url = {https://blog.doubleword.ai/speculating - on - the - margin},}

© 2026 Doubleword
[主站](https://doubleword.ai)[RSS](/rss.xml)