缓存：写入、命中，以及为什么固定开头能省钱

一套客服应用每次都发送相同的服务规则、商品说明和工具定义，只有最后一句顾客问题在变化。模型若每轮从头处理相同前缀，会重复消耗时间与输入用量；提示词缓存就是复用这段前缀的中间计算结果。但「支持缓存」并不代表各家操作、有效期和账单字段相同。

先给答案

缓存复用的是相同提示词前缀的计算结果，不是模型上次写出的答案。OpenAI、Anthropic、Google Gemini Enterprise Agent Platform（原 Vertex AI）与 Amazon Bedrock 的启用方式并不统一：有的默认自动匹配，有的要求标记断点，有的还能先创建可引用的缓存资源。

命中发生在相同前缀，不是相似意思

提示词缓存通常针对请求开头连续不变的一段内容。服务端处理过这段前缀后，可以暂存与推理相关的中间状态；后续请求若满足厂商的模型、长度、前缀一致性、路由和有效期等条件，就可能出现缓存命中。命中是复用前缀计算，不是跳过新问题，也不是直接返回旧答案。

顺序因此很重要。把稳定的系统指令、工具定义、长文档和示例放前面，把用户姓名、时间戳、请求编号和本轮问题放后面，更容易形成可复用前缀。如果在最前面插入当前时间，后面即使有一万字完全相同，也可能因前缀变化而无法复用。不同厂商还可能采用可回看窗口、最小 token 数或指定断点，不能把「完全相同」简化成肉眼看起来差不多。

缓存写入 是服务端首次建立可复用缓存状态的过程。有些产品单列写入 token 或存储费用，有些自动缓存只按普通输入处理首次请求，不另设高价写入；有些显式缓存资源还按保存时长计费。是否划算取决于前缀长度、复用次数、命中率和有效期，不能用一家厂商的写入规则解释所有平台。

四个平台至少有三类做法

截至 2026 年 8 月 27 日，OpenAI 官方 API 文档已按模型代际区分做法：较新的模型既支持由平台放置断点的隐式模式，也支持开发者在内容块选择显式断点；更早一代的支持范围以隐式缓存为主。两类都不是先创建一个可长期引用的缓存资源，但较新模型会在 usage 中分别报告 cached tokens 与 cache write tokens，写入和读取的计费类别也可能不同。不能再把 OpenAI 一概描述成「全自动、没有写入费用」。

Anthropic 官方文档要求请求带 cache_control。当前既可在请求顶层启用自动移动的缓存断点，也可在具体内容块放置显式断点，以控制哪些前缀缓存及有效期。首次建立与后续读取分别体现在用量字段中，写入、读取和普通输入的计费类别有区别。这里的「自动」是应用先声明启用后，由服务端管理断点，不等于所有请求默认缓存。

Google Cloud 的 Gemini Enterprise Agent Platform（原 Vertex AI）官方文档明确区分两种：隐式缓存默认为项目启用，符合条件的重复内容命中后获得相应处理；显式缓存则由应用创建缓存资源、设置到期时间，并在生成请求中引用该资源。显式资源可能涉及存储成本，隐式缓存的首次处理方式也不同于 Anthropic 的写入类别。

Amazon Bedrock 的做法取决于所选模型与接口。官方文档既有通过 cachePoint 等字段设置检查点的模型，也说明某些模型采用自动缓存。Bedrock 还能在 usage 中报告缓存读取和写入输入 token。由于同一平台托管多个模型，不能只看「Bedrock 支持缓存」就推断所有模型的参数、最小长度和有效期一致。

这四组事实会继续变化。设计时应把缓存策略放在模型适配层：每个模型记录启用参数、最小可缓存长度、有效期、用量字段和失效条件；切换模型时重新查官方文档与做实验，不在业务代码里假设一个通用的 cache_write 规则。

用命中率判断，而不是凭感觉省钱

至少记录五项：可缓存前缀 token、缓存写入 token、缓存读取 token、未缓存输入 token、请求延迟。然后按业务场景统计命中率。若系统指令很长但每次在开头加入不同用户资料，命中率可能接近零；若一份产品手册连续服务数百个问题，缓存更可能有价值。

缓存也不是资料存储或访问控制。缓存到期后可能消失，不能拿它保存唯一副本；服务端如何隔离缓存、保留多久和哪些参数改变会失效，要以服务条款和技术文档为准。提示词里原本不该发送的秘密，不会因为「只是缓存」就变得可以发送。

优化顺序可以是：先删掉无关上下文，再稳定公共前缀，然后根据平台启用缓存，最后用 usage 验证。为了命中而保留错误、过期或越权的内容，会节省一点重复计算，却增加业务风险。规则更新后应接受一次缓存失效，让新版本成为后续前缀。

自己试一下

这个实验需要能查看缓存 usage 的 API；普通聊天框通常不显示相关字段。2026 年 8 月 27 日，可用支持提示词缓存的目标模型准备一段超过其最低缓存长度的虚构手册。连续发送三次：第一次为「固定手册＋问题甲」；第二次为「同一固定手册＋问题乙」；第三次在手册最前面改一个版本号，再问问题丙。请求间隔应短于该平台有效期。

记录缓存写入、读取或 cached tokens 以及延迟。通常第二次更可能读到缓存，第三次因开头变化减少命中；但自动路由、最小长度和平台负载可能影响结果。你试的时候结果可能不同，重点是观察「保持前缀」与「修改前缀」时 usage 的变化，而不是只看答案内容。具体实验请求模板已记录在编辑来源文档中。

常见误解

「缓存就是保存答案。」 提示词缓存一般复用输入前缀的中间状态，新问题仍会生成新答案；它不同于应用把完整问答按键值直接保存。

「所有厂商都是先贵价写入、再低价读取。」 Anthropic 等产品会明确区分缓存写入和读取，但 OpenAI 的自动缓存、Gemini Enterprise Agent Platform 的隐式与显式缓存、Bedrock 的模型差异各有口径。必须逐一读当前官方文档和 usage。

三句话总结

1. 提示词缓存复用的是稳定前缀的计算结果，不是旧答案。
2. 自动匹配、声明式断点和显式缓存资源是不同机制，厂商之间不能套用同一规则。
3. 固定内容放前、变化内容放后，并用 usage 与命中率证明是否真的节省。

如果你要做决定

要求供应商现场展示首次请求、重复前缀、修改前缀三种 usage，并书面说明启用方式、有效期、最低长度、写入与读取口径、数据保留及失效条件。没有这些字段，就不要把预计缓存优惠写进预算。