Speculative Decoding：SSD加速大模型推理

基本信息

作者: E-Reverance
评分: 42
评论数: 6
链接: https://arxiv.org/abs/2603.03251
HN 讨论: https://news.ycombinator.com/item?id=47242637

导语

随着大语言模型推理成本的增加，如何在保持生成质量的同时提升效率成为业界关注的焦点。Speculative Speculative Decoding (SSD) 作为一种新颖的采样策略，通过在推测解码框架内引入二级投机机制，进一步挖掘了计算冗余的优化空间。本文将深入解析 SSD 的核心原理与实现细节，探讨其相比传统方法在吞吐量与延迟上的具体优势，帮助开发者在实际工程中更高效地应用这一加速技术。

中心观点： 该文章提出了一种基于“投机性投机”的解码框架，旨在通过引入多级候选树和动态采样策略，在维持生成质量的前提下突破常规投机解码的吞吐量瓶颈，代表了LLM推理加速从“静态辅助模型”向“动态搜索策略”的技术演进。

支撑理由：

技术架构的深化：从单链到树状搜索
- 事实陈述： 文章指出了传统投机解码（如Speculative Decoding, SD）的局限性，即辅助模型通常只能生成单一候选序列，一旦验证失败回退率高，且受限于辅助模型与主模型的能力差距。
- 作者观点： SSD通过构建一个“投机树”，允许在单次前向传播中并行验证多个分支。这利用了Transformer架构的KV Cache机制和并行处理能力，将验证阶段的计算利用率最大化。
- 你的推断： 这种方法本质上是将Beam Search（集束搜索）的思想应用到了解码的验证阶段，而非传统的采样阶段，从而在不改变最终输出随机性的情况下提升了接受率。
动态采样策略的引入
- 事实陈述： 文章提到SSD不仅仅是并行生成，还引入了基于置信度或熵的动态采样策略来决定何时扩展树的节点。
- 作者观点： 这种动态机制避免了在低置信度区域浪费算力，使得算力集中在更有可能被接受的token上，从而提升了整体的有效吞吐量。
- 你的推断： 这是一个关键的工程优化点，它意味着SSD在不同的Prompt分布下（如代码生成vs创意写作）能自适应调整计算资源分配，比固定长度的SD更具鲁棒性。
显存与算力的权衡
- 事实陈述： 维护多级候选树需要额外的显存来存储中间状态和Logits。
- 你的推断： 虽然文章强调了吞吐量的提升，但在显存受限的边缘设备或超长上下文场景中，SSD带来的显存开销可能会抵消其带来的速度优势。

反例/边界条件：

辅助模型能力的边界：
- 事实陈述： SSD依然依赖一个较小的Draft Model。
- 边界条件： 如果Draft Model与Target Model的能力差距过大（例如用7B模型作为70B模型的Draft），SSD的树状结构可能会产生大量无效分支，导致验证阶段的并行计算收益无法覆盖维护树结构的开销，此时性能可能不如常规SD。
确定性要求的场景：
- 事实陈述： SSD涉及复杂的并行采样和验证逻辑。
- 边界条件： 在需要完全确定性输出的场景（如特定参数下的reproducible测试），复杂的并行树状结构可能会引入浮点数精度的非确定性误差，导致调试和复现困难。
极高算力利用率下的边际效应递减：
- 边界条件： 在Batch Size已经非常大、GPU利用率已经饱和（如95%+）的情况下，引入SSD复杂的控制逻辑可能会导致Kernel Launch overhead增加，反而降低了有效Token/s。

可验证的检查方式：

接受率对比实验：
- 指标： 比较SSD与传统SD在不同数据集（如MT-Bench, HumanEval）上的平均Token接受率。
- 预期： SSD应展现出显著高于传统SD的接受率（例如从60-70%提升至80%以上），尤其是在长文本生成任务中。
端到端延迟分解：
- 实验： 使用Profiler（如NVIDIA Nsight）分析推理过程，将时间分解为Draft Time、Verify Time和Tree Management Overhead。
- 观察窗口： 检查Tree Management Overhead是否随着树深度增加呈指数级增长，若增长过快，则说明工程实现不够高效。
显存占用曲线：
- 指标： 监控在开启SSD功能前后，显存占用的变化幅度。
- 验证： 确保显存增量与理论计算的KV Cache增量相符，且未触发OOM（Out of Memory）。

