别再只堆显卡：投机解码如何把推理速度提升两到三倍

摘要：大模型解码阶段卡在显存带宽而不是算力，加卡只能线性缓解。投机解码让一个小模型先"猜"出几个 token，再由大模型一次前向并行验证，在输出分布不变的前提下把出字速度提升 2 到 3 倍。

把一个 70B 模型部署上线，最容易想到的加速手段是加显卡。但在自回归解码阶段，多卡带来的收益往往低于预期，因为瓶颈不在算力。投机解码（Speculative Decoding）提供了另一条思路：不增加计算资源，而是把已经闲置的算力换成更少的显存搬运。

一、出字慢的根因：算力闲着，带宽忙死
每生成一个 token，模型都要把全部权重从显存读进计算单元一次。以 H100 为例，HBM 带宽约 3.35 TB/s，70B 模型 FP16 权重约 140 GB，仅读完权重就需要约 42 毫秒，对应单请求理论上限不到 24 token/s，而同期张量核心的利用率通常只有个位数百分比。

这是解码阶段的典型特征：带宽密集、算力空闲。增大 batch 可以让多路请求共享一次权重读取，把吞吐做上去，但单条请求的延迟几乎不变。批量解决的是"服务器能服务多少人"，解决不了"一个人等多久"。

二、先猜后验，而不是近似
2023 年 Leviathan 等人提出的投机解码，把一次解码拆成两步。第一步，用规模小得多的草稿模型自回归生成 γ 个候选 token，比如一次猜 4 个；第二步，把输入和这 4 个候选一起送进大模型，一次前向并行算出 5 个位置的分布，从前往后逐个比对：猜对的保留，第一个猜错的位置按修正后的分布重新采样。

这套流程采用拒绝采样，最终输出分布与直接用大模型逐 token 采样完全一致，属于无损加速，而不是拿质量换速度。它并不要求草稿模型"猜得准"，只要求"猜得快"，猜错的部分由大模型纠正。

三、收益上限由接受率决定
设草稿 token 被接受的概率为 α，一次验证的期望产出为 (1−α^(γ+1))/(1−α) 个 token。α 取 0.7、γ 取 4 时约 2.8 个；α 提升到 0.9 则约 4.1 个。大模型每轮只做一次前向，成本近似固定，接受得越多，摊薄效果越明显。

工程改进主要围绕提升 α 和降低草稿成本。Medusa 在模型顶部加多个解码头并行预测；EAGLE 复用目标模型的特征层做草稿，接受率通常更高；树形注意力让多条候选路径同时验证，把"线性猜"变成"分叉猜"。公开评测中，这类方案在摘要、翻译、代码补全任务上普遍报告 2 到 3 倍加速。还有零成本的 n-gram 查表法，直接从上下文匹配重复片段，在代码补全、RAG 摘要等高度模板化的场景里效果很好，连草稿模型都不需要。

四、四个容易踩空的场景
第一，高温度创意写作。温度调到 1.0 以上，候选空间熵急剧上升，α 常掉到 0.4 以下，验证开销基本白付，速度甚至可能倒退。

第二，已经跑满的大批量服务。batch 已摊薄权重读取，投机解码的相对收益缩小，还要额外占用显存存放候选 KV。

第三，草稿模型与业务领域不匹配。中文法律文书配一个英文语料训出来的小模型，α 会低得很难看；草稿模型必须用同源数据蒸馏或继续训练。

第四，输出结构高度不可预测的任务，比如自由格式的多语言混排、需要严格 JSON 校验的生成，猜错的代价被放大，收益不稳定。

参数 γ 也要按场景调。γ 太小赚不到，太大则草稿成本上升、α 衰减，通常 3 到 6 是实践中的甜点区间，需要用线上真实流量统计接受率后再定。

结语
投机解码的价值不在于模型更聪明，而在于看清了硬件账本：解码阶段浪费的是算力，紧缺的是带宽。用小模型的高并行填补空闲算力，换取大模型更少的串行前向，这才是它能把速度提升两到三倍的原因。上线前先测接受率，再决定用独立草稿模型、EAGLE 式特征复用还是查表法，比盲目照搬论文配置更靠谱。

标签：大模型, 投机解码, 推理加速, 推理优化, 云上部署