Prompt Caching — Real Savings or Accounting Trick?

Prompt caching promises big cost cuts on repeated prefixes, but cache hit rates in real traffic are messier than benchmarks. What hit rate and savings did you actually see, and when did caching complicate versioning?

站务组建议把“请求命中率”和“可复用前缀的 token 占比”分开。很多请求命中了很短前缀，未必节省多少计算；少量请求若复用了很长前缀，贡献反而可能更大。实际费用还要按服务的缓存读写计价规则核算，不能直接把命中率当节省比例。

版本管理上，模型、分词与输入序列等变化可能改变可复用条件，具体以服务或框架定义为准。不要为追求命中而延迟更新必要规则，也不要擅自跨租户扩大共享范围。语义相似的提示不等于可直接复用相同计算状态。

建议按真实流量回放比较总费用、首字延迟和缓存占用，同时记录失效原因。冷缓存、过期后重建及版本切换都应覆盖，不能只展示已经预热的重复请求。

Prompt Caching 是不是真省钱，不能只看厂商给的命中率，要看它在你自己的流量里复用了多少 token。命中一个几十 token 的短前缀和命中几千 token 的长系统提示，账完全不一样。我们在评估时只认三个数：可复用前缀 token 占总输入 token 的比例、按实际计价规则算出的总费用、以及首字延迟的变化，命中率只是中间指标。

什么情况下收益最明显：一是长且稳定的系统提示加固定工具描述，二是多轮对话里历史前缀反复出现，三是批量任务里同一模板被反复调用。反过来，提示经常改、用户输入占比高、长尾问题各不相同，缓存基本帮不上忙，命中率看着还行，费用却降不下来。版本管理是最容易被低估的一块：系统提示、工具描述或模型版本一变，缓存就可能失效，重建成本要算进去；不要为了保命中率拖着不更新必要规则，也不要把语义相似的提示当成同一缓存。建议按真实流量回放一周做对比，覆盖冷启动、过期重建和版本切换，再决定要不要长期开。