缓存命中和缓存未命中有什么区别

很多开发者第一次接带缓存的接口，都是在对账时才发现问题：同一段提示词，两次调用的账单金额差了一截，或者用量记录里多出几个没见过的字段。这篇不推导缓存怎么生效，只帮你分清命中与未命中在你这边分别意味着什么，以及出账对不上时按什么顺序自查。

很多开发者第一次接带缓存的接口，都是在对账时才发现问题：同一段提示词，两次调用账单金额差了一截，用量记录里还多出几个没见过的字段。先别急着怀疑接口算错，大概率是命中和未命中走了两条不同的计价口径。

这篇不推导缓存怎么生效，只帮你分清命中与未命中在你这边分别意味着什么、账单上怎么认出来、出账对不上时按什么顺序自查。核心一句话：命中和未命中不是「快和慢」的区别，是「要不要重新算一遍输入」的区别。

命中和未命中，差的到底是什么

未命中，服务端要把这次请求的输入从头处理一遍，这部分按正常的输入口径计价。命中，是复用之前已经算过的那段内容，通常走一个单独的、更低的计价项。所以你看到的不是同一个数字变大变小，而是多出来一个计费项目。

• 对开发者可见的差别主要是两个：账单上多一行缓存相关的用量字段，以及同一请求的响应延迟一般更低。
• 命中不保证省钱。如果缓存写进去之后没被复用几次就过期，写入那部分成本就成了沉没成本。
• 判断值不值，先量复用次数，再看单价差，顺序别反。

账单和用量记录里怎么认出来

先看用量明细有没有把缓存写入、缓存读取、普通输入、普通输出分成独立的列。如果这几项混在一列里，你没法直接横向比较，也倒推不出实际单价，这种口径下的对账基本是白费劲。

算实际单价前，先确认自己拿的是哪一列除以哪个总量。各家对缓存字段的命名和口径并不统一，跨平台比价前得先把口径对齐，可以到 /ai-nav/category/ai-api 看当时的倍率和额度说明，别拿记忆里的数字硬套。

什么情况下值得开，什么情况下不划算

判断标准其实就一条：同一段固定前缀，被重复调用的次数够不够多。够多，写入成本被摊薄，缓存读取的单价优势才体现出来；不够多，开缓存只是给自己增加一层对账负担。

• 值得开：同一段长前缀被反复调用；对话轮次多但系统提示固定；批处理任务共享同一套指令。
• 不划算：每次请求的输入都不一样；可复用的前缀本身很短；调用间隔长到缓存早已过期；请求量太小，摊不平写入成本。
• 介于两者之间的情况，先从用量记录里量出一段固定前缀实际被复用了多少次，再决定要不要开，不要凭感觉。

对不上账时的排查顺序

出账和预期对不上，别一上来就找客服，先按下面的顺序自查一遍，大部分问题在前两步就能定位。顺序错了会把时间浪费在核对计价档位上，而问题其实出在请求结构。

1. 确认前缀是否真的可复用看这几次调用有没有共享同一段前缀，中间是不是插了变量、时间戳、随机 ID 这类每次都变的内容。
2. 核对用量字段和计价口径把缓存写入、缓存读取、普通输入、普通输出这几列单独拎出来，分别乘以对应单价再相加，别混算。
3. 对照当时的计价档位到 /official-api 核对当时的计价档位，不要用记忆里的价格去倒推，价格是会调整的。
4. 确认中转的折算方式如果走的是中转，额外确认它对缓存字段怎么折算，不同站的处理可能不一样，到 /sites 看对应站点说明。

命中和未命中不是快慢问题，是「这段输入要不要重新算一遍」的问题，账单上的差别都从这里来。