为什么需要上下文缓存

许多 AI 应用会反复提交相同的大段内容，例如固定系统提示、产品手册、代码仓库摘要或长视频。每次完整发送不仅增加输入 Token 成本，也会拉长首字响应时间。

Gemini 提供隐式缓存和显式缓存两种方式，二者适合不同的调用模式。

隐式缓存

隐式缓存对 Gemini 2.5 及更新模型默认启用，应用无需创建缓存对象。要提高命中概率，应把体积大且稳定的公共内容放在提示词前部，并尽量保持前缀完全一致。

适合场景：

• 多个请求共享相同系统提示。
• 短时间内重复分析同一份材料。
• 不希望维护缓存生命周期。

调用后应检查 usage 中的缓存 Token 指标，而不是假设缓存一定命中。

显式缓存

显式缓存需要创建缓存对象并设置 TTL，随后请求引用该缓存。它更适合明确知道某份大型上下文会被长期复用的场景，例如客服知识库、合同模板或重复的视频问答。

需要注意，Interactions API 目前只支持隐式缓存；若必须使用显式缓存，应使用 generateContent API。

优化清单

1. 把稳定内容放前面，把每次变化的问题放后面。
2. 避免在公共前缀中插入时间戳、随机 ID 等动态字段。
3. 根据实际命中率计算节省金额，不只看单次请求。
4. TTL 不要盲目设置过长，过期资料可能导致回答依据陈旧。
5. 敏感内容进入显式缓存前，确认保存期限和删除策略。

常见误区

缓存不会自动保证回答质量，也不是向量数据库的替代品。它优化的是重复输入的推理成本；需要从大量资料中选择相关片段时，仍然应使用检索、过滤和权限控制。

原始资料：Gemini Context Caching 官方文档