Gemini 上下文缓存降低输入成本 90%：重新认识文档类 AI 应用的经济学
问题很直接：重复文档处理正在吞噬你的 API 成本
每次向 Gemini API 发送同一份 100 页文档来回答不同问题时，你都要为这 100 页支付完整的 token 价格。如果是 10 个问题，20 个问题，或者数百个用户每天都在查询同一套政策手册、代码库或知识库，那成本曲线会变得非常陡峭。
这就是Gemini 的上下文缓存要解决的问题。这个功能让你将大型文档缓存一次，然后在后续请求中引用它，而不是每次都重新发送。成本削减的幅度很大： Gemini 2.5 模型上，缓存的 token 读取成本比标准输入 token 少 90%；Gemini 2.0 模型上的折扣是 75% 。
但这里有个关键点——数字很漂亮，但实际的财务效益取决于你如何使用它。
缓存的两种方式：隐式 vs 显式
隐式缓存默认为所有 Gemini 2.5 及更新的模型启用，Google 会自动为缓存命中的请求转移成本节省，你不需要做任何事来启用它 。
这种方式对某些工作流很有效，但有个限制： 隐式缓存通过检测跨请求的通用前缀来工作，如果你在 prompt 的开头放置可变内容，你会完全错过缓存命中 。对于任何使用动态系统 prompt 或不稳定内容顺序的应用来说，这是个陷阱。
显式缓存给了你更多控制权。 显式缓存提供了更多控制，并确保对引用现有上下文缓存的输入 token 有折扣。在 Gemini 2.5 或更新的模型上，这个折扣是 90%；在 Gemini 2.0 模型上，折扣是 75% 。
但显式缓存涉及存储成本。 缓存存储对 Pro 模型收费 4.50 元/百万 token/小时，对 Flash 模型收费 1.00 元/百万 token/小时 。这意味着 显式缓存涉及存储费用，在某些场景下可能超过你的节省 。
经济学：什么时候缓存真正有意义
关键的经济权衡是查询频率 vs 存储成本。如果你缓存一份 50K token 的文档，存储成本每小时约为 0.05 元（Flash 模型）或 0.225 元（Pro 模型）。你需要在该小时内进行足够多的查询，使得 90% 的 token 价格削减超过这个存储费用。
一个实际例子： 对同一份文档的 20 个问题，不缓存需要 2 百万输入 token，成本为 2.50 元；有缓存则只需约 0.04 元，实现 98% 的成本削减 。但这需要这 20 个问题在一小时内发生，且使用相同的文档。
何时使用显式缓存：可预测的高容量生产应用、大型上下文（32K+ token）、需要保证成本节省的场景、需要 TTL 控制的场景。何时完全跳过缓存：一次性文档分析、快速变化的内容、非常低的查询量、少于 1K token 的上下文 。
中文市场的实际成本
对于中国、台湾、香港和新加坡的开发者来说，这个计算需要转换为当地货币：
| 场景 | 标准输入成本（美元） | 缓存读取成本（美元） | 存储成本/小时（美元） | 何时划算 |
|---|---|---|---|---|
| Gemini 2.5 Pro，50K token 文档 | 0.0625 | 0.00625 | 0.225 | 36+ 次查询/小时 |
| Gemini 2.5 Flash，50K token 文档 | 0.00375 | 0.000375 | 0.05 | 133+ 次查询/小时 |
| Gemini Flash-Lite，50K token 文档 | 0.005 | 0.0005 | 0.05 | 100+ 次查询/小时 |
在人民币中（按 1 美元 ≈ 7.2 人民币 计）：Pro 模型的存储成本约为 1.62 元/小时，你需要在该小时内至少 36 次查询才能收回成本。
对应用架构的实际影响
缓存改变了哪些应用在经济上是可行的：
- 文档问答系统：如果你每天从相同的大型手册或知识库回答数百个问题，显式缓存可能会将每月成本削减 50-70%。
- 代码审查工具： 客户支持带长产品手册的工具就是一个很好的用例 。缓存同一份代码库或 API 文档，在多个代码审查请求中重复使用它。
- 多模态内容处理： 上下文缓存支持包括图像和视频在内的多模态内容，使用文件 API 上传文件，然后在缓存创建中引用它们。视频缓存特别有价值——一个 5 分钟的视频可能包含数百万 token，使得 90% 的折扣对重复查询视频内容的应用特别有影响 。
- 低频工作流：如果你只是偶尔查询一份文档（每周 1-2 次），不要缓存。存储成本不值得。
实现时的陷阱
三个常见的错误会破坏预期的节省：
第一， 缓存有最小 token 阈值——Gemini 2.5 Flash 需要最少 1024 token，Gemini 2.5 Pro 需要最少 4096 token 。如果你尝试缓存一个 500 token 的 prompt，缓存根本不会激活。
第二， 开发者期望堆积折扣——一些开发者设计系统期望结合的 95% 折扣（50% × 90%），但这不是定价的工作方式。缓存折扣首先应用于有缓存命中的地方；批处理折扣应用于剩余的非缓存 token 。
第三，对隐式缓存， 你应该在请求开头保持内容相同，并在 prompt 末尾添加诸如用户的问题或可能从请求到请求变化的其他附加上下文 。反过来做，你会破坏命中率。
与竞争对手的对比
Gemini 提供了最灵活的选择——隐式和显式两种方式都可用。你可以零代码更改地自动获得机会性缓存，或者使用保证折扣的完全手动控制。Gemini 2.5 模型上的 90% 折扣与 Anthropic 并列为最高节省率 。这使 Gemini 在成本优化上相对有利，特别是对于文档处理工作流。
对你的团队意味着什么
如果你正在评估文档处理成本或构建知识库应用，这里是计算方式：
- 估计你每小时会重复查询同一文档多少次。
- 将该数字乘以单个 token 的缓存节省（通常是 90%）。
- 与每小时的存储费用进行比较（Gemini 2.5 Flash 约 0.05 元/小时/百万 token，或 Pro 的 0.225 元）。
- 如果节省超过存储成本，实施显式缓存。否则，跳过它。
对于任何拥有可预测、重复的文档工作流的中文地区的组织来说，Gemini 的缓存 API 是最直接的成本优化手段——不需要改变模型、不需要改变架构，只需要在 token 重复的地方应用 90% 的折扣。数学是清晰的。问题是：你的工作流是否符合条件？