缓存命中率一般是多少

很多人第一次开缓存，看到账单上一个「缓存读」一个「缓存写」，却不知道命中率多少算正常。本篇给一套可落地的判断方法：先算你自己的命中率，再按任务类型判断它偏低还是正常，最后知道该往哪调。数字口径会变，具体倍率去站内官方 API 价格页核对。

很多人第一次开缓存，账单上突然多出「缓存读」「缓存写」两行，心里没底：命中率多少才算正常？这事没有统一答案，因为不同任务类型的天然命中率差得很远。可行的做法是先搞清账单里「命中」指什么，再拿自己的用量日志算一遍，最后按任务类型判断是偏低还是本来就这样。

这篇给一套可落地的判断顺序：先对齐口径，再分档看区间，再自己算，再决定要不要调。文中不写死具体倍率和数值，因为各家平台口径和调价节奏不一样，具体倍率请到站内官方 API 价格页核对当时的数字。

先搞清「命中」在账单里指什么

缓存命中指的是：这次请求的前缀部分，命中了之前已经写入缓存的那段内容。命中的那部分 token 按「缓存读」计价，没命中的部分还是按普通输入计价。所以命中率高不高，直接影响的是输入侧的开销结构，而不是输出侧。

还有一笔容易忽略的账：写入缓存的那一次请求，通常单独按「缓存写」计价。这一笔是前置投入，和后面命中省下的钱不是同一笔账。如果你只看命中率不看写入频次，可能会得出错误结论。具体两档价格差多少，去站内官方 API 价格页核对当时的数字。

• 先确认平台按请求数算命中，还是按 token 数算命中，两种口径算出来的命中率能差出很多
• 确认账单里「缓存读」「缓存写」「普通输入」三栏分别对应什么，别把它们混在一起算
• 确认缓存有效期是多久，过期后的请求会重新走写入，命中率会周期性掉下去

命中率的常见区间：按任务类型分档看

命中率没有「正常值」，只有「这个任务类型下的常见区间」。判断自己偏低还是正常，先给任务归个类，再看同一类里别人的大致水平。下面这张表是分类思路，具体数值请到站内官方 API 价格页和用量日志说明页核对当时的数字。

解释一下为什么多轮对话「越往后越高」：历史消息本身在不断累积，前面的部分只要没被改动，就会成为下一次请求的稳定前缀。但风险也在这里，一旦你在历史中间插入新内容或者改了系统提示，前缀直接失配，命中率会掉一段。

用自己的用量日志算一遍，别套别人的数

别人的命中率对你没有参考价值，因为提示结构不一样。正确做法是从自己的用量日志里取数：拿缓存读 token 数除以总输入 token 数，注意分子分母要用同一口径。如果日志里没这两个字段，先补上再算。

1. 取数从用量日志里筛出最近的真实请求，导出缓存读 token 和总输入 token 两列。
2. 对齐口径确认两列都是 token 口径，不是请求数口径，混用会让结果完全失真。
3. 算比值按同一口径相除，得到你自己的命中率，再和上表的任务类型对照。
4. 验证连算两三天，看波动是否稳定；波动大说明前缀不稳定，先查变动源。

建日志字段的顺序和字段清单，站内有用量日志相关的说明页面可以参考着建。注意别拿压测数据算命中率，压测的重复度不真实，算出来的数会虚高。

想把命中率提上去，改这几处最有效

命中率低，绝大多数时候不是平台的问题，是提示结构的问题。核心原则只有一条：不变的放前面，变的放后面。下面几处改起来成本最低、效果最直接。

• 把系统提示、规则、示例这些固定内容全部前置，用户输入和当次变量放最后
• 检查前缀里有没有时间戳、随机 ID、会话编号这类每次都变的东西，有就挪到最后
• 同一类任务里保持模型和参数不变，换模型等于缓存前缀作废，命中率立刻掉
• 批处理任务集中跑，别拖到缓存过期再调，过期后要重新写入

还有一个常见坑：为了让回答更新鲜，有人在系统提示里塞了当前时间。这一个字段就能让整段前缀失效，命中率从高位直接掉到低位。改法很简单，把它移到用户输入里，或者干脆不写。

什么时候不用在意命中率

命中率不是越高越好，它只是一个成本优化指标。有些情况下，花时间把它提上去，省下的绝对金额还不如你把时间用在别处。判断标准看两条：调用量有多大、提示本身有多长。

• 调用量本来就小，命中率再高也只是省一点零头，不划算专门优化
• 提示本身很短，缓存读和普通输入的差价很小，优化空间有限
• 任务是一次性长文档分析，没有第二次命中的机会，重点该放在裁短输入
• 当前已经在用更便宜的档位，再优化命中率的边际收益不明显

还有一种情况是团队对延迟更敏感：某些平台上缓存读和普通输入的响应速度差不多，这时候优化命中率主要看账单，不要把响应速度当成理由。具体差异到站内价格页和模型资料库核对当时的说明。