Prompt Caching 保姆级教程：2 次命中就回本的隐藏省钱技巧

去年八月我有一个客户项目，每天要处理 3000 多份 PDF 文档，做字段抽取。上线第一周账单直接给我整破防——一周烧了 $780。客户给的预算是一个月 $500，我算了下按这速度一个月得 $3300+，项目直接要赔钱。

那时候我正好看到 Anthropic 更新了 Prompt Caching 的文档，抱着试试的心态改了几行代码。改完跑了一天，第二天打开账单那一刻我真的惊了——单日成本从 $110 降到 $18。不是看错，是真的降了 83%。

从那天起我就成了 Prompt Caching 的重度用户，这东西在我这儿已经是”每个项目上线前必做的检查项”。这篇文章想把我这一年踩过的坑、摸出来的最佳实践全部摊开，给还没用过的人一个能直接照抄的参考。

一、先把价格结构讲清楚

很多文章讲 Prompt Caching 第一句就是”能省 90%”，但不告诉你是在什么条件下省的。先把价格表拉清楚：

以 Claude Sonnet 4.6 为例（Opus 4.7 按比例推算）：

普通 input：$3.00 / MTok
cache write（5 分钟 TTL）：$3.75 / MTok（比普通贵 25%）
cache write（1 小时 TTL）：$6.00 / MTok（比普通贵 100%）
cache read：$0.30 / MTok（是普通的 1/10）
output：$15.00 / MTok（这个不受影响）

读到这里你应该明白 Prompt Caching 的”生意逻辑”了——写入要额外多花钱，但读取便宜到惊人。关键问题是：你得读几次才划算？

算一下：以 5 分钟 TTL 为例，假设有 100K token 的 context。

不缓存：每次都花 $0.30，100 次就是 $30
用缓存：第一次写入 $0.375，后面 99 次每次 $0.03，总共 $0.375 + $2.97 = $3.345

也就是 **100 次调用省了 89%。但是——如果你只调用 1 次，反而多花了 25%**。这就是为什么 Prompt Caching 不是无脑开就好的。

我自己总结的一个记忆点是：2 次命中就回本。

1 次 write + 1 次 read = $0.375 + $0.03 = $0.405
2 次普通 = $0.60
**省 33%**，够本还有赚

也就是说，只要你这段上下文在 5 分钟内至少会被读到 2 次，缓存就值得开。这个阈值极低，99% 的生产场景都能达到。

二、5 分钟 TTL 和 1 小时 TTL 怎么选

这是另一个容易被忽略的决策。

5 分钟 TTL 是默认的。它的逻辑是：每次成功命中，TTL 会被”续期”回 5 分钟。所以只要你的请求间隔不超过 5 分钟，这个缓存可以一直活着。

1 小时 TTL 是付费的——写入贵一倍。它的适用场景很具体：两次请求之间间隔会超过 5 分钟，但不会超过 1 小时。

实际项目里我这么判断：

聊天机器人场景：5 分钟绝对够，用户跑来跑去发消息，5 分钟之内大概率会有下一条
批量处理 job：看批量的节奏。如果是 1 分钟一批，5 分钟足够；如果是半小时跑一次，用 1 小时 TTL 更划算
客服工单 / 低频查询：1 小时 TTL 合适，因为用户第二次问可能间隔几十分钟
一次性任务：别用缓存，纯粹浪费那 25% 的写入溢价

有个反直觉的坑：不要觉得”1 小时肯定比 5 分钟保险”。1 小时 TTL 写入贵一倍，如果你的实际命中率不高，多花的写入钱会吃掉所有省的读取钱。我在一个项目上吃过这个亏——当时怕 cache miss 把 TTL 都设成 1 小时，结果实际命中率只有 35%，账单比 5 分钟 TTL 版本还贵了 40%。

三、cache_control 到底放哪里

这是实操里最容易错的地方。Anthropic 的 API 要求你在请求体里用 cache_control: {"type": "ephemeral"} 标记出哪些是要缓存的 block。但放的位置大有讲究。

核心规则只有一条：缓存从请求最开始一直延伸到标记位置。你标记的是”这段之前的所有内容都要缓存”的结束点。

举个例子，假设你的请求是这样结构：

[system prompt: 2K]
[大段文档 A: 50K]
[大段文档 B: 30K]
[用户当前的问题: 200]

