Claude Prompt Caching (提示词缓存)

Prompt Caching 不是锦上添花，而是长上下文项目里很容易立刻省钱的一项能力。只要你反复发送同一大段前缀，不用缓存基本就是在重复付费。

这类成本浪费平时不一定一眼能看出来，但账单出来时会很明显，尤其是代码助手、长文档问答和固定系统提示特别长的场景。

#1. 为什么需要缓存？

在传统的 API 调用中，每次请求都要重新计算所有的 Token。

• 长文本场景：如果你每次都发送同一个 100K Token 的文档，成本会极高。
• 响应速度：处理大量上下文需要时间，导致首字延迟（TTFT）增加。

Prompt Caching 的优势：

• 省钱：缓存命中能明显减少重复输入成本
• 提速：长上下文下首字延迟通常会更好看

#2. 如何使用缓存？

你只需要在 messages 或 system 内容中添加一个 cache_control 断点。

#代码示例 (Python)

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. 成本估算

缓存的计费分为两部分：

1. 写入费 (Write Fee)：首次存入缓存时的费用（比普通输入略贵）。
2. 命中费 (Read/Hit Fee)：从缓存读取的费用（极低，通常仅为原价的 1/10）。

别把缓存理解成“只给超大项目用”。只要固定前缀足够长、交互足够频繁，它就值得测。相反，如果你的前缀每次都改得很厉害，缓存收益可能没你想的那么高。

说到底，缓存吃的是“重复度”这口饭。重复度不够，再好的缓存也帮不了你太多。

#官方参考

• Prompt caching: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching↗