聊聊大模型 API 开发中的 Prompt Caching：原理、数据实测与省钱效果

本文为 AI 生成文章。 本文由 Gemini 3.5 Flash 根据一组真实的 Claude-Opus API 调用数据总结撰写，由 Claude Code（本人所用工具）整理排版后发布。内容涉及计费反推与节省比例的估算，仅供参考。

重要前置说明：本文基于 Anthropic Claude 系列（实测数据来自 claude-opus-4-8）的 Prompt Caching 机制。各厂商的缓存实现并不通用、规则也各不相同——TTL、计费倍率、最小可缓存长度、命中条件都有差异。比如 OpenAI 的缓存是自动开启、通常 5～10 分钟过期、按缓存命中给予约 50% 折扣（而非 Claude 的 1 折读取）；Google Gemini 的 Context Caching 则需要显式创建缓存对象、按存储时长额外计费。下文所有单价、倍率、TTL 数字都仅适用于 Claude，套用到其他厂商前请务必查阅其官方文档。

在开发基于 LLM（大语言模型）的应用时，尤其是涉及长文本分析、连续对话、或者辅助编程等场景，API 的费用往往会随着对话轮数的增加呈现指数级增长。

原因很简单：大模型是无状态的。为了让它记住上下文，每次你发送新消息时，客户端都必须把”历史所有对话 + 新问题”打包成一个巨大的 Prompt 重新发送一遍。这种 O(N²) 的 Token 增长方式，很快就会让 API 账单变得非常难看。

为了解决这个问题，主流服务商（如 Anthropic、OpenAI 等）推出了 Prompt Caching（提示词缓存） 机制。本文的实测与计费分析均以 Anthropic Claude 为准——它把缓存做成了前缀匹配 + 两档 TTL 的开关，读取约 1 折、写入有溢价，规则清晰。本文将结合一组真实的 Claude-Opus API 调用数据，用最朴实的程序员视角，拆解这个机制是如何帮我们省钱的。

一、 什么是 Prompt Caching？

简单来说，当你的 Prompt 达到一定长度（通常是 1024 或 2048 Token 以上）时，API 服务商会把这部分 Prompt 的 KV Cache（键值缓存）暂时保存在他们的服务器内存中。

当下一次请求发送过来时，如果你的 Prompt 开头部分（Prefix）与缓存的内容完全一致，大模型就不会重新去计算这部分 Token，而是直接从内存中读取。

这带来了两个直接好处：

1. 省钱：缓存读取（Cache Read）的单价通常极其便宜，一般只有标准输入单价的 1/10（1 折）。
2. 提速：省去了重复计算上下文的时间，首字响应时间（TTFT）大幅缩短。

而缓存的生命周期（TTL）是这套机制里最关键、也最容易被忽略的变量。Claude 提供两种档位：5 分钟缓存（5m，默认） 和 1 小时缓存（1h，需显式开启）。前者写入便宜但过期快，后者写入更贵但留得久——这个差异，会直接决定你的账单是”省一半”还是”省了个寂寞”。后文的实测会专门对比两者。

注：5m / 1h 两档 TTL 是 Claude 特有的设计。其他厂商不一定有”可选手动开启长 TTL”这种机制——OpenAI 的缓存 TTL 不可配置，Gemini 的缓存则要按小时单独付存储费。下文的 5m vs 1h 对比只对 Claude 成立。

二、 实测数据分析

1. 机器节奏的高频会话（9 条）

下面是一段连续运行了 22 分钟的真实 API 调用日志。在这个会话中，程序在不断向 Claude-Opus 请求产出长文本，单次输出在 2500 到 4900 Token 之间。

为了方便阅读，我们将数据按照时间正序（从前到后）整理如下（价格保留到小数点后 4 位）：

程序员视角下的技术细节：