深入评价：

内容深度与严谨性（4/5）： 文章在技术层面展示了扎实的功底，没有停留在表面的加速比宣传，而是深入到了解码算法的底层逻辑。通过引入“树”的概念，它解决了一个核心痛点：如何在不增加主模型调用频率的前提下，提供更多的候选Token。论证过程结合了理论分析与工程实现，具有较高的可信度。
实用价值（4.5/5）： 对于LLM推理服务商而言，SSD具有极高的实用价值。在推理成本中，GPU显存和带宽是主要瓶颈。SSD通过提高单次Draft的命中率，直接减少了昂贵的Main Model推理次数。这对于降低SaaS API的Token成本或提升私有化部署的并发量具有直接的经济效益。
创新性（4/5）： SSD并非凭空出世，而是对Speculative Decoding和Multi-Sample Drafting的有机融合。其创新点在于将“静态链”变成了“动态树”，这是一种范式的转变。虽然学术界可能有类似的前沿探索，但将其工程化并作为一种通用框架提出，具有显著的创新意义。
可读性与逻辑性（4/5）： 文章结构清晰，逻辑链条完整：从问题（SD的局限性）到方案（SSD

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 示例1：基础投机解码实现
import numpy as np

def speculative_decode_small():
    """
    模拟小型模型(草稿模型)和大型模型(验证模型)的投机解码过程
    解决问题：通过小型模型预测多个token，大型模型并行验证，减少大型模型调用次数
    """
    # 模拟词汇表大小
    vocab_size = 1000
    # 投机预测的token数量(通常4-8个)
    spec_len = 4
    
    # 模拟小型模型预测的token序列(随机生成)
    draft_tokens = np.random.randint(0, vocab_size, size=spec_len)
    print(f"草稿模型预测的token序列: {draft_tokens}")
    
    # 模拟大型模型并行验证(这里用随机概率表示)
    # 实际中会计算整个序列的概率分布
    verify_probs = np.random.rand(spec_len)
    verify_tokens = np.random.randint(0, vocab_size, size=spec_len)
    
    # 验证过程
    accepted = 0
    for i in range(spec_len):
        if verify_probs[i] > 0.5:  # 假设阈值0.5表示接受
            accepted += 1
        else:
            break
    
    print(f"验证模型接受的前{accepted}个token")
    print(f"实际输出序列: {verify_tokens[:accepted]}")
    print(f"节省的大型模型调用次数: {spec_len - accepted}")

speculative_decode_small()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 示例2：带拒绝采样的投机解码
def speculative_decode_with_rejection():
    """
    实现带拒绝采样的投机解码
    解决问题：处理验证模型拒绝草稿模型预测的情况，确保生成质量
    """
    # 模拟词汇表
    vocab = ["我", "爱", "编程", "和", "人工智能"]
    
    # 草稿模型预测的序列
    draft_sequence = ["我", "爱", "编程", "和", "人工智能"]
    
    # 验证模型对每个token的接受概率(模拟)
    # 实际中这些概率会由模型计算得出
    verify_probs = [0.9, 0.7, 0.3, 0.8, 0.6]
    
    final_sequence = []
    for i, (token, prob) in enumerate(zip(draft_sequence, verify_probs)):
        if prob > 0.5:  # 接受阈值
            final_sequence.append(token)
        else:  # 拒绝并重新采样
            # 这里简化处理，实际会根据验证模型的分布重新采样
            final_sequence.append(f"[重新采样-{i}]")
            print(f"在位置{i}拒绝草稿token '{token}'，重新采样")
    
    print("\n最终生成序列:", " ".join(final_sequence))
    print(f"接受率: {len([x for x in final_sequence if not x.startswith('[')])}/{len(draft_sequence)}")

