KV Cache 到底缓存了什么大模型显存、首字延迟与吞吐量解析摘要KV Cache 是自回归大模型推理中的核心状态。它避免模型在生成每个新 token 时重复计算历史 token 的 Key 和 Value却也会随上下文长度、批量大小和层数持续占用显存。本文从注意力计算出发解释缓存内容、显存估算、首字延迟、解码吞吐量以及常见服务端优化为什么有效。使用大模型 API 或本地推理框架时经常能看到这些参数和指标最大上下文长度、首 token 延迟、每秒输出 token 数、KV Cache 使用率和最大并发请求数。这些概念并不是彼此独立的。它们都和 Transformer 在自回归生成阶段如何处理历史 token 有关。从自回归生成说起假设输入是KV Cache 可以减少模型先处理全部输入 token并预测下一个 token。得到新 token 后模型再次基于“原输入 已生成 token”预测下一项循环直到遇到停止条件。如果每一步都重新计算所有历史 token 在每一层注意力中的中间结果计算量会大量重复。KV Cache 的作用就是保存历史 token 已经算过的 Key 和 Value下一步只计算新 token 对应的部分。注意力层里的 Q、K、V简化后的单头注意力可以写成Q XWq K XWk V XWv Attention(Q, K, V) softmax(QK^T / sqrt(d))V这里X是当前层的输入表示Q用来表达当前 token 在寻找什么信息K用来和查询计算相关性V提供被加权汇总的内容。在生成第t个 token 时新 token 的 Query 需要和第1到t个 token 的 Key 计算注意力再对对应 Value 加权。历史 token 的 K 和 V 在同一轮请求中不会变化因此可以缓存。Query 只服务于当前这次注意力计算通常没有必要像 K、V 一样跨生成步骤保存。这就是“KV Cache”名称的来源。Prefill 与 Decode 是两个阶段推理通常可以拆成两个阶段。Prefill处理整段输入Prefill 阶段一次处理提示词中的多个 token计算每一层的表示并建立初始 KV Cache。输入越长需要处理的 token 越多首 token 往往出现得越晚。因此 TTFT 不只受网络影响也受提示词长度、模型规模、批处理调度和硬件状态影响。Decode逐个生成 tokenDecode 阶段通常一次为每个活跃序列生成一个 token。借助 KV Cache模型不需要重新计算历史 token 的 K 和 V但新 Query 仍需要读取历史缓存并执行注意力。因此KV Cache 消除了大量重复计算却没有让生成成本变成与上下文长度完全无关。上下文越长每步需要读取和参与注意力的历史状态仍然越多。KV Cache 为什么占显存一个粗略估算式是KV Cache 字节数 ≈ 2 × 层数 × token 数 × KV 头数 × 每头维度 × 每元素字节数 × 批量大小式子开头的2分别代表 Key 和 Value。为了理解量级假设一个示例模型具有 32 层、32 个 KV 头、每头维度 128使用每元素 2 字节的 FP16 或 BF16单个序列有 4096 个 token。代入后2 × 32 × 4096 × 32 × 128 × 2 2,147,483,648 字节 ≈ 2 GiB这只是用来说明公式的假设模型并不代表某个具体产品。实际模型可能使用多查询注意力或分组查询注意力使 KV 头数少于 Query 头数也可能对缓存采用更低精度或者按页管理内存。从公式可以看到缓存会随这些变量近似线性增长活跃序列数量每个序列已经占用的 token 数模型层数KV 头数量和每头维度缓存数据类型的字节数。为什么 GQA 和 MQA 能减少缓存标准多头注意力中Query、Key 和 Value 通常都有多个头。多查询注意力MQA让多个 Query 头共享一组 K/V分组查询注意力GQA则让一组 Query 头共享 K/V。如果 Query 头数是 32而 KV 头数从 32 减少到 8前面的估算式中与 KV 头数相关的部分理论上会缩小到四分之一。这能降低缓存占用和内存带宽压力但模型结构的变化也会影响训练与质量权衡不能把它简单理解成没有代价的运行时开关。TTFT 与每秒输出 token 数为何不同几个常见指标描述的是不同阶段指标主要对应阶段反映什么TTFTPrefill、排队和网络用户多久看到第一个 tokenTPOTDecode相邻输出 token 的平均时间tokens/sDecode稳态生成速度端到端时延全流程请求从发出到完成共花多久长提示词可能明显增加 TTFT但生成开始后的速度仍然可接受也可能首 token 很快却因为上下文很长或系统并发较高后续 token 输出较慢。因此只看一个“总耗时”很难定位问题。测试推理服务时至少应区分排队与网络时间、Prefill 时间、首 token 到达时间、Decode 阶段的 token 间隔和输出 token 总数。连续批处理为什么提高吞吐量不同请求的提示词长度和输出长度各不相同。如果服务端必须等同一批所有请求结束后才能接收下一批计算资源会出现空闲。连续批处理会动态移除已完成的序列并把新请求加入当前调度。这样可以提高设备利用率和整体吞吐量。但吞吐量与单请求延迟存在权衡批量更大通常更容易充分利用加速器同时服务更多序列会增加 KV Cache 总量调度不合理时单个请求可能等待更久长短请求混合时需要避免长请求持续影响短请求。所以“每秒处理的总 token 更多”并不自动等于“每个用户都更快”。Paged Attention 解决什么问题每个请求最终会生成多少 token在开始时往往并不确定。若为每个序列提前预留一整块最大长度的连续显存会产生内部浪费不同长度请求反复进入和退出也会带来碎片问题。Paged Attention 的核心思路是把 KV Cache 切成固定大小的块并通过逻辑映射组织这些块类似虚拟内存分页不要求一个序列的所有缓存物理连续按实际增长逐步分配块请求结束后可以回收块某些共享前缀场景下可以复用缓存块。它主要改善缓存的内存管理与利用率不会改变注意力需要读取历史 K/V 这一基本事实。前缀缓存什么时候有效许多请求可能共享相同的系统提示词、工具定义或固定模板。如果服务端能识别完全相同的前缀就有机会复用该前缀已经计算出的 KV Cache从而减少重复 Prefill。要让前缀缓存更容易命中可以考虑把稳定的系统指令放在前面避免在固定前缀中加入每次变化的时间戳或随机 ID保持工具定义和序列化格式稳定把用户每次变化的内容放在共享前缀之后。但缓存命中还取决于服务端实现、模型版本、分词结果和缓存策略。客户端不能只凭 Prompt 看起来相似就假定一定复用了缓存。上下文越长不一定越好更大的上下文窗口提供了容纳更多信息的能力但会带来现实成本Prefill 需要处理更多 tokenKV Cache 占用增加Decode 需要访问更长的历史状态无关信息可能干扰模型定位关键内容API 费用通常与输入和输出 token 数有关。实际应用中比“一股脑塞入全部历史”更有效的做法通常包括删除重复日志、对较早对话做结构化摘要、用检索选择相关文档片段以及为必须保留的约束建立短而稳定的系统前缀。这不是单纯压缩字数而是在有限上下文中提高有效信息密度。KV Cache 量化的收益与代价如果把 KV Cache 从 FP16/BF16 降为 FP8 或更低精度理论上可以减少缓存显存和读取带宽让同一设备容纳更多并发或更长上下文。但低精度可能引入量化误差实际影响与模型、层、任务和实现有关。评估时不能只看显存下降还应测试长上下文任务质量事实召回和指令遵循不同输入长度下的退化程度量化与反量化本身的运行开销服务端是否真正支持相应精度和内核。一个更完整的推理测试记录测试大模型服务时可以记录下面这些字段model prompt_tokens completion_tokens queue_time_ms time_to_first_token_ms total_time_ms tokens_per_second finish_reason http_status timestamp如果服务端不返回阶段时间可以在客户端至少记录请求开始、第一个流式数据块到达和请求结束三个时间点。比较不同结果时要保持模型、提示词、输出上限、采样参数和测试网络尽可能一致。少量请求只代表当时的观察不足以证明长期服务能力。常见误区误区一有 KV Cache 后长上下文生成就不再变慢KV Cache 避免重复计算历史 K/V但每步注意力仍要处理历史缓存。它降低了成本不是消除了上下文长度的影响。误区二显存只由模型权重决定线上推理还要考虑 KV Cache、临时激活、运行时工作区、内存碎片和并发请求。能装下权重不代表能稳定服务目标上下文和并发量。误区三吞吐量高等于单请求延迟低大批量和连续调度可以提高系统总吞吐但请求可能经历更长排队或更高 token 间延迟。服务目标必须明确偏向吞吐、延迟还是二者平衡。误区四上下文窗口应该始终用满窗口是容量上限不是内容目标。无关上下文会消耗 Prefill、缓存、带宽和费用还可能降低回答聚焦程度。结论KV Cache 缓存的是每层注意力中历史 token 的 Key 和 Value。它用显存换计算避免自回归生成过程中反复计算相同历史状态。理解这一点后很多现象可以串起来长 Prompt 会增加 Prefill 与 TTFT长上下文和高并发会推高 KV Cache 占用GQA/MQA、分页管理和缓存量化能降低不同维度的开销连续批处理提高系统吞吐却需要权衡单请求延迟精简上下文与稳定前缀既是 Prompt 工程也是推理系统优化。评估一个推理方案时不应只问“模型能支持多少上下文”还应问在目标硬件、并发、延迟和质量要求下真正需要保留多少有效上下文。