1. 极小的物理输入（输入 Token = 2）：由于程序采用了”继续（Continue）”或者自动追加历史的逻辑，真正的”新输入”极其微小（只有 2 个 Token，可能就是一个”继续”指令），大部分上下文都在缓存中流转。
2. 缓存的滚动累积：注意看每一轮的 缓存读取。第 2 轮读取了第 1 轮写入的 14,673；第 3 轮读取了 17,270（即 14,673 + 2,597）。整个会话的上下文像滚雪球一样越来越大，到了最后一轮，缓存中已经驻留了 39,029 个 Token。
3. 缓存的时效性：每一次请求的间隔都在 2 到 3 分钟左右。这保证了缓存不会因为超时（5m TTL）而被服务商自动清除——这是一段典型的”机器节奏”会话，5m 缓存游刃有余。

2. 但真实的人类使用不是这样（43 条完整日志）

上面这 9 条之所以省心，是因为程序调用间隔只有 2～3 分钟，5m TTL 几乎永远不会被打破。但真实的人类使用完全不同——看文献、思考、打字、喝口水，任何一步都可能把间隔拖过 5 分钟。

为了搞清楚 5m 和 1h 到底哪个更实用，我又拉取了一段跨越约 12.5 小时（2026-06-19 11:36 至 2026-06-20 00:07）、共 43 条 的更完整调用日志来复盘。上面那 9 条（17:56～18:18）正是其中第 13～21 条。

为便于阅读，价格保留到小数点后 4 位，时间统一取 HH:MM:SS：

数据特征速览：模型以 claude-opus-4-8 为主（39 次），夹杂少量 gemini-3.5-flash（3 次）和 gpt-5.4（1 次）；使用节奏呈现明显的”集中爆发后长久停顿”的 Session 模式。其中前 12 条（11:36～16:12）是典型的零缓存段（缓存读/写全为 0），第 13～21 条是上面那份高频 5m 缓存段，24 条之后则混入了 1h 缓存的痕迹。

3. 请求间隔分布：5m 与 1h 谁覆盖得更广

把相邻两次请求的时间差（共 42 个间隔）分成三档，就能直观看出两种 TTL 的覆盖率差异：

• 5m 缓存最多只能覆盖 66.7% 的请求；
• 1h 缓存可以覆盖到 **90.5%**（再多吃下中间那 23.8%）；
• 剩下 9.5% 的长停顿，谁也救不了，必须重新冷写入。

也就是说，对人类节奏的会话而言，1h 缓存比 5m 缓存多覆盖近四分之一的场景。

4. 现场：抢 5m”抢不过来” vs 1h”续命成功”

光看分布不够直观，日志里有两段几乎教科书级别的现场。

现场一：抢 5m 缓存”功亏一篑”（20:52 ～ 21:04）

• 20:52:14：冷写入 29,571 Token；
• 20:57:49（间隔 5 分 35 秒）：仅仅比 5 分钟多出了 35 秒，5m 缓存已经过期，缓存读取直接归 0，系统被迫重新完整写入 34,329 Token，单次烧掉 **$$0.3553$**。

这就是典型的”只差一点点，5m 没抢过来”。

现场二：1h 缓存”续命成功”（23:12 ～ 23:33）

• 23:12:32：写入 36,269 Token；
• 23:19:36（间隔 7 分 04 秒）：按 5m 逻辑缓存早该清空，但实际数据是——缓存读取 36,269，仅增量写入 4,760。7 分钟前写入的 36k 完好复用；
• 23:33:14（间隔约 12 分钟）：依然成功读取了 5,376 缓存 Token，增量写入 2,120。

这组铁证说明：后期已切换到 1h 缓存，原本会被 5m TTL 清掉的几万 Token，被长 TTL 成功捞了回来。

三、 缓存机制到底帮我们省了多少钱？

1. 开缓存 vs 不开缓存（粗略估算）

先做一道简单的对比计算题。假定该通道的计费规则如下（早期粗略反推）：

• 标准输入 / 缓存写入单价：约 $6.40 / 百万 Token
• 标准输出单价：约 $24.20 / 百万 Token
• 缓存读取单价：约 $0.64 / 百万 Token（1 折）

在没有缓存的情况下，每次请求都需要把所有历史上下文作为标准输入发送（以上面 9 条为例）：

