大模型推理从来不是算力问题，而是带宽问题。GPU 算力堆得越高，显存墙反而越明显。每生成一个字，都要等一次权重搬运——这才是真正的瓶颈。投机解码就是冲着这个瓶颈去的：用一个轻量模型先猜，让大模型做一次批量校对。
一、先猜后验：基本套路
投机解码的核心假设很简单：相邻 token 之间的推理路径高度相似。如果有一个小模型能廉价地跑一遍这些相似路径，并把结果交给大模型做一次批量验证，那么原本需要 N 次前向传播的序列，就能压缩到 N/k + 1 次。k 是每次猜对的 token 数，1 是最后那一次验证调用。
验证这一步并不简单——不是简单地接受或拒绝所有猜测，而是逐 token 比对概率分布。如果小模型猜对了某个 token，并且它给出的概率也落在大模型分布的高概率区间内，就接受；如果不对，就退回小模型当前位置，让大模型重新生成。
这套机制的好处是数学上的严格性：只要小模型和大模型的输出分布完全一致，最终序列的概率分布就和直接用大模型采样一模一样。也就是说，速度上来了，质量一点没丢。
二、2 倍是常态，不是天花板
在 2026 年的实际生产环境里，投机解码的加速比通常落在 1.8 到 2.5 倍之间。首 token 延迟改善最明显——从 200 毫秒压到 80 毫秒的级别，用户感知上是”响应快了不止一倍”。后续 token 也有改善，但幅度逐渐收敛，因为批量验证本身也有开销。
加速比的真正瓶颈不在算法，而在两个工程指标：小模型与大模型的语义距离，以及两者的 token 化是否一致。前者决定猜测命中率，后者决定能不能复用 KV cache。如果两个模型连分词方式都不一样，那每一步都得多做一次对齐，加速效果就立刻打折。
三、不是所有模型都适合
投机解码对两类模型特别友好：一类是写作类、对话类的同质化输出任务，因为相邻 token 的相关性高，命中率自然就高；另一类是解码阶段算力远大于前缀处理的场景，比如长上下文问答。代码生成介于两者之间，命中率在 60% 左右，加速比能到 1.5 倍左右。
完全不适配的是两类任务：高度发散的创意写作，以及需要精确数值计算的场景。前者的小模型命中率低到 30%，加速比反而是负数；后者的微小概率差异会导致验证频繁失败，浪费掉的算力比省下来的还多。
四、2026 年的几个落地坎
把投机解码塞进生产链路并不容易。最直接的坎是调度：一个小模型加一个大模型的双实例部署，需要重新设计 serving 框架，让两个模型能在 GPU 上并行而不是排队。NVIDIA 的 TensorRT-LLM v2 在 2025 年底把这条链路封装进了推理引擎，开发者只需要写配置即可。
第二个坎是成本。小模型虽然便宜，但跑一次也是钱。命中率低于 1.3 的场景，加速带来的 GPU 时间节省不足以抵消小模型的推理成本。这时候更划算的做法是直接调大模型的批处理大小，而不是上投机解码。
第三个坎是评估。加速比不能只看平均数，要看尾延迟 P99。在高峰时段命中率会下降，这时候如果批处理过小，整体加速比可能从 2 倍掉到 1.2 倍，用户体验就是”偶发性卡顿”。生产环境必须为尾延迟做单独的容量规划。
五、它改变了什么
投机解码最深远的影响不是性能数字，而是把”推理”这件事从纯算力问题变成了系统问题。以前大家讨论的是”卡够不够”，现在讨论的是”路径能不能复用”。这种思维转变会让整个 LLM serving 行业更接近传统数据库的优化思路——缓存、批处理、近似、并行，每一个旋钮都值得单独调。
所以投机解码不是新算法，而是新工程。它让推理这件事从”只能堆卡”变成了”可以省着用”——而省着用，正是 LLM 服务进入大规模商用的真正起点。