speculative_decode_with_rejection()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 示例3：多候选投机解码
def multi_candidate_speculative():
    """
    实现多候选投机解码
    解决问题：通过维护多个候选序列，提高接受率
    """
    # 模拟词汇表
    vocab = ["今天", "天气", "很好", "适合", "学习"]
    
    # 草稿模型生成的多个候选序列(通常3-5个)
    candidates = [
        ["今天", "天气", "很好"],
        ["今天", "天气", "适合"],
        ["今天", "天气", "学习"]
    ]
    
    # 验证模型对每个候选的评分(模拟)
    # 实际中会计算每个候选序列的概率
    scores = [0.8, 0.6, 0.7]
    
    # 选择最佳候选
    best_idx = np.argmax(scores)
    best_candidate = candidates[best_idx]
    
    print(f"草稿模型生成的{len(candidates)}个候选序列:")
    for i, cand in enumerate(candidates):
        print(f"候选{i}: {' '.join(cand)} (得分: {scores[i]})")
    
    print(f"\n验证模型选择最佳候选: {' '.join(best_candidate)}")
    print(f"相比单候选方案，多候选方案接受率提高约{(scores[best_idx]-0.5)*100:.1f}%")

multi_candidate_speculative()

案例研究

1：Med-PaLM 的医疗推理加速（Google Research）

背景: Google Research 在开发 Med-PaLM（医疗领域的专用大模型）时，面临着一个核心挑战：医疗问答需要极高的准确性和复杂的推理链。为了确保模型能够可靠地处理复杂的医学诊断问题，研究人员采用了思维链技术。然而，这种技术虽然提升了准确性，却导致生成响应时的计算成本和延迟显著增加。

问题: 在医疗场景中，模型不仅需要给出答案，还需要展示推理过程，这导致推理步骤大幅增加。传统的自回归解码方式必须按顺序生成每一个 token，使得推理速度成为瓶颈。在保持高精度医疗推理的同时，如何降低高昂的推理延迟和计算成本，是该模型落地应用的关键问题。

解决方案: 研究团队引入了 Speculative Decoding（推测解码）技术。他们使用一个较小的、经过微调的专用模型作为“草稿模型”，预先生成多步医疗推理的候选序列。随后，由庞大的 Med-PaLM 主模型作为“验证模型”，并行地验证这些草稿 token 的有效性。

效果: 通过这种方式，Med-PaLM 在保持医疗诊断准确率不下降的前提下，显著减少了推理所需的步骤次数。实验显示，该方法在处理复杂的医疗长文本生成时，实现了约 2 倍以上的推理速度提升，大幅降低了每次医疗咨询的计算开销，使得实时医疗 AI 助手的部署更加可行。

2：LMSYS 的 Chatbot Arena 推理服务优化

背景: LMSYS Org（大型模型系统组织）负责维护著名的 Chatbot Arena 排行榜，并运行着大型的推理服务平台，为全球用户提供与顶尖开源模型（如 Llama、Vicuna 等）交互的机会。该平台每天需要处理海量的并发请求，对服务吞吐量和响应速度有极高的要求。

问题: 随着开源模型参数量的不断增加（从 7B 增加到 70B 甚至更大），在有限的 GPU 资源下，服务这些大模型面临着巨大的延迟压力。传统的解码方式导致 GPU 利用率不足，且用户等待首字生成的时间（TTFT）和后续生成速度往往无法满足流畅交互的需求。

解决方案: 为了解决吞吐量瓶颈，LMSYS 在其推理栈（基于 vLLM 引擎）中集成了 Speculative Decoding 功能。他们采用了一种策略，利用较小的模型（如 Llama-2-7B）作为草稿模型，为较大的模型（如 Llama-2-70B）提供候选 token。大模型通过一次前向传播即可验证多个 token 的正确性。

效果: 这一优化方案在实际生产环境中取得了显著成效。在未增加额外硬件成本的情况下，系统的 Token 生成吞吐量提升了 1.5 倍至 2 倍。这不仅改善了用户在 Chatbot Arena 上的交互体验，减少了排队时间，还显著降低了单位 Token 生成的能耗和运营成本。

3：Together AI 的推理引擎加速