• 第 1 轮：输入 14,675 + 输出 2,550 = $0.1555
• 第 2 轮：输入 (2 + 14,673 + 2,597) = 17,272 + 输出 2,938 = $0.1816
• 第 3 轮：输入 (2 + 17,270 + 3,073) = 20,345 + 输出 3,397 = $0.2124
• …
• 第 9 轮：输入 (2 + 39,029 + 4,935) = 43,966 + 输出 4,717 = $0.3955

将这 9 轮的无缓存预估费用相加，总计为：$2.4312。而开启缓存后，日志里的 配额消耗 直接求和只有 $1.2173。

• 节省金额：2.4312 − 1.2173 = $1.2139
• 成本降幅：49.93%

通过使用缓存，这波调用的账单直接被腰斩（省了一半）。特别注意的是最后一轮（第 9 轮）：上下文已累积到 4.4 万 Token，无缓存要 $0.3955，开缓存仅 $0.1683，单次降幅 **57%**。

2. 从账单精确反推：5m、1h、零缓存各多少钱

上面用的是粗略单价。现在手握 43 条完整数据，可以把三档价格钉得更准。用日志里”纯零缓存”段（如 11:36、16:03）反推，得到基础价：

• 基础输入单价：0.000005$/token）
• 基础输出单价：$$25.00$ / 百万 Token

再拿 5m 段和 1h 段的”写入”请求做减法，就能把缓存读写单价也钉死。

5m 缓存写入单价（以 17:56:35 为例：输出 2,550、写入 14,673、花费 $$0.155466$）：

1h 缓存写入单价（以 23:12:32 为例：输出 4,697、写入 36,269、花费 $$0.480124$）：

读取单价在两种模式下都不变，稳定在 $$0.50$ / 百万 Token（基础输入的 1 折）。三种模式的完整价格表如下（均为 Claude 的计费倍率——5m 写入 1.25×、1h 写入 2×、读取 0.1× 是 Anthropic 的官方定价规则；OpenAI 读取折扣约 0.5×、Gemini 需另付缓存存储费，倍率完全不同，不可混用）：

注：第 1 小节里 $6.40 与 $0.64 是早期粗估；这里用完整 43 条数据反推后得到更精确的 $6.25、$0.50（5m）与 $10.00、$0.50（1h）。结论方向不变——缓存读取只要 1 折，这是省钱的核心。

3. 盈亏平衡：1h 写入涨价 60% 划不划算

1h 缓存写入单价贵了 60%（从10.00$），值不值，取决于它替你挡掉了多少次”冷启动重新写入”。以单次缓存数据量 30k Token 做盈亏平衡：

• 5m 缓存超时后重新写入一次：

• 1h 缓存首次写入更贵（多花 $$0.1125$）：

• 但若 5～60 分钟内出现一次本会失效的请求，1h 改为”读取命中”：

相比 5m 失效后的重新写入（$$0.1875$），这次命中直接省下：

结论：虽然 1h 首次写入多花 $$0.1125$，但只要在 1 小时内因”超时没抢过 5m”而少发生 1 次冷启动（省 $$0.1725$），多出来的写入成本就被完全覆盖并开始盈利。日志里 22:49～23:21 那段多次 7～11 分钟停顿，正是用更高的写入单价换来了多次 3.6万～4.1万 Token 的高额读取命中，整体依然合算。

4. 三种策略实战算账

假设一段对话平均历史上下文 30,000 Token、每轮新增输入 3,000 Token、共 5 轮：

场景 A：手速极快，每轮都控制在 5 分钟内（完美命中）

• 零缓存：每轮都为全部历史买单，$30k\to33k\to36k\to39k\to42k$

• 5m 缓存：首轮写入 30k，后续 4 轮读取 30k + 写入新增 3k

省约 64%。

• 1h 缓存：逻辑同上，写入按 $$10.00$ 算

省约 46%。

高频连续对话里，5m 缓存最省钱；1h 因写入太贵反而吃亏；零缓存最贵。

