Prompt Caching 实战

企业如何大幅降低 LLM API 费用

以 2026 年 7 月实测数据为准。Anthropic 如有静默更新，实际行为可能有所变化。

问题的根源

不少企业在导入 LLM API 之后，发现每月账单持续攀升，却找不到明显的优化空间。问题往往出在一个容易被忽略的地方：每一个对话回合，系统都在重新传送完全相同的系统提示词给模型，而每一个 token 都按全价计费。

以一个生产环境的对话系统为例，系统提示词动辄超过四千个 token。每次对话、每个回合，这四千个 token 都在重复传送、重复计费。这不是架构缺陷，而是大多数团队未曾留意的计费盲点。

Anthropic 的 Prompt Caching 功能正是针对此问题而设。然而，它的实际运作方式与许多人的直觉判断存在几个关键落差，踩错其中一个，cache 便会静默失效——账单照旧，开发者毫不察觉。

计费原理

Prompt Caching 的核心逻辑是将稳定的 token 序列在首次传送时写入缓存，后续回合直接读取，而非重新处理。计费公式如下：

总费用 = Cache Read × 0.1 + Cache Write × 1.25 + 未缓存输入 + 输出

Cache Read 的费率是正常输入价格的 10%；Cache Write 是 125%，属一次性成本。首个回合写入缓存，第二个回合起即开始读取，费用大幅下降。

以实测数据说明：第二个回合写入 3,157 个 token，第三个回合读取同样的 3,157 个 token，单回合计费下降约 47%。对话越长，累积节省越显著。根据生产系统的实测，短对话可节省约 54%，长对话则可达 80% 至 90%。

模型设有最低 token 门槛：Claude Sonnet 需达 1,024 tokens，Claude Haiku 需达 2,048 tokens。系统提示词过短将无法触发缓存，这是另一个常见的认知落差。如需了解各模型的 API 定价，可参考2026 年 LLM API 定价比较。

哪些内容适合缓存

适合放入缓存的是「稳定内容」——每次对话都不会改变的系统提示词静态部分，例如角色定义、回应格式指引、固定的背景知识。这类内容结构清晰，长期不变，是缓存命中率最高的候选项目。

不适合缓存的是「动态内容」，包括每次查询结果都不同的 RAG 记忆区块，以及每个回合都在向前移动的对话历史最后一条消息。这类内容每回合都在变化，即使设置缓存标记，缓存 key 每次都不同，结果是每回合都在写入而从不读取。

这里有一个关键的架构原则：稳定内容与动态内容必须分离。若将 RAG 查询结果混入系统提示词，系统提示词便会因此在每个回合发生变化，缓存永远无法命中。这是生产系统中最常见、也最难被察觉的错误。

实际踩过的坑

缓存本身并不复杂，但有几个陷阱值得特别注意。

动态内容混入系统提示词。如上所述，这是命中率归零的最直接原因。解决方法是在架构层面明确分离 stablePart 与 dynamicPart，前者设置 cache_control，后者另行传递。

缓存标记放在对话最后一条消息。缓存的边界每个回合都在向前移，导致每次都是写入而从不读取。缓存标记应设置在稳定的系统提示词区块，而非动态移动的消息边界。

加入 Streaming 后未重新验证缓存。Streaming 部署后，缓存可能静默失效。若未主动追踪 cache_creation 与 cache_read 的回应数值，三个回合全部显示 cache_creation: 0 才会被发现。

TTL 格式错误。正确格式为整数秒数（ttl: 300），而非字符串（ttl: "1h"）。格式错误不会返回 400 错误，API 正常接受请求、回应正常，只是缓存静默不生效。这类问题需通过刻意追踪 billing log 才能察觉。

Anthropic 亦曾在未正式通知的情况下更新缓存行为：2026 年 3 月，TTL 由 1 小时缩短至 5 分钟，长对话的命中率因此下跌；2026 年 7 月，显式 TTL 由可选变为必填，未设置者静默失效。两次变更均非通过 400 错误或文件更新通知，而是直接影响计费数字。定期核对 cache 命中数据，是生产系统的基本监控项目。

结语

Prompt Caching 本身的逻辑并不难，但它的效果完全取决于实作细节：稳定内容与动态内容是否分离、缓存标记的位置是否正确、TTL 格式是否符合当前 API 规范。以上任何一点出错，缓存便会静默失效，账单照旧，而日志里不会出现任何错误提示。

对于已在生产环境使用 LLM API 的团队，值得做的第一步是追踪每个回合的 cache_creation_input_tokens 与 cache_read_input_tokens 数值。若 cache_creation 持续高于 cache_read，通常意味着架构中存在上述问题之一。找到问题、修正分离逻辑，节省效果往往立竿见影。