推测解码与 KV Cache：让大模型推理“批量上菜”

可视化演示

动态演示推测解码与KV Cache加的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

推理瓶颈溯源：主厨的“独木桥”

晚上八点的“慢火推理坊”，客人流水席的单子长得像永远点不完。林师傅掌勺，每道菜都得自己下锅：西湖醋鱼端上桌，才轮到叫花鸡开火。后厨灶台再多，一道菜没出锅，下一道菜就干瞪眼——这就是大模型自回归生成的“独木桥”：一步迈不过去，后面所有人都得等着。

大模型生成文字与上菜同理：每次只计算下一个 token 的概率，算完这一个，才能拿着它作为上下文去算下一个。假设要生成 N 个 token，每个 token 需要一次完整的前向传播，单步耗时记为 t_token。没有缓存优化时，总延迟就是 N 次串行累加，越长越慢。

为什么不能像炒大锅饭一样一盘出？因为条件概率的链条严格顺着时间：第 i 个词的概率分布取决于前 i−1 个词，前一步的结果是后一步的输入。GPU 再强悍，这一步没完成，下一步就无米下锅。这也解释了为什么 KV Cache、推测解码这些“不走寻常路”的优化如此重要。

所以，想给流水席提速，只有两条路：要么减少上菜的“轮次”——让学徒预做几道菜，主厨批量验收；要么缩短每道菜的烹制时间——把洗好的菜料提前备好。前者叫推测解码，后者叫 KV Cache，而它们还能联手。

推测解码原理：学徒预做，主厨批量验收

这天，后厨来了位叫小快的学徒。林师傅炒菜时，小快就蹲在旁边盯着：看他放了生抽，就知道下一勺准是料酒；看他铺好姜丝，就猜到要淋豉油。小快用一口小锅，一口气预做出几道“猜测菜”，端到林师傅面前——这正是推测解码的雏形。

在推测解码里，小快就是草稿模型（draft model）——一个又小又快的模型，用同样的前缀快速预测接下来的 k 个候选 token。林师傅则是目标模型（target model），接过候选后做一次批量前向，同时算出 k 个位置的概率，逐一与草稿比对。

比对一致的位置，直接采用；遇到第一个不一致的位置就停下：前面一致的部分全部“白赚”，不一致处换成目标模型自己的 token，然后从这个位置重新开始下一轮推测。贪婪模式下比较 argmax 是否相同，采样模式下则按概率分布做接受-拒绝采样。整个过程中，最终输出永远由目标模型把关，生成质量不受草稿模型影响。

林师傅不用再从头起锅——小快预做的菜，对了的直接照方批量上桌，错了的撤掉。猜得越准，白赚越多。但小快也不是随便招的，这就要看选人的门道了。

草稿模型策略：挑一把称手的小锅

小快不是随便招的。选一个眼神不好、手还抖的学徒，预做的菜全翻车，主厨还得浪费时间重做。可要是请一位米其林大厨来当学徒，预做倒是准——可他备菜的工夫，都够林师傅自己炒完一桌菜了。轻和准，必须取舍。

草稿模型的常见选择有三类：第一类是小型语言模型，几千万到十亿参数，与大模型共享词表，生成速度通常是目标模型的 5 到 10 倍；第二类是 N-gram 统计模型，从语料里统计高频词串，零训练成本，适合输入风格固定的场景；第三类是检索式草稿，从相似历史文本中找候选答案。关键衡量指标是覆盖率。

覆盖率太高不一定好——如果为了 90% 的覆盖率要付出 10 倍的草稿耗时，加速比反而下降。工程上一般同时盯着两个数：接受率 α 和草稿成本比 γ，两者联合评估，才能判断这把“小锅”值不值得用。

招小快，笔试看覆盖率，试用看接受率，最终看的是“上菜总时间”。锅趁手了，接下来就看主厨怎么一口气验收。

批量验证流程：五双筷子齐下

