编辑推荐：
据报道，推测解码（Speculative Decoding, SD）的加速比难以比较，因为方法通常在不同的服务运行时和配置下进行评估。研究人员提出了SpecLLM，一个可插件评估框架，它在各方法间应用通用的调度、批处理、KV缓存（KV-cache）、CUDA图
据报道，推测解码（Speculative Decoding, SD）的加速比难以比较，因为方法通常在不同的服务运行时和配置下进行评估。研究人员提出了SpecLLM，一个可插件评估框架，它在各方法间应用通用的调度、批处理、KV缓存（KV-cache）、CUDA图（CUDA Graph）和执行后端（execution-backend）策略，同时保留方法所需的提议和验证路径。研究人员实现了八种推测解码（SD）方法，并在不同批次大小、受控在线负载和两种模型规模下进行了评估。研究人员将吞吐量加速比分解为??=??/??，其中??是每个SD步提交的平均令牌数，c是该步相对于匹配的自回归解码步的无量纲执行成本。测量的c取决于方法-运行时交互、硬件、工作负载、基线和配置。在评估条件下，方法排名随批次大小和在线负载而变化，并且当执行成本或排队增加时，更长的提交长度不一定产生更低的延迟。因此，SpecLLM提供了受控的运行时内可比性，而非运行时无关的公平性；SD结果应报告、延迟、可行性以及测量条件。
大语言模型（Large Language Model, LLM）推理中，自回归（Autoregressive, AR）生成因逐令牌依赖导致加速器并行性利用不足，成为系统瓶颈。推测解码（Speculative Decoding, SD）通过草稿模型生成候选令牌并由目标模型并行验证，旨在缓解此瓶颈。然而，不同SD方法的加速比报告难以直接比较，原因在于方法常基于不同服务运行时和配置评估，导致方法效果与实现效果混淆。现有基准（如Spec-Bench、SPEED-Bench）标准化了工作负载，但未控制运行时策略（如调度、批处理、KV缓存管理、CUDA图捕获等），因此需要统一框架实现受控比较。研究人员针对此问题设计了SpecLLM框架，相关成果发表在《Electronics》上。
研究人员在SpecLLM框架中实现了八种代表性SD方法，包括标准SD（Standard SD）、后缀解码（Suffix Decoding）、EAGLE3、SVIP、TurboSpec、LayerSkip、SV（Speculative Verification）和HSDDW（Hierarchical Speculative Decoding with Dynamic Windows）。评估使用Qwen3-14B（单GPU）和Llama-3.3-70B（四GPU）作为目标模型，搭配相应草稿模型（如Qwen3-0.6B），工作负载来自SPEED-Bench数据集的混合熵层，覆盖固定批次离线设置和泊松到达在线设置。通过分解吞吐量加速比??=??/??（??为每SD步平均提交令牌数，c为无量纲条件执行成本），研究人员分析了不同批次大小、在线负载和模型规模下的性能轨迹。
**5.1. 评估设置**：所有受控比较使用相同SpecLLM运行时，固定调度器、批处理、分页KV缓存、CUDA图、分块预填充及注意力/执行后端策略，同时保留各方法所需的验证布局、前向形状和辅助模型前向。评估在NVIDIA RTX PRO 6000 Blackwell Server Edition GPU上进行，共三次独立运行，结果以均值±标准差报告。
**5.2. 与生产引擎的公共子集比较**：研究人员将SpecLLM与vLLM 0.17.1和SGLang 0.5.13在公共可执行配置子集（Qwen3-14B目标、Qwen3-0.6B草稿、批次上限16）上比较。绝对吞吐量比率在0.93至1.13之间，均值±标准差范围覆盖1，表明各引擎性能接近，但EAGLE3比率较低。此结果仅适用于该子集，不推断其他方法或配置。
**5.3. 服务条件对平均排名的影响**：在Qwen3-14B离线设置下，评估批次大小从4到16，三种提示/输出长度配置。结果显示，EAGLE3（草稿长度6）的平均加速比从b4的2.24降至b16的0.93，甚至低于AR基线；而标准SD和TurboSpec在整个范围保持加速比>1。方法排名随批次大小变化，且不确定性区间重叠，因此描述为均值排名反转而非统计分离。
**5.4. 通过τ和c解释加速比**：在b8时，EAGLE3（草稿长度2）提交令牌数τ=2.26，但条件执行成本c=1.63，导致加速比S=1.39，低于标准SD（τ=1.76，c=0.96，S=1.85）。τ单独不能决定吞吐量性能，c的差异同样关键。跨b4至b16，c随批次增大而增加，不同方法轨迹不同，EAGLE3的c增长更快。
**5.5. 离线与在线差异**：比较离线b16与在线最大批次16（到达率0.4-0.8）的结果。在线平均加速比与离线存在差异，例如TurboSpec（草稿长度6）的ΔS=-0.03，HSDDW（草稿长度4）的ΔS=0.22。τ和c均随场景变化，表明离线结果不能直接迁移至在线服务。
**5.6. 在线延迟和排队行为**：在到达率0.4-0.8请求/秒下，标准SD和TurboSpec保持TPOT低于AR基线，且排队延迟较低。EAGLE3在原生容量12时仍保持加速比>1，但p95排队时间从0.4时的6.6秒增至0.8时的18.8秒，显示出严重的尾延迟。HSDDW和SV在到达率0.4时排队已超过84秒和69秒。因此，吞吐量、TPOT、TTFT、端到端延迟和排队必须共同报告。
**5.7. 跨模型规模评估**：在Llama-3.3-70B在线设置下，EAGLE3（草稿长度6）在到达率0.4时平均加速比1.79，但TTFT p95高达329秒；标准SD和TurboSpec加速比1.13-1.14，TTFT p95仅2.5-3.5秒。在辅助LayerSkip-Llama3-8B设置中，LayerSkip虽接受草稿令牌数高，但加速比接近1，表明执行成本抵消了提交增益。这些结果强调方法选择依赖于工件、硬件和延迟目标。
**5.8. 报告建议**：单一加速比值不足以解释SD性能，应联合报告τ、c、延迟、排队、可行性及条件参数。当均值轨迹跨越基线时，需报告上下界配置区间。
讨论部分总结：SD性能不能由运行时无关的加速比概括；方法选择依赖于工件、工作负载、运行时、硬件、延迟目标和可行批次容量。研究人员强调，SpecLLM提供的是受控运行时内比较，而非跨系统绝对公平性。研究结论（Section 9）翻译如下：报告的速度比是有条件的，取决于方法-工件配置、运行时、工作负载、硬件和匹配基线。SpecLLM通过分离通用运行时控制与插件接口解决了比较问题。对八种方法的评估显示，均值排名随条件变化，吞吐量和尾延迟可能导致不同操作结论。分解??=??/??使提交增益和条件执行成本显式化，但c仍是条件依赖的残差而非内在方法属性。因此，SD评估应共同报告τ、c、均值±标准差、延迟、排队、可行性、工件和运行时条件。未来工作应扩展评估至更多方法、硬件配置、量化方案、熵层级和流量混合，并纳入草稿模型训练与维护成本。
