提示缓存：把重复的前缀省下来

缓存是按前缀匹配的，不是语义匹配。请求开头哪怕改了一个字，后面的内容再长也无法命中。理解这一点，后面的结构设计、命中率计算和成本判断才有意义。

这个专题包含什么

专题分两部分。原理部分讲三件事：上下文缓存匹配什么、缓存命中率怎么算、token 在缓存计费里扮演什么角色。实践部分讲怎么把请求改成「稳定在前、变化在后」，怎么用对照实验验证命中，怎么把命中率折算回成本，以及最大输出 token 为什么会挤压缓存带来的收益。专题不承诺具体折扣，也不给出通用命中率；不同服务的缓存门槛、存活时间和写入计费都不一样，官方没写清的地方需要按实际响应里的用量字段来测。多用户共用同一前缀时，还要确认缓存隔离边界，避免把甲用户的内容带给乙用户。

学习顺序

先读上下文缓存，弄清前缀匹配、写入与读取的区别；这是后面所有判断的前提。再读缓存命中率，学会从响应的用量字段里拆出命中与未命中，而不是凭感觉说「应该省了」。第三篇是最小实践课：按稳定度重排请求，清掉时间戳、请求 ID 这类伪随机内容，再做一组对照。理解 token 放在第四步，因为计费最终都落到输入与输出 token 上。最后用成本估算课收尾：把命中部分的折扣、未命中部分的全价和写入溢价放在一张账里算，调用次数少时，缓存反而可能更贵。如果用量很小，先做成本估算再决定要不要上缓存，不要为了一个开关增加维护面。

全部相关词条

原理组是判断依据：上下文缓存、缓存命中率、token。实践组是落地手段：提示缓存实操课、成本估算课、最大输出 token。先看懂机制再动手，顺序反了容易把「开了缓存」当成「一定省钱」。另一个容易忽略的点是缓存寿命：间隔太久，下次请求仍然按冷启动计费。命中率也不是越高越好，先看命中的是不是那批真正重复的内容。如果请求前缀本来就短，或者调用频率很低，最合理的决定可能是不做缓存，把钱花在别处。