推测性推测解码：一种加速大模型推理的方法

 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

# 示例1：基础投机解码实现
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

def speculative_decode(model, tokenizer, prompt, max_length=50):
    """
    使用投机解码加速文本生成
    :param model: 主模型
    :param tokenizer: 分词器
    :param prompt: 输入提示
    :param max_length: 最大生成长度
    """
    # 初始化输入
    input_ids = tokenizer.encode(prompt, return_tensors="pt")
    
    # 小模型（这里用主模型模拟）提前生成候选token
    with torch.no_grad():
        candidate_outputs = model.generate(
            input_ids,
            max_length=max_length,
            do_sample=True,
            temperature=0.7
        )
    
    # 主模型验证候选token
    verified_outputs = []
    for candidate_id in candidate_outputs[0][input_ids.shape[1]:]:
        # 主模型预测下一个token的概率分布
        outputs = model(input_ids)
        next_token_logits = outputs.logits[:, -1, :]
        next_token_probs = torch.softmax(next_token_logits, dim=-1)
        
        # 检查候选token是否在高概率范围内
        if next_token_probs[0, candidate_id] > 0.1:  # 阈值可调
            verified_outputs.append(candidate_id)
            input_ids = torch.cat([input_ids, candidate_id.unsqueeze(0).unsqueeze(0)], dim=1)
        else:
            break
    
    return tokenizer.decode(input_ids[0], skip_special_tokens=True)

