证明提示缓存真的命中了：在聚合站上别靠猜，靠可观测证据
本文介绍如何在LLM API聚合站上通过可观测证据判断提示缓存是否真的命中，避免将偶然的快响应当成命中。文章从缓存命中的本质出发，讲解在OpenAI兼容接口上可获取的信号（如usage字段中的缓存相关计数），并给出埋点与验证的实操方法，帮助开发者建立可靠的缓存命中判断逻辑。
提示缓存能显著降低延迟和成本，但很多开发者容易把一次偶然的快响应当成缓存命中。在聚合站上，由于底层可能路由到不同模型供应商，判断缓存是否命中更需要可观测证据。本文介绍如何通过埋点和接口信号来可靠地验证缓存命中。
缓存命中的本质
提示缓存通常由模型供应商实现：当相同的前缀（如系统提示、长上下文）在短时间内重复出现时，供应商会复用已计算的部分，从而减少计算量。命中时，API响应可能更快，但快响应不一定代表命中——网络波动、模型负载低、请求简单都可能导致快速返回。因此，不能仅凭延迟判断。
OpenAI兼容接口上的可用信号
大多数聚合站提供OpenAI兼容的接口。在响应中，usage字段可能包含缓存相关的计数。例如，部分供应商会在usage中返回prompttokensdetails，其中包含cached_tokens（或类似字段），表示本次请求中命中缓存的token数。具体字段名和可用性取决于底层供应商和聚合站的透传策略。
你可以检查响应JSON中是否存在此类字段。如果聚合站透传了供应商的原始usage，你就能直接看到缓存命中情况。若未透传，则需通过其他方式推断。
埋点与验证方法
要可靠判断缓存命中，建议在客户端埋点，记录每次请求的以下信息：
- 请求时间戳
- 请求的模型名称
- 提示前缀的哈希（如系统提示+历史消息的哈希）
- 响应延迟
- 响应中的usage字段（完整记录）
- 是否流式响应
然后，对相同前缀的连续请求进行对比。如果第二次请求的usage中cached_tokens大于0，或延迟显著低于第一次且稳定，则可能命中。但要注意：延迟降低也可能是其他因素导致，因此usage字段是更直接的证据。
设计对照实验
为了排除偶然因素，可以设计对照实验：
- 准备两个不同的长前缀A和B，长度相近。
- 交替发送请求：A, B, A, B...
- 记录每次的usage和延迟。
- 如果A的第二次请求出现缓存计数或延迟明显下降，而B没有，则说明A命中了缓存。
重复多次，观察一致性。
聚合站的特殊考量
聚合站可能将请求路由到不同供应商，不同供应商的缓存策略和usage字段可能不同。因此，你需要确认聚合站是否保证相同前缀的请求路由到同一供应商。如果不保证，缓存命中率可能不稳定。建议在埋点中记录响应头或响应体中可能存在的供应商标识（如果有），以便分析。
另外，聚合站可能对usage字段进行标准化处理，导致缓存计数丢失。在这种情况下，你可以通过延迟分布来间接推断，但可靠性较低。最佳实践是优先选择透传原始usage的聚合站。
总结
判断提示缓存是否命中，不能依赖单次快响应。通过记录usage中的缓存计数、设计对照实验、并考虑聚合站的路由特性，你可以获得可观测证据，从而准确评估缓存效果，优化提示设计。