模型工程系列新篇。前几篇聊过扩缩容、混部、冷启动——都是资源视角，这篇聊一个「同样资源跑出数倍吞吐」的杠杆：KV Cache 复用。它藏在推理引擎的配置深处，但吃透它，是推理服务优化的分水岭。
先讲人话版原理
大模型生成每个 token 时，要「重读」前文全部内容算注意力——这个重读的计算结果（Key/Value 矩阵）就是 KV Cache。没有缓存时每生成一个 token 都要重算全部前文（平方复杂度）；有缓存则只算新增部分（线性复杂度）。KV Cache 是推理快的基本盘——而「复用」是这个基本盘的第二层：多请求之间、多轮对话之间，共享前缀部分的缓存不再重算。
三种复用场景（收益递增）
场景一：批内前缀共享
100 个请求都带同样的系统提示（2K token 的角色设定）——传统模式每个请求各算各的前缀。开启前缀缓存后，相同前缀只算一次，后续请求直接读。实测：系统提示占比越高，收益越大——2K 前缀的批量请求吞吐提升 35%~50%。
场景二：多轮会话复用
对话第二轮时，第一轮的上下文（比如 5K token）是「上一轮已算过的缓存」——开启会话缓存，第二轮只需计算新增部分。实测多轮场景首 token 延迟从 800ms 降到 200ms 级——多轮对话产品的「秒回感」基本靠它。
场景三：重复内容命中
翻译场景天然适配：术语表、固定模板段在每次请求里重复出现——配合内容级缓存（前面翻译实测篇聊的），重复内容的推理成本趋近于零。
工程实践的三个关键决策
决策一：缓存的内存预算
KV Cache 按显存计费且不便宜（长上下文模型 KV Cache 可达模型权重的 1~2 倍）。预算三问：缓存多少会话？保留多久？满了怎么淘汰（LRU 是底线，按业务价值加权是进阶）？无限缓存的显存会先于收益爆掉。
决策二：失效粒度
系统提示改版了、术语表更新了——相关缓存必须失效。粗粒度失效（全清）安全但浪费；细粒度（按前缀哈希失效）高效但实现复杂。起步建议：粗粒度+低频变更（把变更集中到定时窗口），规模上来再细化。
决策三：命中率的可观测
缓存命中率是这套机制的命脉：命中率掉了（业务变了/淘汰策略不合理）收益直接归零还白占显存。三个基础指标：前缀命中率、会话命中率、缓存驱逐率——进监控大盘，P 告警。
一个真实配置的收益账
某客服推理服务（多轮会话为主）：开启会话缓存+前缀缓存后——
- 首 token 延迟：780ms → 210ms
- 吞吐（同显存）：+42%
- 显存代价：+18%（缓存预算）
- 净收益：同等体验下硬件需求降 30%，或同等硬件下并发能力升 40%
这是不动模型、不加卡片的纯工程优化——一次配置改造吃到数月红利。
边界与提醒
- KV 复用对「前缀重复多」的业务是神药，对「每次输入都完全不同」的业务（如一次性长文翻译的单轮调用）收益有限——先分析你的请求前缀分布再动手
- 不同推理引擎的缓存实现成熟度差异大（有的只支持场景一）——选型时这是高频被忽略的维度
- 缓存与安全的交叉：多租户场景下缓存必须按租户隔离（A 的前缀缓存不能被 B 命中）——安全边界篇的原则在这里同样适用
（模型工程系列：迁移评估 → 竞技场 → 网关路由 → 扩缩容 → 评测流水线 → 混部 → 版本管理 → 冷启动 → 安全边界 → 灰度发布 → 本文：输出缓存）
