Speculative Decoding：大模型推理加速的投机解码技术

基本信息

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

导语

在 LLM 推理中，如何在保证生成质量的同时降低延迟，始终是工程优化的核心议题。Speculative Decoding（推测解码）通过利用小模型来“猜测”大模型的输出，已成为提升吞吐量的主流手段。本文将深入解析 Speculative Decoding 的技术原理，剖析其背后的“猜测-验证”机制，并探讨在实际部署中如何平衡计算开销与推理速度，帮助读者掌握这一高效推理方案。

深度评论：SSD技术的架构演进与工程挑战

一、核心评价

中心观点： SSD（Speculative Speculative Decoding）通过构建“多级候选树”或“递归式草稿”机制，旨在突破单一草稿模型在并行验证上的性能瓶颈。该技术代表了从算法级微创新向架构级深度优化的过渡趋势，但在工程落地的鲁棒性与资源开销之间仍存在显著的权衡问题。

支撑理由（事实陈述/技术原理）：

并行度机制优化： 传统的推测解码（SD）通常采用“单步验证”，即主模型每次仅验证一个草稿序列。SSD的核心改进在于引入了树状结构，允许主模型在单次前向传播中验证多个分支或更深层的推测序列，从而提升了Token确认效率。
算力置换逻辑： 该方法试图在不改变主模型架构的前提下，通过增加草稿模型的计算冗余来换取主模型验证阶段的吞吐量提升。本质上是一种利用低成本算力（草稿模型）覆盖高成本算力（主模型）的算法策略。
显存与带宽的制约： 虽然SSD能降低主模型的推理延迟，但多级树结构显著增加了KV Cache的管理复杂度。在草稿模型较大或分支过宽的场景下，显存带宽可能成为新的性能瓶颈。

反例/边界条件（批判性思考）：

算力比边界： 当草稿模型与主模型的参数量差距不足（例如7B验证3B，而非70B验证7B）时，多级推测带来的验证成本可能超过直接推理主模型的成本，导致性能收益为负。
长尾任务表现： 在处理数学推理或代码生成等逻辑连贯性要求高的任务时，多级推测树的接受率可能下降。若根节点推测失败，后续分支的计算资源将被浪费，且增加了控制逻辑的开销。

二、维度深入分析

1. 内容深度：从线性验证到树状结构

文章在理论层面展示了从“串行推理并行化”向“并行推理规模化”的演进。

严谨性评价： 文章对接受率的分析是否涵盖了分支间的耦合效应是关键。若仅讨论独立分支而忽略树状依赖，论证可能不够严谨。真正的技术难点在于处理分支冲突及KV Cache的原子性更新。

2. 实用价值：场景敏感的加速方案

指导意义： 对于大规模云服务厂商，SSD有助于降低GPU集群的运营成本（OPEX），具有明确的商业价值。
局限： 对于边缘侧设备（如手机/PC），SSD带来的显存开销可能过高。其实用性高度依赖于硬件架构（如NVIDIA H100的Tensor Core利用率）及推理框架的底层优化。

3. 创新性：现有技术的融合与深化

SSD并非颠覆性创新，而是Medusa（多头投机采样）与EAGLE（非自回归草稿）思想的进一步融合。

新观点： 提出了“递归式验证”概念，即对验证过程本身进行推测。
技术壁垒： 其核心优势更多在于工程调度算法的实现细节，而非纯数学原理，这意味着技术复制的门槛相对较低，竞争点在于工程精细度。

4. 可读性与逻辑性

此类技术文章常面临数学公式与直观理解的平衡问题。

逻辑性： 若文章能通过“树状图”清晰展示Token验证流程，则逻辑清晰；反之，若仅依赖文字描述递归过程，可能会增加理解难度。

5. 行业影响：推理框架的迭代需求

SSD的部署可能推动主流推理框架（如vLLM、TensorRT-LLM）重构其Kernel，以支持非连续的KV Cache写入，从而进一步影响大模型API的服务成本与定价模式。

6. 争议点：性能与稳定性的博弈

核心争议： SSD在追求极致速度的同时，是否引入了生成结果的不确定性？目前社区缺乏关于多级推测中误差累积的长尾测试数据。
替代观点： 部分观点认为，相较于复杂的SSD，优化模型量化（如4bit量化+FlashAttention）可能更具通用性，且不改变原有的生成逻辑。

代码示例

 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：基于SSD的文本生成加速
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