林师傅验收小快的预做菜，不会一道一道等出锅再尝下一道。他把五道菜同时端到眼前，五双筷子齐下，三秒之内全尝完：对的三道当场批量出锅，第四道味道不对撤下，第五道连着也撤了。这就是批量验证的现场。

这里的“同时端上”就是批量验证（batch verification）：目标模型把草稿提交的 k 个候选位置拼成一个 batch，一次前向同时算出所有位置的概率分布，而不是逐 token 串行重算。一次前向的耗时约等于原来的一次 token 前向，相当于把 k 次串行压成了 1 次。

验证时逐位置比较：位置 i 通过，继续；位置 i 失败，则接受前缀 0 到 i−1，用目标模型在该位置的输出替换草稿，并丢弃后续候选。如果 k 个候选全部通过，还能额外把目标模型预测的第 k+1 个 token 也收下——白赚一个。全部通过最赚，但概率随 k 指数下降，所以草稿长度不是越长越好。

批量验证就是主厨的五双筷子，但筷子再多，菜不对还是得撤。而撤下的菜不浪费——只要备料阁的存货跟得上。

缓存协同优化：半成品食材柜

林师傅做菜有个习惯：姜丝、蒜末、高汤，凡是能提前备好的半成品，全放进“备料阁”。客人点菜，备料阁里取现成的，只炒最后一步。备料阁就是 KV Cache——历史 token 的 Key 和 Value 向量存起来复用，不重新计算。

KV Cache 的核心是避免重复计算注意力。生成第 i 个 token 时，前 i−1 个 token 的 K、V 无需重算。在推测解码中，KV Cache 有两套配合：草稿模型生成候选时，有自己的独立小缓存；目标模型验证时，复用已生成序列的 KV，只为候选位置增量计算新增的 KV 部分。

验证不通过的候选，其 KV 应丢弃，绝不混入主缓存；验证通过的候选，其 KV 随位置并入主缓存。草稿模型与目标模型的 KV 维度不同，绝不能互相复用。内存上，KV 总量由序列长度决定：

缓存配推测，就像备料阁配小快：预做菜的半成品不用主厨重备，验证通过直接入库存。效率和空间都花在刀刃上。可是这笔买卖到底划不划算？得算账。

加速效果评估：算算小快的性价比

月底盘点，老板问：请小快到底快了多少？账房先生拿出两本台账：一本记小快预做的菜有多少被直接端走，一本记小快备菜花了多少工夫。两者一算，就是小快的“性价比”。

量化指标有两个：接受率 α 和草稿成本比 γ。α 是草稿候选被目标模型采纳的比例，γ 是草稿模型生成一个 token 的平均耗时除以目标模型生成一个 token 的耗时。真实加速比不是 α 单独决定，必须把 γ 也放进账本。

期望接受长度 E[L] = (1−α^{k+1})/(1−α) 给出平均每轮白赚的 token 数。每轮总成本是目标模型 1 次验证加上草稿 k 次生成，即 1 + k·γ。两数相除得到端到端加速比。举个实例：α=0.8、k=4、γ=0.1 时，E[L]≈3.36，S≈2.4 倍——一顿操作，上菜快了两倍多。

账房算完，老板点头：请小快这笔账，值。但老板又问了一句——是不是每家店都该请学徒？

应用场景落地：什么样的餐厅该请学徒

隔壁快餐店老板连连摇头：客人要的是“现点现出”，你让学徒先预做四道菜再一起端上来？客人早走了。对面宴会厅老板却抢着请：一桌二十道菜，预做省下的时间客人看得见摸得着。场景不同，答案完全不同。

推测解码适合的场景包括：高吞吐的批量任务、长文本生成（摘要、代码、报告）、以及草稿模型容易获得的部署——例如用同词表小模型做草稿。不适用的场景恰恰是那些对每次流式输出都极致敏感的交互：推测解码要攒够 k 个候选再批量验证，天然引入一个小小的等待，把首个 token 到每个 token 的延迟压到极限的场景反而吃亏。

