Gemini 隐式缓存怎么才能命中：官方给的两个办法
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
隐式缓存是 Gemini 里少数「不用你做任何事」的省钱机制：官方文档写明它对 Gemini 2.5 及更新型号默认启用，无需任何操作，命中之后会自动返还节省下来的费用。但「默认启用」不等于「一定命中」。官方在缓存文档里只给了两个提高命中率的办法——把较大且常见的内容放在提示开头，以及在短时间内发送具有相似前缀的请求；另外还有一道硬门槛：隐式缓存有最低输入 token 要求，而且这个门槛因模型而异。也就是说，你的提示词怎么排、请求什么节奏发、用哪个型号，共同决定了这笔钱省不省得下来。而你唯一能拿来判断结果的，是响应对象里的 usage.total_cached_tokens 字段——不看它，你连自己有没有命中都不知道。
先分清两种缓存，别把办法用错地方
Gemini 官方文档里的缓存分两种：隐式缓存（implicit）和显式缓存（explicit）。
隐式缓存是自动的。官方的表述是对 Gemini 2.5 及更新型号默认启用，无需任何操作，命中后自动返还节省的费用。官方还写明它同时支持有状态与无状态两种对话模式，有状态那一侧对应的字段是 previous_interaction_id。也就是说不管你是靠这个 id 串上下文，还是每次自己组装完整请求，隐式缓存这条路都是通的，不需要为某种对话模式做额外适配。
显式缓存是你主动创建、主动引用的缓存对象，控制权在你手上。这里有一个很容易踩的接口选型坑：Interactions API 只支持隐式缓存，不支持显式缓存；要用显式缓存，必须改用 generateContent API。这不是配置开关的问题，是接口本身的能力差异，所以选接口的时候就得把缓存策略一起想清楚，等业务跑起来再回头换 API，改动量完全不是一个量级。
本文讲的是隐式缓存这一侧——它的好处是零成本接入，代价是你对它只有间接的影响力，只能通过组织请求的方式去「争取」命中，而不能命令它命中。
办法一：把较大且常见的内容放在提示开头
这是官方在缓存文档里给出的第一条提高命中率的方法：把较大且常见的内容放在提示的开头。
拆开看，这句话里有三个限定词，每个都有用。
「较大」——官方没有给出「多大算大」的定义，但方向是清楚的：该往前排的是那些体量占大头的部分，比如系统提示、角色设定、工具说明、产品手册、代码库摘要、长文档正文。把几十个字的零碎片段调到最前面，对整体前缀的影响有限。
「常见」——指在你的请求里高频重复出现的那部分。一段只在某个特定用户的某次会话里出现的内容，排到最前面也没有意义，因为没有第二次请求会带着同样的开头来。
「开头」——这是最有工程含义的一条。它意味着提示的物理顺序直接影响成本，而不只是影响效果。很多人写提示是按「先说清楚要干什么，再把资料贴上」的顺序，把用户问题放在最前面，把长文档放在后面。从命中率角度看，这个顺序正好是反的。
有意思的是，官方在长上下文文档的常见问题里给出了完全同向的另一条建议：把查询或问题放在提示的末尾，也就是放在所有其他上下文之后，官方特别注明当总上下文很长时这样效果更好。两条建议出自不同的文档页——一条在缓存文档里，一条在长上下文的常见问题里——但指向的是同一种提示结构：固定的、体量大的内容在前，随每次请求变化的问题在后。这条排版规则可以直接写进你的提示模板，属于两头都不吃亏的改动。
按官方这条口径反推，最该避开的写法是把时间戳、随机 ID、用户名这类每次都不同的小字段放在提示最前面：它们本身不占多少体量，却让每个请求的开头都各不相同，而官方的第二条办法要求的恰恰是「相似前缀」。这类字段挪到提示后半段，是改动最小、最不影响业务逻辑的一步。
办法二：在短时间内发送具有相似前缀的请求
这是官方给的第二个办法，原话的关键词是「短时间内」和「相似前缀」。
「相似前缀」呼应的就是办法一：只有把公共部分排到前面，多个请求之间才谈得上有共同前缀。两个办法其实是一件事的两面，一个管空间布局，一个管时间分布。
「短时间内」这一条对任务编排的影响更大。它意味着同一批共享上下文的请求，最好凑在一起发，而不是均匀地摊在一整天里。举几个实际的差别：
- 同一份长文档要问二十个问题，一次性把二十个请求发出去，和每隔一小时发一个，命中情况可能完全不同
- 定时任务如果按「每个客户一天一次」的方式调度，每次请求之间隔得很远，共享前缀基本没机会派上用场
- 把跨客户的任务按「共享哪份上下文」重新分组，而不是按客户 ID 分组，是一个纯编排层的改动，不用动模型调用代码
至于「短时间」到底是多短、缓存条目能保留多久，官方缓存文档里没有找到相关说明。所以这里不要自己脑补一个保留时长写进设计文档，更不要基于某个想象出来的数字去卡任务间隔。能确定的只有方向：越集中越好。
还有一道你绕不过去的门槛：最低输入 token 数
前面两个办法都是「提高命中率」，但在此之上还有一个前置条件：官方写明隐式缓存有最低输入 token 门槛，并且这个门槛因模型而异。具体数值请以官方文档为准，本文按站点规则不列数字——它属于随型号更新而变的参数，写下来很快就会过期。
这条约束的实际后果有两个。
第一，短提示的场景不用在缓存上花心思。如果你的请求本来就短，不管前缀排得多整齐、请求发得多密集，都够不到门槛，优化方向应该换成别的（比如少传不必要的 token，官方在长上下文常见问题里也是这么建议的：不需要传给模型的 token 就别传）。
第二，换模型必须重新确认门槛。因为门槛因模型而异，你在一个型号上调好的提示结构，换到另一个型号上可能就掉到门槛以下了。Gemini 的型号迭代很快，团队里换型号往往只是改一个字符串，很容易忽略这条隐藏成本变化。稳妥的做法是：把型号切换当成一次需要复核成本的变更，切完之后回头看命中数据。
怎么确认到底命中了没有
这是整件事里最实在的一步，也是最多团队漏掉的一步：你必须能看到命中量，否则前面所有优化都是猜的。
官方给出的查询方式是读响应对象的 usage.total_cached_tokens 字段，Python 和 JavaScript 两侧都是这个字段。
建议的做法是把它当成一个常规指标接进日志：每次调用记录下这次请求的缓存 token 数，聚合出「缓存 token 占总输入 token 的比例」这样一个可观察的曲线。有了曲线之后，很多判断才立得住：
- 改了提示模板的顺序，命中比例有没有变化
- 换了型号之后，命中比例是不是塌了（很可能就是撞上了那道因模型而异的门槛）
- 某个业务场景常年零命中，那它本来就不适合靠隐式缓存省钱，别再在它身上调了
关于成本侧的通用做法，可以配合看站内的 API 成本监控怎么做 和 缓存计费机制，那两篇讲的是跨厂商的通用形态，本文讲的是 Gemini 这一家的具体规则。
命中之后省的是哪一笔钱
Gemini 官方常见问题里列出的计费依据有四项：输入 token 数、输出 token 数、缓存的 token 数，以及缓存 token 的存储时长。
前三项好理解，第四项是这家和不少平台不一样的地方——存储本身也是一个计费维度。官方在长上下文文档里说得更直白：把用户上传的文件缓存起来，按小时为存储付费，换取重复提问时输入成本的下降。所以做缓存决策的时候，账要两边一起算：省下来的重复输入费用，对上为此付出的存储费用。
至于隐式缓存这一侧的存储是否也单独计费，我们能核到的官方材料里没有明确说明，这里不做推断。隐式缓存这边官方明确写了的是另一句：命中后自动返还节省的费用。也就是说你不需要为「用上缓存」做任何申领动作。
另外提醒一个和缓存无关但经常一起被算错的点：官方定价页的表头写明输出价格是包含思考 token 的。也就是说模型的思考部分按输出侧计费，不在输入侧，缓存优化再好也管不到这一段。所有单价请查官方定价页，本文不列。
什么时候该放弃隐式缓存
隐式缓存的定位是「白捡的」：它默认开着，你顺手把提示结构理顺、把请求编排集中，能省一笔是一笔。但它不受你控制，也不保证命中。
官方在长上下文常见问题里给的三条实操结论里，有一条正好指向了边界：当你有一组要重复使用的相似上下文时，用上下文缓存来降本。这种「明确知道哪份上下文会被反复用」的场景，就该考虑显式的上下文缓存，把控制权拿回来——但要记得前面那条接口约束，显式缓存必须走 generateContent API，Interactions API 上没有这条路。
官方还点出了一个很少被提及的权衡：在长上下文检索里，「大海捞针」式的单目标检索是最基本的设置；要找多根针或特定信息时，准确率会变化，性能可能因上下文而变化很大。官方明确承认检索准确率与费用之间存在固有权衡——想在单次查询里拿到很高的准确率，代价是每次都付全量输入 token 的费用；想检索大量条目还要保持准确率，可能得发很多次请求。上下文缓存在后一种工作负载里就是降本的关键。
最后：三个最容易栽的坑
第一，把「默认启用」当成「一定命中」。默认启用只说明你不用开开关，命不命中取决于门槛、前缀和时间分布三件事。上线前把 usage.total_cached_tokens 接进监控，比事后看账单猜原因划算得多。
第二，选错接口。Interactions API 只支持隐式缓存这条限制，是在选接口那一刻就决定了后续缓存策略上限的，等业务铺开再迁移代价很大。
第三，换型号不复核。门槛因模型而异这一条，意味着型号是缓存策略的一部分，不是一个可以随手替换的字符串。
同轴还有一篇讲 Gemini 两种 429 的区别，排查限流时容易和成本问题混在一起看，可以顺手读一下：Gemini 的两种 429。以上机制均以官方文档当前版本为准，具体数值请查官方文档与定价页。