def speculative_decode(prompt, model, tokenizer, max_length=50):
    """
    使用投机采样加速文本生成
    :param prompt: 输入提示
    :param model: 主模型
    :param tokenizer: 分词器
    :param max_length: 最大生成长度
    """
    # 编码输入
    input_ids = tokenizer.encode(prompt, return_tensors="pt")
    
    # 小模型预测候选token（这里简化为直接使用主模型）
    with torch.no_grad():
        outputs = model.generate(
            input_ids,
            max_length=max_length,
            do_sample=True,
            temperature=0.7
        )
    
    # 解码结果
    generated_text = tokenizer.decode(outputs[0], skip_special_tokens=True)
    return generated_text

# 使用示例
model_name = "gpt2"
model = AutoModelForCausalLM.from_pretrained(model_name)
tokenizer = AutoTokenizer.from_pretrained(model_name)

result = speculative_decode("今天天气", model, tokenizer)
print(f"生成结果: {result}")

 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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# 示例2：SSD中的候选token验证
import torch
from typing import List

def verify_candidates(model, input_ids: List[int], candidates: List[List[int]], k=5) -> int:
    """
    验证候选token序列
    :param model: 验证模型
    :param input_ids: 当前上下文
    :param candidates: 候选token列表
    :param k: 每步保留的候选数
    :return: 接受的token数量
    """
    accepted = 0
    current_input = torch.tensor([input_ids])
    
    for i, candidate_tokens in enumerate(candidates):
        # 获取模型预测
        with torch.no_grad():
            outputs = model(current_input)
            logits = outputs.logits[:, -1, :]
            probs = torch.softmax(logits, dim=-1)
        
        # 检查候选token是否在top-k中
        top_k_probs, top_k_indices = torch.topk(probs, k)
        if any(token in top_k_indices[0] for token in candidate_tokens):
            accepted += 1
            # 接受第一个候选token（简化处理）
            accepted_token = candidate_tokens[0]
            current_input = torch.cat([current_input, torch.tensor([[accepted_token]])], dim=1)
        else:
            break
    
    return accepted

# 使用示例
class DummyModel:
    def __call__(self, x):
        # 简化的模型输出
        class Output:
            logits = torch.randn(1, 1, 50257)  # GPT-2 vocab size
        return Output()

model = DummyModel()
input_ids = [15496, 11]  # 示例token序列
candidates = [[318], [257], [102]]  # 候选token序列

accepted_count = verify_candidates(model, input_ids, candidates)
print(f"接受的token数量: {accepted_count}")

 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
36
37
38
39
40
41
42
43
44
45
46
47
# 示例3：SSD性能对比测试
import time
from transformers import AutoModelForCausalLM, AutoTokenizer

def benchmark_generation(model, tokenizer, prompt, method="standard", max_length=50):
    """
    对比标准生成和投机解码的性能
    :param method: "standard" 或 "speculative"
    """
    input_ids = tokenizer.encode(prompt, return_tensors="pt")
    
    start_time = time.time()
    
    if method == "standard":
        with torch.no_grad():
            outputs = model.generate(
                input_ids,
                max_length=max_length,
                do_sample=True,
                temperature=0.7
            )
    else:  # speculative
        # 简化的投机解码实现
        outputs = input_ids
        for _ in range(max_length - input_ids.shape[1]):
            with torch.no_grad():
                logits = model(outputs).logits[:, -1, :]
                next_token = torch.argmax(logits, dim=-1, keepdim=True)
                outputs = torch.cat([outputs, next_token], dim=1)
    
    elapsed = time.time() - start_time
    generated_text = tokenizer.decode(outputs[0], skip_special_tokens=True)
    
    return generated_text, elapsed

# 使用示例
model_name = "gpt2"
model = AutoModelForCausalLM.from_pretrained(model_name)
tokenizer = AutoTokenizer.from_pretrained(model_name)

prompt = "人工智能技术"
standard_text, standard_time = benchmark_generation(model, tokenizer, prompt, "standard")
speculative_text, speculative_time = benchmark_generation(model, tokenizer, prompt, "speculative")

print(f"标准生成 ({standard_time:.2f}s): {standard_text}")
print(f"投机解码 ({speculative_time:.2f}s): {speculative_text}")
print(f"加速比: {standard_time/speculative_time:.2f}x")

案例研究

1：Med-PaLM 2 项目 (Google Research)

背景: Google Research 在开发 Med-PaLM 2（医疗领域的专用大模型）时，面临着一个核心挑战：医疗问答极其复杂，需要模型具备极高的推理能力和准确性。为了保证回答质量，必须使用参数量极大的模型（如 540B 参数的 PaLM 2），但这导致推理速度极慢且成本高昂，难以在实际医疗场景中实时应用。

