把输入拆成两块，是这个工具的前提

提示缓存复用的是请求前缀，所以算收益前必须先把一次请求的输入拆成两部分： 每次都一样的固定前缀（system prompt、工具/函数定义、常驻知识片段）， 和每次都变的变化部分（检索片段、对话历史、用户输入）。

固定前缀占总输入的比例，直接决定了收益上限——这个比例是六成，那么无论命中率多高， 你最多也只能优化这六成的成本。工具会把这个上限单独算出来，避免你对缓存抱有不切实际的期待。

命中率从哪来

已经上线的项目，从 API 响应的 usage 字段取缓存命中的 token 数，除以总输入 token 数。 这个数要记进日志并做成监控——缓存最坑的地方是没生效不会报错， 账单照样出，只有你以为省了钱。

还没上线的话，先用「固定前缀占比」当理论上限估一个偏乐观的值，再算一遍悲观值（比如打对折）， 给出一个区间而不是单点。命中率上不去的八个常见原因见 提示缓存命中率上不去？八个常见原因。

怎么把命中率做上去

就一条原则：把请求的前半截钉死。具体做法是按稳定性分层拼装请求—— 系统指令、工具定义、常驻知识放最前面，检索片段、历史、用户输入放后面。

然后把前缀里的动态内容全部赶走：当前时间（真要的话降低精度到天）、请求 ID / 追踪 ID （挪到请求头或元数据）、用户标识、随机排序的集合（显式排序）。 缓存是逐字符前缀匹配，差一个字符，后面几千 token 就一起作废。

算出来不划算怎么办

说明你的场景不适合靠缓存降本，该换个方向： 如果固定前缀占比低，先去压缩变化部分（用检索替代整份文档、裁剪历史）； 如果输出占大头，去控制输出长度，见 max_tokens 该设多大； 如果调用稀疏，缓存等不到复用就过期，考虑把可延迟的任务改走批处理（通常五折）， 见提示缓存和批处理该用哪个。

完整的降本优先级见大模型 API 降本十招， 缓存本身的计费结构（命中价、写入价、存活时间）见 提示缓存是怎么计费的。

一个容易被忽略的附带收益

缓存命中的部分不用重算，首 token 延迟会明显下降。 交互式产品里，这个体感收益有时比省下的钱更值钱，但它不会出现在账单上，所以经常被漏掉。 评估缓存效果时建议成本和延迟两个指标一起看，测法见 大模型 API 的速度怎么测。