Anthropic API Prompt Cache深度分析：22%命中率才回本

你在 Anthropic API 上开启 Prompt Caching，因为所有降低成本指南都这么说。但很少有人提到：缓存有一个回本点，如果你的流量达不到这个门槛，账单反而会涨而不是降。

Cache Write 不是免费的——它有额外开销

根据 dev.to 上的分析，在 Anthropic API 上，缓存不仅有一种价格，而是两种，以普通 input token 价格（1.0×）为倍数计算：

Cache write，TTL 5 分钟：普通 input 价格的 1.25 倍。

Cache write，TTL 5 分钟：普通 input 价格的 1.25 倍。

Cache write，TTL 1 小时：普通 input 价格的 2.0 倍。

Cache write，TTL 1 小时：普通 input 价格的 2.0 倍。

Cache read（cache hit）：普通 input 价格的 0.1 倍——即减少 90%。

Cache read（cache hit）：普通 input 价格的 0.1 倍——即减少 90%。

精确前缀匹配机制：只要在 prompt 开头附近改动一个字节，后面整个部分就会被计为 cache miss。

回本点：约 22%

文章算出了回本点与 hit rate h、写系数 W 和读系数 R 的关系：当 (1-h)·W + h·R 低于普通 input 价格时，缓存才有利，等价于最低 hit rate 为 (W-1)/(W-R)。代入具体数字：5 分钟缓存在约 21.7% 的 hit rate 时回本；1 小时缓存——因为写费用翻倍——需要达到约 52.6% 才能回本。

文章中的示例说明：一个运行 claude-sonnet-5（标价 2.00 美元/百万 input token）的 support bot，前缀 20K token，每天 200 次请求。不缓存：8.00 美元/天。Hit rate 90%：1.72 美元/天。但在 hit rate 15% 时——请求过于稀疏导致缓存在被再次读取前就已过期——费用是 8.62 美元/天，比不缓存还贵。

如何真实测量 hit rate，不要靠估算

Anthropic API 的每个 response 都会返回 cache_creation_input_tokens、cache_read_input_tokens 和 input_tokens。用真实流量跑这些字段来计算 hit rate，而不是靠猜。如果 hit rate 是 0% 但每个请求的前缀明明一模一样，文章指出了常见原因：system prompt 里插入了 timestamp 或 UUID，或者 json.dumps 没有对 key 排序导致每次 field 顺序不同——破坏了前缀匹配。

另一个需要留意的细节：缓存生效的最小长度门槛因模型而异，且并不随模型代数增加而单调递增——据文章：Claude Opus 5 上是 512 token，Opus 4.8 和 Sonnet 5 上是 1024 token，Opus 4.6 和 Haiku 4.5 上是 4096 token。一个 3K token 的 prompt 在这个模型上能缓存但在另一个模型上会静默地不缓存，完全不会报错。

在判断缓存是正在省钱还是正在烧钱之前，先测量 production 流量的真实 hit rate。

在判断缓存是正在省钱还是正在烧钱之前，先测量 production 流量的真实 hit rate。

如果流量稀疏或前缀因用户而异（很少重复），考虑关闭 1 小时缓存——相比默认的 5 分钟，它需要高得多的 hit rate 才能回本。

如果流量稀疏或前缀因用户而异（很少重复），考虑关闭 1 小时缓存——相比默认的 5 分钟，它需要高得多的 hit rate 才能回本。

检查前缀中是否有字段因每次请求而变（timestamp、UUID、JSON key 顺序）——这是导致 cache hit rate 归零却无人察觉的常见原因。

检查前缀中是否有字段因每次请求而变（timestamp、UUID、JSON key 顺序）——这是导致 cache hit rate 归零却无人察觉的常见原因。

This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.