推测解码与连续批处理深度实战：突破自回归生成的双重瓶颈

引言：自回归生成的根本瓶颈

大语言模型（LLM）的自回归（autoregressive）生成方式是其推理速度的根本瓶颈所在。每一步生成都必须依赖前一步的输出，导致推理过程是严格串行的。更关键的是，每个 token 的生成都需要加载完整的模型权重进行前向计算——对于 70B 参数量的模型，这意味着每一步都要读取约 140GB 的权重数据（FP16），使得推理过程成为内存带宽受限（memory-bandwidth bound）而非计算受限（compute-bound）的操作。

在传统的自回归生成中，生成一个包含 n 个 token 的响应需要 n 次串行前向传播，每次计算都只能利用 GPU 算力的一小部分。以 A100 80GB 为例，其理论算力为 312 TFLOPS（FP16），但内存带宽仅为 2TB/s。对于一个 70B 模型，单步推理的算术强度（arithmetic intensity）约为 1-2 FLOP/byte，远低于 A100 的"屋顶线"（roofline）拐点（约 150 FLOPS/byte），这意味着 GPU 的计算单元绝大部分时间都在等待数据加载。

本文将深入探讨当前最核心的两项推理优化技术：推测解码（Speculative Decoding）和连续批处理（Continuous Batching），从数学原理、工程实现到性能调优，全方位拆解高性能推理系统的设计。

一、推测解码（Speculative Decoding）：用草稿换速度

1.1 核心洞察：大部分 token 是"容易的"

推测解码的核心洞察是：虽然从语言模型的概率分布中精确采样是困难的，但大多数 token 实际上是"容易预测的"。给定前文"今天北京的天气"，下一个 token 是"晴朗"或"很好"的概率极高，这种 token 即使使用一个小型模型（draft model）也能准确生成。

与之相对，在某些"困难"的决策点上——例如需要进行逻辑推理、数学计算或事实核查的 token——小模型可能会出错，这时就需要用原始的大模型（target model）来验证。这种"草稿-验证"（draft-verify）的模式，避免了小模型串行生成时的精度损失。

1.2 数学原理

具体来说，推测解码的每一步执行以下过程：

1. 草稿阶段：使用小型草稿模型 M_q 自回归地生成 γ 个 token（x_{t+1}, ..., x_{t+γ}）
2. 验证阶段：使用目标大模型 M_p 并行地同时验证所有 γ+1 个 token 的概率分布
3. 接受/拒绝：对每个位置 i（从 1 到 γ），按以下规则决定：
   • 以概率 min(1, p_i(x) / q_i(x)) 接受该 token（其中 p 是目标模型分布，q 是草稿模型分布）
   • 被拒绝时，从分布 clip(p_i - q_i, 0) 重新采样一个 token
4. 输出保证：最终输出的 token 序列与直接由目标模型 M_p 采样得到的分布完全一致

这是一个极其优美的性质：推测解码不是近似算法，它在数学上等价于目标模型的原始采样分布。无论草稿模型的接受率多低，都不会降低输出质量。

1.3 加速比的数学分析

设草稿模型的接受率为 α（每个 token 被接受的概率），草稿模型的推理速度为目标模型的 c 倍（c > 1，因为小模型更快），则期望加速比可以近似为：

E[加速比] ≈ (1 - α^(γ+1)) / (1 - α) × (c / (1 + cγ))

直观理解：当草稿模型与目标模型高度相关（α 接近 1）时，加速比趋近于约 c，即接近草稿模型与目标模型的速度比。当接受率低时，加速比接近 1x（无加速但也不会减速）。实践中，对于同系列模型（如 LLaMA-70B + LLaMA-7B），典型加速比为 2-3x。

1.4 Speculative Decoding vs Medusa vs Lookahead Decoding

推测解码并非唯一的并行解码方案，当前主要有三种路线：

• Speculative Decoding (Leviathan et al., 2023)：需要独立的草稿模型，需要额外显存但实现简洁
• Medusa (Cai et al., 2024)：在目标模型上训练多个额外的"预测头"（multi-head），同时预测未来多个 token，无需草稿模型，代价是需要额外训练开销
• Lookahead Decoding (Fu et al., 2023)：使用 Jacobi 迭代的思想，用目标模型自身的 n-gram 缓存做草稿，完全不需要额外模型，在 batch 场景下表现尤佳

二、连续批处理（Continuous Batching）：让 GPU 不再空转

2.1 传统静态批处理的致命缺陷

在传统的静态批处理（static batching）中，一个 batch 中的所有请求必须同时开始、同时结束。这意味着：当某个请求已经生成完毕（输出了 EOS token），它仍然要占据 GPU 内存，等待 batch 中最慢的请求完成。