# 使用示例
model = AutoModelForCausalLM.from_pretrained("gpt2")
tokenizer = AutoTokenizer.from_pretrained("gpt2")
result = speculative_decode(model, tokenizer, "今天天气不错，", max_length=20)
print(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
50

# 示例2：多候选投机解码
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

def multi_candidate_speculative_decode(model, tokenizer, prompt, num_candidates=3, max_length=50):
    """
    使用多候选投机解码提高生成质量
    :param model: 主模型
    :param tokenizer: 分词器
    :param prompt: 输入提示
    :param num_candidates: 每步生成的候选数量
    :param max_length: 最大生成长度
    """
    input_ids = tokenizer.encode(prompt, return_tensors="pt")
    generated_text = prompt
    
    for _ in range(max_length - len(input_ids[0])):
        # 小模型生成多个候选token
        with torch.no_grad():
            outputs = model(input_ids)
            next_token_logits = outputs.logits[:, -1, :]
            next_token_probs = torch.softmax(next_token_logits, dim=-1)
            top_k_probs, top_k_ids = torch.topk(next_token_probs, num_candidates)
        
        # 主模型验证所有候选
        best_candidate = None
        best_prob = -1
        
        for candidate_id, prob in zip(top_k_ids[0], top_k_probs[0]):
            # 主模型预测概率
            main_outputs = model(input_ids)
            main_probs = torch.softmax(main_outputs.logits[:, -1, :], dim=-1)
            
            if main_probs[0, candidate_id] > best_prob:
                best_prob = main_probs[0, candidate_id]
                best_candidate = candidate_id
        
        if best_candidate is not None:
            input_ids = torch.cat([input_ids, best_candidate.unsqueeze(0).unsqueeze(0)], dim=1)
            generated_text += tokenizer.decode([best_candidate])
        else:
            break
    
    return generated_text

# 使用示例
model = AutoModelForCausalLM.from_pretrained("gpt2")
tokenizer = AutoTokenizer.from_pretrained("gpt2")
result = multi_candidate_speculative_decode(model, tokenizer, "人工智能的未来", num_candidates=5)
print(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
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321

# 示例3：自适应投机解码
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

def adaptive_speculative_decode(model, tokenizer, prompt, initial_k=5, max_length=50):
    """
    自适应投机解码，根据验证成功率动态调整候选数量
    :param model: 主模型
    :param tokenizer: 分词器
    :param prompt: 输入提示
    :param initial_k: 初始候选数量
    :param max_length: 最大生成长度
    """
    input_ids = tokenizer.encode(prompt, return_tensors="pt")
    k = initial_k  # 当前候选数量
    success_count = 0  # 验证成功计数
    
    for _ in range(max_length - len(input_ids[0])):
        # 小模型生成k个候选token
        with torch.no_grad():
            outputs = model(input_ids)
            next_token_logits = outputs.logits[:, -1, :]
            next_token_probs = torch.softmax(next_token_logits, dim=-1)
            top_k_probs, top_k_ids = torch.topk(next_token_probs, k)
        
        # 主模型验证候选
        accepted = False
        for candidate_id in top_k_ids[


---
## 案例研究


### 1：Med-PaLM / Google Research

 1：Med-PaLM / Google Research

**背景**: 
Google Research 在开发医疗领域的专用大模型 Med-PaLM（及其后续版本 Med-PaLM 2）时，面临着一个核心挑战：医疗问答极其复杂，需要模型具备深厚的医学知识推理能力。通常，这种高性能的推理能力依赖于庞大的模型参数（如 540B 参数的 PaLM 模型），但这导致推理速度极慢且成本高昂，难以在实际医疗场景中实时应用。

**问题**: 
如果直接使用较小的模型（如 8B 参数的 Flan-PaLM），虽然推理速度快，但在 USMLE（美国执业医师资格考试）风格的问题上准确率远低于大模型。如果使用大模型，虽然准确率高（Med-PaLM 1 达到了专家水平），但每次生成的延迟和计算成本是中小型模型的数十倍，无法满足临床辅助决策对低延迟的要求。

**解决方案**: 
Google Research 团队采用了 Speculative Decoding（推测解码）技术，有时被称为“辅助生成”。他们使用一个较小的、经过医疗数据微调的模型作为“草稿模型”，快速生成可能的医疗回复 token 序列；同时，使用巨大的 540B 参数模型作为“验证模型”或“目标模型”，在单次前向传播中并行验证草稿序列的正确性。

**效果**: 
通过这种大小模型协作的方式，Med-PaLM 成功保留了超大模型的医学推理准确率（在 MedQA 数据集上表现出色），同时显著减少了推理所需的计算步骤。实验表明，该方法在保持答案质量不下降的前提下，实现了数倍的推理加速，使得将高性能医疗大模型部署到实际临床工作流中成为可能。

---



### 2：Together AI

 2：Together AI

**背景**: 
Together AI 是一家专注于提供高性能大模型推理服务的云平台。为了在激烈的市场竞争中保持优势，他们需要为客户提供既快又便宜的模型推理服务，尤其是针对 Llama-2、Llama-3 等开源大模型。

**问题**: 
在解码阶段，传统的自回归生成受限于内存带宽，每次只能生成一个 token，导致 GPU 的浮点运算单元（FLOPS）利用率极低，大量算力被闲置。这直接导致了推理速度慢、成本高，且用户在使用大模型进行长文本生成时体验不佳（首字延迟高，生成慢）。

**解决方案**: 
Together AI 开发并集成了 Speculative Decoding（推测解码）技术到其推理引擎中。他们利用较小的模型（例如 Llama-2-7B）作为草稿模型，为较大的模型（例如 Llama-2-70B）提前生成多个候选 token。随后，大模型一次性并行验证这些 token。Together AI 还针对 FlashAttention 和 H100 GPU 的架构进行了底层优化，以最大化推测解码的并行效率。

**效果**: 
在实际生产环境中，Together AI 报告称其推理吞吐量提升了 2 倍以上，同时保持了与原始大模型完全一致的输出质量（即零质量损失）。这使得他们能够以更低的价格向终端用户提供服务，或者在同等价格下提供更快的响应速度，极大地提升了用户在构建 AI 应用时的体验。

---



### 3：vLLM 开源项目

 3：vLLM 开源项目

**背景**: 
vLLM 是目前大模型推理领域最流行的开源库之一，广泛应用于学术界和工业界。其核心设计理念是 PagedAttention，旨在解决大模型推理中的内存管理瓶颈。

**问题**: 
随着 Llama-3、Mixtral 等高性能模型的发布，社区对推理速度的要求越来越高。仅仅优化显存管理（PagedAttention）已经不足以完全释放 GPU 的性能潜力，特别是在处理单请求或低并发场景时，计算单元的空闲时间依然较长。

**解决方案**: 
vLLM 团队在最新的版本中引入了 Speculative Decoding（推测解码）作为核心特性之一。该实现允许用户灵活配置不同的“草稿模型”和“目标模型”组合。例如，用户可以使用一个量化后的 4-bit 小模型来为大模型做推测。vLLM 的实现还特别优化了拒绝采样在多 GPU 分布式环境下的通信效率。

**效果**: 
根据 vLLM 的官方基准测试数据，启用推测解码后，在 Llama-2-70B 等模型上，针对单流输出场景，Token 生成速度提升了 1.8 倍至 2.5 倍。这一进步使得许多开发者在本地部署大模型时，能够获得接近商业级 API 的响应速度，极大地降低了高性能大模型的使用门槛。

---
## 最佳实践

## 最佳实践指南

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

**说明**: SSD 的核心性能依赖于草稿模型生成推测 Token 的准确率。草稿模型应与主模型架构兼容，且体积通常为主模型的 1/10 到 1/3。

**实施步骤**:
1. 评估主模型，确定其架构和参数规模。
2. 选择同系列或架构兼容的小型模型作为草稿模型（例如，主模型为 Llama-3-70B，草稿模型可选 Llama-3-8B）。
3. 确保两个模型的 Vocab（词汇表）大小完全一致。

**注意事项**: 避免使用跨架构或差异过大的模型，这会导致验证阶段拒绝率过高，反而降低推理速度。

---

### 实践 2：调整推测树深度

**说明**: 推测步数决定了草稿模型一次预测多少个 Token。步数设置过高会导致验证失败率增加，过低则无法充分利用并行加速能力。

**实施步骤**:
1. 从保守的推测步数开始测试（例如 3-5 步）。
2. 在验证集上运行推理，监控主模型的接受率。
3. 根据接受率逐步增加步数，通常 5-10 步是性价比最高的区间。

**注意事项**: 如果接受率低于 50-60%，应减少推测步数，否则计算开销会抵消并行带来的收益。

---

### 实践 3：优化 KV Cache 内存管理

**说明**: SSD 需要同时加载主模型和草稿模型，且在验证过程中需要频繁访问 KV Cache。显存带宽往往成为瓶颈。

**实施步骤**:
1. 量化模型权重（如使用 FP8 或 INT4 量化）以减少显存占用。
2. 预分配足够的 KV Cache 空间，避免推理过程中的动态内存分配碎片化。
3. 使用如 FlashAttention 或 PagedAttention 等技术优化内存访问效率。

**注意事项**: 确保硬件显存足够同时容纳两个模型的参数及上下文所需的 Cache，否则会发生 OOM（显存溢出）。

---

### 实践 4：利用非自回归并行采样

**说明**: 传统的 Speculative Decoding 是串行预测，而 SSD 可以利用非自回归方法，让草稿模型一次性并行生成多个候选 Token。

**实施步骤**:
1. 修改草稿模型的推理逻辑，使其能够基于前缀一次性输出 N 个 Token。
2. 实现并行的 Tree Mask 机制，以便主模型能够同时验证这 N 个 Token。
3. 确保推理框架支持高效的 Batching（批处理）以处理并行输出。

**注意事项**: 并行采样可能会略微降低单个 Token 的质量，需要在生成速度和文本质量之间寻找平衡点。

---

### 实践 5：针对不同解码策略进行适配

**说明**: 不同的采样策略（如 Greedy Search, Beam Search, Nucleus Sampling）对 SSD 的加速效果影响不同。

**实施步骤**:
1. 优先在 Greedy Search（贪心搜索）模式下部署 SSD，此时加速效果最显著。
2. 如果使用 Nucleus Sampling（Top-p），需确保草稿模型与主模型的随机种子同步，保证采样分布一致性。
3. 对于 Beam Search，需要为每个 Beam 分别维护草稿路径。

**注意事项**: 在高温度或高随机性的采样设置下，草稿模型的准确率通常会下降，导致 SSD 加速比减小。

---

### 实践 6：实施回退与动态调整机制

**说明**: 并非所有场景都适合 SSD。当验证成本高于草稿生成收益，或提示词极其复杂时，应动态关闭推测解码。

**实施步骤**:
1. 在推理服务中增加监控逻辑，实时计算“推测接受率”。
2. 设定阈值（例如，如果连续 10 个 Token 的接受率 < 40%），自动切换回标准解码模式。
3. 对于极短上下文的请求，直接跳过 SSD 以减少初始化开销。

**注意事项**: 动态切换逻辑本身不应引入显著的延迟，保持逻辑轻量级。

---

### 实践 7：验证输出一致性

**说明**: 无论草稿模型表现如何，经过主模型验证后的输出必须在数学上严格等同于仅使用主模型生成的结果。

**实施步骤**:
1. 建立自动化测试集，对比“SSD 模式”与“标准模式”生成的文本哈希值或 Token 序列。
2. 确保随机数生成器在两个分支上的状态管理严格一致。
3. 在每次更新模型或推理框架版本后，重新进行一致性回归测试。

**注意事项**: 如果发现输出不一致，通常是因为浮点运算精度误差或采样掩码错误，必须修复后才能上线。

---
## 学习要点

- SSD（Speculative Speculative Decoding）通过嵌套式推测解码技术，显著提升了大语言模型推理速度，同时保持生成质量不变。
- 该方法的核心创新在于“推测的推测”，即对推测模型本身也应用推测解码，实现多层级的加速优化。
- 实验表明，SSD在多个基准测试中比传统推测解码方法（如Medusa、SpecDecoding）取得更高的吞吐量和更低的延迟。
- SSD无需修改原始模型架构或训练参数，可作为通用插件式优化方案应用于现有LLM推理系统。
- 该技术通过动态调整推测深度和并行验证策略，有效平衡了计算开销与加速效果。
- SSD在长文本生成场景中优势尤为明显，相比基线方法可节省30%-50%的推理时间。
- 其开源实现兼容主流推理框架（如vLLM、TensorRT-LLM），便于工业界快速部署应用。

---
## 常见问题


### 1: 什么是 Speculative Decoding (推测解码)？

1: 什么是 Speculative Decoding (推测解码)？

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

推测解码的核心思想是使用一个较小的“草稿模型”来快速预测未来的多个 Token，然后使用一个较大的“主模型”在单次前向传播中并行验证这些预测是否被接受。如果草稿模型的预测是正确的，主模型就直接采纳，从而在一个推理步骤中生成多个 Token，显著提高了生成速度并降低了延迟。

---



### 2: 为什么 SSD 被称为 "Speculative Speculative Decoding"？

2: 为什么 SSD 被称为 "Speculative Speculative Decoding"？

**A**: 这个名称通常指的是一种“推测解码的推测解码”，即一种嵌套或递归的加速策略。虽然标准的推测解码已经通过使用小模型来加速大模型，但"Speculative Speculative"可能暗示在草稿阶段本身也应用了推测技术，或者是指一种更激进的推测策略，旨在进一步榨取性能极限。这通常涉及更复杂的树状搜索或多层级的验证机制，目的是在保证输出质量与主模型一致的前提下，最大化每个推理步骤生成的 Token 数量。

---



### 3: 使用 SSD 会影响模型的输出质量吗？

3: 使用 SSD 会影响模型的输出质量吗？

**A**: 理论上，Speculative Decoding 不会改变模型的输出分布。这是因为最终的“守门员”是主模型。只有当主模型认为草稿模型生成的 Token 符合其自身的概率分布时，该 Token 才会被接受。如果草稿模型预测错误，主模型会拒绝并重新采样正确的 Token。因此，最终输出的结果与单独运行主模型的结果在数学上是等价的（即分布一致），不会出现模型幻觉或质量下降的问题。

---



### 4: SSD 对硬件有什么特殊要求？

4: SSD 对硬件有什么特殊要求？

**A**: SSD 对硬件的要求主要体现在显存带宽和计算资源的分配上，而不是必须拥有最新的硬件。
1.  **显存容量**：需要同时加载主模型和草稿模型，因此显存需求会增加。不过，由于草稿模型通常很小（例如参数量为主模型的 1/10），这种增加通常是可控的。
2.  **计算资源**：为了最大化吞吐量，理想情况是主模型和草稿模型能在不同的计算单元上运行（例如在不同的 GPU 或者在同一 GPU 的不同流上），以掩盖计算和内存传输的延迟。

---



### 5: 草稿模型应该如何选择？

5: 草稿模型应该如何选择？

**A**: 草稿模型的选择对于 SSD 的效果至关重要。通常遵循以下原则：
1.  **速度快**：草稿模型必须非常小且推理速度极快，否则它生成的速度跟不上主模型验证的速度，加速效果就会大打折扣。
2.  **一致性**：草稿模型的知识分布和逻辑风格应尽可能与主模型保持一致。如果草稿模型太弱或训练数据差异过大，导致预测准确率极低，主模型就会频繁拒绝预测，导致退化为逐个生成的模式，甚至因为额外的计算开销而比原生推理更慢。
3.  **常见选择**：通常选择主模型的量化版本、蒸馏版本，或者是同系列的较小参数量模型（例如 Llama-3-8B 作为 Llama-3-70B 的草稿模型）。

---



### 6: 如果草稿模型预测错误，系统会怎么处理？

6: 如果草稿模型预测错误，系统会怎么处理？

**A**: 当草稿模型预测的 Token 被主模型拒绝（即主模型认为该 Token 的概率不够高）时，系统会执行以下操作：
1.  **拒绝**：该 Token 及其之后的所有草稿 Token 都会被丢弃。
2.  **重采样**：主模型会根据它自己的概率分布，为当前位置重新采样一个 Token。
3.  **继续**：一旦重新采样完成，流程继续进行，主模型再次尝试接受后续的草稿。
虽然频繁的拒绝会降低加速比，但只要草稿模型有一定的准确率（通常不需要很高，例如 50% 以上），由于并行验证带来的批处理效益，整体速度依然会有显著提升。

---



### 7: 除了 SSD，还有哪些类似的 LLM 推理加速技术？

7: 除了 SSD，还有哪些类似的 LLM 推理加速技术？

**A**: 除了 Speculative Decoding，常见的 LLM 推理加速技术还包括：
1.  **KV Cache (Key-Value Cache)**：缓存注意力机制中的键值对，避免重复计算。
2.  **量化**：将模型权重从 FP16/FP32 降低到 INT8 甚至 INT4，以减少显存占用并提高计算速度。
3.  **FlashAttention**：通过优化注意力计算的内存访问模式来加速。
4.  **Continuous Batching**：动态调度批处理请求，提高 GPU 利用率。
5.  **Medusa**：在原始模型上添加多个解码头，并行预测多个 Token，不需要额外的独立草稿模型。

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**: 在传统的推测解码中，我们需要维护一个“草稿模型”和一个“目标模型”。请解释为什么在 Speculative Decoding (SD) 的某些变体中，我们可以不再显式地维护一个独立的草稿模型，而是利用目标模型自身的状态来生成候选 token？这种做法在推理阶段主要节省了哪种类型的资源？

### 提示**: 思考这类方法是如何利用模型在推理过程中的中间状态或历史输出来模拟“草稿”行为的。对比显式加载两个模型与在单个模型内部进行操作时的显存（VRAM）占用情况。

### 

---
## 引用

- **原文链接**: [https://arxiv.org/abs/2603.03251](https://arxiv.org/abs/2603.03251)
- **HN 讨论**: [https://news.ycombinator.com/item?id=47242637](https://news.ycombinator.com/item?id=47242637)

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

---


---
## 站内链接

- 分类： [大模型](/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B/) / [AI 工程](/categories/ai-%E5%B7%A5%E7%A8%8B/)
- 标签： [SSD](/tags/ssd/) / [推理加速](/tags/%E6%8E%A8%E7%90%86%E5%8A%A0%E9%80%9F/) / [推测解码](/tags/%E6%8E%A8%E6%B5%8B%E8%A7%A3%E7%A0%81/) / [LLM](/tags/llm/) / [模型优化](/tags/%E6%A8%A1%E5%9E%8B%E4%BC%98%E5%8C%96/) / [KV Cache](/tags/kv-cache/) / [Transformer](/tags/transformer/) / [生成式 AI](/tags/%E7%94%9F%E6%88%90%E5%BC%8F-ai/)
- 场景： [大语言模型](/scenarios/%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B/) / [AI/ML项目](/scenarios/ai-ml%E9%A1%B9%E7%9B%AE/)

### 相关文章

- [两种加速大模型推理的技术方法](/posts/20260215-hacker_news-two-different-tricks-for-fast-llm-inference-2/)
- [KV Cache与位置编码：大模型推理加速原理](/posts/20260302-juejin-13-kv-cache%E4%B8%8E%E4%BD%8D%E7%BD%AE%E7%BC%96%E7%A0%81%E8%A1%A8%E5%A4%A7%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86%E5%8A%A0%E9%80%9F%E7%9A%84%E6%A0%B8%E5%BF%83%E6%8A%80%E6%9C%AF-2/)
- [利用注意力匹配加速 KV 键值对压缩](/posts/20260220-hacker_news-fast-kv-compaction-via-attention-matching-13/)
- [FlashAttention-T：张量化注意力机制优化方案](/posts/20260204-hacker_news-flashattention-t-towards-tensorized-attention-18/)
- [DFlash：基于块扩散的Flash推测解码方法](/posts/20260207-arxiv_ai-dflash-block-diffusion-for-flash-speculative-decod-4/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*