Modal 发布 Qwen 系列 DFlash 投机模型，推理最高提速 3 倍

我们全力投入投机解码，我们想告诉你为什么。

但首先：我们是 Z Lab 的 DFlash 草稿模型架构的忠实粉丝。这就是为什么我们本周为 Qwen 3.5 397B-A17B 发布了一个最先进的 DFlash 推测器，并与 SGLang 紧密合作，确保其性能达到世界一流水平。

这也是我们与 Z Lab 合作，为 Qwen 系列中更多模型训练最先进推测器的原因，我们今天在 Hugging Face 上发布这些模型：

在现有 DFlash 推测器强大基线的基础上，这些新的草稿模型在各种工作负载上额外实现了 5 - 20% 的加速。

这足以在 B200 节点上以并发 1 运行 Qwen 3.5 122B-A10B 达到超过 1000 tok/s。下面大致展示了这一效果，与没有任何推测、以 250 tok/s 运行的模型相比，使用的是我们 LLM Engineer’s Almanac 中的 token 计时模拟器：

此外，它们在非常长的上下文任务（如智能体软件工程）中能更好地保持其接受长度。

下面，我们解释为什么我们看好推测用于 LLM 推理加速——以及作为 AI 应用整个持续改进循环的一部分。但首先，一个包含高层次要点的 tl;dr。

首先，投机解码是实现高交互性下最先进推理性能的唯一重要的引擎优化。昂贵的 CUDA 工程师进行数天的艰苦内核优化工作，或仔细分析并消除主机端瓶颈，带来的加速只有几个百分点。这是一场苦差事，是一场寸土必争的游戏。许多推理提供商浪费了大量工程时间，构建充满这些优化的专有引擎。

投机解码带来的加速要大得多——以 2 倍或 3 倍这样的整数因子衡量，而不是 2% 或 3%。下图展示了我们在训练过的推测器中以及内置 MTP 基线中观察到的加速，作为推测器质量的函数。如果你对细节感兴趣，可以在 Modal Notebook 中探索数据。

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

最后，当投机解码针对应用的领域特定数据进行定制时，它会带来真正无与伦比的加速。这意味着投机解码是苦涩教训式的：因为投机解码底层依赖机器学习，当你只是投入更多数据和计算来解决这个问题时，加速就会增加——不需要顶尖的内核工程师。这意味着它可以像它所加速的 AI 应用一样，乘上硬件、算法、自动研究和规模方面持续改进的相同指数曲线。

推测解码对当代自托管推理的成功如此关键，以至于你甚至可以说推测就是你所需要的一切。

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

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

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

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

目标模型为这些 token 计算自己的输出概率，并应用一种重采样技术（对于‘heads，通常是顺序拒绝采样）。对于确定性/贪婪解码（即温度 0），这仅仅意味着接受目标模型本会自回归输出的 token 前缀，拒绝之后的所有 token，并插入一个由目标模型预测的 token。

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

推测解码的核心直觉与微处理器中的推测执行相同：串行执行如此昂贵，以至于并行执行你可能丢弃的工作仍然是值得的。

每次解码过程非常像数据库中的顺序扫描。每次过程你都要将所有活跃权重（数 GB）从GPU 内存加载到GPU SM中，就像每次扫描时你必须将整个表加载到处理器中一样。推测解码则类似于物化视图的急切构建，与数据库中的另一次顺序扫描相伴而行。如果没有查询读取该视图，工作就被浪费了，但你通常受限于 I/O 带宽，所以浪费的工作在边际上是“免费”的。

问题在于你需要创建这个推测器模型。早期方法要么使用经典机器学习（例如n-gram 模型），导致被接受的 token 很少，要么使用另一个神经网络，导致草稿成本很高。两者都会降低推测带来的加速，正如我们在下面更精确地建模和模拟的那样。当代架构，如MTP、EAGLE-3和DFlash，使用的推测器模型搭上了目标模型过去计算的便车。

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

但“相对”在这里承担了很多。机器学习项目以难以管理且容易失败而闻名。幸运的是，最难的问题并不涉及推测器训练。

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

在机器学习中，我们创造一台机器来模仿世界上某个数据生成过程。我们称这台机器为 ML 模型——除非它在人类能获得报酬的某件事上足够好，那样的话我们称它为“AI”。

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

