LLM推理每秒只能吐几个token，你以为是算力不够？错了——根子在内存带宽，今天我把Speculative Decoding这条路彻底算清楚了

LLM 推理每秒只能吐几个 token，你以为是算力不够？错了——根子在内存带宽。今天我把 Speculative Decoding 这条路彻底算清楚了。

先说一个你一定经历过的场景

你让 AI 帮你生成一段代码，或者让它解释一段报错——然后盯着进度条等它一个字一个字地吐出来。慢的时候，一个完整回复要等十几秒甚至更久。

这个时候你可能会想：是不是 GPU 算力不够？是不是模型太大了？

都不是。 真正的瓶颈，99% 的人都忽略了一个底层事实——LLM 推理是内存带宽受限（memory-bandwidth-bound），不是计算受限。

具体来说：每生成一个 token，GPU 都要把整个模型的权重从显存（HBM）加载到计算单元。对于一个 70B 参数的模型，仅模型权重在 FP16 下就占约 140GB——加载一次就要走一遍显存带宽。这个操作的特点是：顺序读取 + 反复执行，GPU 的并行计算能力根本没被用上。

这就是 Speculative Decoding（投机解码）要解决的核心问题。

它的工作原理：两个人打配合

Speculative Decoding 的思路很优雅，本质上是用两个模型打配合：

第一步：小模型（Draft）快速”猜”多个 token。 这个小模型可以是 0.5B~3B 参数，生成速度极快。比如它猜：”Paris”、”is”、”the”、”capital”。

第二步：大模型（Target / Verifier）并行验证所有猜测。 注意这里是一次前向传播并行验证 K 个 token，而不是逐个生成。整个 transformer 的注意力机制天然支持在序列维度上并行计算，所以这一步的成本并不高。

第三步：接受或拒绝。 如果 Draft 猜的 token 落在大模型的”接受阈值”内，就直接采纳；如果第一个 token 被拒绝，大模型就重新采样，后面的候选 token 全部作废。

整个验证过程数学上保证输出分布与大模型独立推理完全一致，不是近似，是 lossless——你拿到的东西跟单独跑大模型一模一样。

真实例子：

• 传统自回归生成：”Paris”、”is” → 2 次大模型前向传播
• Speculative Decoding：Draft 猜 “Paris”、”is”、”the”、”capital” → 大模型一次并行验证 → 接受前 2 个 → 实际只跑了 1 次大模型前向传播

速度到底能快多少？三个真实数据

1. vLLM 的 EAGLE3：2~3 倍加速是常态

EAGLE（Extrapolation Algorithm for Greater Language-model Efficiency）是目前最成熟的 Speculative Decoding 方法之一，第三代 EAGLE3 在 vLLM 中已合并进主线（Red Hat 团队主导集成）。

核心改进：不再只在 token 空间预测，而是在隐藏态层做特征融合预测，接受率比纯 token 空间方法高得多。

实际数字：

• Qwen3-32B + Qwen3-1.7B 作为 Draft：接受率约 72%~78%，实际加速约 2.5 倍
• Llama 3.3-70B + Llama 3.2-3B（同家族配对）：接受率 78%~84%，实际加速 2.8 倍~3.2 倍
• 在 NVIDIA H100 上，EAGLE3 吞吐量为 347 tokens/s，比非投机解码基线高 1.3 倍（来源：SwiftSpec 论文，ASPLOS 2026）

2. PayPal 生产数据：延迟降 18%~33%，吞吐量升 22%~49%

PayPal 研究团队在 commerce agent 场景下做了最诚实的生产级测试——不是跑分，是在 40 种真实硬件配置下测的。

结论：

• Gamma=3（每次猜 3 个 token）：延迟降低 18%~33%，吞吐量提升 22%~49%
• 最惊人的数字：单张 H100 + EAGLE3 ≥ 两张 H100 标准推理。这意味着 GPU 成本直接减半。
• 接受率稳定在约 35.5%（commerce 领域特定 token 分布，接受率低于通用 benchmark，这是真实的生产数字，不是 cherry-pick）

这个数字是可信的——PayPal 明确说明了接受率为什么偏低，没有粉饰数据。

3. P-EAGLE：把草稿生成也并行化，又快了 1.69 倍

