Prompt Caching 降本：省钱的关键不是模型选得好，而是前缀排得对

大模型 API 账单里，输入 Token 的花费往往被忽视。很多人盯着输出价格选模型，却没意识到：当你的 System Prompt 有 2000 Token、RAG 上下文有 3000 Token 时，每次请求光"说前话"就要花一大笔钱。

Prompt Caching 就是针对这个问题的。原理不复杂：把请求中重复出现的前缀部分缓存起来，下次遇到相同前缀就跳过计算，直接复用。省的是 GPU 的算力，反映在账单上就是 Token 单价打折。

2026 年，OpenAI、Anthropic、Google 都支持了这个功能。但三家的实现方式差别不小，用法也不一样。搞混了不但省不了钱，还可能多花钱。

三家机制对比

OpenAI：自动缓存，不用改代码

OpenAI 的做法最简单：你什么都不用做。只要连续两次请求的前缀相同（至少 1024 Token），系统自动识别并缓存。缓存命中的 Token，价格打五折。

GPT-4o 的缓存输入价格是 $1.25/百万 Token（正常 $2.50）。GPT-5.1 的缓存保留时间最长，可以到 24 小时；其他模型大概 5-10 分钟。

好处是零改造成本。坏处是你没法控制缓存行为——不能指定"这段一定要缓存""那段一定不要"。如果请求间隔太长、或者前缀稍有变化，缓存就失效了。

Anthropic：手动标记，省得更多

Anthropic 的方式是反过来的：你得在请求里显式标记哪些内容需要缓存。用 cache_control 参数，最多设 4 个缓存断点。

{
  "system": [
    {
      "type": "text",
      "text": "你是一个代码审查助手，以下是项目的编码规范文档...(2000 tokens)",
      "cache_control": {"type": "ephemeral"}
    }
  ]
}

缓存命中时，输入价格直接打一折——$0.30/百万 Token（Claude 3.5 Sonnet 正常 $3.00）。但有个代价：第一次写入缓存时，会额外收 25% 的费用。所以如果你的请求没有复用性（每次前缀都不一样），手动缓存反而更贵。

缓存 TTL 只有 5 分钟。每次命中会刷新 TTL，但如果 5 分钟内没有相同前缀的请求，缓存就过期了。对于低频场景不太友好。

Google Gemini：自动缓存，规则类似 OpenAI

Gemini 的缓存也是自动的，价格打五折，TTL 约 10 分钟。和 OpenAI 的体验差不多，不需要改代码。

怎么才能把命中率拉上去

理解了机制，关键问题就变成：怎么让更多请求命中缓存？

答案只有一条：把不变的内容放前面，把变化的内容放后面。

一个典型的请求结构是：

[System Prompt] → [RAG 文档/上下文] → [对话历史] → [用户当前输入]

System Prompt 几乎不变，放最前面。RAG 文档在同一个会话里通常也不变。对话历史每轮增长，但前面的轮次不变。用户输入每次都不同，放最后面。

这个排列的效果是：前缀越长的部分越稳定，缓存命中的 Token 数就越多。

有几个容易犯的错误：

错误一：把时间戳放在 System Prompt 里。 有人喜欢在 System Prompt 开头加"当前时间：2026-02-06"。一旦加了，每分钟前缀都变，缓存全部失效。把时间信息放到末尾，或者只精确到小时。

错误二：RAG 文档顺序不固定。 如果你的 RAG 检索返回 5 篇文档，每次排序不一样，缓存就废了。给文档排个固定顺序——按 ID 排、按相关性分数排都行，保持一致就好。

错误三：对话历史做了后处理。 有的系统会在每轮对话后对历史做摘要、裁剪。这会改变前缀，导致缓存失效。如果要压缩历史，尽量只裁剪尾部，保持开头不动。

各场景的实际收益

根据公开数据和我们自己的测试，几个典型场景的成本变化：

| 场景 | 前缀 Token 数 | 缓存命中率 | 成本下降 | |------|-------------|-----------|---------| | 客服机器人（固定 System Prompt + FAQ 文档） | ~3000 | 90%+ | 40-50% | | RAG 问答（固定知识库上下文） | ~4000 | 80-85% | 35-45% | | 代码助手（项目规范 + 仓库上下文） | ~5000 | 85-90% | 45-55% | | 多轮对话（长对话历史） | 递增 | 70-80% | 30-40% | | 批量翻译（相同 System Prompt） | ~1500 | 95%+ | 45-50% |

Anthropic 的高折扣（一折）在高复用场景下收益最大。但如果你的请求模式比较零散，OpenAI 的自动缓存反而更稳——不用操心标记和 TTL。

怎么监控缓存效果

光配了缓存不够，你得知道它到底省了多少钱。

OpenAI 的响应里有 usage.prompt_tokens_details.cached_tokens 字段，直接告诉你这次请求有多少 Token 命中了缓存。Anthropic 的响应有 usage.cache_read_input_tokens 和 usage.cache_creation_input_tokens。

建议做三个监控指标：

缓存命中率：命中 Token 数 / 总输入 Token 数。低于 60% 就该检查前缀结构了。
每请求实际成本：把命中和未命中的 Token 分开计价，算真实花费。
缓存写入频率：如果 Anthropic 的 cache_creation 次数远多于 cache_read，说明缓存一直在过期重建，TTL 管理有问题。

一个真实案例

我们有一个内部的代码审查工具，System Prompt 约 1800 Token（编码规范），每次请求会附上当前文件内容（平均 2000 Token）和 Git diff（平均 500 Token）。

优化前，每次请求的输入成本约 $0.011（GPT-4o）。

第一步，把编码规范放在最前面，开启 OpenAI 自动缓存。命中率约 75%，成本降到 $0.008。

第二步，发现文件内容部分也有复用（同一个 PR 里反复审查同一个文件）。把文件内容排在 System Prompt 后面、diff 前面。命中率提升到 88%，成本降到 $0.005。

第三步，清理掉 System Prompt 里的一行动态生成的"当前日期"。命中率到 93%，成本 $0.004。

总共优化了 63%。整个过程没有换模型，没有改功能，只是调整了 Prompt 的排列。

参考链接

OpenAI Prompt Caching 文档：https://platform.openai.com/docs/guides/prompt-caching
Anthropic 缓存使用指南：https://docs.anthropic.com/claude/docs/prompt-caching
Burnwise 2026 Caching 指南：https://www.burnwise.io/blog/prompt-caching-guide