在推测器训练中，这一鸿沟被消除了，而且数据非常充足，因为数据生成过程就是另一个机器学习模型！在训练过程中，收集更多数据、重塑数据或即时生成数据都轻而易举。无需将你的软件工程师重新分配去从事宏观数据精炼。此外，还有一个几乎不受古德哈特定律影响的目标指标：目标模型的接受率和目标推理系统的加速比。

机器学习基础设施很难，但幸运的是我们懂基础设施。通过构建我们自己的推测器训练框架，充分利用Modal 的快速自动扩缩容和海量并发能力，我们能够将推测器训练速度提升 40 倍。你可以在这里尝试一个类似的、专为后训练强化学习设计的 Modal 原生训练框架。

训练自定义推测器之所以有用，是因为在接受长度——进而加速比——这一指标上，可以在应用使用所产生规模的数据集上取得有意义的提升，这些数据集规模在数万到数十万个 token 的量级。我们已经看到，微调后的模型将接受长度从基线 3 提升到超过 9。正如我们在下文所展示的，这相当于从 25% 的加速比到 3 倍加速比的差别。

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

为了理解为什么提升接受长度如此重要，让我们从三个角度对推测解码进行建模：

在生产推理引擎 SGLang 中，通过接受模拟进行的一些轻量级仿真
一个极其简单的数学模型，用于建立直觉
一个更复杂的 roofline 模型，以充实这种直觉

这些技术中的每一种都让我们能够理解、领会并针对高接受长度带来的加速比进行工程优化，而无需运行大量昂贵、耗时的机器学习训练任务。

在 SGLang 中模拟推测

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

对于其他加速推理的方法，比如内核优化，我们可以很容易地模拟工作负载。例如，在 SGLang 中，你可以传入 --load-format=dummy 来获得随机权重，并在基准测试期间发送随机 token ID。这可能会对行为产生一些微小影响，尤其是在数值不稳定的内核中。但它与生产环境足够接近，可以加速大量优化工作。

模拟将算法开发与数据语义解耦。这样做有很多好处。例如，数 TB 规模的大型模型权重或数据集无需从存储移动到开发服务器。它们甚至不需要从磁盘加载或经过 CPU 内存——可以直接在设备上生成！

模拟推测（speculation）的基准测试更棘手。推测器本身就是个 ML 模型，所以你不能只拿随机张量跑它，否则接受长度会暴跌。推测器是在分布外运行的！这似乎就排除了用虚拟权重的可能。而输入数据更棘手，因为它需要与实际系统所见的内容高度匹配，对微调过的推测器尤其如此。下周再详谈！

SGLang 包含一个鲜为人知的环境变量可以解决这个问题：SGLANG_SIMULATE_ACC_LEN。设置这个标志后，它会模拟接受行为，即不管目标模型的概率如何，直接接受生成 token 直到某个长度。使用随机权重的推测器和目标模型仍会产生大致相同的工作量，因此耗时也大致相同。

与任何对复杂数值代码的扰动一样，这当然会导致与真实工作负载产生偏差。不过，它给了我们另一种方式来校验模型，并预测训练更好的推测器能带来多少收益。

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

接受长度	输出 tok/s	加速比
1	75	1x
2	140	1.86x
4	268	3.57x
8	422	5.62x

我们可以补充更多证据，并通过数学建模来建立直觉，理解加速从何而来以及如何进一步提升，这正是我们接下来要讨论的。

推测的玩具模型

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

首先，让我们定义 speedup：

我们可以很容易地把吞吐量建模为以下量的函数：

- 接受长度，即推测产生的 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 不会给目标前向传播增加延迟。
推测器前向传播不增加延迟。

现在让我们修正这些。

用 roofline 做更好的建模

注意：本节中的模型是使用 Doubleword 的 Fergus Finn 在这篇博客文章中提出的 DeepSeek-V4 Flash 推测模型开发的。该模型中的数值被用作我们实现最优草稿长度计算的参考。

为了将目标前向传播的延迟作为负载（包括草稿 token）的函数纳入考量，我们基于一些简化假设构建了该前向传播的简单模型：

