为什么你的 Gemini API 中转费总是没省下钱？聊聊缓存机制那些坑

最近在折腾 AI 工具的时候，发现一个很肉痛的事情：明明开了支持缓存的中转站，用了号称有 KV Cache 机制的 Gemini 模型（比如 Gemini 1.5 Pro），但每次看账单，怎么感觉跟没缓存一样？

特别是用 LobeHub 这类客户端的时候，经常出现两种让人崩溃的情况：要么是“缓存命中了”，但计费倍率写着 1，根本不打折；要么是倍率虽然有优惠（比如 0.1），但翻烂了调用记录，发现命中的次数寥寥无几。

这到底是 Gemini 本身太难伺候，还是中转站的问题，或者是我们的打开方式不对？今天就来深扒一下这里面的技术逻辑。

KV Cache 机制主要缓存输入部分的处理结果，一旦 System Prompt 发生微调，缓存即失效。

1. 缓存不是万能的：System Prompt 的隐形陷阱

很多人觉得缓存很简单，就是我把上一次的问题再问一遍，系统就不要钱了。 错！

API 的 KV Cache（Key-Value Cache）机制，主要缓存的是“输入部分”的处理结果。对于长上下文模型来说，最值钱的其实是 System Prompt（系统提示词）或者长文档的上下文预处理。

如果你在 LobeHub 等客户端里，给每个对话都预设了一个非常复杂、非常长的“人设”或“知识库”，这确实给模型增加了负担。但是，如果你在这个人设的基础上，哪怕只是改了一个标点符号，或者追加了一个新的、极简的问题，整个缓存的哈希值可能就变了。

很多中转站为了稳定性，对缓存 Key 的匹配是非常严格的。一旦你的 Prompt 发生变化，缓存就会失效，只能重新计算。这就是为什么你觉得“明明问的差不多”，结果却没省钱的原因。

2. 中转站的实现差异：伪缓存与真缓存

市面上做 Gemini 中转的服务商非常多，但他们实现的策略天差地别。

有些中转站（或者比较早期的版本），虽然写着支持缓存，但实际上可能只是简单地复用模型生成的结果（Response Caching），而不是更底层的 KV Cache。这种情况下，服务商可能会为了覆盖成本，设置很苛刻的命中条件，或者直接把倍率设为 *1，意味着“我虽然技术上帮你省了算力，但我不想给你打折”。

还有一种情况是服务商的缓存节点配置问题。Gemini 的原生 API 对缓存有特定的参数要求，如果中转层没有正确透传这些参数（比如 cached_content 的处理），那么上游 Google 就无法识别到这是可以复用的请求，自然就按全价收费了。

3. LobeHub 等客户端的副作用

回到开头提到的 LobeHub，这类优秀的开源客户端确实好用，但它们在请求封装上可能会做一些“优化”。

显式的 Prompt Prefix Caching 可以将固定的指令部分优先缓存，从而提高命中率。

比如，为了提升对话体验，客户端可能会自动补全一些参数、在请求头里加入额外的元数据，或者在每次请求时自动带上之前的对话历史作为上下文（滑动窗口）。虽然这为了体验是好事，但对于极度敏感的缓存机制来说，这简直是灾难。

如果中转站没有针对这些客户端的特定特征做适配，那么即使是完全相同的提问，客户端发出的两次 API 请求在底层看来也是完全不同的两个请求，缓存自然无法命中。

4. 怎么解决？如何薅到这波羊毛？

既然问题找到了，咱们也得想办法解决。如果你想最大化利用中转站的缓存优惠，可以试试以下几个方向：

• 保持 System Prompt 绝对静态：尽量把复杂的指令固化，不要在对话过程中频繁修改“人设”。如果你需要改变人设，最好开启一个新的对话窗口。
• 寻找支持“提示词前缀缓存”的中转站：目前比较先进的中转站已经开始支持显式的 Prompt Prefix Caching。你可以在调用时明确指定哪一部分是“前缀”，这部分会被优先缓存。询问你的服务商是否支持此类参数。
• 检查计费倍率规则：在使用之前，务必看清服务商的计费说明。如果缓存命中后的倍率是 *1，那就说明该服务商的缓存对你没有经济价值，赶紧换一家。
• 简化上下文：对于不需要长文档分析的场景，尽量减少挂在上文窗口里的 token 数量。请求内容越短、越标准化，命中的概率就越大。

总结

Gemini 模型虽然强，但它的缓存机制确实比较“高冷”。遇到缓存不生效，不必急着骂 LobeHub 或者全怪罪模型，更多时候是我们在使用习惯和路由层面对“精确匹配”的要求理解不够。调整好提问策略，选对支持深度优化的中转站，这波技术羊毛还是能薅下来的。