响应缓存、Prompt Cache 与 KV Cache 有什么区别

大模型应用谈“缓存”时，可能是在业务服务里直接复用旧答案，也可能是在模型 API 层复用相同输入前缀，还可能指推理引擎内部保存的注意力状态。三者虽然都减少重复工作，却有不同的命中条件、权限风险和可观察指标。把 Prompt Cache 当成答案缓存，会误以为新问题可以跳过生成；把 KV Cache 当成 API 参数，又会在应用层寻找不存在的控制项。本文给出三类缓存的边界，并说明开发者应如何排列前缀和验证命中。

1. 三类缓存复用的对象不同

名称在不同平台中可能不同，判断时应先看“缓存了什么”和“由谁管理”，而不是只看产品术语。

2. 响应缓存需要业务语义

响应缓存命中后不再请求模型，因此应用必须判断旧答案是否仍然有效。缓存键不能只包含问题文本，还要考虑会改变结果的条件，例如：

用户或租户权限。
知识库和提示词版本。
模型与生成参数。
工具返回的数据版本。
时间相关条件。

固定、经过审核且允许复用的结果更适合响应缓存。包含实时数据、用户私有上下文或非确定工具调用的请求，需要更严格的失效规则。两个用户的问题相同，不代表他们有权看到同一个答案。

3. Prompt Cache 仍会生成新答案

Prompt Cache 复用的是相同输入前缀，不是最终输出。根据 Claude Prompt Caching 官方文档，后续请求可以在共享前缀后追加不同内容，并分别生成回答。

例如，多个问题都以同一版制度文档开头：

系统约束 -> 工具定义 -> 制度文档 -> 问题 A
系统约束 -> 工具定义 -> 制度文档 -> 问题 B

问题不同，不能复用答案；前面的稳定内容相同，才可能复用前缀处理。支持模型、最小长度、有效期、计费和请求字段属于可变事实，必须在实施时查看当前官方文档。

4. 为什么稳定内容要放在动态内容前面

前缀缓存要求从请求开头形成连续相同的区域。若把当前时间、随机请求标识或用户个性化字段放在前面，变化会提前截断可复用前缀。

可以按下面的顺序组织：

较稳定的工具定义和系统约束
             ↓
同一版本的长文档
             ↓
需要保留的会话历史
             ↓
用户、时间和本轮问题

“稳定内容靠前”只是一般原则。具体可缓存块、排序要求和消息结构仍应以目标 API 文档为准；为了命中缓存而改变安全语义并不可取。

5. KV Cache 通常由推理层管理

模型逐 token 生成时，需要引用已处理上下文的注意力状态。KV Cache 保存这些中间状态，避免对相同序列反复计算。自建推理服务时，显存、并发、批处理和前缀复用策略会直接影响这一层。

调用托管模型 API 的应用通常不能直接管理服务端 KV Cache，只能使用厂商公开的缓存接口和 usage 数据。即使某个平台将 Prompt Caching 建立在类似的推理优化之上，应用契约仍是 API 文档，而不是推理引擎内部实现。

6. 先判断任务是否具备复用条件

评估 Prompt Cache 时至少检查：

前缀在多次请求之间是否逐字稳定。
相同前缀是否会在有效期内再次使用。
动态字段能否放到稳定前缀之后。
请求是否达到当前模型的缓存条件。
缓存边界是否遵守用户和租户权限。

一次性任务、持续变化的文档、每次重新排序的工具定义，以及不同用户完全不同的私有资料，都可能缺少有效复用条件。不能为了提高命中率把不应共享的上下文合并。

7. 用对照请求验收，而不是凭速度判断

验收流程可以保持简单：

固定模型、系统内容、工具定义和文档。
发送第一条问题并保存完整 usage。
只修改末尾用户问题，再次发送。
检查当前 API 定义的缓存创建与读取字段。
修改稳定前缀，发送对照请求。
比较命中字段是否按预期变化。

响应速度会受网络、排队和生成长度影响，不能单独证明缓存命中。若经过兼容层，还要确认请求块没有被重排、缓存字段没有丢失、usage 没有被改写。

8. 结论与限制

响应缓存复用答案，需要应用承担权限、版本与失效语义；Prompt Cache 复用输入前缀，但仍会生成新答案；KV Cache 属于推理层状态，托管 API 用户通常无法直接控制。选择方案前先明确要避免哪一种重复计算。

本文不提供价格、节省比例、有效期或模型支持列表。它们会随平台和版本变化；实际方案必须依据当前官方文档，并用原始请求、usage 响应和测试时间记录验收。缓存优化也不能替代知识检索、数据权限或答案正确性检查。