在典型的 AI 工作流程中,您可能会反复将相同的输入令牌传递给模型。Gemini API 提供两种不同的缓存机制:
- 隐式缓存(在 Gemini 2.5 模型上自动启用,但不保证节省费用)
- 显式缓存(可在大多数型号上手动启用,保证节省费用)
如果您想保证节省费用,但需要进行一些额外的开发者工作,那么显式缓存就很有用。
隐式缓存
默认情况下,所有 Gemini 2.5 模型都会启用隐式缓存。如果您的请求命中缓存,我们会自动将节省的费用返还给您。您无需执行任何操作即可启用此功能。自 2025 年 5 月 8 日起生效。对于 2.5 Flash,上下文缓存的最小输入 token 数为 1,024;对于 2.5 Pro,上下文缓存的最小输入 token 数为 4,096。
为了提高隐式缓存命中的几率:
- 尝试将大型内容和常见内容放在提示的开头
- 尝试在短时间内发送具有相似前缀的请求
您可以在响应对象的 usage_metadata
字段中查看缓存命中的 token 数量。
显式缓存
借助 Gemini API 的显式缓存功能,您可以将某些内容传递给模型一次,缓存输入 token,然后在后续请求中引用缓存的 token。在特定量级下,使用缓存的令牌比重复传入相同的语料库令牌成本更低。
缓存一组令牌时,您可以选择在令牌被自动删除之前,缓存的保留时长。此缓存时长称为存留时间 (TTL)。如果未设置,TTL 默认为 1 小时。缓存费用取决于输入令牌大小以及您希望令牌保留的时间。
本部分假定您已安装 Gemini SDK(或已安装 curl),并且已配置 API 密钥,如快速入门中所述。
使用 OpenAI 库进行显式缓存
如果您使用的是 OpenAI 库,则可以使用 extra_body
中的 cached_content
属性启用显式缓存。
何时使用显式缓存
上下文缓存特别适合较短的请求重复引用大量初始上下文的场景。例如,对于以下使用场景,可以考虑使用上下文缓存:
- 有大量系统指令的聊天机器人
- 对较长的视频文件进行的重复分析
- 针对大型文档集的定期查询
- 频繁的代码库分析或 bug 修复
显式缓存如何降低成本
虽然上下文缓存是一项付费功能,但它的目的是为了降低整体的运营成本。结算取决于以下因素:
- 缓存词元数:缓存的输入词元数,如果相同的词元在后续提示中被重复使用,则按折扣费率计费。
- 存储时长:所缓存词元的存储时长 (TTL),按缓存词元数的 TTL 时长计费。TTL 没有最小值或最大值限制。
- 其他因素:可能还会产生其他费用,例如非缓存输入词元和输出词元的费用。
如需了解最新价格详情,请参阅 Gemini API 价格页面。如需了解如何计算 token,请参阅 token 指南。
其他注意事项
使用上下文缓存时,请注意以下事项:
- 对于 2.5 Flash,上下文缓存的最低输入 token 数为 1,024;对于 2.5 Pro,上下文缓存的最低输入 token 数为 2,048。最大值与相应型号的最大值相同。(如需详细了解如何统计 token 数量,请参阅 token 指南)。
- 该模型不会区分缓存的令牌和常规输入令牌。缓存的内容是提示的前缀。
- 上下文缓存没有特殊费率或使用限制;
GenerateContent
的标准费率限制适用,令牌限制包括缓存的令牌。 - 缓存的 create、get 和 list 操作的
usage_metadata
中会返回缓存的令牌数量,使用缓存时GenerateContent
中也会返回该数量。