KV 缓存与长上下文推理

它是什么

Transformer 生成文本是一个 token 一个 token 往后写的。每写一个新 token，注意力都要和前面所有 token 的键（K）与值（V）做一次计算。这些 K、V 只取决于已经写下的内容，算过一次就不会再变，所以推理引擎把它们存起来反复用，这份存储就是 KV 缓存。

为什么上下文越长越贵

• KV 缓存的大小与「层数 × KV 头数 × 每头维度 × 上下文长度」成正比，随上下文线性增长。长上下文推理的瓶颈往往不是算力，而是这份缓存占掉的显存，以及每一步都要把它读一遍的带宽。
• 推理分两段：预填充一次性读入整段输入、算出全部 K、V，可以并行，吃算力；解码每次只多出一个 token，却要读完整份缓存，吃带宽。两段的成本结构不同，引擎经常把它们拆开调度。

常见手段与代价

1. 分页管理（PagedAttention）：像操作系统管理内存页那样分块分配缓存，减少碎片，同一张卡能并发更多请求。
2. 前缀缓存：多个请求共享同一段开头（系统提示、同一份文档）时只算一次。智能体反复带着同一段历史调用模型，命中率高，收益明显。
3. 压缩：降低精度（如 FP8 KV 缓存）、让多个注意力头共享 K/V，或把几个 token 合成一个缓存条目。省下了显存，但可能带来新的失效方式——分块压缩会让检索准确率随信息相对压缩窗口边界的位置周期性起伏。

读信号时看什么

• 「上下文窗口 100 万 token」说的是放得下，不说明在这么长时还找得回信息，也不说明你付得起这份显存。
• 推理引擎更新里关于 KV 缓存和预填充的改动，直接决定同一张卡能扛多少并发；升级前后用自己的负载实测。
• 长上下文按长度分档定价，背后就是这份缓存的成本。