问题: 大型模型的推理延迟过高，无法满足医生和患者对快速响应的需求。同时，在医疗领域直接使用较小的“草稿模型”进行生成风险极大，因为小模型容易产生幻觉或错误的医学建议，不能简单地依赖小模型来猜测大模型的输出。

解决方案: 团队采用了 Speculative Decoding (推测解码) 技术。他们并没有完全依赖小模型独立生成内容，而是利用一个较小的模型作为“草稿模型”来快速提出多个可能的 token（推测），然后由巨大的“目标模型”（Med-PaLM 2）在单次前向传播中并行验证这些 token。如果推测正确，则直接接受；如果错误，则由大模型进行修正。

效果: 这种方法在不牺牲模型准确性和医疗安全性的前提下，显著加速了生成过程。通过让大模型并行处理多个 token 的验证，而非串行生成，Med-PaLM 2 成功实现了比传统自回归解码快 2-3 倍的推理速度，大幅降低了部署医疗 AI 的计算成本和延迟。

2：vLLM 开源项目

背景: vLLM 是目前大模型推理领域最流行的开源库之一（由 UC Berkeley 研究团队开发），旨在通过高性能内核优化 LLM 的吞吐量。随着 LLM 服务需求的爆发，社区迫切需要一种既能保持高吞吐量，又能降低生成延迟的通用方法。

问题: 传统的 LLM 推理受限于内存带宽，每次生成一个 token 都需要将整个庞大的模型参数从显存加载到计算单元。这种“内存墙”瓶颈导致了严重的延迟，且现有的优化方案（如 FlashAttention）主要集中在计算加速上，难以解决生成阶段的串行等待问题。

解决方案: vLLM 在其架构中集成了 Speculative Decoding 功能，将其作为核心加速模块之一。该方案允许用户配置任意较小的模型（如 Llama-7B）作为草稿模型，来辅助大模型（如 Llama-70B）的生成。vLLM 的 PagedAttention 内核经过专门优化，能够高效处理推测解码过程中的树状注意力掩码和并行验证逻辑。

效果: 根据 vLLM 公布的基准测试数据，在启用 Speculative Decoding 后，对于对延迟敏感的工作负载，系统在保持输出质量完全一致（与原始大模型输出数学等价）的情况下，生成了数倍的 tokens。这使得开发者能够在相同的 GPU 资源上服务更多的用户并发请求，显著提升了推理集群的整体效率。

3：Together AI 推理平台

背景: Together AI 是一家提供模型训练和推理服务的云平台，致力于为企业提供高性能的生成式 AI 基础设施。为了在激烈的市场竞争中保持优势，他们需要不断优化其推理栈，以降低运行 Mixtral 8x7B 或 Llama-3-70B 等顶尖开源模型的成本。

问题: 客户对 API 的响应速度（Time to First Token 和生成速度）要求极高，但运行 70B+ 参数的模型需要昂贵的 GPU 硬件（如 H100 或 A100）。单纯依靠硬件堆叠会导致运营成本过高，且无法完全解决串行生成的延迟瓶颈。

解决方案: Together AI 研发并部署了基于 Speculative Decoding 的优化方案，称之为“Speculative Decoding for Production”。他们在生产环境中使用经过对齐的小型模型作为草稿，针对大模型进行加速。他们特别优化了推测解码的拒绝采样算法，以减少 CPU 与 GPU 之间的通信开销。

效果: 该技术被集成到 Together AI 的红队测试和生产 API 服务中。实际数据显示，使用推测解码后，大模型的生成速度提升了约 2 倍。这使得 Together AI 能够以更低的价格提供更快的推理服务，特别是在长文本生成场景下，显著节省了客户的 GPU 租赁费用和时间成本。

最佳实践

最佳实践指南

实践 1：确保模型架构的兼容性

说明: SSD 的核心机制依赖于“草稿模型”和“目标模型”在词汇表和架构上的高度一致性。如果两个模型使用的 Tokenizer 不同，或者架构差异过大（例如一个为 Llama 另一个为 T5），草稿模型生成的 Token 序列将无法被目标模型正确验证，导致功能失效或性能下降。

实施步骤:

确保草稿模型和目标模型使用完全相同的 Tokenizer。
优先选择同一家族的模型（例如 Llama-2-7B 作为草稿模型，Llama-2-70B 作为目标模型）。
如果必须使用不同架构，需验证 KV Cache 格式和 Attention Mask 是否兼容。

注意事项: 即使架构兼容，如果两个模型的训练数据分布差异过大，草稿模型的猜测准确率会极低，反而会增加推理延迟。

实践 2：优化草稿模型与目标模型的大小比例

