什么是 上下文缓存（Context Caching）？
上下文缓存（Context Caching）是一种跨请求推理优化：复用由供应商或运行时管理的合格提示前缀状态，减少重复预填充计算，但不会复用模型的最终答案。
快速了解
| 全称 | 上下文缓存（Context Caching）/ 提示缓存（Prompt Caching）/ 前缀缓存（Prefix Caching） |
|---|---|
| 规范文档 | 官方规范 |
工作原理
上下文缓存也常被称为 Prompt Caching 或 Prefix Caching，用于跨请求复用保持稳定的输入所对应的计算。它不是响应缓存：模型仍会根据缓存前缀与本次动态后缀生成新回答。它也不同于加速单次逐 Token 解码的 KV Cache，以及可能为相似查询直接返回旧答案的 Semantic Cache。缓存不会扩大上下文窗口，也不能证明模型正确利用了缓存证据。
可复用单元取决于供应商和运行时。托管 API 可能隐式发现合格前缀、允许调用方设置显式断点，或要求先创建独立 Cached Content 对象；自托管引擎通常对完整 Token Block 哈希并复用其 Attention State。共同点是必须满足兼容的前缀身份，而不是两个 Prompt 语义相似即可命中。应把稳定的指令、Tool Schema、示例与已授权参考资料放在前面，把时间戳、Request ID、每次变化的检索片段和当前用户问题放在后面。
生产缓存身份必须覆盖所有可能改变渲染前缀或计算状态的值：模型与 Tokenizer Revision、Chat Template 或 Serializer、按序排列的 Tool 与输出 Schema、多模态预处理、Adapter、运行时功能、缓存断点、Tenant 或 Trust Group、Policy Revision 和 Content Hash。具体哪些字段参与匹配由供应商 API 决定，因此应用传入的 Cache Key 只是路由或隔离提示，不能证明两个请求有权共享。Canonical Serialization 可以减少意外 Miss，但内容进入缓存前仍必须完成 Authorization。
缓存生命周期属于接口契约。Cold Request 可能计算并写入前缀，Warm Request 可能读取它；缓存也可能在标称上限前过期或被淘汰。最小可缓存长度、TTL、命中续期、Write Charge、Storage Charge、Breakpoint 上限和 Usage Field 都随模型、端点与供应商变化。并发请求若在首次写入可见前同时到达，也可能全部 Miss。缓存不可用时必须回退为普通推理，不能改变正确性或授权决策。
成本收益必须根据真实流量测量，而不是套用宣传折扣。应记录 Cache Read、Cache Write 与未缓存输入 Token，Hit/Miss 数量、可复用前缀长度、Write Amplification、Eviction、p50/p95 TTFT、端到端延迟及每个成功任务成本，并比较 Cold、Warm、Expired、Changed-prefix 和禁用缓存对照组。即使命中 Token 比例很高，如果写入很少被复用、存储单独计费、路由分散流量或动态后缀主导延迟，整体仍可能不划算。
缓存状态属于敏感派生数据。应遵循供应商当前的 Retention、Residency 与删除契约，不能认为哈希后 Secret 就已匿名。按 Tenant 和 Authorization Scope 分区；自托管系统应把 Tenant Salt 或等效隔离输入纳入缓存身份，除非明确接受机密性影响，否则不要跨租户共享。已有研究表明，依赖缓存的时间差可能泄露其他用户是否提交过某个前缀，并在共享推理系统中支持 Prompt 重建。
缓存发布必须采用可观测、可回滚的策略。固定模型、端点、Prompt Serializer、Cache Mode、Key Derivation、Breakpoint Layout、TTL、Tenant Scope 与 Pricing Snapshot。测试精确命中、预期的局部前缀命中、Miss、过期、来源更新、策略变化、并发冷启动、取消、故障转移与跨租户拒绝；当 Cache Read 突降、Write 持续增长却没有后续复用、旧 Revision 仍可寻址，或延迟显示禁止作用域之间发生共享时触发告警。
主要特点
- 跨请求前缀复用：减少重复 Prefill，但每个请求仍生成新的回答
- 供应商语义不同：隐式匹配、显式断点、Cached Content 对象、阈值、TTL 与计费并不统一
- 严格缓存身份：模型、Tokenizer、序列化、Schema 顺序、内容、运行时功能和隔离作用域都可能影响命中
- 性能优化而非正确性状态：Miss 与 Eviction 必须退化为未缓存推理，不能改变 Policy
- 成本可观测：Cache Read、Write、Miss、Write Amplification、TTFT、任务成本与过期需要分别统计
- 共享状态具有安全性：Tenant 分区、Retention、删除、抗碰撞与 Timing Side Channel 都需要控制
常见用途
- 在多轮 Agent 中复用版本化系统策略、Tool Catalog 与输出 Schema
- 针对同一份已授权文档、代码快照、音频或视频提出多个问题
- 保持 Append-only 对话前缀温热，只把新一轮消息作为动态后缀
- 在自托管推理服务中仅限同一 Tenant 或 Trust Group 共享 Prefix Block
- 使用 Cold、Warm、Expiry 与 Update 流量比较隐式和显式缓存策略
示例
Loading code...常见问题
Context Caching、Prompt Caching 与 Prefix Caching 是同一概念吗？
它们通常都指跨请求复用重复输入前缀的已处理状态，但名称不构成统一 API 契约。各供应商在隐式发现、显式断点、Cached Content 对象、最小长度、匹配规则、TTL、计费与隔离方式上不同，实施时必须以目标端点的当前文档为准。
上下文缓存与 KV Cache、Semantic Cache 有什么区别？
普通 KV Cache 在一次自回归生成内部复用 Attention State；Context 或 Prefix Caching 把兼容前缀复用扩展到多个请求；Semantic Cache 通常匹配相似查询，并可能不运行模型就返回已存答案。三者的 Key、生命周期、正确性风险和安全边界不同。
缓存命中会改变答案或扩大上下文窗口吗？
不会。前缀命中只跳过兼容的 Prefill 计算，模型仍根据相同逻辑输入与本次后缀重新生成答案。它不会增加上下文窗口容量、刷新过期来源、改善证据利用，也不会让带随机性的相同请求必然返回相同输出。
Prompt 看起来相似，为什么 Cached Token 仍为零？
常见原因包括前缀低于模型阈值、空格或顺序变化、时间戳或用户字段位于断点前、Tool 或 Schema 变化、模型或 Tokenizer 不同、缓存已过期或淘汰、路由分散，以及并发请求早于首次写入可见。应以响应 Usage Field 为准。
如何评测并保护上下文缓存？
应测量 Cold/Warm TTFT、端到端延迟、Cache Read/Write Token、Hit Rate、Write Amplification、过期与任务成本，并测试前缀变化、策略升级、故障转移和并发。缓存必须按 Tenant 与 Authorization Scope 隔离，核对 Retention 与 Residency，在支持时使用 Salt，并测试基于时间差的跨租户信息泄露。