加速器的内存带宽和算术带宽始终被完全利用，
内存传输和计算可以完美重叠，所有延迟都被隐藏，并且
主机向加速器投喂工作的速度快于加速器完成工作的速度，从而避免了开销。

对于更大的模型、更长的序列长度和更大的批大小，这些假设都更为准确。

基于这些假设，我们可以根据模型需要读取多少字节、需要执行多少次浮点运算（flops），以及在充分利用内存和算术带宽时这些操作需要多长时间，来估算模型的延迟。我们只需取两者中较高的延迟（计算下界或内存下界）。这就是性能的roofline 模型。

从机制上讲，这种计算按层进行最为容易，因为注意力和矩阵乘法的表现差异很大。我们忽略其他层，因为它们通常要么非常快，要么可以通过尾声或其他内核融合与运行时间更长的操作重叠。

这意味着该建模代码看起来大致像：

注意，对于少量查询 token，注意力和稠密 MLP 模块加载的字节数在 query_tokens_per_seq 上大致恒定。这证明了我们简单模型中的核心近似是合理的——只要计算延迟给出的下界不高于内存延迟给出的下界，该模型中计算出的延迟对于单个查询 token 和多个查询 token 就大致相同。

相关的架构数据可以从Hugging Face 配置中读取，并结合一些简单逻辑来计算所执行的 flops 和读取的字节数。

我们选择将推测器的前向传播延迟建模为目标模型的固定百分比——5% 到 20% 左右似乎很常见。对于自回归式草稿器，这是每个草稿 token 支付一次。对于像 DFlash 这样生成块的草稿器，这是每个块支付一次。

这些计算相当快，因此我们可以动态进行——在浏览器中用 JavaScript，无需 GPU。你可以在这里试一试。

下面我们走查该模型的一个示例输出。

该图表比较了推测相对于自回归基线在解码上的加速，针对部署在单个 B200 节点上处理特定工作负载的 DeepSeek-V4 Pro。此工作负载为短序列长度（约 4k token/序列）和高并发（批大小为 32 个序列）。顶部图表显示了若干草稿器在不同草稿长度下的预测加速倍数，以及最高加速倍数。根据该模型，该加速在最优草稿长度（或 16，取较小者）处实现。

比较了三个草稿模型。金色的是“理想”草稿模型。该草稿模型具有近乎完美的接受率，并能瞬间完成其前向传播。至少根据 roofline 方面的考量，这为该工作负载和硬件下的推测提供了一个上限。蓝色的草稿模型代表典型的自回归 MTP 草稿模型，其接受长度较短。绿色的草稿模型代表典型的训练良好的块草稿模型（如 DFlash），其接受长度要高得多。

使用更快的草稿模型并将接受长度从约 3 提升到约 8，会大幅改变预测可实现的加速比。它从 20%（这已经相当可观）变为 3 倍，足以开启新的应用或市场。进一步提升接受长度将允许更大的块大小。

这个模拟器并不完美——原因如上所述，受限于 roofline 模型，也因为它没有尝试对张量跨 GPU 的通信进行建模。然而，我们发现它比简单的玩具模型更正确。例如，它正确预测了对于像 DeepSeek-V4 Pro 这样的混合专家模型，推测器加速比随批量大小呈非单调（“U 形”）变化，而对于像 Qwen 3.5 27B 这样的稠密模型则呈单调变化。你可以在这里看到这一点：先查看图表的默认版本，然后选择 Qwen 3.5 27B。

接下来是什么？

在本文中，我们考虑了开源推测解码当前的生产级最先进水平。未来会是什么样？

我们预计会出现以下趋势：

自适应推测
推测器架构的改进
推测器实现的改进
拥抱有损推测解码
推测器的迭代训练与蒸馏

自适应推测器训练

首先，我们认为这涉及更多定制推测器。生产数据会经历漂移。用户行为随时间变化，推理系统（包括推测器）需要适应。Together 在这方面有出色的先前工作。我们正在试验自适应推测器训练，并期待将其部署给我们的用户并与他们一起部署。

