聊聊大模型 API 开发中的 Prompt Caching：原理、数据实测与省钱效果
本文为 AI 生成文章。 本文由 Gemini 3.5 Flash 根据一组真实的 Claude-Opus API 调用数据总结撰写，由 Claude Code（本人所用工具）整理排版后发布。内容涉及计费反推与节省比例的估算，仅供参考。
在开发基于 LLM（大语言模型）的应用时，尤其是涉及长文本分析、连续对话、或者辅助编程等场景，API 的费用往往会随着对话轮数的增加呈现指数级增长。
原因很简单：大模型是无状态的。为了让它记住上下文，每次你发送新消息时，客户端都必须把”历史所有对话 + 新问题”打包成一个巨大的 Prompt 重新发送一遍。这种 $O(N^2)$ 的 Token 增长方式，很快就会让 API 账单变得非常难看。
为了解决这个问题，主流服务商（如 Anthropic、OpenAI 等）推出了 Prompt Caching（提示词缓存） 机制。本文将结合一组真实的 Claude-Opus API 调用数据，用最朴实的程序员视角，拆解这个机制是如何帮我们省钱的。
一、 什么是 Prompt Caching？
简单来说，当你的 Prompt 达到一定长度（通常是 1024 或 2048 Token 以上）时，API 服务商会把这部分 Prompt 的 KV Cache（键值缓存）暂时保存在他们的服务器内存中。
当下一次请求发送过来时，如果你的 Prompt 开头部分（Prefix）与缓存的内容完全一致，大模型就不会重新去计算这部分 Token，而是直接从内存中读取。
这带来了两个直接好处：
- 省钱：缓存读取（Cache Read）的单价通常极其便宜，一般只有标准输入单价的 1/10（1 折）。
- 提速：省去了重复计算上下文的时间，首字响应时间（TTFT）大幅缩短。
二、 实测数据分析
下面是一段连续运行了 22 分钟的真实 API 调用日志。在这个会话中，程序在不断向 Claude-Opus 请求产出长文本，单次输出在 2500 到 4900 Token 之间。
为了方便阅读，我们将数据按照时间正序（从前到后）整理如下（价格保留到小数点后 4 位）：
| 序号 | 触发时间 | 输入 Token | 输出 Token | 缓存读取 Token | 缓存写入 Token | 实际花费 (USD) |
|---|---|---|---|---|---|---|
| 1 | 17:56:35 | 2 | 2,550 | 0 | 14,673 | $0.1555 |
| 2 | 17:59:06 | 2 | 2,938 | 14,673 | 2,597 | $0.0970 |
| 3 | 18:02:19 | 2 | 3,397 | 17,270 | 3,073 | $0.1128 |
| 4 | 18:04:50 | 2 | 3,687 | 20,343 | 3,586 | $0.1248 |
| 5 | 18:07:53 | 2 | 4,275 | 23,929 | 3,617 | $0.1415 |
| 6 | 18:09:58 | 2 | 2,550 | 27,546 | 4,362 | $0.1048 |
| 7 | 18:13:15 | 2 | 4,498 | 31,908 | 2,594 | $0.1446 |
| 8 | 18:16:43 | 2 | 4,901 | 34,502 | 4,527 | $0.1681 |
| 9 | 18:18:07 | 2 | 4,717 | 39,029 | 4,935 | $0.1683 |
程序员视角下的技术细节：
- 极小的物理输入（输入 Token = 2）：由于程序采用了”继续（Continue）”或者自动追加历史的逻辑，真正的”新输入”极其微小（只有 2 个 Token，可能就是一个”继续”指令），大部分上下文都在缓存中流转。
- 缓存的滚动累积：注意看每一轮的
缓存读取。第 2 轮读取了第 1 轮写入的14,673；第 3 轮读取了17,270（即 $14,673 + 2,597$）。整个会话的上下文像滚雪球一样越来越大，到了最后一轮，缓存中已经驻留了 39,029 个 Token。 - 缓存的时效性：每一次请求的间隔都在 2 到 3 分钟左右。这保证了缓存不会因为超时（通常 TTL 为 5 到 10 分钟）而被服务商自动清除。
三、 缓存机制到底帮我们省了多少钱？
我们来做一道简单的对比计算题。
假定该通道的计费规则如下（通过数据反推）：
- 标准输入 / 缓存写入单价：约 $6.40 / 百万 Token
- 标准输出单价：约 $24.20 / 百万 Token
- 缓存读取单价：约 $0.64 / 百万 Token（1 折）
1. 如果没有缓存机制（每次都按标准输入计费）：
在没有缓存的情况下，每次请求都需要把所有历史上下文作为标准输入发送。
- 第 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。
2. 有缓存机制（实际花费）：
根据日志中的 配额消耗 直接求和：
$1.2173。
3. 对比结论：
- 节省金额：$2.4312 - 1.2173 = \mathbf{$1.2139}$
- 成本降幅：49.93%
通过使用缓存，这波调用的账单直接被腰斩（省了一半）。
特别需要注意的是最后一轮（第 9 轮）：此时上下文已经累积到了 4.4 万 Token。如果没有缓存，仅这单次对话就要花费 $0.3955；而开启缓存后，实际仅花费 $0.1683，单次降幅达到 **57%**。
四、 如何在代码中榨干缓存的价值？
如果你也想在自己的项目里落地这个优化，以下是几个非常务实的开发建议：
- 保持 System Prompt 和背景资料静态化，并置于最前：
大模型的缓存匹配是从头开始的（Prefix Matching）。把不经常变动的内容（如 System Prompt、业务知识库、Few-Shot 示例）放在最前面。一旦中间插入了动态变量（如当前时间、用户信息），后面的内容就无法触发缓存了。 - 注意服务商的最小缓存阈值：
并非所有请求都会被缓存。比如 Anthropic 的 Claude-3.5-Sonnet 要求 Prompt 至少达到 1024 Token 才会开启缓存，Opus 则需要更高。如果你的 Prompt 只有一两百个 Token，不需要花精力去设计缓存。 - 集中批处理或控制对话间隔：
缓存是有生命周期（TTL）的，通常在 5 到 10 分钟没有新请求后，缓存就会被释放。如果是后台跑批量任务，建议排队集中发送，避免零星发送导致缓存反复失效。 - 控制链式调用的中间变动：
在设计 Agent 的多步骤链式调用时，尽量保证前置步骤的输出是确定的，或者将动态变化的部分放在 Prompt 的最末尾。
总结
Prompt Caching 不是什么玄乎的高阶算法，而是一个非常纯粹的、符合后端开发直觉的工程优化手段。只要稍微调整一下 Prompt 的拼接顺序和接口调用节奏，就能在长文本和多轮对话场景下换来几乎翻倍的性价比。