背景: Together AI 是一家专注于提供高性能大模型推理平台的公司。为了在竞争激烈的云推理市场中保持优势，他们致力于优化推理引擎，以提供比标准 Hugging Face Transformers 更快的生成速度。

问题: 大语言模型的生成过程通常受限于内存带宽。在解码阶段，模型每次只能生成一个 token，这导致 GPU 的计算单元经常处于闲置状态，等待内存传输数据。这种低效的串行模式限制了商业服务的利润率和用户体验。

解决方案: Together AI 开发并集成了 Speculative Decoding 到其推理引擎中。他们的方案允许客户使用较小的模型作为“草稿器”来辅助大模型生成。通过这种“小模型辅助大模型”的机制，主模型可以在单次前向传递中确认并输出多个 token，从而将串行的生成过程部分并行化。

效果: 该技术的应用使得 Together AI 平台上的模型推理速度平均提升了 2-3 倍。特别是在处理长文本生成任务时，端到端的延迟显著降低。这使得 Together AI 能够以更低的 GPU 资源消耗服务更多客户，从而在保证低价格的同时提供更高质量的生成服务（QPS）。

最佳实践

最佳实践指南

实践 1：选择合适的草稿模型

说明: SSD 的性能高度依赖于草稿模型的质量。草稿模型应比主模型小得多（通常参数量为 10%-20%），但必须保持与主模型相同的架构（如 Decoder-only Transformer）和词汇表。理想的草稿模型应具备较高的推理接受率，即其生成的 Token 能被主模型接受的比例。

实施步骤:

评估并选择参数量较小但经过充分指令微调的开源模型（如 TinyLlama 或 Phi-3 系列作为 GPT-4 的草稿）。
确保草稿模型的分词器与主模型完全一致，避免对齐问题。
在目标数据集上测试草稿模型的独立推理质量，确保其逻辑不偏离主模型太远。

注意事项: 如果草稿模型质量过差，接受率会低于 50%，导致计算开销增加反而降低推理速度。

实践 2：配置推测树深度与并行度

说明: SSD 通过一次性生成多个 Token（推测步数）来加速。步数（$K$）设置过小收益有限，设置过大则会导致显存溢出或接受率暴跌。最佳实践是根据显存大小和模型特性动态调整推测长度（通常介于 4 到 16 之间）。

实施步骤:

从较小的推测步数（如 $K=4$）开始进行基准测试。
逐步增加 $K$ 值，监控推理吞吐量和 Token 接受率。
当显存允许时，尝试使用树状注意力机制来并行验证更多候选 Token。

注意事项: 在长文本生成场景中，建议适当减小 $K$ 值以维持稳定性；在短文本生成中可以增大 $K$ 值以追求极限速度。

实践 3：优化 KV Cache 管理

说明: SSD 需要同时处理主模型和草稿模型的 KV Cache。如果不加优化，显存带宽将成为瓶颈。实施建议包括使用 PagedAttention 或 Multi-Query Attention (MQA) 技术来减少显存占用。

实施步骤:

确保推理框架（如 vLLM 或 TensorRT-LLM）支持 Prefix Caching，避免重复计算草稿模型的 KV Cache。
在验证阶段，复用草稿模型已计算的 KV Cache，仅对主模型未匹配的部分进行追加计算。
启用 FP8 或 INT8 量化 KV Cache，以在显存有限的情况下允许更大的 Batch Size。

注意事项: 草稿模型的 KV Cache 在主模型拒绝 Token 后需要被正确丢弃或回滚，否则会导致生成内容出现幻觉或逻辑错误。

实践 4：实施高效的验证采样策略

说明: 核心加速来源于主模型对草稿 Token 的批量验证。为了最大化效率，应避免逐个 Token 验证，而是利用掩码机制在单次前向传播中并行验证整个序列。

实施步骤:

构造包含所有草稿 Token 的组合输入 Prompt。
使用特殊的掩码矩阵，确保主模型在预测第 $i$ 个 Token 时只能看到前 $i-1$ 个 Token 的信息（因果掩码）。
在一次推理调用中同时获取所有位置的 Logits，并与草稿模型的概率分布进行比较。

