缓存行为因后端而异：实测 Claude、GPT、DeepSeek 是否都认你的缓存前缀

为什么缓存不能一概而论

许多聚合站用户默认：只要请求前缀相同，所有模型都会命中缓存。实际上，缓存是各模型供应商在服务端实现的机制，是否支持、如何计费、前缀匹配的粒度都可能不同。把同一份工作负载发往不同后端，命中率可能有明显差异。

设计一个可复现的横向对比

要比较缓存行为，需要控制变量，让请求除了模型后端之外尽可能一致。

• 固定前缀：准备一段足够长、内容稳定的系统提示或文档上下文，作为可缓存前缀。
• 固定后缀：每次请求只改变末尾的用户问题，确保前缀部分完全一致。
• 固定参数：温度、最大输出长度等参数保持一致，避免无关变量干扰。
• 连续请求：对同一后端连续发送多次，观察从第几次开始命中缓存。
• 记录用量字段：多数供应商会在响应 usage 中返回缓存命中/未命中的 token 数，注意收集这些字段。

实测观察：不同后端表现不同

在聚合站同一把 key 下，对 Claude、GPT、DeepSeek 分别跑上述工作负载，可以观察到：

• Claude：通常对显式标记的可缓存前缀有明确支持，命中情况可从响应字段读出。
• GPT：部分模型支持自动前缀缓存，但命中条件与前缀长度、请求间隔有关。
• DeepSeek：也提供上下文缓存能力，但计费方式和命中判定与前者不完全相同。
• 其他后端（Qwen、GLM、Kimi 等）：支持程度各异，需要逐一验证。

关键结论不是“谁更好”，而是不能假设缓存行为跨后端一致。同一份前缀在 A 后端命中，在 B 后端可能完全不命中。

如何解读命中率差异

命中率差异可能来自几个层面：

• 是否支持：部分后端没有前缀缓存机制。
• 前缀长度门槛：有的后端要求前缀达到一定长度才启用缓存。
• 匹配粒度：有的按 token 精确匹配，有的允许一定容错。
• 过期策略：缓存有效期不同，间隔太久会失效。

因此，看到命中率为零时，先确认该后端是否支持缓存，再检查前缀长度和请求间隔。

在聚合站场景下的成本优化建议

聚合站按官方价 ×1.3 扣费，缓存命中通常能降低实际消耗。要利用好这一点：

• 先测再优化：对常用后端跑一轮小规模对比，确认哪些后端真正命中。
• 前缀尽量稳定：把系统提示、文档上下文放在最前面，并保持内容不变。
• 集中请求：在缓存有效期内连续请求，避免间隔过长导致失效。
• 按后端调整策略：对缓存友好的后端多放长上下文，对不支持的保持精简。

小结

缓存是后端特性，不是 API 聚合层的统一保证。用同一把 key 跑同一份可缓存前缀，横向对比各后端的命中情况，才能做出准确的成本判断。先实测，再优化，比默认“都会缓存”更可靠。