但自适应推测并不像“用 cron 检查接受长度”那么简单。用户行为的一些变化是季节性的，而非持续性的。例如，一家在 Modal 上构建自适应推测的公司有两个位于地球两端的不同基地，各自使用自己的（混合）语言。这限制了固定容量推测器的加速效果。更糟的是，一个实现不佳的自适应推测器系统会在用户群每次变化时触发重新训练，每天两次，而它本可以只维护两个“区域推测器”，并以低得多的频率重新训练。

更好的推测器架构

其次，我们认为这涉及更多关于推测器架构的工作。DFlash 引入了两个我们喜欢的新想法（正如我们在 LMSys Org 博客上详细解释的那样）。KV 注入技术允许更深、更智能的草稿模型。DFlash 的单步扩散/“眯眼一看就是 BERT”方法也更适合高算术强度的硬件。

但如今扩散模型中热门的新技巧是使用流映射。扩散模型通过其去噪操作诱导出一个向量场，典型的推理方法会逐步跟随该向量场。流映射接收初始状态和步数，输出最终状态——就像积分的查找表，而非顺序积分器。借助一些巧妙的数学，你可以写出目标函数，以同时训练一个多步扩散模型和一个用于多步所有“跳跃”的积分器，包括单步去噪器。对于推测，这为你提供了一个额外的旋钮，用于权衡接受长度和草稿器延迟，而无需重新训练草稿器。

更好的推测器实现

第三，我们认为推测器的实现将会改进。在将 DFlash 与 SGLang 集成时，我们发现需要为 KV 注入步骤编写一个融合内核，以提高利用率和吞吐量。

这里有一个通用的教训：推测器必须比目标模型运行得更快，这通常意味着它们更小。较小的模型难以饱和内存和算术带宽，并且在最适合较大模型的相同硬件上运行时更容易产生主机开销。推测器与目标模型的解聚很有趣，但我们预计通信延迟会使其仅限于少数小众用例。

内核融合的极限是巨型内核——一个运行整个模型的单一内核。由于巨型内核编写的工程成本高昂，这类内核此前很罕见，相比之下普通内核编写就像写 bash 脚本。当代的巨型内核方法，如Hazy Research 的这项工作，使用设备上的“解释器”以最大并发和最大复用运行来自更高级程序的指令，取得了令人印象深刻的结果。随着编码代理的兴起，工程成本正在下降，包括在内核编写方面。请参阅我们的客户 Recursive Superintelligence 的这篇博客文章，了解有趣的早期结果（以及关于奖励黑客的警示故事）。

有损推测解码

由于推测解码是无损的，对于提供返回特定模型样本的 API 的通用推理提供商来说，它是一个极好的选择。但这种无损保证是有约束的。

鉴于专有推理领域最近发生的事件，越来越多的组织正在考虑拥有自己的推理并使用开放模型。当你拥有自己的推理时，你可以根据自己的需求进行优化——包括以模型行为的某些变化换取延迟的大幅改善。

飞轮的愿景

让我们勾勒一下推测器和内部推理如何协同工作，以交付一个在质量、延迟和成本方面持续改进的系统。

典型的组织使用通用基础模型来原型化推理应用，通常通过专有提供商。

一旦应用原型化完成，你就可以投入工程精力来托管推理。在 Modal，我们正在尽可能简化这一过程——下周会有更多内容。原型化期间开发的追踪和评估使这一过渡无缝衔接。通用的预训练推测器模型确保成本和延迟得到控制，且不牺牲质量。

一旦你从这种自托管推理中获得了数万个样本，你就可以训练一个自定义的推测器。自定义推测器可用于在固定延迟下降低成本，或在固定成本下降低延迟。

一旦你拥有更多样本，你就可以将部署的目标模型蒸馏（硬蒸馏或软蒸馏）为一个更小的模型，从而在不损害质量的情况下进一步降低延迟和/或成本。关键的是，用于构建评估和训练推测器的相同数据源也可以用于蒸馏。

现在你重复这一过程——以更小的模型作为新的基线。

由于整个技术栈都基于计算和数据，它都会因算法、模型和硬件的改进而加速。这意味着质量、成本降低以及来自蒸馏和推测的性能提升所形成的复利循环，正建立在你的组织内外许多改进的复利循环之上。

如果你有兴趣构建这个，请联系我们。如果你有兴趣构建支持这个的基础设施，我们正在招聘。