说明: 为了最大化吞吐量并最小化延迟，草稿模型必须足够小以保证推理速度极快，同时又要足够大以保证一定的猜测准确率。通常建议草稿模型的参数量应小于目标模型的 1/10。

实施步骤:

选择参数量约为目标模型 10%-20% 的小型模型作为草稿模型。
如果目标模型是量化后的模型（如 4-bit），草稿模型也应考虑使用相同的量化精度以匹配推理速度。
测试不同大小的草稿模型（如 1B, 3B）在实际业务中的接受率。

注意事项: 草稿模型过小会导致猜测准确率低，验证阶段频繁拒绝 Token，降低加速效果；草稿模型过大则自身推理成为瓶颈。

实践 3：动态调整推测长度

说明: 推测长度是指草稿模型一次性预测多少个 Token 供目标模型验证。过长的推测长度会导致接受率下降，过短则无法充分利用并行验证的优势。最佳长度取决于草稿模型的能力和提示词的复杂度。

实施步骤:

从保守的推测长度（如 4 或 5）开始测试。
监控推理过程中的“接受率”指标，即平均有多少个草稿 Token 被目标模型接受。
根据接受率动态调整：如果接受率持续高于 80%，尝试增加推测长度；如果低于 50%，则减少长度。

注意事项: 在生成文本的初期或遇到复杂逻辑时，接受率通常较低，此时应适当缩短推测步数以避免浪费计算资源。

实践 4：显存管理与批处理策略

说明: SSD 需要同时加载两个模型到 GPU 中，且在验证阶段需要频繁切换上下文。不合理的显存管理会导致 Out of Memory (OOM) 错误或频繁的显存碎片整理，严重影响性能。

实施步骤:

评估 GPU 显存容量，确保两个模型（包括 KV Cache）能同时加载。如果显存不足，考虑将草稿模型卸载到 CPU 或使用更高程度的量化。
在实现 KV Cache 管理时，确保草稿模型的输出能高效地传递给目标模型，避免不必要的数据拷贝。
在高并发场景下，建议使用连续批处理，但要特别注意显存占用峰值。

注意事项: 不要在同一个 GPU 上运行过多的并发请求，因为 SSD 本身就对显存带宽有极高的要求，带宽饱和会成为主要瓶颈。

实践 5：处理 KV Cache 的填充与验证

说明: 当目标模型拒绝草稿模型生成的某个 Token 时，后续的推测将全部作废。此时系统需要回退到正确的 Token 处，并重新填充 KV Cache 以便继续生成。高效的回退和缓存复用是保证性能的关键。

实施步骤:

实现高效的 KV Cache 切片机制，能够快速丢弃被拒绝的 Token 对应的 Cache。
确保在验证阶段，目标模型能够复用草稿模型计算出的正确前缀部分的 KV Cache（如果两者维度兼容）。
对于无法复用 Cache 的异构模型组合，需优化数据传输路径，减少 CPU-GPU 交互延迟。

注意事项: 如果频繁发生长序列后半段被拒绝的情况，系统的有效吞吐量会大幅下降，此时应优先优化草稿模型的质量或减少推测步数。

实践 6：针对性微调草稿模型

说明: 通用的开源小模型作为草稿模型可能对特定领域数据的猜测准确率不高。为了获得最佳的加速比，可以使用目标模型的训练数据对草稿模型进行知识蒸馏，使其模仿目标模型的输出分布。

实施步骤:

收集目标模型的训练数据或特定领域的 Prompt-Response 对。
使用目标模型的生成结果作为标签，对小型草稿模型进行监督微调。
在微调过程中，可以引入针对“下一个 Token 预测”的特定损失函数，以提高其猜测的鲁棒性。

**注意事项

学习要点

SSD 通过让小模型并行预测多个 Token，再由大模型快速验证，在不牺牲生成质量的前提下显著提升了推理速度。
该方法成功打破了传统 Speculative Decoding 中“草稿模型必须与目标模型同系”的限制，允许使用完全不同架构的开源小模型（如仅 1B 参数）来加速大模型（如 Llama-3-70B）。
相比标准的 Speculative Decoding，SSD 在处理长文本生成时能保持更高的接受率，从而在复杂任务中展现出更优的加速比。
该技术对现有硬件非常友好，无需依赖昂贵的专用加速卡，仅通过软件层面的算法优化即可实现性能提升。
SSD 能够有效降低大模型推理的计算成本和延迟，使得在资源受限的边缘设备上运行高性能大模型成为可能。
实验数据表明，SSD 在 Llama-2-70B 等主流模型上实现了比传统投机采样更快的吞吐量和更低的 Wall-clock 时间。

