8.0
热点
AI SCORE
技术实践2026-08-14 00:01
DFlash speculative decoding 测评：tokens/s 指标可能误导
dev.to · AI#推理优化#Speculative Decoding#ML工程
Editor brief · 编辑速览
30B 级模型部署中，DFlash 用块扩散草稿取代自回归草稿，实现一次前向传播生成 8-16 token 块，但单纯 tokens/s 指标无法反映其真实吞吐收益，需结合接受率综合评估。
DFlash（"Block Diffusion for Flash Speculative Decoding"）是加州大学圣地亚哥分校 z-lab 推出的一个推测性解码框架，它用轻量级块扩散（block-diffusion）草稿模型取代了 EAGLE-2/EAGLE-3 等方法中使用的自回归草稿模型。与逐个生成草稿 token（本质上仍是顺序过程，只是比目标模型便宜）不同，DFlash 的草稿模型以目标模型的隐藏层状态特征为条件，在一次前向传播中对一整块候选 token（通常 8 到 16 个）进行去噪。然后目标模型像经典推测性解码一样并行验证整个块。
以下两点使 DFlash 在架构上区别于 EAGLE 式草稿模型：
草稿模型是非自回归的。 块扩散（掩码去噪）头同时预测多个未来位置，而不是将每个生成的 token 作为输入反馈回来去生成下一个。
草稿模型是上下文条件的，而不仅仅是 token 条件的。 它消耗目标模型前向传播中投射的隐藏层状态特征，这正是它能达到比纯 token 级草稿模型更高接受率的原因——草稿模型"看到"的是目标模型的"思维"，而不仅仅是它输出的 token。
该项目报告的数量级加速数据应作为上限而非保证来对待：论文基准测试中最高约 6 倍的无损加速，与 EAGLE-3 在相同条件下的对比中最高 2.5 倍，NVIDIA 自身报道在良好的批处理和内核条件下在 Blackwell 硬件上可达 15 倍。在实际生产环境中，你流量混合下的数字会低于标题数字；这个差距正是本文的主题，而且现在也可以在独立的第三方数据中看到，而不仅仅是供应商的宣传（更多内容见 §1.3 和 §6）。
DFlash 在 vLLM（--speculative-config）和 SGLang（--speculative-algorithm DFLASH）中都提供了开箱即用的支持，此外还有面向 Qwen3/LLaMA-3.1 的 Transformers 后端和面向 Apple Silicon 的 MLX 后端。这种广泛的服务栈支持——而不是仅仅作为研究项目——正是各团队评估它作为新部署中 EAGLE-3 草稿模型默认替代方案的重要原因。
大多数公开的推测性解码基准测试集中在两个极端：能够舒适地放在单个消费级 GPU 上且还有余量的小型模型（7–9B），以及默认需要多 GPU 张量并行的高级规模模型（70B+）。这两个极端都不能反映增长最快的生产细分领域：运行在单块高显存 GPU 上的密集型或轻量稀疏型 27B–35B 模型——A100 80GB、H100 80GB 或专业级 RTX 5090——这正是 DFlash 提供检查点的模型类别（Qwen3.5-27B、Qwen3.6-27B、Qwen3-Coder-30B-A3B、gemma-4-31B-it、Qwen3.5-35B-A3B）。
选择这个层级的基准测试对推测性解码特别有意义，因为：
它处于内存带宽/计算约束的拐点。 在 BS=1 时，FP16/FP8 格式的 30B 密集模型在解码时完全受内存带宽限制——这正是推测性解码设计要利用的运行环境。7B 模型的余量太大，以至于几乎任何草稿模型看起来都不错；而在多 GPU 上运行的 70B+ 模型会引入 NVLink/PCIe 和张量并行通信开销，用互联效应混淆了推测性解码的信号。
它是单 GPU 企业和边缘部署的实际上限。 超过约 30–35B 密集型后，大多数团队要么激进地量化，要么转向多 GPU 服务，这将完全改变成本/延迟计算方式。
它暴露了小型模型隐藏的草稿开销效应。 块扩散草稿模型前向传播的计算成本在 30B 目标总步时间中所占比例远大于 70B 目标——因此草稿路径中的任何低效都会清楚地显示在数字中。
如果你的基准测试方法论在 30B 下经不起审视，它在真实集群中也不会。
这不再只是一个假设的基准测试层级。2026 年 8 月 10 日，Meta 开源了 Muse Glimmer，这是一个约 29.6B 参数的密集型、面向 AI 智能体的模型，从 Meta 更大的 Muse Spark 模型蒸馏而来，并附带了一个官方训练的 DFlash 草稿模型（约 2.56B 参数、5 个草稿层、16-token 块）作为版本的一级发布内容，与完整的 BF16 权重、两个官方 GGUF 量化版本以及面向 Apple Silicon 和 NVIDIA 的 ExecuTorch 包一同发布。这使得 Glimmer 成为最早将推测性解码作为模型卡片的一部分进行维护——而不是作为社区附加项目——的主流实验室发布之一。
Meta 自己测量的、在 batch size 1、贪心解码条件下的数据，是对抗论文标题乘数的有用现实检验：
| 硬件 | 朴素解码 | 使用 DFlash | 加速比 |
|---|---|---|---|
| RTX 5090 | 74.9 tok/s | 233.4 tok/s | 3.1x |
| M5 Max | 26.6 tok/s | 50.2 tok/s | 1.8x |
| M4 Max | 未披露 | 未披露 | 1.5x |
DFlash 论文在理想条件下的小型模型上报告了超过 6 倍的加速；而 Meta 自己发布的 30B 级模型在 4-bit 下 RTX 5090 上的数字是 3.1 倍。关于该发布的独立评论（见 §6）已明确指出，这些是 batch=1、贪心解码数字，是在 Meta 自己的提示集上平均得出的，不应被视为通用交互速度——实际加速仍然取决于草稿 token 接受率、提示分布、采样配置、内存带宽和验证内核效率，正如本文在 §3.3 中论证的那样。这与论文的 6 倍和 NVIDIA 的 15 倍数字所暗示的"实际效果因人而异"的差距是相同的，现在有了一个具名供应商自己的数字处于实验室声明和实际场景之间。
值得提请注意的是方法论方面：Glimmer 的模型卡片推荐随机采样（temperature 1.0、top-p 0.95、top-k 64），但其发布的 generation_config.json 默认使用贪心解码，上表的 DFlash 吞吐量也是在贪心解码下测量的。贪心解码是确定性的，往往会提高草稿 token 接受率；采样增加了方差，并可能明显减少 DFlash 的速度优势。你对 Glimmer 或任何配备 DFlash 的模型进行的任何基准测试都需要明确说明它使用了哪种模式，因为两者是不可比的数据。
Aggregate tokens/sec（所有并发请求生成的总输出 token 数除以墙上时钟时间）是推测性解码基准测试中最常报告的数字，也是最容易操纵或误读的数字。它至少混淆了四个独立效应：
一种推测性解码方法可以通过在高并发下运行来 posting 出色的 aggregate TPS 数字，此时目标模型的批处理计算成为主导，而对最终用户实际感受到的指标几乎没有任何改善：他们在单次实时对话中等待 token 之间的延迟。Aggregate TPS 是服务器吞吐量指标。大多数关于"模型感觉慢"的抱怨是单流延迟抱怨。它们不是同一维度，而推测性解码的全部价值主张在 TPS 测量不好的那个维度上最为强烈。
TTFT（Time to First Token，首 token 时间）vs. TBT / Inter-Token Latency（token 间延迟）
TTFT 由对完整输入上下文的预填充注意力支配，基本不受推测性解码影响，因为草稿模型只在解码开始后才介入。TBT（也称为 token 间延迟或 ITL）才是 DFlash 块扩散草稿应该发挥作用的地方：如果单次前向传播可靠地产生多个被接受的 token，有效的 per-token 延迟就会下降，即使每个验证步骤比单个自回归步骤消耗更多墙上时钟时间。
分别报告 TTFT 和 P50/P90/P99 TBT——永远不要把它们混成一个"平均延迟"数字。
这是所有推测性方法的核心指标。接受率是目标模型验证步骤保留的草稿 token 所占比例；平均接受长度（常写作 τ，tau）是每次验证轮次实际提交的 token 平均数量（草稿块大小设定的是上限，而非下限）。一个每次提议 16 个 token 但平均只被接受 3 个的草稿模型，与一个每次提议 4 个 token 但同样接受 3 个的草稿模型相比，没有本质区别——只是前者消耗了更多算力。接受率也高度依赖任务类型：代码补全和结构化/模板化输出（局部可预测性高）接受的草稿 token 远多于开放式创意写作或多步推理轨迹，后者的 token 熵更高。
一个真实的 30B 运行案例让这一点更加具体。在一份独立发布的基准测试日志中，涵盖了在单块 24GB Blackwell 级 GPU 上部署的 Meta Muse Glimmer 30B + DFlash 配置，一个短代码任务达到 84.64 tok/s，接受率约 38.7%；而跨越代码、文章、推理和基础设施工作的混合工作负载，在相同权重、相同 GPU、相同草稿模型下，降至 38.34 tok/s，接受率约 14.4%。作者的表述值得直接引用：使用推测性解码后，每秒 token 数不再是一个纯粹的硬件基准，而同时成为了一个可预测性基准。
DFlash 的草稿模型并非免费的。每次验证轮次的成本包括：(a) 草稿模型对当前上下文窗口加上预测的目标隐藏状态的前向传递，以及 (b) 目标模型对提议块的整体并行验证。在小批量下，草稿模型的成本是无论如何都会产生的延迟，无论 token 是否被接受；在大批量下，草稿模型与目标模型竞争相同的 GPU 算力和内存带宽预算。要分别跟踪草稿延迟和验证延迟——不要让两者被吸收到一个单一的"解码步骤"数字中。
有一个开销来源很容易被完全忽略：token 选择实际在哪里执行。在上述同一份 30B 基准测试日志中，草稿模型的贪婪 token 选择最初被路由到 CPU 侧路径，即使草稿模型本身运行在 GPU 上，迫使其在系统最热的循环内进行一次设备到主机的往返和同步。将 argmax 选择直接移入草稿模型的 on-GPU 后端计算图中——在计算图中增加一行代码——单独就产生了 5.6% 的吞吐量提升，而且一旦工作负载的可预测性足以让 DFlash 发挥作用，效果会进一步复合。一般的经验教训是：如果利用率、接受率和墙上时钟吞吐量彼此不一致，在假设模型或 GPU 是瓶颈之前，先检查草稿循环中的主机/设备同步边界。
推测性解码的加速效果随批量大小增长而缩小，因为目标模型每个 token 的验证成本即使没有推测也能在更大批量上摊薄——当 GPU 已经充分利用时，每次传递"免费"额外 token 的边际价值会下降。这正是服务堆栈越来越多地在超过并发阈值时自动禁用推测的原因（在生产配置中通常观察到在 32 个并发序列左右）：超过该点后，草稿模型的开销可能使吞吐量净为负。任何报告单一 TPS 数字而未说明测量时批量大小的基准测试，都不是可用的结果。
TPS 掩盖真相的模式并非推测性解码独有；它与行业 AI 智能体编程端现已充分记录的问题属于同一类失败模式。一份广泛流传的案例描述了一个团队切换到"SWE-Bench 上排名第一的模型"后，在完成相同工作量的情况下月度推理账单增加了约两倍，因为分数更高的模型在每个已解决工单上消耗了数倍的 token、更多的工具调用轮次，且缓存复用率比一个分数略低但便宜得多的替代方案差得多。本文可推广的观点：单一的领导板数字——无论是编程基准上的"% 解决"还是推测性解码基准上的"每秒 token 数"——都将多个独立的成本和质量维度压缩成一个易于发布和易于误读的数字。两个案例的修复方法相同：报告成本相关的指标（AI 智能体基准的消耗 token 数、工具调用轮次、缓存命中率；推测性解码的接受率、平均接受长度、草稿开销），而不是用它们替代标题数字。
DFlash 的草稿模型接收当前序列，注入从目标模型多层隐藏状态中提取的上下文特征（通过一个轻量投影进入草稿模型自己的 KV 缓存），然后对一个 block_size 位置的块进行去噪：一个观察到的"锚"token（最近的目标验证 token，或一个采样的奖励 token）followed by 被掩码的未来位置。在一次非自回归前向传递中，草稿模型一次性填充所有被掩码的槽。然后目标模型对整个块执行一次并行验证——结构上与 EAGLE 或 Medusa 验证相同，但提议步骤从顺序变成了并行。
对于 30B 基准测试，两个配置旋钮最为重要：
num_speculative_tokens（vLLM）/ speculative-num-draft-tokens（SGLang）——块大小，在已发布的 DFlash 配置中通常为 15–16。更大的块提高了每轮的上限，但也提高了被拒绝的块的成本和每轮的验证算力。
草稿注意力后端：DFlash 配置经常为草稿模型固定一个独立于目标模型后端的特定注意力后端（例如，草稿路径使用 fa4 而目标使用 trtllm_mha），因为草稿模型的注意力模式（在一个短掩码块加上注入的上下文特征上）与目标模型的长上下文因果注意力有不同的最优 kernel。
Meta 自己的 Glimmer 草稿模型是这种设计的一个具体实例：它从 52 层目标模型的五层中提取隐藏状态特征（而非一层），将它们注入草稿模型的每一层（而不仅仅是草稿模型的输入），并使用五层草稿层，而 EAGLE-3 风格的草稿模型通常只使用一层。公开的技术解读中引用了所述理由：因为块扩散草稿使得提议 16 个 token 的成本与提议 1 个 token 大致相同，草稿模型可以负担得起更大、更有条件的结构，而不必支付随块大小增长而压垮自回归草稿模型的每 token 草稿税。
8B 目标模型运行成本极低，草稿模型的开销几乎无关紧要。几乎任何推测性方法都会显示出较大的相对加速，因为基线在绝对值上已经很快，即使在中等批量大小下，单 GPU 内存带宽也很少成为绑定约束。
70B+ 目标模型通常需要在 2–8 个 GPU 之间进行张量并行。这在每次验证步骤中引入了跨设备通信（NVLink 或 PCIe all-reduce），而该通信成本在很大程度上与每轮验证的 token 数量无关——这意味着推测性解码并行验证的相对收益被一个与草稿质量无关的固定通信税部分掩盖了。
30B 密集模型（或 30B 级 MoE）目标模型在单 GPU 上处于以下 regime：
这就是 30B 参数模型在诊断上很有用的原因：它足够大，会受到内存带宽限制（这正是投机解码应该发挥最大作用的地方），又足够小，单 GPU 的内核调度和草稿模型开销不会隐藏在多 GPU 通信效应之后。巧合的是，这也正是 Meta 在架构设计上针对 Glimmer 的目标层级：混合局部/全局注意力布局（52 层中 39 层使用 2,048-token 滑动窗口注意力，只有 13 层使用全序列注意力）结合 16:1 的分组查询注意力比率，独立分析估算将 131K 上下文下理论 104GB 的 KV 缓存压缩到约 1.7GB，正是为了让整个技术栈（权重、KV 缓存、视觉投影仪和 DFlash 草稿模型）能装进单张 24GB 消费级 GPU。基准测试的关键点：在这一层级，注意力布局和缓存几何结构与投机解码的内存带宽故事交互影响，其程度不亚于草稿模型本身本身，而只报告 tok/s 而不报告真实上下文长度下 VRAM 占用量的基准测试遗漏了半数关键信息。
高聚合 TPS，用户交互体验反而下降。 在高并发（BS=16–32+）时，聚合 TPS 可能上升，而每用户 TBT 反而变差，因为调度器在用相同的计算预算打包更多序列——聚合数字上升，但每个用户的数据流都变得更卡顿。这是团队误读基准测试最常见的方式：他们跑一个吞吐量扫描，看到 BS=32 时 TPS 数字很漂亮，就把它当作"交互式"配置发货了。
BS=1 时 TPS 下降源于验证开销。 在 BS=1 时，如果某个工作负载的接受率一般（例如高 token 熵的长文本推理），草稿模型前向传播的固定成本加上大部分被拒绝的验证轮次，可能使单流生成比普通自回归解码更慢——即使同一配置在代码补全流量上表现出明显优势。单一混合 eval 集上的 TPS 数字完全掩盖了这一点。
分块大小与接受率不匹配，以及为什么只看接受率可能选错配置。 增大 num_speculative_tokens 看起来很美（天花板更高），但如果你的流量实际接受率低，你付出大 rejected 分块的次数更多。"最优"分块大小与工作负载相关，应该扫出来而不是从公开默认值假设。一份公开的 30B 扫描结果让这个陷阱具体化了：4-token 草稿分块达到 47.5% 接受率，但只有 34.5 tok/s；而 15-token 分块只接受 18.0% 的提案，却达到 47.2 tok/s，快了 37%——尽管接受的比例低得多，因为更长的分块平均摊销了每次昂贵的目标模型验证通过的已提交 token。单独看接受率会指向 4-token 配置；只有平均接受长度（τ）才能解释为什么 15-token 配置实际上赢得了吞吐量。要同时报告两者，不要让接受率百分比 alone 驱动分块大小决策。
隐藏的采样器默认值悄悄改变你的数字。 服务栈的默认采样参数可能与模型的文档推荐值不同，且不会有任何错误或警告。在同一份公开的 30B 日志中，取消 llama.cpp 在 Meta 文档化的 temperature/top-p/top-k 设置之上额外应用的未请求默认 min-p=0.05 过滤器，使测得的吞吐量提升约 8%，因为额外的过滤器改变了哪些候选 token 成为权威的，进而决定了草稿模型的提议前缀是否通过验证。一份报告了 temperature 但遗漏 top-p、top-k 和 min-p（包括你没有显式设置时服务栈默认应用的值）的基准测试是不可复现的。
长上下文 KV 缓存位置变化本身会改变解码速度。 服务器接受大的 --ctx-size 只证明上下文能加载，不代表它能高效运行。在同一案例研究中，将 262K-token 上下文填满到容量，将远缓存解码吞吐量降至 21.56 tok/s——与相同配置下短提示词测得的 84.64 tok/s 相比大幅下降，纯粹因为对已满的长上下文 KV 缓存的注意力计算更昂贵，与草稿模型无关。上下文容量和上下文性能是两码事；要对空缓存和现实填充率的缓存都做基准测试。
| 指标 | 捕获内容 | 报告粒度 |
|---|---|---|
| 原始聚合 TPS | 总服务器吞吐量 | 按 batch size / 并发级别 |
| 有效交互性（tok/s/user） | 单个用户实际体验 | 按并发级别，P50/P90 |
| TTFT | Prefill + 排队延迟 | P50/P90/P99，与 decode 分开 |
| TBT / ITL | 每 token 解码延迟 | P50/P90/P99，与 TTFT 分开 |
| 草稿接受率 | 本工作负载上的草稿质量 | 按任务类别（code、chat、reasoning） |
| 每轮平均接受 token 数（τ） | 实现的加速天花板 | 按任务类别 |
| 草稿模型开销 | 草稿的计算/带宽成本 | 隔离的草稿传递延迟 |
| 草稿选择后端路径 | argmax/选择是否保持在 GPU 上 | 每个配置检查一次 |
| 采样参数（包括隐藏默认值） | 接受率数字的可复现性 | 每次运行的全套参数 |
| GPU VRAM 占用 | 可部署性 | 目标权重 + 草稿权重 + KV 缓存在目标最大并发下的占用，在现实缓存填充下测量，而非加载时 |
| 质量 vs. 量化 | 速度提升是否以精度为代价 | 困惑度或任务评估，与每个量化变体配对 benchmark |
这故意是一个框架而非填好的计分板：实际数值与工作负载、硬件和量化相关，任何从 vendor blog 拉来的数字，如果不经过你自己的流量回放，都应该被视为粗略先验，而非部署决策。把上面的列当作你自己基准测试运行在信任"DFlash 给我们带来了 Nx"这个说法之前必须填写的最小集合。
第一步——启用 DFlash 启动服务栈。
vLLM，在 30B 类目标模型上使用匹配的 DFlash 草稿检查点：
vllm serve Qwen/Qwen3.5-27B \
--speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.5-27B-DFlash", "num_speculative_tokens": 15}' \
--attention-backend flash_attn \
--max-num-batched-tokens 32768
SGLang，在 35B-A3B MoE 变体上：
export SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1
python -m sglang.launch_server \
--model-path Qwen/Qwen3.5-35B-A3B \
--speculative-algorithm DFLASH \
--speculative-draft-model-path z-lab/Qwen3.5-35B-A3B-DFlash \
--speculative-num-draft-tokens 16 \
--tp-size 1 \
--attention-backend trtllm_mha \
--speculative-draft-attention-backend fa4 \
--mem-fraction-static 0.75 \
--trust-remote-code
对于本地 / 单 GPU llama.cpp 部署（Meta 自己的 Glimmer GGUF release 和大多数社区 DFlash 基准测试实际使用的路径），最可能悄悄搞砸你数字的两个标志是那些加载配置文件的标志：