工程落地要点有三：草稿长度 k 可动态调整，接受率高就加长、低就缩短；草稿模型与目标模型词表必须对齐；主流推理框架如 vLLM、TensorRT-LLM 已内置推测解码支持，可直接开启。配合 KV Cache 的前缀缓存，长对话场景收益更明显。用总延迟公式算清楚账，再决定要不要请这位小快：

把对的人用在对的环节，后厨才能又稳又快。快餐店继续单锅快炒，宴会厅请来小快批量上菜——大模型推理的优化，从来不是一招鲜，而是看菜下饭。

AI 应用场景

Python 演示

import random class DraftOracle:    """草稿模型:以给定命中率猜测下一个token"""     def __init__(self, hit_rate=0.7):        self.hit_rate = hit_rate        self.vocab = ["的", "你", "好", "是", "吗"]     def probe(self, prefix):        if random.random() < self.hit_rate:            return self._target_token(prefix)        return random.choice(self.vocab)     @staticmethod    def _target_token(prefix):        return "的" if len(prefix) % 3 == 0 else "你"  class TargetOracle:    """目标模型:决定真正的下一个token"""     @staticmethod    def probe(prefix):        return "的" if len(prefix) % 3 == 0 else "你"  def speculative_generate(draft, target, prompt, max_len=24, gamma=4):    generated = list(prompt)    draft_rounds = 0    target_rounds = 0    while len(generated) < max_len:        prefix = generated        candidates = []        for _ in range(gamma):            candidates.append(draft.probe(prefix))            prefix = prefix + [candidates[-1]]        draft_rounds += 1        verdicts = [target.probe(generated + candidates[:i]) for i in range(gamma)]        target_rounds += 1        cut = gamma        for i in range(gamma):            if verdicts[i] != candidates[i]:                cut = i                break        generated += candidates[:cut]        if cut < gamma:            generated.append(verdicts[cut])    return generated, draft_rounds, target_rounds  def autoregressive_generate(target, prompt, max_len=24):    generated = list(prompt)    rounds = 0    while len(generated) < max_len:        generated.append(target.probe(generated))        rounds += 1    return generated, rounds  if __name__ == "__main__":    random.seed(42)    prompt = ["你"]    draft = DraftOracle(hit_rate=0.7)    target = TargetOracle()    spec_tokens, d_rounds, t_rounds = speculative_generate(draft, target, prompt)    ar_tokens, ar_rounds = autoregressive_generate(target, prompt)    gamma = 0.2    spec_cost = d_rounds * gamma + t_rounds    print("普通自回归前向次数:", ar_rounds)    print("推测解码目标模型前向次数:", t_rounds)    print("推测解码总折算成本(草稿按0.2计): %.1f" % spec_cost)    print("加速比: %.2fx" % (ar_rounds / spec_cost))    print("生成结果是否一致:", spec_tokens == ar_tokens)

1. class DraftOracle模拟草稿模型：以 70% 概率猜中目标 token，其余 30% 随机挑一个，体现“快但不够准”。
2. class TargetOracle模拟目标模型：总是给出标准答案，代表“慢但正确”的最终裁决者。
3. candidates.append(draft.probe(prefix))草稿阶段：在累加前缀上连续预测 gamma 个候选 token。
4. verdicts = [target.probe(...) for i in range(gamma)]验证阶段：目标模型一次批量前向，同时算出所有候选位置的标准答案。
5. if verdicts[i] != candidates[i]: cut = i; break找到第一个不匹配位置，从这里截断回退。
6. generated += candidates[:cut]接受匹配前缀，被认可的 token 全部“白赚”。
7. spec_cost = d_rounds * gamma + t_rounds草稿前向按 0.2 倍成本折算，模拟 γ 对加速比的影响。

常见误区

面试题