“推测即一切”。

在这篇博文中，我们宣布与 Z Lab 联合发布六个最先进的 DFlash 推测器，适用于 @Alibaba_Qwen 3.x。

在 B200 上，Qwen 3.5 122B-A10B 的输出速度超过 1000 tok/s。

阅读博文，了解我们为何全力押注推测解码。

https://t.co/Bv3Zc95Xgh https://t.co/FQ6eWQbhTO

推测即一切 | Modal 博客

来源：https://modal.com/blog/spec-is-all-u-need 我们全力押注推测解码，今天就来聊聊原因。

但首先：我们是 Z Lab (https://modal.com/blog/spec-is-all-u-need#) 的 DFlash (https://modal.com/blog/spec-is-all-u-need#) 草稿模型架构的重度粉丝。正因如此，我们本周发布了针对 Qwen 3.5 397B-A17B (https://huggingface.co/modal-labs/Qwen3.5-397B-A17B-DFlash) 的最先进 DFlash 推测器，并与 SGLang 紧密合作，确保其性能达到世界领先水平 (https://www.lmsys.org/blog/2026-06-15-next-generation-speculative-decoding-dflash-v2/)。

同样出于这个原因，我们与 Z Lab 合作训练了针对 Qwen 系列更多模型的最先进推测器，今天在 Hugging Face 上发布：

• Qwen 3.6 35B-A3B-DFlash (https://huggingface.co/modal-labs/Qwen3.6-35B-A3B-DFlash)
• Qwen 3.5 4B-DFlash (https://huggingface.co/modal-labs/Qwen3.5-4B-DFlash)
• Qwen 3.5 9B-DFlash (https://huggingface.co/modal-labs/Qwen3.5-9B-DFlash)
• Qwen 3.5 27B-DFlash (https://huggingface.co/modal-labs/Qwen3.5-27B-DFlash)
• Qwen 3.5 35B-A3B-DFlash (https://huggingface.co/modal-labs/Qwen3.5-35B-A3B-DFlash)
• Qwen 3.5 122B-A10B-DFlash (https://huggingface.co/modal-labs/Qwen3.5-122B-A10B-DFlash)

在现有 DFlash 推测器的强大基线之上，这些新的草稿模型在多种负载下额外实现了 5% 到 20% 的加速。

这足以在 B200 节点上以并发 1 的情况下，让 Qwen 3.5 122B-A10B 运行在超过 1000 tok/s 的速度。以下是大致效果，对比了无推测时 250 tok/s 的速度，该模拟基于我们的 LLM 工程师手记 (https://modal.com/llm-almanac/) 中的 Token 时间模拟器 (https://modal.com/llm-almanac/token-timing-simulator)：

此外，它们在超长上下文任务（如代理型软件工程）上能更好地保持其接受长度。

下面，我们将解释为何我们看好推测在 LLM 推理加速中的前景——以及它如何成为 AI 应用持续改进循环的一部分。但首先，以下是高层次的要点总结。

首要一点：推测解码是实现高交互性下最先进推理性能时唯一重要的引擎优化。昂贵 CUDA 工程师数日艰苦的内核优化工作 (https://modal.com/blog/flash-attention-4-faster)，或者仔细的性能分析 (https://modal.com/blog/boosting-multimodal-inference-performance-by-greater-than-10-with-a-single-python-dictionary) 与消除主机端瓶颈 (https://modal.com/blog/host-overhead-inference-efficiency)，带来的加速往往只有几个百分点。这是一场苦战，寸步难行。许多推理提供商浪费了大量工程小时来构建包含这些优化的专有引擎。

推测解码能带来大得多的加速——以 2 倍或 3 倍这样的整数因子衡量，而不是 2% 或 3%。下图展示了我们在训练的推测器以及内置 MTP 基线中观察到的加速比，作为推测器质量的函数。如果你对细节感兴趣，可以在 Modal 笔记本 (https://modal.com/notebooks/modal-labs/charles-dev/nb-mFGHBCz7sQT9THdbkx7jat) 中探索数据。

因此，对推测解码的适当支持比其他优化更为重要。开源推理引擎如 SGLang 和 vLLM 已经意识到了这一点，根据我们的经验，它们已经缩小了与专有引擎的差距。推测解码通常也能与推理引擎性能的其他工作相结合。

最后，当推测解码针对应用中的特定领域数据定制时，它能带来真正无与伦比的加速。这意味着推测解码是苦涩教训 (http://www.incompleteideas.net/IncIdeas/BitterLesson.html) 的体现：因为推测解码底层依赖机器学习，当你投入更多数据和算力时，加速效果就会提升——无需顶尖的内核工程师。这意味着它可以跟随硬件、算法、自动研究 (https://modal.com/blog/autoscaling-autoresearch) 和其加速的 AI 应用规模的持续改进指数曲线一同前进。

推测解码对当代自托管推理的成功如此关键，以至于你甚至可以说：推测即一切 (https://en.wikipedia.org/wiki/Attention_Is_All_You_Need)。

什么是推测解码，为什么它如此重要？

简要回顾：推测解码（又称“spec dec”）无损地加速 LLM 推理的“解码”阶段，该阶段根据输入生成输出 token。

这是一个串行操作，因为 Transformer（及类似 Transformer）语言模型是自回归地生成输出 token——基于自身输出。

推测解码通过传入由另一个系统（推测器，又称“起草器”或“草稿模型”）生成的一组 token，将这种串行工作转化为并行工作。目标模型可以并行处理这些 token，就像模型并行处理输入 token 一样（在“预填充阶段”）。

目标模型计算这些 token 的自身输出概率，并应用重采样技术（通常是顺序拒绝采样 (https://bookdown.org/rdpeng/advstatcomp/rejection-sampling.html)）。对于确定性/贪婪解码（即温度 0），这意味着接受目标模型原本会自回归输出的 token 前缀，拒绝之后的所有 token，并插入目标模型预测的一个 token。

再次强调，这种加速是无损的。推测解码生成的样本序列与目标模型的分布相同（除了浮点数累加重排序等非确定性来源）。

推测解码的核心直觉与微处理器中的推测执行 (https://charlesfrye.github.io/programming/2023/11/10/llms-systems.html#speculative-execution-in-processors) 相同：串行执行代价如此之高，以至于并行执行可能被丢弃的工作仍然是值得的。

每次解码传递很像数据库中的顺序扫描。每次传递，你都需要将所有激活的权重（数 GB）从 GPU 内存 (https://modal.com/gpu-glossary/device-hardware/gpu-ram) 加载到 GPU SM (https://modal.com/gpu-glossary/device-hardware/streaming-multiprocessor) 中，就像在每次扫描中必须将整个表加载到处理器一样。那么，推测解码就类似于在数据库中与另一次顺序扫描相伴的物化视图 (https://hashrocket.com/blog/posts/materialized-view-strategies-using-postgresql) 的急切构建。如果没有任何查询读取该视图，工作就被浪费了，但你通常受 I/O 带宽限制，因此浪费的工作是“免费”的，从边际角度看。

问题在于你需要创建这个推测器模型。早期方法要么使用经典机器学习（例如 n-gram 模型 (https://github.com/apoorvumang/prompt-lookup-decoding)），导致接受的 token 很少，要么使用另一个神经网络 (https://modal.com/blog/reinforcement-learning-infrastructure-problem) ，导致起草成本高昂。两者都降低了推测带来的加速，我们将在下面更精确地建模和模拟。当代架构，如 MTP (https://arxiv.org/abs/2404.19737)、EAGLE-3 (https://arxiv.org/abs/2503.01840) 和 DFlash (https://arxiv.org/abs/2602.06036)，使用依赖于目标模型过去计算的推测器模型。

这些推测器模型轻量级，带来高接受长度，并且相对容易训练。

但“相对”二字至关重要。机器学习项目以难以管理和容易失败而闻名 (https://fullstackdeeplearning.com/course/2022/lecture-8-teams-and-pm/#0-why-is-this-hard)。幸运的是，最困难的问题并不在于推测器训练。

训练推测器是简单模式的机器学习。

在机器学习中，我们创建一个模仿世界中某些数据生成过程的机器。我们称那个机器为 ML 模型——除非它在某些人类有偿工作方面足够好，那时我们称之为“AI”。

这种设置中最棘手的部分之一是“在世界中”这个部分。世界生成数据是随意的，但几乎所有这些信息都会丢失。只有一小部分被计算机系统捕获，而观察世界的过程会扰动数据生成过程。此外，你所能收集的数据与你真正想要建模的底层过程之间几乎总是存在巨大差距。

在推测器训练中，差距被消除，数据也很丰富，因为数据生成过程正是另一个 ML 模型！ 收集更多数据、重塑数据或在训练过程中动态生成数据都非常容易。无需将你的软件工程师重新分配 (https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering) 到宏数据精炼 (https://lumon-industries.com/) 中。还有一个几乎不受古德哈特定律 (https://en.wikipedia.org/wiki/Goodhart%27s_law) 影响的目标指标：目标模型的接受率和目标推理系统的加速比。

机器学习中的基础设施很困难，但幸运的是我们了解基础设施 (https://modal.com/blog/reinforcement-learning-infrastructure-problem)。我们通过重新架构和优化开源训练代码以适应 Modal，已经能够将推测器训练速度提高 40 倍。你可以尝试一个类似的系统，专为训练后强化学习设计，点击这里 (https://gym.modal.dev/)。

训练自定义推测器很有用，因为在应用使用所创建的数据集规模下（数万或数十万个 token 的量级），接受长度（从而加速）的指针可以被有意义地移动。我们已经看到微调模型将接受长度从 3 的基线增加到超过 9。这就是 25% 的加速与 3 倍加速之间的区别，如下所示。

通过三个简单模型理解接受长度重要性的直觉

要理解为什么提高接受长度如此重要，让我们用三种方式建模推测解码：

• 在生产推理引擎 SGLang 中通过接受模拟进行轻量级模拟
• 一个用于直觉的极其简单的数学模型
• 一个更复杂的屋顶线模型来充实这种直觉

每种技术都让我们能够理解、欣赏并设计出高接受长度带来的加速，而无需运行大量昂贵、耗时的 ML 训练运行。

在 SGLang 中模拟推测

在决定投入资源训练推测器之前，我们想了解推测可能带来什么样的加速。

对于其他加速推理的方法，如内核优化 (https://modal.com/blog/flash-attention-4-faster)，我们可以轻松模拟工作负载。例如，在 SGLang 中，你可以传递 --load-format=dummy 来获取随机权重，并在基准测试中发送随机 token ID。这可能会对行为产生一些微小影响，尤其是在数值不稳定的内核中。但足够接近生产环境，可以加速大量优化工作。

模拟将算法开发与数据语义解耦。这有许多好处。例如，不需要在存储和开发服务器之间移动 TB 级的模型权重或数据集。甚至不需要从磁盘加载或通过 CPU RAM —— 它们可以直接在设备上生成！

但模拟推测更棘手。推测器本身就是一个 ML 模型，所以你不能在随机张量上运行它，否则接受长度会急剧下降。推测器将处于分布外！这似乎排除了使用虚拟权重。而输入数据更加棘手，因为它需要非常接近实际系统将看到的数据，尤其是对于微调过的推测器。下周会有更多相关内容！

SGLang 包含一个鲜为人知的环境变量解决了这个问题：SGLANG_SIMULATE_ACC_LEN。设置此标志会通过仅接受生成到一定长度的 token 来模拟接受行为，而不考虑目标模型的概率。使用随机权重的推测器和目标模型仍然会产生大致相同的工作量，因此花费大致相同的时间。

与任何对复杂数值代码的扰动一样，这当然会导致与实际工作负载的偏差。然而，它为我们提供了另一种检查模型和预测更好训练的推测器收益的方法。

如果我们在 B200 上以并发 1、4K 输入 token、4K 输出 token 的随机数据对 Qwen 3.5 27B 进行基准测试，并模拟接受长度在 1（自回归）到 8 之间，我们会看到显著的加速。

我们可以添加更多的证据线，并通过数学建模来培养关于加速来自何处以及如何通过提高接受长度来增加加速的直觉，接下来我们将进行数学建模。

一个推测的玩具模型

让我们从我们能想到的最简单的推测解码模型开始。在这个模型中，我们将看到推测带来的加速等于接受长度。

首先，让我们定义 加速比：

我们可以将吞吐量建模为以下参数的函数：

• 接受长度，即通过推测产生的 token 数量 (acc_len)
• 草稿长度，即推测的 token 数量 (draft_len)

我们将自回归解码建模为“预测一个 token draft_len 次，得到 draft_len 个 token”。我们将推测解码建模为“一次传入 draft_len 个 token，得到 acc_len 个 token”。

首先，假设模型在 1 个 token 上的延迟与在 draft_len 个 token 上的延迟相同。我们代入这些值：

如果我们展开这个式子，我们会注意到许多项抵消了——draft_len / draft_len 和 model.latency(1) / model.latency(1)。实际上，我们得到：

这种相等延迟的假设并不总是成立，并且可能严重错误。请耐心等待——我们将证明它何时近似成立，并很快改进我们的模型。

但这个简单的模型出乎意料地有用。例如，下面是我们本周发布的所有推测器在 SGLang 推理引擎中测得的加速比，并将非常简单的 speedup == acc_len 模型绘制为虚线。虽然加速比一直被高估，但观察到的接受长度之间存在线性趋势。

因此，我们有一个实用的经验法则，用于根据实际值范围内的接受长度估计加速比——线性，而不是二次、平方根或对数。然而，它实际上不能用于估计加速比。

高估的发生是因为我们做了许多有利于推测解码的假设：

• 草稿 token 不会给目标前向传递增加延迟。
• 推测器前向传递不增加延迟。

现在让我们修正这些。

用屋顶线模型进行更好的建模

注意：本节中的模型是使用 Doubleword (https://doubleword.ai/) 的 Fergus Finn (https://github.com/fergusfinn) 在这篇博文 (https://fergusfinn.com/blog/economics-of-speculative-decoding/) 中提出的 DeepSeek-V4 Flash 推测模型开发的。该模型中的数字被用作我们实现最优草稿长度计算的参考。