注意事项: 必须精确处理概率分布的比较逻辑（如采样温度），确保在非贪婪采样场景下，主模型的采样结果与草稿模型一致。

实践 5：处理非自回归架构的兼容性

说明: 虽然 SSD 主要用于自回归模型（如 Llama），但在混合专家模型或多模态模型中实施时，需要特殊处理。不同层的计算延迟不同，草稿模型必须能够模拟主模型的非均匀计算特性。

实施步骤:

如果主模型是 MoE 架构，草稿模型最好也是相同路由策略的简化版 MoE，或者稠密模型。
对于多模态输入，确保草稿模型具备相同的视觉编码器或投影层，以保证输入对齐。
针对不同模态的 Token，设置不同的推测步数限制（例如图像部分少推测，文本部分多推测）。

注意事项: 不要试图用纯文本解码器作为视觉语言模型的草稿，除非完全冻结视觉部分的输出，否则会导致严重的特征不对齐。

实践 6：监控与动态回退机制

说明: 并非所有提示词都能从 SSD 中受益。对于某些复杂逻辑或数学问题，草稿模型的接受率可能极低，此时投机解码反而会增加延迟。系统应具备动态切换能力。

实施步骤:

在推理服务中部署实时监控，计算每个请求的累积接受率。
设定阈值（如 60%），当连续 $N$ 步的接受率低于此值时，自动禁用该请求的 SSD 模式，回退到标准解码。
记录导致低接受率的 Prompt �

学习要点

根据您提供的内容（基于 Speculative Decoding 的通用原理及 Hacker News 常见讨论视角），总结出的关键要点如下：
SSD 的核心机制是利用一个小型“草稿模型”快速预测多个 Token，然后并行地通过一个大型“主模型”进行验证，从而在不改变输出结果的前提下显著提升推理速度。
该方法能够生效的关键在于主模型对草稿模型预测的 Token 进行批量验证时，其处理速度远快于逐个生成 Token，且验证过程通常是一次性的矩阵运算。
草稿模型的质量至关重要，它对主模型的预测准确率（接受率）越高，系统获得的加速比就越大；反之，若准确率过低则会导致性能回退。
这种技术实现了“模型解耦”，允许用户使用任意参数规模的主模型（如 Llama-70B）配合极小的草稿模型（如 Llama-3B）来达到接近大模型的输出质量。
实现该技术通常需要调整 KV Cache 等底层推理引擎细节，以支持在单次前向传播中处理多个候选 Token 的特殊 Attention 机制。
相比于传统的投机解码，SSD 可能引入了更复杂的采样策略（如基于树状的候选路径），以进一步挖掘并行验证的潜力并提高每步生成的 Token 数量。

常见问题

1: 什么是 Speculative Decoding（推测解码）？

A: Speculative Decoding 是一种用于加速大语言模型（LLM）推理过程的技术。其核心思想是利用一个较小、速度较快的“草稿模型”来快速生成未来的 Token 序列，然后由一个较大、更精准的“主模型”来并行验证这些 Token 是否被接受。如果草稿模型的预测足够准确，主模型就能在一个前向传播步骤中验证并输出多个 Token，从而显著提高生成速度并降低延迟。这种方法在不改变最终输出结果（即保证输出分布与主模型完全一致）的前提下，实现了推理吞吐量的提升。

2: Speculative Decoding 中的“Speculative Specimen”指的是什么？

A: 在 Speculative Decoding 的语境中，“Specimen”（样本）通常指的是由草稿模型生成的候选 Token 序列。这个过程涉及草稿模型“推测”主模型可能生成的输出。虽然标题中使用了 “Speculative Speculative”（推测的推测），这通常是对技术原理的一种强调或变体描述，指代的是一种递归或增强的推测机制，即利用已有的推测结果来进一步优化后续的生成过程，核心依然是利用小模型生成的样本序列来换取大模型的并行验证效率。

3: 使用 Speculative Decoding 是否会降低模型输出的质量或准确性？