在 LLM 推理中，不同请求的输出长度差异巨大——有些只需要十几个 token，有些则需要数千个 token。这种"木桶效应"导致 GPU 资源的严重浪费：短请求完成后显存无法释放、新请求无法插入正在运行的 batch、GPU 算力在最慢请求的生成期间被大量闲置。实测表明，在动态负载下，静态批处理的 GPU 利用率通常只有 20-40%。

2.2 Continuous Batching（迭代级调度）

Continuous Batching（也称为 iteration-level scheduling 或 batching with chunking）的核心思想是：在每个 decoding step 之后动态地添加和移除请求。其工作流程如下：

1. Scheduler 维护一个 running queue 和一个 waiting queue
2. 每个 iteration 开始时，检查是否有请求已完成（生成 EOS 或达到 max_tokens）
3. 将已完成的请求移出 batch，释放其占用的 KV Cache 空间
4. 从 waiting queue 中取出新请求加入 batch（前提是有足够的 KV Cache 槽位）
5. 执行一次前向传播，处理 batch 中所有活跃请求的一步解码

这种精细化的调度使得 GPU 几乎不会因为等待而被闲置。

2.3 Prefill 与 Decoding 的相位分离

Continuous Batching 面临的一个关键挑战是 prefill 阶段（处理输入 prompt）和 decoding 阶段（逐 token 生成输出）的特性差异：Prefill 一次性处理整个 prompt，属于 compute-bound（算力受限）；Decoding 单步只处理一个 token，属于 memory-bandwidth bound（带宽受限）。如果它们混合在同一批次中，prefill 的长计算会阻塞 decoding 步骤，导致已运行请求的解码延迟波动。

现代引擎的解决方案包括：Chunked Prefill（将长 prompt 分成多个 chunk，每个 iteration 只处理一个 chunk，与 decoding 无缝混合）和分离式调度（Disaggregated Serving）（将 prefill 和 decoding 分配到不同的 GPU 上分别执行，避免相互干扰，这是 vLLM v0.6+ 和 TensorRT-LLM 的最新方向）。

三、工程实现：vLLM 与 TGI 中的实战优化

3.1 vLLM 的调度器设计

vLLM 的 Scheduler 是 Continuous Batching 的典范实现，其调度策略如下：decoding 请求优先于 prefill 请求（降低 TTFT 对 TFT 的影响）；通过 enable_chunked_prefill=True 启用 Chunked Prefill，将 prefill 限制在 max_num_batched_tokens 内分块执行；当 GPU KV Cache 不够时将部分请求的 KV 暂时 swap 到 CPU 内存。

关键参数调优：max_num_seqs（最大并发请求数）、max_num_batched_tokens（每 iteration 最大 token 数）、gpu_memory_utilization（KV Cache 显存比例，默认 0.90）。

3.2 TensorRT-LLM 的 In-Flight Batching

HuggingFace TGI 使用的 TensorRT-LLM 实现了类似的 "in-flight batching"，其特色在于：GPT Attention Kernel 融合减少 kernel launch overhead、CUDA Graph 捕获对固定 shape 计算部分加速、FP8/INT4 量化结合 KV Cache 量化进一步降低显存占用。

3.3 推测解码在 vLLM 中的配置

vLLM v0.4+ 已内置推测解码支持。两种主要配置方式：使用独立草稿模型（如 LLaMA-7B 配合 LLaMA-70B），或启用基于 n-gram 缓存的推测解码（无需额外模型，适合显存受限场景）。

四、性能基准与实测

在标准测试条件下（A100 80GB × 2, LLaMA-2-70B, input 512 tokens, output 128 tokens），典型结论是：开启推测解码后有显著吞吐提升，与 KV Cache 优化带来的 batch 增长效应叠加，综合吞吐可达基础方案的 2-4 倍；TTFT 通过 chunked prefill 等方案可降低约 40-60%；动态负载下 GPU 利用率从 20-40% 提升至 80-95%。

五、前沿方向：从单卡到集群

推理优化仍在快速演进，当前前沿方向包括：Paged KV Cache 在多机多卡环境中的分布式扩展、MoE 架构下的推测解码 token 路由策略、以及结合量化 KV Cache 提升单卡上下文窗口至百万 token。这些技术共同推动着推理吞吐量的持续提升和单 token 成本的不断下降。

六、总结：推理优化的层次体系

高性能 LLM 推理系统的优化可分为多个层次：算法层面包括推测解码等降低 step 数的策略、调度层面有连续批处理最大化 GPU 利用率、系统层面通过 KV Cache 管理等技术优化显存效率。这些技术相互叠加而非替代，共同构筑起现代推理引擎的能力边界。

理解这些核心技术的原理，不仅有助于正确选择和配置推理引擎，也是深入理解分布式系统、操作系统和计算机体系结构之间关系的绝佳切入点——毕竟，优化 GPU 利用率的本质，与当年优化 CPU 和内存利用率的哲学一脉相承。