你要问自己：哪些部分是多次请求之间不变的？

如果文档 A 是每次调用都一样的（比如产品手册），文档 B 也是，只有用户问题在变，那就在文档 B 末尾打标记：

messages = [
    {
        "role": "user",
        "content": [
            {"type": "text", "text": "<manual>...文档A...</manual>"},
            {"type": "text", "text": "<policy>...文档B...</policy>",
             "cache_control": {"type": "ephemeral"}},
            {"type": "text", "text": "用户问题：{question}"}
        ]
    }
]

system prompt 单独也可以标，这里不展开。

最多可以标 4 个缓存断点。这在”部分变部分不变”的场景特别有用。比如：

断点 1：system prompt（永远不变）
断点 2：用户档案（同一用户之内不变）
断点 3：会话历史前 N 轮（每轮往后推）
断点 4：当前轮工具调用结果

这种多断点设计我在做长会话 Agent 的时候用过，命中率能拉到 75% 以上。

四、什么样的请求适合缓存

不是所有 API 请求都值得开缓存。我总结了三个适合的场景：

第一，大段静态上下文 + 小段动态输入。典型代表是文档问答——每次上下文都是那几万字的手册，只有用户问题在变。这种场景缓存命中率天然就高。

第二，多轮对话。只要你的对话超过 3-4 轮，前面的历史 + system prompt 缓存起来就能省很多。我一个做客服机器人的朋友，把这个开了之后月账单从 $1800 降到 $460。

第三，批量并行调用。比如同一个 prompt 模板，不同的用户数据并行跑一百份。第一个请求写入缓存，后面 99 个全是 cache hit，省钱爽到飞起。

不适合缓存的场景也要明确：

上下文每次都变（比如每个请求都是独立的短问答）
context 太短（低于 1024 token，Anthropic 有最小缓存长度限制）
高度敏感的数据不想留在服务端缓存里（虽然官方文档说缓存是隔离的，但合规要求严格的场景自己判断）

五、一个真实的 before/after 账单对比

回到开头那个 PDF 处理项目。我把优化前后的数据摊开：

优化前（每份 PDF 一次独立请求）：

每份 PDF 平均 context 40K token
每天 3000 份
每天 input 消耗：12000 万 token（120M）
日账单：约 120 × $3 = $360（实际因为输出 token，综合算下来 $110 左右按入口看）

优化后（相同的抽取模板用 caching）：

system prompt + 抽取规范（约 8K token）整段缓存
每份 PDF 的正文还是要现读（不能缓存，因为每份不一样）
缓存命中率：~95%
日账单：$18

省了 83%。客户爽到直接给我加了一个模块的单。

这个数字的前提是我做了两件事：

把所有”跨请求不变的”部分整合到 prompt 前半段。很多人一开始把”当前这份 PDF 内容”放在最前面，这样根本没法缓存——小改动
用 5 分钟 TTL，因为 3000 份 PDF 基本是 7x24 在跑，请求间隔远小于 5 分钟

六、最后几个实操建议

上线前先看 cache 命中率。Anthropic API 返回里有 cache_read_input_tokens 和 cache_creation_input_tokens 两个字段，监控这俩就知道缓存是不是真的在工作
不要过度设计。一开始只标一个断点就行，跑起来有数据之后再看要不要加
注意模型版本切换会让缓存失效。从 Sonnet 4.5 升到 4.6 的时候，所有缓存都要重建。这时候预热缓存的成本别忘了算
本地调试先别开缓存。测试阶段频繁改 prompt，开了反而浪费写入费用

Prompt Caching 说白了就是把”重复的 context 只付一次近似全价，之后打 1 折”。这事儿技术上不难，但很多人根本没去看文档，默认就用普通 API。我在 Claude API 知识地图里看到这块的关注度其实不高，大部分人还停留在”换模型省钱”的层面——其实单是把 Prompt Caching 开好，省的钱就比换模型多得多。

降本这件事，cocoloop.cn 主站之前整理过一批案例，如果你想系统了解 AI 应用的成本优化路径，可以去翻翻。

🚀 想深挖更多成本优化技巧？

本站持续更新 Claude API 成本优化实战。想看更多 AI 一手资讯，推荐访问 news.cocoloop.cn；想看 API 相关问答，可以去 ask.cocoloop.cn。