EAGLE 的一个隐藏天花板：Draft 生成 K 个 token 需要 K 次顺序前向传播，K 越大开销越大。

P-EAGLE（Parallel EAGLE）把这个也并行化了——所有 K 个 Draft token 在一次前向传播中全部生成。

代价是：需要额外训练一个支持并行生成的 draft head，不能直接用标准 EAGLE 模型。

在 NVIDIA B200 上，P-EAGLE 比标准 EAGLE3 再快 1.05 倍~1.69 倍。vLLM 0.16.0+ 已支持，通过 parallel_drafting: true 启用。

生产部署绕不开的三个工程问题

1. 内存：两个模型同时跑，显存够用吗？

这是最常被低估的问题。一个 70B 模型 FP16 要 140GB，加一个 7B Draft 模型，就是约 154GB——两张 H100 80GB 才能放得下。

vLLM 的解法是 PagedAttention：把 KV Cache 从连续内存块改成非连续页面，像虚拟内存一样管理碎片，还能实现 Prompt 缓存——多个请求共享相同系统 prompt 的前缀页面。实测可以把有效 batch size 提高 2~5 倍。

2. 配对策略：Draft 模型怎么选？

同家族配对是黄金标准（例如 Llama 70B + Llama 8B，或 Qwen 32B + Qwen 1.7B）。相同的 tokenizer、相同的 token 嵌入空间，预测分布天然对齐，接受率 72%~84%。

跨家族配对（例如 Llama 70B + Qwen 7B）接受率会降到 55%~65%，实际加速约 1.5 倍，不是不能用，但收益明显缩水。

纯 N-gram 方法：不需要额外 Draft 模型，用历史 n-gram 统计预测。轻量、零额外内存，但接受率只有 30%~50%，适合对速度要求不高但不能加内存的场景。

3. 接受率对加速效果的非线性影响

很多人以为”接受率越高加速越高”是线性关系——错。

实际加速公式：speedup ≈ (α·K + 1) / (1 + r·(K + 1))

其中 α = 接受率，K = 投机 token 数，r = Draft 时间 / Verifier 时间。

70% 接受率下，理论加速上限 3.3 倍，但扣除 Draft 本身的延迟消耗后，实际约 2.1 倍。接受率低于 50% 时，实际加速往往低于 1.3 倍，这时候就该重新选配对了。

前端工程师什么时候需要关心这件事

场景一：你在调用 LLM API。 投机解码是服务提供方的事情，你不需要管。但如果 API 提供方已经启用了 EAGLE3，你就已经在享受 2~3 倍的 token 生成加速了——延迟降低对交互体验的影响是直接的。

场景二：你在本地跑模型。 无论用 vLLM 还是 llama.cpp（现在支持 EAGLE3、DFlash、P-EAGLE），只要启用 Speculative Decoding，都是免费的性能提升。llama.cpp 最新版已集成 DFlash（NVIDIA 团队贡献的 block diffusion 草稿方法），在消费级 GPU 上也能跑出 2~3 倍加速。

场景三：你在做 AI 应用层性能优化。 理解了这个机制，你就知道为什么有些场景下 AI 响应”忽快忽慢”——可能不是模型问题，是 token 生成数量的波动导致的内存带宽压力变化。

结论

LLM 推理慢，根子不在算力，在内存带宽——每次吐一个 token 都要把整个模型权重走一遍。Speculative Decoding 用一个简单的思路解决了这个问题：小模型猜，大模型并行验证，数学上还保证 output distribution 完全一致。

2026 年了，这条路已经相当成熟。Red Hat、PayPal、vLLM、TensorRT-LLM 等都在生产环境跑着，EAGLE3 和 P-EAGLE 把接受率和并行度都推到了新的高度。下次你觉得 LLM 慢的时候，先别急着换更大参数的模型——看看它有没有在用投机解码。

数据来源：

1. vLLM Speculative Decoding 官方文档（vllm.ai，2026 年持续更新）
2. PayPal Research: EAGLE-3 在 Commerce Agent 生产环境的 40 配置基准测试（arXiv，2026-08）
3. SwiftSpec: Disaggregated Speculative Decoding and Fused Kernels（ASPLOS 2026）
4. P-EAGLE: Parallel Speculative Decoding in vLLM（vllm-project.github.io，2026-03）