Claude Prompt Caching (提示词缓存)
Prompt Caching 不是锦上添花，而是长上下文项目里很容易立刻省钱的一项能力。只要你反复发送同一大段前缀，不用缓存基本就是在重复付费。
这类成本浪费平时不一定一眼能看出来，但账单出来时会很明显，尤其是代码助手、长文档问答和固定系统提示特别长的场景。
1. 为什么需要缓存？
在传统的 API 调用中，每次请求都要重新计算所有的 Token。
- 长文本场景：如果你每次都发送同一个 100K Token 的文档，成本会极高。
- 响应速度：处理大量上下文需要时间，导致首字延迟（TTFT）增加。
Prompt Caching 的优势：
- 省钱：缓存命中能明显减少重复输入成本
- 提速：长上下文下首字延迟通常会更好看
2. 如何使用缓存？
你只需要在 messages 或 system 内容中添加一个 cache_control 断点。
代码示例 (Python)
import anthropic
client = anthropic.Anthropic()
# 假设这是一段非常长的背景资料
long_document = "这里是 5 万字的法律条文..."
message = client.messages.create(
model="claude-3-5-sonnet-20240620",
max_tokens=1024,
messages=[
{
"role": "user",
"content": [
{
"type": "text",
"text": long_document,
"cache_control": {"type": "ephemeral"} # 在这里设置缓存断点
},
{
"type": "text",
"text": "请根据以上条文回答：如果发生 X 情况，应该如何判罚？"
}
],
}
],
)
3. 核心限制与规则
- 最小缓存单位：
- Claude 3.5 Sonnet: 1024 Tokens 起步。
- Claude 3 Haiku: 2048 Tokens 起步。
- 缓存寿命：默认 5 分钟，Anthropic 官方现在也提供 1 小时 TTL 选项。
- 最大断点数：单次请求最多支持 4 个缓存断点。
还有两个很容易忽略的点：
ephemeral仍然是当前支持的缓存类型- 精确命中要求很严格，前缀内容需要 100% 一致
4. 推荐应用场景
A. RAG 系统
将核心知识库或检索到的长文档缓存，用户针对同一文档进行多轮追问时极其高效。
B. 角色扮演游戏
缓存庞大的世界设定、角色属性和剧情大纲。
C. 编程助手
缓存整个项目的核心结构定义和 API 文档。
5. 一个更实用的判断方法
如果你每次请求都要带：
- 很长的 system prompt
- 固定的工具定义
- 一大段知识库前缀
- 大型代码库上下文
那就别犹豫，先测缓存。这个收益通常比你微调 prompt 字句更直接。
我更建议先做一个很土但有效的实验：开缓存跑一组，不开缓存跑一组，直接看 TTFT 和输入成本。很多团队做完这一步，就不会再把缓存当“以后再说”的优化项了。
6. 成本估算
缓存的计费分为两部分：
- 写入费 (Write Fee)：首次存入缓存时的费用（比普通输入略贵）。
- 命中费 (Read/Hit Fee)：从缓存读取的费用（极低，通常仅为原价的 1/10）。
别把缓存理解成“只给超大项目用”。只要固定前缀足够长、交互足够频繁，它就值得测。相反，如果你的前缀每次都改得很厉害，缓存收益可能没你想的那么高。
说到底，缓存吃的是“重复度”这口饭。重复度不够，再好的缓存也帮不了你太多。
