第 5 章 前缀缓存与投机解码：重复的活别干两遍
第 5 章 · 前缀缓存与投机解码：重复的活别干两遍
章节摘要：显存与时间两大浪费收拾干净后，还剩两类"重复劳动"：相同的提示词前缀被不同的请求一遍遍重新计算；解码只能一步一步串行爬。本章沿"复用"这条追因线走：前缀缓存（5.1）把算过的前缀存下来直接引用，投机解码（5.2）用小模型起草、大模型一次验多个 token。读完本章，你会掌握两种"不增加算力却成倍提速"的思路及其适用边界。
一条主线
主线场景的推理服务经过第 3、4 章改造后，吞吐与延迟都已经体面。但账单上还有两个刺眼的数字：其一，TTFT 里 prefill 占比居高不下——复盘发现，超过一半的请求携带同一段 2000 token 的系统提示词，这段前缀每天被重复计算上万次；其二，decode 每步 20 毫秒看似稳定，可模型的权重带宽明明还有富余——一步只验一个 token，硬件在"低效地正确"。
两个问题的共性是重复：前者重复计算相同的内容，后者重复执行相同结构的串行步骤。解法也各有一个漂亮的杠杆：前缀缓存利用的是"内容不变性"——同样的前缀，算一次就够，谁需要谁引用；投机解码利用的是"验证比生成便宜"——大模型一步可以并行验证多个候选 token，用小模型的草稿把串行的一步变成"多步猜测、一次校对"。
本章两站各有一个开关级的应用心智：5.1 讲前缀缓存怎么打开、命中率怎么养、哪些提示词写法毁命中；5.2 讲草稿模型怎么选、接受率怎么看、什么场景反而变慢。
沿途站点
- 5.1 前缀缓存：从"请求级的写时复制"升级为"跨时间的块级缓存"：以块的 token 序列做索引，相同前缀跨请求、跨时间复用；讲清命中率的决定因素——提示词结构、流量构成、缓存容量与淘汰策略。
- 5.2 投机解码：草稿模型快速猜出若干候选 token，主模型一次前向同时验证；接受率是命门，数学保证是"分布完全一致"；给出草稿模型选型与参数（步数 k）的取舍表。
拐点与结论
本章的拐点是一条容易被忽略的经济学：推理系统里，"缓存命中"和"批量验证"都是把串行变并行的手段，而它们的成本恰恰是最便宜的显存占用。算力不能凭空增加，但"把算过的事情记下来"与"把多件验证合并成一次前向"都能在不增加硬件的前提下成倍减少耗时——这是软件定义性能的典型样本。
结论落在选型心智上：前缀缓存几乎无条件值得开启（代价只是块池里多占一些显存），差异只在命中率高低；投机解码则要精挑场景——接受率低于五成的负载会把时间浪费在草稿与验证的来回上。两件武器装好后，第 6 章去处理最后两类硬约束：模型大到装不下（并行）与精度冗余（量化）。
读完你应该
- 说清前缀缓存与 5.1 之前"请求间共享"的区别：一个跨时间、以块哈希为索引，一个只在同时在线的请求间共享；
- 用日志里的缓存命中率与 TTFT 变化验证缓存收益，并据此改进提示词结构；
- 解释投机解码为什么能保证输出分布与主模型完全一致；
- 根据负载特征预判投机解码的接受率区间，决定开与不开；
- 算一笔"草稿模型开销 vs 一步多 token"的账，解释接受率阈值从哪来；
- 把两件武器与第 3、4 章的机制串成完整的 vLLM 优化叙事。
下一章的接力
重复劳动消灭之后，剩下的都是硬账：模型权重放不放得下、精度给得准不准。第 6 章进入量化与并行的世界——AWQ、GPTQ、FP8 各砍哪部分显存，张量并行与流水线并行各自怎么把大模型摊到多张卡上。