场景 B：正常对话，第 3、4 轮之间停了 7 分钟（去喝了口水）

• 零缓存：不受时间影响，仍为 $0.90；
• 5m 缓存：第 4 轮超时失效，必须重新全额写入 39k（39k × $6.25/M），总额升至 约 $0.47（一次超时多花近 50%）；
• 1h 缓存：7 分钟仍在窗口内，顺利读取（39k × $0.50/M），总额保持 约 $0.48。

一旦出现 1～2 次轻微停顿，5m 省下的钱就会被”重新写入”迅速蚕食，最终几乎与 1h 持平，长对话里甚至可能反超。

四、 如何在代码中榨干缓存的价值？

如果你也想在自己的项目里落地这个优化，以下是几个非常务实的开发建议：

1. 保持 System Prompt 和背景资料静态化，并置于最前：
   大模型的缓存匹配是从头开始的（Prefix Matching）。把不经常变动的内容（如 System Prompt、业务知识库、Few-Shot 示例）放在最前面。一旦中间插入了动态变量（如当前时间、用户信息），后面的内容就无法触发缓存了。
2. 注意服务商的最小缓存阈值（Claude 因模型而异）：
   并非所有请求都会被缓存。Claude 不同模型的最小可缓存前缀不同：Sonnet 4.5/4.6、Haiku 3.5 等约 1024～2048 Token，而 Opus 4.5～4.8 需要 4096 Token 才会缓存。低于阈值的请求即使打了 cache_control 标记也静默不缓存（不报错，只是 cache_creation_input_tokens 始终为 0）。如果你的 Prompt 只有一两百个 Token，不需要花精力去设计缓存。其他厂商阈值规则各异，需另行确认。
3. 集中批处理或控制对话间隔：
   缓存是有生命周期（TTL）的，5m 缓存在 5 分钟没有新请求后就会被释放，1h 缓存则能撑到 1 小时。如果是后台跑批量任务，建议排队集中发送，避免零星发送导致缓存反复失效。
4. 控制链式调用的中间变动：
   在设计 Agent 的多步骤链式调用时，尽量保证前置步骤的输出是确定的，或者将动态变化的部分放在 Prompt 的最末尾。
5. 看”工作流”选 TTL 档位：
   • 坚决不用零缓存：除非是单次、不带历史的”One-shot”一问一答，否则只要超过 2 轮，哪怕用写入最贵的 1h 缓存也比零缓存划算得多。
   • 自动化脚本 / Agent 自动运行（间隔以秒计）：无脑选 5m 缓存，写入便宜、成本最低；
   • 人类在网页/客户端交互（看文献、思考、打字，极易超 5 分钟）：建议开 1h 缓存，用稍高的写入单价换取整段对话的容错率和稳定性，避免现场一那种”只超 35 秒就重写 34k Token”的惨剧。
6. 5m 的”心跳续命”技巧：
   若被迫用 5m 又怕超时，可以在客户端引入”自动心跳”——例如第 4 分钟发一个微型请求把缓存顶活，用 5m 的低价逼近 1h 的留存效果。

总结

Prompt Caching 不是什么玄乎的高阶算法，而是一个非常纯粹的、符合后端开发直觉的工程优化手段。只要稍微调整一下 Prompt 的拼接顺序和接口调用节奏，就能在长文本和多轮对话场景下换来几乎翻倍的性价比。

更进一步，在 5m 与 1h 两种 TTL 之间做选择，本质上是在写入单价和容错窗口之间做权衡：机器节奏选 5m 最省，人类节奏选 1h 最稳。搞清楚自己调用链的”心跳节奏”，才能把缓存这把刀用到最锋利的那一面。

最后再强调一次全文的适用边界：以上原理、计费倍率（5m 写入 1.25×、1h 写入 2×、读取 0.1×）、两档 TTL、最小缓存阈值，都是 Anthropic Claude 系列 的实测结论。换到 OpenAI、Gemini 等其他厂商时，缓存机制的设计和价格模型并不互通——省钱思路相通，但具体数字必须以各家官方文档为准。