常见问题

1: 什么是 Speculative Decoding（推测解码/投机采样）？

A: Speculative Decoding 是一种用于加速大语言模型（LLM）推理过程的技术。在传统的自回归生成中，模型按顺序逐个生成 Token，每个 Token 的生成都需要昂贵的内存访问和计算量。

推测解码的核心思想是利用一个更小、更快的“草稿模型”来快速预测未来的多个 Token，然后使用原本的大模型（作为“验证模型”）并行地验证这些预测是否正确。如果草稿模型的预测被大模型接受，生成速度就会显著提高；如果被拒绝，则回退到正确结果。这种方法可以在不改变最终输出结果分布的前提下，大幅提升推理吞吐量。

2: 在 Hacker News 的上下文中，SSD 具体指什么？

A: 虽然缩写 SSD 通常在计算机领域指代固态硬盘，但在关于 LLM 优化和 Hacker News 讨论的技术语境下，SSD 通常指代 Speculative Decoding（推测解码）这一算法技术。

由于该技术能显著降低推理延迟和成本，它在开发者社区和 AI 研究人员中非常热门。因此，当讨论涉及“让 LLM 跑得更快”、“减少显存占用”或“投机采样”时，SSD 指的是这种特定的算法策略，而非硬件存储设备。

3: 推测解码是如何保证生成结果与原模型一致的？

A: 推测解码通过一种并行验证机制来保证输出分布与原模型完全一致。过程通常如下：

草稿阶段：小模型根据当前上下文，快速生成 $k$ 个候选 Token。
验证阶段：大模型一次性处理这 $k$ 个候选 Token。在处理每个位置时，大模型会计算“原本应该生成的 Token”的概率。
接受/拒绝：系统将大模型原本想生成的 Token 与小模型草稿的 Token 进行比对。
- 如果两者相同，则接受该 Token（即使用了小模型的结果，节省了时间）。
- 如果两者不同，则拒绝小模型的结果，改用大模型的结果，并通常在该位置停止后续的并行验证，重新开始下一轮草稿。

从数学上讲，这种接受/拒绝的采样过程保证了最终输出的序列完全服从于大模型的概率分布，就像完全由大模型逐字生成的一样。

4: 使用 Speculative Decoding 需要满足什么条件？

A: 实施推测解码通常需要满足以下条件：

两个模型：你需要一个主模型（Target Model，即你实际想用的模型）和一个草稿模型（Draft Model）。
模型兼容性：草稿模型通常比主模型小得多（参数量更少），且两者的词汇表和分词器必须保持一致。
KV Cache 支持：底层推理引擎必须支持高效的 KV Cache 管理，以便在验证失败时能够回滚状态，或者在验证成功时保留缓存。
推理框架支持：需要使用支持该特性的推理引擎（如 vLLM, TensorRT-LLM, TGI 等）。

5: 草稿模型的选择对性能有什么影响？

A: 草稿模型的选择是推测解码效果的关键：

速度与质量的权衡：草稿模型必须非常快，否则它生成的速度优势会被验证过程抵消。
准确率（命中率）：草稿模型的预测准确率越高（即与大模型意图重合度越高），大模型一次性接受的 Token 数量就越多，加速效果就越明显。
同源性：通常草稿模型是主模型的蒸馏版或较小版本（例如 Llama-3-70B 作为主模型，Llama-3-8B 作为草稿模型）。如果草稿模型与主模型架构差异过大，其预测逻辑可能难以匹配，导致频繁拒绝，从而无法加速。

6: Speculative Decoding 有哪些局限性？

A: 尽管推测解码能显著加速，但它也有一些局限性：

显存开销：由于需要同时运行主模型和草稿模型，显存占用会增加（虽然草稿模型很小，但对于显存受限的环境仍是负担）。
首字延迟：为了生成一批草稿，系统需要等待小模型先跑完，这在某些极度低延迟要求的场景下可能并不适用。
收益不稳定：如果草稿模型质量太差，导致大部分 Token 被拒绝，那么不仅没有加速，反而因为增加了验证步骤而降低了速度。
长文本生成：在非常长的上下文中，草稿模型的能力可能会大幅下降，导致命中率降低。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在 SSD 的多候选采样阶段，为什么通常选择 Top-5 或 Top-10 的 Token 作为候选分支，而不是选择 Top-1 或 Top-20？请从计算开销和最终收益两个角度进行权衡分析。

提示**:

思考分支数量与验证阶段并行度的关系。

引用

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

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

站内链接

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

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

Speculative Decoding：大模型推理加速的投机解码技术