大模型的"短期记忆术"：超擎数智详解 KV Cache
大模型逐字回答时，如果每次都要重算前文，就会浪费算力、拖慢响应。KV Cache 把推理产生的中间计算结果保存下来复用，从而减少重复计算。本文详解 Prefill / Decode 两阶段处理流程、显存瓶颈与 KV Cache 卸载、跨请求的前缀缓存复用，并给出 TTFT、TPOT、TPS 三个评估维度。
当你向 AI 助手提交一份 50 页的财报，要求它"分析主要风险并给出建议"时，你可能注意到：回答并非瞬间出现，而是像打字一样逐字生成。这个看似简单的过程背后，藏着 AI 推理效率的核心秘密——KV Cache，一项正在重塑大模型推理性能的关键技术。
随着 AI 应用从实验室走向规模化部署，从短对话走向长文档处理，从单用户走向高并发服务，推理效率、响应速度与资源成本正在成为决定 AI 商业化成功的关键因素。而 KV Cache，正是解决这些问题的核心抓手。
一、为什么大模型的回答要逐字生成？
先从一个日常体验说起。当你让 AI"阅读这份报告，概括主要结论"时，它并不是把一份事先准备好的答案调出来显示，而是实时计算每一个即将生成的文字。例如：
北京 → 是 → 中国 → 的 → 首都
大模型每生成一个新片段（技术上称为 Token，可以理解为"文本小单元"），都要利用前面已有的信息：用户的问题、提供的报告，以及已经生成的回答。这些可供参考的内容，统称为 上下文。
核心问题来了：如果每生成一个新字，都要把前面的资料和已生成的文字重新计算一遍，会发生什么？
答案是大量重复计算、资源浪费、响应变慢。这就像做一道复杂数学题，每写一步都要把前面的所有中间结果重新算一遍，效率极低。
KV Cache 就是为了解决这个问题而生的：把前面已经计算出、后续还会用到的中间结果保存下来，需要时直接调用，避免重复计算。
二、什么是 KV Cache？大模型的"计算草稿本"
可以把 KV Cache 想象成做数学题时保留的计算草稿：不需要每一步都从头算起，而是把中间结果写在草稿纸上，下一步直接引用这些结果进行继续计算。
不同的是，大模型保存的不是人类可读的文字，而是数值化的计算结果，这就是"K"和"V"。
- K（Key，键）：用于判断哪些已有内容与当前生成内容相关。
- V（Value，值）：提供按关联程度组合使用的信息。
K 和 V 都不是从报告里直接摘录的关键词或句子，而是大模型通过注意力机制计算得到的数字。
理解 KV Cache，记住这句话就够了：
它缓存的不是"报告原文"，也不是"摘要"，而是处理这份报告时产生的中间计算结果。
当大模型需要理解"主要风险"时，它不会平等对待报告中的每一部分，而是通过注意力机制识别关键信息。K 帮助判断关联程度，V 提供实际信息内容。在同一段上下文和相关条件不变时，前面已经算出的 K、V，后续仍然可以使用。把这些数字保存下来，后面需要时直接读取，就是 KV Cache 的基本原理。
图 1：使用 KV Cache，减少的是已有内容的重复计算
三、KV Cache 如何工作？从输入到输出的完整过程
用户提交问题并等待 AI 回答，称为一次"请求"。在这个过程中，KV Cache 主要经历两个阶段。
第一阶段：处理输入，建立缓存（Prefill）
用户提交报告和问题后，大模型先处理这些输入，建立对应的 KV Cache，再开始生成回答。
这解释了一种常见体验：提交很长的报告后，往往需要等待一段时间，回答才开始逐字出现。原因之一，就是系统需要先完成输入处理，进行"预热"，为后续高效生成做准备。当然，系统繁忙、请求排队也会增加等待时间。
第二阶段：生成回答，更新缓存（Decode）
开始回答后，大模型会继续利用已有 KV Cache。同时，新生成的文字也会成为后续参考的内容，因此处理这些文字时，还会产生新的 K、V 并加入缓存。
整个过程可以简化为：
图 2：先建立缓存，再持续使用和补充；生成结束时停止循环
四、KV Cache 的价值与局限
KV Cache 最直接的价值是避免重复劳动，提升推理效率。但需要明确的是，保留计算草稿不等于已经得到完整答案。
大模型仍然需要计算后续内容，读取缓存本身也需要时间。此外，在许多常见模型中，上下文越长，每一步需要使用的缓存数据也越多。因此，即使启用了 KV Cache，长对话仍然可能比短对话慢。
KV Cache 的效果因场景而异，没有固定"加速 X 倍"这种说法：
在短对话场景中，KV Cache 带来的收益相对有限，因为上下文本就不长；在长文档分析场景中，收益显著，因为避免了反复处理前文资料；在高并发服务场景中，缓存复用能大幅提升系统吞吐。效果取决于模型、设备，以及输入和回答的长度。
减少计算的同时，需要付出另一项代价：存储空间的占用。这就引出了下一个问题。
五、存储挑战：当显存装不下缓存时怎么办？
大模型通常使用 GPU 进行计算。GPU 拥有专用的高速内存——显存。正在参与计算的 KV Cache 通常就放在显存中。
沿用计算草稿的类比：保留的草稿越多，需要的摆放空间越大。显存也一样，它并不是无限的，而且除了 KV Cache，还要存放运行大模型所需的其他数据。
显存受两个因素直接影响：
- 单个任务长度：对同一模型而言，输入报告和已生成回答越长，需要保存的缓存通常越多。
- 并发任务数量：系统同时处理的请求越多（称为"并发"），通常需要更多缓存空间。
不同模型保存 K、V 的方式不同，所以不能只根据报告字数判断缓存大小。
这也解释了一个常见困惑：为什么一台设备能运行某个大模型，却不一定能同时处理很多长文档？答案是——容纳模型本身，与留出足够的缓存空间，是两回事。
显存有限时，系统还可以把部分 KV Cache 转移到计算机的主内存、硬盘，或通过网络连接的存储设备中，需要时再读回。这种做法叫作 KV Cache 卸载，注意，这不是删除缓存，而是换一个位置保存。
这样可以腾出显存空间，但读取和传输数据需要时间：
- 如果取回结果比重新计算更快，就可能提高速度；
- 如果搬运太慢，则未必有速度收益。
因此，"能保存更多"不等于"回答一定更快"，还要看数据能否及时送到计算所需的位置。
图 3：把显存比作工作台，外部存储比作储物柜：换地方保存可以腾出空间，但取回数据需要时间
这正是 AI 推理时代存储加速技术的核心挑战：如何通过高速网络、优化的存储架构和智能调度策略，让 KV Cache 卸载既能扩展容量，又不成为瓶颈？
由中国信通院牵头、落地超擎数智的 ODCC AI 存储实验室，正围绕这一关键方向，开展面向推理场景的 KV Cache 专项测试，通过多模型、多架构、多传输路径的系统验证，为 AI 存储技术选型和部署规范提供实测依据。作为实验室承载单位，超擎数智提供高性能算网环境支撑，携手产业伙伴推动相关测试方法和标准体系的完善。
六、进阶能力：跨请求的 KV Cache 复用
前面讨论的是单次回答中使用缓存。如果系统继续保留这些结果，还能供其他请求使用，这就是"复用"。
例如，同一份报告分别用于回答两个问题：
图 4：相同报告可以复用计算结果，不同问题仍然需要分别生成答案
两次输入开头的报告相同。系统如果支持缓存复用，第二次就可直接复用报告的计算结果，只继续处理新问题和生成新答案。
这叫作前缀缓存："前缀"指输入开头相同的部分。系统找到并使用了适用的缓存，就称为缓存命中。
这种优化在多个场景特别有价值：
- 客服系统中多个用户咨询同一份产品手册
- 知识库问答中反复查询同一批文档
- 代码助手多次引用同一份代码库
不过，这不是按照"意思差不多"来模糊匹配的。通常需要开头的 Token 序列一致，使用的模型和相关设置也要匹配。如果前面增加了一段指令，即使后面的报告没变，也可能影响复用。
因此，重复提交同一份报告不保证一定加速，还要看缓存是否保留、是否匹配，以及系统是否支持。
七、常见误解：KV Cache 不是大模型的"永久记忆"
缓存可以复用，是否意味着大模型已经永久记住了报告？并不是。
几种常见的保存方式，需要区分：
| 保存方式 | 保存内容 | 主要用途 |
|---|---|---|
| KV Cache | 处理内容时产生的部分计算结果 | 避免重复计算 |
| 聊天记录 | 用户与 AI 的对话文字 | 查看历史，或作为后续输入 |
| 答案缓存 | 已经生成的完整回答 | 条件匹配时直接返回已有回答 |
| 应用的长期记忆 | 用户偏好、历史事实等 | 在后续交互中重新提供参考 |
例如，AI 应用下次仍记得用户喜欢简短回答，可能是因为它保存了这项偏好，并在新对话中再次提供给大模型，不一定与 KV Cache 有关。
"短期记忆"是对用途的比喻，不是固定的保存期限。
KV Cache 可能在回答后释放，也可能被继续保留；保存这些结果，并不等于训练了大模型，让它永久学会了报告内容。
同样，缓存不是原始文字，也不代表其中没有敏感信息。来自私密材料的缓存仍需妥善保护，不能因为是计算结果就忽视数据安全。
八、如何评估 KV Cache 的实际效果？
理解原理后，在阅读相关测试报告时，可以重点关注三个关键维度。
1. 测试条件与数据来源
- 冷状态（Cold）：指完全没有现成缓存，必须从头计算。
- 热状态（Warm）：指已有适用的缓存可以复用。
即便都是热状态，缓存直接放在显存中，还是需要从硬盘或内存读回，速度也会有明显差异。公平比较时，应尽量保持模型、输入与回答长度、并发请求数等条件一致。
2. 用户体验的两个核心指标
用户感受到的"快"，其实包含两部分：
| 指标 | 全称 | 含义 |
|---|---|---|
| TTFT | Time To First Token | 从提交问题到收到第一个 Token 的时间（开始回答前等多久） |
| TPOT | Time Per Output Token | 后续平均生成一个 Token 需要的时间（开始回答后生成多快） |
复用文档对应的缓存，往往有助于更早开始回答，却不代表后续生成也按相同比例加快。
3. 系统整体处理能力（吞吐量）
常见的指标是每秒处理多少 Token，简称 TPS。例如，系统同时服务更多用户，每秒生成的文字总量可能增加，但每位用户不一定更快得到回答。
因此，吞吐量高不能直接等同于个人体验更快。评估时要明确区分：衡量用户体验看 TTFT 和 TPOT，衡量整体处理能力还要看 TPS。
九、KV Cache：推理时代的基础设施关键
KV Cache 并不神秘，它的核心逻辑只有一句话：保存中间计算结果，减少重复劳动，让推理更高效。
但在 AI 应用规模化落地的今天，围绕这项技术的系统优化正在成为产业竞争的关键战场。从技术角度看，KV Cache 带来了三大核心挑战：
- 如何在有限显存与外部存储之间实现高效调度，平衡存储容量与访问速度。
- 如何提升缓存命中率，让跨请求复用的机会更多、效果更好。
- 如何针对不同业务场景进行性能优化，让通用技术在具体应用中发挥最大价值。
从存算分离架构、GPU Direct RDMA 高速传输，到智能调度策略和标准化测试方法，产业链正在围绕 KV Cache 展开系统性创新。
超擎数智作为 ODCC AI 存储实验室承载单位，持续关注 AI 推理场景下的存储加速技术演进，携手产业伙伴推动 KV Cache 卸载等关键技术的测试验证与标准探索，为推理时代的 AI 基础设施建设贡献力量。