Gemini API 中转站缓存为什么总是失效？省钱秘籍都在这

最近在折腾 Gemini 2.5 Pro（或者叫 3.1 Pro，版本号乱得很），主要通过各类中转站来调用。用了一段时间大家可能会发现一个很搞心态的问题：明明官方宣传了有 Prompt Caching（提示词缓存）能打折计费，为什么账单上看要么根本没触发，要么触发了价格却一点没变？

这事儿其实不怪你的运气不好，而是大模型 API 中转机制和缓存策略之间存在着微妙的“代沟”。今天咱们就抛开晦涩的文档，用大白话+技术干货把这事儿掰扯清楚，顺便教你怎么排查到底是不是中转站坑了你。

一、 为什么缓存总是“哑火”？

中转站转发请求的示意，展示客户端、中转站与官方 API 之间的数据交互及可能丢失的请求头信息。

首先得明白，Google 官方 API 的缓存机制是基于“系统提示词”或者长文本上下文的匹配来实现的。它要求你在请求里显式地声明某些内容需要缓存，或者系统检测到重复的高额度上下文。

**1. 请求头被改了 **很多中转站为了做聚合或者统一计费，会在转发请求时重写请求头。如果 Google 识别缓存的特定 Header 字段（比如 cached_content 相关的字段）在中转层被过滤或者没透传过去，那上游的 Google 服务器根本就不知道你要“读缓存”，自然每次都按全价算。

**2. 上下文指纹对不上 **缓存的命中原理其实是对文本做哈希匹配。比如你用了一个超长的系统 Prompt，第一次发送过去，Google 把它存起来。下一次请求时，如果你的 Prompt 哪怕是改动了一个标点符号，或者中转站自动插入了一小段隐形文字（比如为了做审计），这就导致生成的指纹不一致，缓存直接失效。

排查问题时进行抓包分析或检查代码配置的场景。

**3. 模型名称映射问题 **中转站通常会把 gemini-2.5-pro 映射成内部 ID 再转给 Google。如果在映射过程中没有正确保留 Google 官方要求的缓存控制参数，或者中转站自己并没有对接 Google 最新的缓存计费接口，那你在前端看到的“计费倍率 *0.1”只是一个假象，实际上它是后端自己模拟的数据，并未真实体现在上游成本里。

二、 “缓存生效了但不打折”是怎么回事？

有朋友反馈：“我看日志显示缓存命中了，倍率是 *1，跟没算一样。” 这种情况通常有两类原因：

• 中转站的“二次定价”策略： 有些良心中转站会告诉你“我给你打了折”，但实际上上游扣款如果没变，它为了维持利润，可能把原本应该给用户的 0.1 倍率给“吃”掉了，或者直接按照标准 Tokens 量收费，只在自己的系统里标记一下“已缓存”安抚用户。
• 写操作 vs 读操作： 在某些 API 定义里，写入缓存的过程本身也是要收费的。如果你是在进行连续对话，第一轮写入缓存的成本可能并不低，随后的读取才是 0.1 倍率。如果你的任务大部分都是一次性请求（比如每次都有新的大文件上传），那就一直是写入过程，感受不到便宜。

三、 如何排查和解决？

既然知道了坑在哪，咱们就得有对应的手段来验证。不要盲目相信前端显示的那个“折扣率”，我们可以通过以下几种方式来测试：

1. 抓包对比法（最硬核）： 使用抓包工具（如 Charles 或 Fiddler），或者某些带有“调试模式”的客户端，直接发给中转站请求。对比一下你发出的请求里，关于 contents 的具体内容是否和官方 API 文档要求的缓存格式一致。如果你用的是 OpenAI 兼容格式，看看中转站是否把 system 字段正确转义给了 Google 的原生接口。

2. 控制变量测试： 找一个超长的 System Prompt（比如几千字的背景设定）。第一次请求，记录返回的 Token 消耗和费用。紧接着第二次发送完全一样的请求（哪怕 User Message 变了，只要 System Prompt 没变）。

   • 如果两次的总 Token 消耗差距巨大（第二次极低），说明缓存是真生效的。
   • 如果两次差不多，那说明这家中转站没做透传，或者是假缓存。

3. 检查客户端配置： 很多用户使用的是像 LobeHub 这类客户端。有些老版本客户端在处理 Google API 时，可能并没有正确勾选“启用 Prompt Caching”的选项，或者在请求构建时默认把 cached_content 置空了。升级到最新版（v2.2.x 以上）并检查设置里的高级参数是很有必要的。

四、 总结建议

Gemini 的缓存机制对于长文档分析、代码库问答这类场景是神器，能省下 90% 的 Token 费用。但在中转站环境下，它极其依赖透传的完整性。

• 想薅羊毛： 尽量选择支持原生 Google API 通道的中转，或者在购买前先拿小号跑一次上面的“控制变量测试”，别直接充大钱。
• 开发者自用： 如果你有能力，推荐自己写个简单的转发层，保证 Google 那边的请求头和参数原封不动地透传，这样才能把缓存的好处吃满。

别再看着账单发呆了，赶紧去抓包看看你的中转站是不是在“假装”给你打折吧！