超级管理员
楼主
推测解码这两年成了大模型推理的标配优化，但很多团队上线后发现收益远低于论文数字。这篇讲清楚为什么。
原理一句话
用一个小模型快速猜出后续若干 token，再用大模型一次性并行验证。猜对的直接接受，猜错的从第一个错的位置重来。正确性由接受拒绝采样保证，输出分布与直接用大模型一致。
收益公式
加速比大致等于「每轮接受的 token 数」除以「验证一轮的相对成本」。两个变量缺一不可。
论文里常常把接受率做到 3 到 4，但那是特定任务、特定草稿模型。换成你的业务，接受率可能只有 1.3。
为什么你的场景不灵
第一，任务类型不匹配。代码补全、格式化输出这类高度可预测的任务，接受率高；开放创作、多语言混排，接受率低。
第二，草稿模型与主模型分布差太多。用同系列小模型做草稿效果最好，随便找个 1B 模型凑数，接受率会崩。
第三，高并发批量场景。GPU 本来就跑满了，验证一輪的计算没有空闲算力可用，加速直接归零。
什么时候该上
单流、低延迟、交互式场景，比如 IDE 补全、客服首响。批处理、离线生成场景，提升吞吐更实际的办法是调 batch 与量化。
上线前必做的一件事
在真实流量上采样一千条请求，统计接受率分布与端到端延迟分位数。别看平均值，看 P99。推测解码在长尾请求上的表现经常比不开更差，因为猜错重来的成本会集中爆发。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
