@_avichawla: Anthropic. Google. Meta. 每个人都在用来自1990年代的一个想法将LLM推理速度提升2-3倍。在1990年代，CPU设计者…

Anthropic. Google. Meta. 每个人都在使用来自1990年代的一个想法，将LLM推理速度提升2-3倍。 在1990年代，CPU设计者遇到了流水线停顿问题。 最初，CPU被设计成分阶段处理指令，例如取指、解码、执行和写回。 它们完成一条指令后才开始下一条，导致大多数阶段处于空闲状态。 流水线技术通过让多条指令像流水线一样同时流经各个阶段解决了这个问题。 但它也引入了一个新问题。 当CPU遇到条件分支（if/else）时，它还不知道该走哪条路径。 但流水线已经开始获取下一条指令。如果这些指令来自错误路径，所有工作都会被清空。 流水线发生停顿，在典型程序中大约每三条指令就会发生一次。 分支预测解决了这个问题。 处理器保留了历史分支记录，预测可能的路径，并提前执行。 如果预测正确（大约95%的概率），流水线就不会停顿。如果预测错误，只需清空并重试。 现在，LLM推理在不同的硬件上面临同样的问题。 GPU可以并行处理多个token。这在预填充阶段完成，此时一次性处理整个提示，计算单元被完全填满。 但在解码阶段，模型逐个生成token。每个token依赖于前一个，因此GPU无法提前工作。 它每次为每个token从内存加载数十亿参数，几乎瞬间完成计算，然后空闲等待下一步。 原本可以一次处理多个token的硬件现在只能一次处理一个。 推测解码以分支预测解决CPU停滞的方式打破了这一限制。 → 一个小模型猜测接下来的K个token。 → 大模型然后在单次前向传递中验证所有K个token。 这个验证步骤看起来就像预填充阶段，一次性处理多个token，计算单元被完全填满。 → 最佳情况下，一次大模型调用可以得到K+1个token。 → 最坏情况下，只得到1个token，与标准解码完全相同。 而且在这两种情况下，输出分布在数学上始终一致。 Google Search在AI Overviews中正是使用这种方法服务超过20亿用户。vLLM、TensorRT-LLM和SGLang也内置了支持。 我写了一篇文章详细介绍推测解码的完整机制。它涵盖了KV缓存、推测解码的内部原理（附代码）以及权衡。 请阅读以下内容。 ____ 找到我 → @_avichawla 每天我都会分享关于DS、ML、LLMs和RAGs的教程与见解。