SPEED-Bench：面向推测解码的统一且多样化的基准测试 SPEED-Bench: A Unified and Diverse Benchmark for Speculative Decoding
NVIDIA 为推测解码算法提供兼顾语义多样性与生产级吞吐评估的统一基准
前置知识
推测解码 (Speculative Decoding, SD)
用一个小型的 draft 模型先连续预测 $\gamma$ 个候选 token，再用大目标模型一次并行验证它们；只要草稿命中率高，就能把原本 $T$ 次串行解码压缩为接近 $T/\gamma$ 次并行验证，从而绕过低并发下的访存瓶颈。
整篇 SPEED-Bench 都在评估各种 SD 方法（N-Gram、Vanilla SD、EAGLE3、Native MTP）的真实加速比，必须先理解这套 draft-then-verify 的工作机制才能看懂所有指标的物理意义。
条件接受率 (Conditional Acceptance Rate, AR) 与平均接受长度 (AL)
AR 是在前缀已经被接受的前提下，第 $i$ 个草稿 token 被目标分布接受的概率；AL $= 1 + \sum_{i=1}^{\gamma} \prod_{j=1}^{i} AR_j$ 是一次 verification 平均产出的 token 数（含免费的验证 token）。
AR/AL 是衡量 drafter 质量的领域敏感指标，SPEED-Bench 的 Qualitative Split 就是为更稳定地测准这两个量而设计的。
访存 bound vs 计算 bound 的转换
低并发时 LLM 解码时间主要花在把权重从 HBM 搬到 SM 的片上缓存，计算单元空转；BS 增大后单步计算量超过访存量，进入 compute-bound，SD 的并行验证收益会被摊薄甚至反转为减速。
SPEED-Bench 的 Throughput Split 横跨 1k-32k 的 ISL 和最高 BS=512，就是为了扫描这条从 memory-bound 到 compute-bound 的边界曲线。
RoPE 位置编码与上下文扩展 (YaRN)
RoPE 给每个位置编码一组旋转角度，长上下文时如果训练时没见过足够长的位置，推理阶段会出现失效；YaRN 通过缩放频率分量来补位置，弥补训练 ISL 不足的问题。
Section 8.5 用 EAGLE3 在长 ISL 下精度骤降的例子说明，drafter 训练 ISL 与 RoPE 配置不匹配会直接造成 AL 退化，是理解实验的重要背景。
vLLM / TensorRT-LLM / SGLang 推理引擎
vLLM 用 PagedAttention + 连续批处理；TensorRT-LLM 通过编译成 CUDA Graph 做极致优化；SGLang 用结构化语言模型程序抽象调度。它们都支持 SD，但实现方式差异巨大，会影响真实加速比。
SPEED-Bench 的核心卖点之一就是跨这三个生产级引擎做公平对比，所以读者需要知道它们各自做了哪些系统级优化才能理解附录 M 中引擎差异的来源。
研究动机
当前 SD 算法的评估存在系统性偏差。最常用的 MT-Bench 在大多数类别只有 10 个样本、2 轮对话，且全部来自 Chatbot Arena 的简单子集，统计噪声极大；SpecBench 虽然迈向标准化，但它的多语言子集干脆全是 WMT14 德译英的 Translate German to English 模板，15% 的总样本毫无结构多样性。更严重的是，几乎所有论文都只在 HuggingFace Transformers 这类高层库上、batch size = 1、ISL < 100 token 的设置下报速度，而真实生产场景是 vLLM/TRT-LLM、BS=32-256、ISL 8k-32k 的混合负载。在低并发下 SD 收益最大，但随着 BS 增大系统从 memory-bound 转向 compute-bound，长草稿的验证开销反而会成为负担，最后可能净减速；此外，现有 drafter（如 EAGLE3 默认把词表裁到 32k）在英语代码/数学上几乎无感，但在多语言、长尾 RAG 上有 22% 的目标 token 直接不在裁剪后的词表中，缺陷完全被小数据集掩盖了。最后，很多团队习惯用 vLLM/InferenceMAX 的 random-token 脚本压测，但随机 token 既触发 MoE 路由器坍缩（附录 G 显示某些层有 20-30% 的专家完全没被激活），又让模型倾向输出这是噪声之类的模板回复，把 AR 虚高 23%，导致最终 throughput 估计严重失真。
本文的目标是作者希望构建一个面向真实生产负载的 SD 基准，能够在多样化文本域、可变 ISL、可变 batch size 的二维空间里，同时给出草稿质量（AR/AL）和端到端加速比；并且通过统一的 token 化、prompt 模板、消息路由层，让 vLLM、TensorRT-LLM、SGLang、SpecBench 跑出 apples-to-apples 的对比。
与已有工作不同的是，SPEED-Bench 切入的角度是评测方法学而非新算法。具体差异在于：1) 用基于 OpenAI text-embedding-3-large 的 Greedy Selection + Local Swap Refinement 在 18 个公开数据池里挑出 880 个样本，使平均 pairwise similarity 比 SpecBench 低 40%、多语言类低 83%，相对排名稳定性提升 14×（Kendall-τ），从源头解决统计噪声；2) 新增 Throughput Split（5 个固定 ISL bucket × 3 类难度 × 512 样本）专门刻画高并发+长上下文，并附带用 AL × t_ar / t_sd 解析估计任意域加速比的代理公式；3) 把测量框架做成 thin client，外部统一处理 token 化与 chat template，把引擎内部的优化当作一等公民纳入报告，而不是像 HF Transformers 那样把系统差异也归到算法头上。
核心方法
SPEED-Bench 由三个松耦合的组件构成，整体思路是先用语义选择把评测集压扁，再用结构化负载扫描硬件行为，最后用统一客户端把多家引擎拉到同一起跑线。具体地：作者先把 24 个公开数据池（SpecBench、HLE、LiveCodeBench、HumanEvalPack、Code Contests、RoleBench、CoSER、WritingBench、Creative Writing V3、MT-Bench 101、MMLU-Pro、MMATH、OPUS-100、MCIF、ChatRAG-Bench、CNN/DailyMail 等）切成 11 类共 880 样本的 Qualitative Split，每类 80 条，其中约 20% 是 2-5 轮多轮对话，配套难度、子类别、目标语言等元字段；Throughput Split 则把 BAMBOO、Gutenberg、WritingBench、AdaLEval、HLE、Long Code Arena、RepoBench（Python/Java）等压成 5 个 ISL bucket（1k/2k/8k/16k/32k）× 3 档熵等级（Low/Mixed/High），每格 512 条，可堆到 BS=512；最后测量框架是一个 asyncio thin client，外部统一 tokenize（用 o200k base tokenizer 算 ISL）并对各家引擎发相同 token 序列，从流式响应里统计 AR/AL、TTFT、step latency、User TPS、Output TPS。
核心创新不在算法，而在评测协议——把数据选择、负载生成、引擎调用三个原本耦合的环节解耦，使 SD 速度报告终于能区分草稿质量下降和系统进入 compute-bound 两种截然不同的瓶颈。具体讲三个本质区别：第一，相对于随机选样本，作者将选 $k$ 个样本最大化语义多样性这件事建模为 $\min_{S} \sum_{i \in S} \sum_{j \in S, j \ne i} x_i^\top x_j$（其中 $x_i$ 是 text-embedding-3-large 的行归一化向量），用 Greedy + Local Swap 求近似最优，使每个类别的相对排名在 10 次独立采样中保持 14× 更一致；第二，相对于随机 token 测吞吐，作者显式构造固定 ISL 的真实文本负载，并用不同熵等级来代理领域复杂度，使得 $t_{ar}$（单步解码时间）和 $t_{sd}$（一次 SD 验证时间）可以在同一个 ISL bucket、BS 网格上联合扫描，得到可靠的吞吐-延迟 Pareto 曲线；第三，相对于各家引擎各自吃 raw text，SPEED-Bench 的 thin client 把 BOS、chat template、特殊 token 处理全部外置并冻结，只把数值实现、CUDA kernel、连续批处理留给引擎，从而把 SD 算法本身的贡献从系统优化中剥离。
方法步骤详情
方法分三步走。Step 1（Qualitative 数据筛选）：先用 OpenAI text-embedding-3-large 把每个候选 prompt 嵌入成 $d$ 维向量并做行归一化，使其 cosine similarity 等价于点积 $x_i^\top x_j$；对每个类别独立跑 Algorithm 1，先随机挑一个样本做种子，迭代 $\arg\min_{i \notin S} \sum_{j \in S} x_i^\top x_j$ 贪心扩展到 $k=80$，再做 Local Swap Refinement：寻找 swap 对 $(i_o \in S, i_i \notin S)$ 严格减小目标 $\Delta = \sum_{j \in S \setminus \{i_o\}} (x_{i_i}^\top x_j - x_{i_o}^\top x_j)$ 后替换，直到收敛或达最大迭代次数；最终相比 SpecBench 把平均 pairwise similarity 从 0.22 降到 0.14，多语言类更从 0.3 量级降到 0.05 量级。Step 2（Throughput 数据构造）：在 8 个数据集上先用 o200k tokenizer 计算真实 token 数，按 ISL 目标做截断或在末尾拼接中性后缀 please answer now 做 padding，使 prefill 输入是确定长度的真实语义；按 (Low, Mixed, High) Entropy 三档分桶，每格 512 样本×5 个 ISL bucket 共 7680 条；采样阶段把同一 ISL 的请求按 BS 同时塞进引擎。Step 3（测量与上报）：thin client 用 asyncio 并发 dispatch 请求到目标引擎，从 streaming object 中每收到一个 chunk 就打时间戳，根据 chunk 包含的 token 数推断 AL，按 $AL = 1 + \sum_{i=1}^{\gamma} \prod_{j=1}^{i} AR_j$ 反算 AR；延迟侧同时上报 TTFT、step latency、User TPS（单请求每秒生成 token 数）和 Output TPS（所有并发请求每秒生成 token 数之和）；最终报告对 TensorRT-LLM、vLLM、SGLang、SpecBench 四种后端的兼容。
技术新颖性
技术新颖性体现在三个层面。第一，把评测集构造从工程师经验提升为有可证明稳定性的优化问题——Algorithm 1 在 Roleplay 类把跨子集 AL 相对波动从 22.7% 压到 0.6%，Kendall-τ 排名一致性从 0.056 提到 0.004，并提供了 QP 凸松弛作为对照（结果证明 Greedy+Swap 既快又好）。第二，引入熵分桶 + 固定 ISL 的 throughput 实验范式，把 $t_{ar}$ 和 $t_{sd}$ 解耦到系统侧、AL 留在领域侧，并给出 $S = (t_{ar} \cdot AL)/t_{sd}$ 的解析代理，在 Llama 3.3 70B + EAGLE3 + BS=16 上验证了代理值与端到端测量值在 1k/2k/8k 全部吻合（差距 ≤ 0.02×）。第三，把引擎差异显式纳入评测对象：在附录 M 中展示了 TensorRT-LLM 用 one-model CUDA Graph 把整段 draft-verify loop 装进单图，吞吐比 vLLM 的 two-model 模式更高，但代价是失去动态草稿策略的灵活性——这种 trade-off 是过往 HF-only 评测完全看不到的。
实验结果
核心实验围绕五个目标模型（Llama 3.3 70B、GPT-OSS 120B、DeepSeek R1、Qwen3 235B、Qwen3-Next）和四类 drafter（N-Gram、Vanilla SD、EAGLE3、Native MTP）在 BS=32、DL=3、temperature=0 下展开。Table 1 给出关键加速比：Llama 3.3 70B 上 EAGLE3 达到 1.90× 平均加速、Vanilla SD 1.60×、而 N-Gram 反而是 0.88× 净减速（因 AR 太低，验证开销回不来）；GPT-OSS 120B + EAGLE3 拿到 1.34×，但 N-Gram 仅 0.29×——这是 drafter 必须保证足够 AR 才划算的直接证据。Figure 3 显示 AL 随 DL 变化的两个反直觉规律：1) Qwen3-Next 的原生 MTP head 在长 DL 下保持最高 AL，预训练阶段学到的草稿头比后训练接的 EAGLE3 更鲁棒；2) Vanilla SD（外部草稿模型）尽管单步开销更高，但在更长 DL 下 AL 仍能涨，而 EAGLE3 的浅层 MLP head 很快就饱和，说明 EAGLE3 的加速上限受限于 head 表达力。Figure 4 直接揭示 EAGLE3 把词表裁到 32k 的副作用：在 Multilingual 类 AL 掉了 10.05%、RAG 掉 9.51%、Summarization 掉 10.22%，而 Coding/Math/Writing 受影响不到 6%，与 Table 14 显示多语言目标 token 有 22% 不在裁后词表里的现象完全吻合。Figure 5 对比 SpecBench vs SPEED-Bench：SpecBench 的 Coding/Reasoning 仅 10 样本时 EAGLE3 和 Vanilla SD 看起来差不多，但扩到 80 样本后 Vanilla SD 在长 DL=7 时全面胜出，特别在 Multilingual 上差距最显著——说明 SpecBench 的多语言类把翻译等价于多语言是严重欠采样。Figure 6 量化了 random-token 测速的偏差：在 GPT-OSS 120B + EAGLE3 + DL=3 + 8k ISL 下，合成输入比 SPEED-Bench 高估吞吐 23%，即便不开 SD 的 baseline 也存在差距，根因是 random token 让 MoE 路由器坍缩（Figure 12 显示某些层 20-30% 的专家完全没被激活）。Figure 7 用 Throughput Split 扫描 BS 维度：BS=2-256 上 DL=3 在低 BS 时吞吐更高，但 BS=64 后验证开销压过收益，DL=1 反而最优——证实最优 DL 是 BS 的函数，传统固定 DL=1 或 DL=5 的报告都过于片面。Figure 8 给出 ISL 维度的影响：训练 ISL=1k 的 EAGLE3 在 8k 推理时 AL 骤降到 1.0 以下，但推理时套上 YaRN RoPE 缩放就能救回大部分精度，说明 ISL 不匹配是 drafter 长上下文失效的主因之一。Table 10 的代理公式验证显示，Llama 3.3 70B + EAGLE3 + BS=16 + DL=3 下，代理 speedup 与实测 speedup 在 1k/2k/8k 全部误差 ≤ 0.02×，证明系统侧时延 × 领域侧 AL 的解耦是可行的工程捷径。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Llama 3.3 70B Qualitative AL | Average AL (BS=32, DL=3) | Vanilla 2.44 / EAGLE3 2.44 / N-Gram 1.41 | 无 SD 时的 AL=1.00 | EAGLE3 +144%、Vanilla +144%；N-Gram 仅 +41% 且在 BS=32 下净减速 |
| Llama 3.3 70B 端到端加速比 (T=0) | Mean Speedup | EAGLE3 1.90× / Vanilla 1.60× | 1.00× (自回归 baseline) | EAGLE3 +0.90×、Vanilla +0.60×；N-Gram 0.88× 反而 -0.12× |
| GPT-OSS 120B 端到端加速比 (T=0) | Mean Speedup | EAGLE3 1.34× | 1.00× | +0.34×；N-Gram 0.29× 是全表最差，AR 完全撑不起验证开销 |
| DeepSeek R1 / Native MTP | Mean Speedup (T=0) | 1.45× | 1.00× | +0.45×；mean AL=2.55，证明预训练阶段就内嵌的 MTP head 接近 EAGLE3 的水准 |
| Qwen3 235B (SGLang) | Mean Speedup (T=0) | Vanilla 1.17× / EAGLE3 1.33× | 1.00× | +0.17× / +0.33×；EAGLE3 在 235B 规模上首次反超 Vanilla |
| Qwen3-Next (SGLang) | Mean Speedup (T=0) | EAGLE3 1.06× / MTP 1.20× | 1.00× | MTP 再次证明原生 head 比外挂 head 更高效，且 SGLang one-graph 不如 TensorRT-LLM 激进 |
| Llama 3.3 70B 高温 (T=1) 加速比 | Mean Speedup | Vanilla 1.15× / EAGLE3 1.75× | 1.00× | 高温采样下 Vanilla 的相对收益下降最明显（-0.45×），因 drafter 在高熵域更难命中目标分布 |
| Throughput Split 8k ISL 合成 vs SPEED-Bench | Average Throughput Gap | GPT-OSS 120B + EAGLE3 + DL=3 上合成输入高估 23% | SPEED-Bench 实测吞吐 | 证伪 random token 压测可用于 SD benchmark 的常见做法 |
| EAGLE3 词表裁剪 32k 影响 | AL 相对降幅 (DL=3) | Multilingual -10.05%、RAG -9.51%、Summarization -10.22% | Full vocabulary 下的 AL | 暴露了 EAGLE3 在词表长尾上的失败模式，是 MT-Bench 类小数据集完全看不见的 |
| 代理公式 vs 实测 speedup | Speedup estimation error | Llama 3.3 70B + EAGLE3 + BS=16 全部误差 ≤ 0.02× | 1.63× / 1.39× / 0.85× (高熵) 与 2.23× / 1.91× / 0.87× (低熵) 实测 | 把系统时延 × 领域 AL 分解为可分离的两段，可用于快速扫描未知域 |
局限与改进
作者明确指出三大局限：1) BS > 256 时 Python GIL 会成为客户端瓶颈，因此极高高吞吐场景的 measurement framework 还在扩展中；2) 主实验只评估 draft chain 而非 tree-based verification（虽已用 Qwen3 235B + EAGLE3 + SGLang 在附录 F 验证树形 top-k=8/DL=7 可拿到 AL=3.65，但生产上 BS>1 主要还是 chain 主导）；3) 评测目前覆盖五个目标模型和四类 drafter，对新兴方法如 MagicDec、LongSpec、REST、ParallelSpec 等的覆盖还不够全面。我自己的观察还有：1) Thin client 的 externalization 虽然保证了公平，但无法捕捉 chat template 在引擎内部的细微差异（例如 vLLM 与 TRT-LLM 对 multi-turn 历史的 BOS 处理顺序略有差别），跨引擎绝对数值仍有 ±2% 的不确定度；2) Throughput Split 的 padding 用固定后缀 please answer now，对超长 ISL（32k）下 attention sink 的影响未做敏感性分析，可能让 padding 占大头时 AR 偏高；3) EAGLE3 训练数据对 multilinguality 仅给 0.1× 采样权重，作者承认这是为了控制训练成本，但反过来也意味着 SPEED-Bench 揭示的多语言缺陷可能同时掺杂了训练分布偏差与裁剪偏差，单独归因到词表裁剪还需更严格的 ablation。
独立分析的弱点
独立分析几个可改进的弱点。第一，Qualitative Split 总样本只有 880（每类 80），对 Roleplay 类仍不够，因为 AL 相对波动有 0.6% 虽小但对单个 benchmark 的标准差仍可能在 ±0.02 AL 量级；改进方向是用更大候选池（如扩到 50k 候选）跑 Greedy，或者干脆把 $k$ 从 80 提到 200-300，毕竟 evaluation 成本随样本线性增长，权衡更宽松。第二，Throughput Split 强行把 ISL 对齐到 1k/2k/8k/16k/32k 这五个离散 bucket，对于工业上常见的 4k、12k 这种中间档位反而缺失曲线点；改进方向是加入 4k/12k 这两档，或允许用户自定义 bucket 大小，并报告连续 ISL 的 Pareto envelope。第三，thin client 目前要求所有引擎接收预 tokenize 后的 list[int]，无法探测某些引擎独有的内部优化（如 SGLang 的 RadixAttention 跨请求 KV 共享），这导致在多轮对话场景下不同引擎的绝对加速比并非严格 apples-to-apples；改进方向是允许引擎在隔离模式下独立处理 text，并用交叉验证子集去校准。第四，Greedy Selection 算法用了外部商用 API（OpenAI text-embedding-3-large）做 embedding，限制了 benchmark 的可复现性和成本可控性；改进方向是开源一个等价的多语 embedder（如基于 BGE-M3 或 NV-Embed-v2）作为离线备选。第五，appendix N 揭示 lmsys/EAGLE3-gpt-oss-120b-bf16 和 nvidia/gpt-oss-120b-Eagle3-long-context 在长 ISL 下 AL 骤降，但作者没给出系统性的 drafter 卡长上下文失败表，只在 GPT-OSS 120B 上做了实验；改进方向是把 drafter 长上下文鲁棒性单独做一个 leaderboard 子项目。
未来方向
作者已点名的未来工作包括：1) 把 measurement framework 扩展到 BS > 256，去掉 Python GIL 限制（用 multiprocessing 或 C++ 重写客户端）；2) 覆盖更多 SD 范式如 ParallelSpec、PARD、MagicDec、LongSpec 的真实生产评测；3) 把 EAGLE3 训练 ISL 与 RoPE scaling 配置做成最佳实践检查清单。基于成果可延伸的方向还有：1) 把 SPEED-Bench 的 Throughput Split 拓展为 drafter-aware batch scheduler 评测平台，让用户对比不同 continuous-batching 策略对 SD 收益的影响；2) 把 entropy 分桶做成 continuous 谱（用 GPT-OSS 的 logit entropy 或 Renyi entropy 排序）而不是离散三档，从而支持 fine-grained Pareto curve；3) 把 Greedy Selection 算法推广到多语种 embedding 池，做多语对齐的多样性最大化，有望进一步揭示 EAGLE3 等英文主导 drafter 在低资源语言上的真实失败模式；4) 与 AI engineering 流程结合，把 benchmark 跑出的 (AL, t_ar, t_sd) 三元组作为自动选择 drafter 候选的 oracle，嵌入到 vLLM/TRT-LLM 的 runtime 中。
复现评估
复现评估总体上较好。优点：1) 数据集全部基于 24 个公开数据集，已在 HuggingFace 上发布（链接见脚注），并且附带 subcategory、difficulty、turn count 等元字段，license 合规（如 GitHub 代码只取 MIT/Apache 2.0 仓库、CoSER 角色只取 Project Gutenberg 公版书）；2) 评测框架基于 Python asyncio 源码开源，能直接接到 vLLM v0.13.0、SGLang v0.5.7、TensorRT-LLM 1.2.0rc1/rc7 这三个具体版本；3) 算法细节（Algorithm 1 的 Greedy+Swap）有伪代码，并提供 QP 凸松弛作为对照（附录 C）；4) EAGLE3 训练细节在附录 I 完整公开，包括 Nemotron Post-Training Dataset V2、500k 样本、8xB200、AdamW + cosine LR 3e-4、3 epoch。不足：1) 主实验使用的 B200 单卡/8 卡硬件门槛较高，普通实验室难以复现 Llama 70B / Qwen3 235B 等大模型的完整 throughput 结果（部分 BS 较低的结果仍可在 A100/H100 上跑）；2) Greedy Selection 用的是 OpenAI text-embedding-3-large 商用 API，离线跑全套需要付费，作者未提供离线 embedder 备选；3) 部分第三方 drafter checkpoint（如 lmsys/EAGLE3-gpt-oss-120b-bf16）没有公开训练超参，无法复现其长上下文失效的原因；4) Throughput Split 的 padding 策略（please answer now 后缀）虽然简单但没有 ablation，敏感性未知。整体复现难度中等：跑 Qualitative Split 在 H100/A100 单卡 + 7B-13B 目标模型上几小时内即可完成；跑完整 Throughput Pareto 曲线则需要至少 8 卡 B200 + 70B 模型，整轮实验预计 1-2 周。
论文图表