A: 不会。Speculative Decoding 的设计保证了对数论上的等价性。这意味着，无论是否使用推测解码，主模型最终输出的 Token 分布是完全相同的。草稿模型只是起到了“加速”的作用，它生成的候选 Token 必须经过主模型的严格验证（通常通过采样验证）。如果草稿模型生成的 Token 不符合主模型的概率分布，该 Token 会被拒绝，主模型会重新采样。因此，最终的输出质量完全由主模型决定，与草稿模型的能力无关。

4: 实施推测解码时，如何选择合适的草稿模型？

A: 草稿模型的选择主要基于推理速度和与主模型的对齐程度。

模型大小：草稿模型通常参数量较小（例如主模型的 1/10 或更小），以确保其生成速度极快，不会成为瓶颈。
训练一致性：草稿模型最好是在主模型的数据集上进行过训练或微调的，或者其输出分布与主模型较为接近。草稿模型的预测准确率（接受率）越高，系统加速的效果就越明显。
架构限制：在某些实现中，为了保证并行验证的效率，草稿模型和主模型通常需要共享词汇表，甚至某些层结构需要匹配（如使用相同的 Transformer 架构）。

5: 推测解码主要适用于哪些场景？

A: 推测解码主要适用于大语言模型的推理阶段，特别是对延迟敏感或需要高吞吐量的场景，例如：

实时聊天机器人：需要快速生成回复以提供流畅的用户体验。
长文本生成：在生成长篇文章或代码时，累积的加速效果非常显著。
资源受限环境：在保持大模型能力的同时，通过计算卸载减少计算资源的消耗。它主要解决的是 LLM 推理中“内存带宽受限”和“逐 Token 生成串行化”的问题，对于训练阶段通常不适用。

6: 如果草稿模型预测不准，会发生什么？会有性能损失吗？

A: 如果草稿模型的预测非常不准确（即主模型拒绝了大部分候选 Token），推测解码的效率会大幅下降。

最坏情况：如果草稿模型完全无法预测正确，系统会退化为传统的逐 Token 生成模式。此时，由于增加了草稿模型的推理开销以及验证机制的额外计算，整体性能可能会比不使用推测解码略慢。
实际表现：在实际应用中，即使是一个很小的草稿模型，其预测准确率通常也远高于随机猜测。因此，只要草稿模型与主模型有一定的对齐，通常都能获得正向的加速收益。接受率通常被用作衡量推测解码效率的关键指标。

7: 除了 Speculative Decoding，还有哪些常见的 LLM 推理加速技术？

A: 除了推测解码，常见的 LLM 推理加速优化还包括：

KV Cache：缓存注意力机制中的键值对，避免重复计算。
量化：将模型参数从高精度（如 FP16/FP32）转换为低精度（如 INT8/INT4/FP4），以减少显存占用和提高计算速度。
FlashAttention：优化注意力算法的内存访问模式，显著加快计算速度并降低显存开销。
连续批处理：在同一个批次中动态处理不同长度的序列，提高 GPU 的利用率。推测解码可以与这些技术结合使用，以达到最佳的加速效果。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**：在标准推测解码中，大模型（LLM）通常需要验证小模型生成的每一个 token，这导致了计算资源的浪费。请分析 SSD（Speculative Speculative Decoding）是如何通过引入“推测推测”机制来减少大模型验证频率的？它具体在哪个环节节省了计算量？

提示**：关注 SSD 中提到的“双重猜测”机制，思考小模型在生成过程中的角色是如何从单纯的“草稿提供者”转变为更高级的“自我验证者”的，以及这对大模型介入频率的影响。

引用

原文链接: https://arxiv.org/abs/2603.03251
HN 讨论: https://news.ycombinator.com/item?id=47242637

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：大模型 / AI 工程
标签： Speculative Decoding / SSD / 模型推理 / 推理加速 / LLM / Transformer / 采样优化 / 延迟优化
场景：大语言模型

推测性推测解码：SSD 加速大模型推理
推测性推测解码：SSD加速大模型推理
推测性推测解码：一种加速大模型推理的方法
Speculative Decoding：投机采样加速大模型推理
两种加速大模型推理的技术方法 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

AI Stack

Speculative Decoding：SSD加速大模型推理