什么是 Prompt Caching
大模型在收到一段输入时，要对每一个 token 做”注意力预填充”（prefill），这是推理成本和首字延迟的主要来源。如果你的应用每次请求都带着同一份超长的系统提示词、工具定义或示例，这些前缀其实完全一样——Prompt Caching 就是让厂商把这部分前缀的 KV 计算结果缓存下来，后续请求直接复用，跳过重复计算。
简单说：同样的提问，第二次起更便宜，也更慢出首字变成更快。
Prompt Caching 不会让模型变聪明，它只省”重复计算”的钱和延迟。长上下文、多轮对话、固定系统提示词这类场景收益最大；一次性短请求几乎没收益。
两大厂商怎么实现
OpenAI 和 Anthropic 的底层思路一致（复用前缀），但开关方式和折扣力度不同。
OpenAI：全自动，零配置
- 从 GPT-4o 、 GPT-4o mini 、 GPT-4.1 、 o 系列起自动开启，不用改代码、不加头。
- 前缀至少 1024 token 才进缓存，之后按 128 token 递增匹配。
- 缓存的输入 token 打 5 折（50% off）。
- 闲置 5–10 分钟失效，极端高负载下最长保留约 1 小时。
Anthropic / Claude：显式断点，折扣更狠
- 用
cache_control在指定内容块上打缓存断点（也支持自动缓存）。 - 读取缓存的输入仅收 0.1 倍（90% off），但写入要收 1.25 倍。
- 两档 TTL：默认 5 分钟（写 1.25× / 读 0.1×），1 小时档（写 2× / 读 0.1×，Claude 4.5+ 可用）。
- 门槛同样 1024 token 。
实战：把命中率做高
缓存命中的唯一硬条件是”请求前缀完全一致”。所以你的 prompt 结构必须按稳定度从高到低排列：系统指令 → 参考文档/检索上下文 → 工具定义 → 少样本示例 → 用户消息。把不变的内容永远放最前面，变化的部分（用户问题）放最后。很多人搞反了——把用户上下文前置、模板后置，命中率自然接近零。
- 把系统提示词、工具 schema 、固定示例提取成常量，每次请求原样拼在最前面，绝不动态拼接顺序。
- 确认 prefix 长度超过 1024 token；太短（比如只有几十字系统词）根本不进缓存，优化了也没用。
- 在代码里打印
usage.prompt_tokens_details.cached_tokens，用真实命中率迭代，而不是凭感觉。
怎么确认缓存真的生效了？
每次响应都带
usage.prompt_tokens_details.cached_tokens 字段，非 0 即命中。 OpenAI 在 Dashboard 的 Usage 面板也能按缓存/未缓存过滤。前缀必须逐字一样吗？
必须。只要前缀里任何一个 token 变了（多一个空格、换一行、调顺序），就是缓存未命中，整段按原价计费。
Anthropic 写缓存要 1.25 倍，会不会亏？
5 分钟档大约命中 1 次就回本；高频应用（同一前缀每小时触发上千次）Anthropic 更划算，中低频用 OpenAI 的零配置更省心。
小结
对任何”重复大段上下文”的应用——聊天机器人、 RAG 管线、带工具定义的 AI Agent——Prompt Caching 都是杠杆最高的成本优化。 OpenAI 胜在零配置，Anthropic 胜在折扣深。先把前缀结构摆正，再去看账单，通常会吓你一跳地低。
相关阅读：如果你打算把这类优化落成自动化发布流程，可以看看本站《用 WordPress REST API + 应用密码远程自动发文章》。
评论 (0)