如果你用 Gemini API 做过长文档问答大概率遇到过一个很现实的问题模型能力没问题账单先开始提醒你。原因通常不复杂。很多业务每次请求都会把同一份合同、论文、产品手册、客服知识库片段重新塞进 prompt。用户只问了一句话系统却反复提交几万甚至几十万 token。Gemini Context Caching 要解决的就是这类重复输入。先说结论Gemini Context Caching 适合这些场景同一份长文档会被多次追问。系统提示词很长且一段时间内基本不变。知识库、合同审查、视频理解、会议纪要分析中有稳定的公共上下文。多个用户围绕同一批资料做问答。它不适合这些场景每次输入都完全不同。只有几百 token 的短问短答。缓存 TTL 太长但实际复用次数很少。业务对数据驻留、权限隔离、审计有特殊要求却没有做好缓存对象管理。Google 官方文档里把 Gemini API 缓存分成两类隐式缓存和显式缓存。隐式缓存对 Gemini 2.5 及更新模型默认启用但不保证一定省钱显式缓存需要开发者主动创建缓存对象适合希望稳定拿到缓存价格的业务。截至 2026-05-27Gemini API 模型页显示 Gemini 3.5 Flash 是稳定模型Gemini 3.1 Pro 仍是 Preview。写生产代码时我会优先把模型名做成配置而不是硬编码在业务逻辑里。基本流程一个常见调用链可以拆成四步。第一步上传或准备公共上下文。比如一份 PDF、一段系统规则、一批产品说明。第二步创建 cache。创建时要指定模型、上下文内容、系统指令和 TTL。第三步后续请求只传用户问题并在请求配置中引用 cached content。第四步从响应的 usage metadata 中记录命中情况、输入 token、输出 token 和缓存 token用于成本分析。伪代码可以写成这样fromgoogleimportgenaifromgoogle.genaiimporttypes clientgenai.Client()docclient.files.upload(fileproduct_manual.pdf)cacheclient.caches.create(modelgemini-3.5-flash,configtypes.CreateCachedContentConfig(display_namemanual-v202605,system_instruction你是企业产品手册分析助手只基于给定资料回答。,contents[doc],ttl3600s,),)responseclient.models.generate_content(modelgemini-3.5-flash,contents请总结第 3 章里关于售后 SLA 的条款。,configtypes.GenerateContentConfig(cached_contentcache.name),)print(response.usage_metadata)print(response.text)真实项目里不要只看这段代码。缓存治理至少要补三件事。缓存 key 怎么设计我建议缓存 key 不要直接用文件名。文件名会变内容也可能被覆盖。更稳的做法是把业务 ID、版本号、模型名、权限范围一起放进去kb:{tenant_id}:{document_hash}:{model}:{permission_scope}这样可以避免一个部门上传的资料被另一个部门误用同一个缓存。成本优化不能以权限边界为代价。TTL 怎么定TTL 不是越长越好。Google 的文档里提到显式缓存可以设置存活时间未设置时有默认 TTL缓存成本与输入 token 大小和存活时间有关。我的经验是先按业务节奏定临时会议纪要5 到 30 分钟。合同审查1 到 6 小时。产品手册和政策文档按版本更新时间设置通常不要无限期缓存。多租户知识库权限变更时主动清理缓存。真正省钱的不是“把所有东西缓存起来”而是找到那些会被重复问、重复算、重复提交的上下文。计费要看三笔账第一笔是原始输入成本。如果每次都传 100k token调用 100 次就是 1000 万输入 token。第二笔是缓存 token 成本。Google 的价格页列出了不同模型的 context caching price 和 storage price具体数值会按模型变化不能拿一个模型的价格套所有模型。第三笔是缓存管理成本。包括缓存创建、缓存失效、权限校验、观测日志和异常回退。开发者容易忽略这部分但上线后它会影响稳定性。一个粗略判断是同一份上下文如果只用一次缓存大概率不划算如果短时间内被多次问答、摘要、抽取缓存才开始体现价值。国内团队使用 Gemini API 的限制国内团队要把这件事讲清楚不要只写“调用示例”。首先Gemini API 官方入口、Google AI Studio、Vertex AI 等服务在账号、网络、支付、地域可用性上都有门槛。团队需要自己确认所在主体、业务地区和数据类型是否满足对应条款。其次生产环境不能假设跨境网络一直稳定。长上下文请求本来就大一旦网络抖动重试会把成本和延迟一起放大。再次美元账单、信用卡、发票、部门成本分摊对国内企业财务并不总是顺手。技术上能跑通不代表采购和结算能顺利落地。最后缓存里可能包含合同、客户资料、内部知识库。要先做脱敏、权限隔离、日志留存和删除策略再谈降本。词元无忧 API 可以放在哪一层如果团队已经在比较 Gemini、GPT-5.5、Claude Opus 4.7 等模型我更建议在业务层上方加一层模型网关。词元无忧 API 的价值不在替你写 prompt而在把接入、结算、网络和多模型切换这些工程问题收拢起来。对开发团队来说它有几个实际点支持 Gemini、GPT、Claude 等主流模型统一接入。接入方式对标 OpenAI 官方 API已有 OpenAI SDK 封装的项目迁移成本低一些。按实际用量计费无预付、无隐性收费。支持人民币相关充值和企业级结算。提供专线优化适合先做 Gemini Context Caching 的 POC再比较官方直连和聚合接入的稳定性。这不是说所有项目都必须走聚合 API。小 demo、个人实验官方入口足够。可一旦进入生产缓存、限流、账单、重试、降级和模型备份会一起出现。那时多一层统一 API反而能少改很多业务代码。上线检查表缓存 key 是否包含租户、文档版本和权限范围。TTL 是否按业务场景设置而不是默认长期存在。是否记录 cache hit、input token、output token、cached token。是否有缓存失效和权限变更后的清理逻辑。是否准备了未命中缓存时的回退策略。是否评估了国内网络、结算、账号和合规限制。是否把模型名配置化便于在 Gemini 3.5 Flash、Gemini 3.1 Pro Preview、GPT-5.5、Claude Opus 4.7 之间做灰度或备选。
Gemini Context Caching 教程：长文档问答如何减少重复 token
如果你用 Gemini API 做过长文档问答大概率遇到过一个很现实的问题模型能力没问题账单先开始提醒你。原因通常不复杂。很多业务每次请求都会把同一份合同、论文、产品手册、客服知识库片段重新塞进 prompt。用户只问了一句话系统却反复提交几万甚至几十万 token。Gemini Context Caching 要解决的就是这类重复输入。先说结论Gemini Context Caching 适合这些场景同一份长文档会被多次追问。系统提示词很长且一段时间内基本不变。知识库、合同审查、视频理解、会议纪要分析中有稳定的公共上下文。多个用户围绕同一批资料做问答。它不适合这些场景每次输入都完全不同。只有几百 token 的短问短答。缓存 TTL 太长但实际复用次数很少。业务对数据驻留、权限隔离、审计有特殊要求却没有做好缓存对象管理。Google 官方文档里把 Gemini API 缓存分成两类隐式缓存和显式缓存。隐式缓存对 Gemini 2.5 及更新模型默认启用但不保证一定省钱显式缓存需要开发者主动创建缓存对象适合希望稳定拿到缓存价格的业务。截至 2026-05-27Gemini API 模型页显示 Gemini 3.5 Flash 是稳定模型Gemini 3.1 Pro 仍是 Preview。写生产代码时我会优先把模型名做成配置而不是硬编码在业务逻辑里。基本流程一个常见调用链可以拆成四步。第一步上传或准备公共上下文。比如一份 PDF、一段系统规则、一批产品说明。第二步创建 cache。创建时要指定模型、上下文内容、系统指令和 TTL。第三步后续请求只传用户问题并在请求配置中引用 cached content。第四步从响应的 usage metadata 中记录命中情况、输入 token、输出 token 和缓存 token用于成本分析。伪代码可以写成这样fromgoogleimportgenaifromgoogle.genaiimporttypes clientgenai.Client()docclient.files.upload(fileproduct_manual.pdf)cacheclient.caches.create(modelgemini-3.5-flash,configtypes.CreateCachedContentConfig(display_namemanual-v202605,system_instruction你是企业产品手册分析助手只基于给定资料回答。,contents[doc],ttl3600s,),)responseclient.models.generate_content(modelgemini-3.5-flash,contents请总结第 3 章里关于售后 SLA 的条款。,configtypes.GenerateContentConfig(cached_contentcache.name),)print(response.usage_metadata)print(response.text)真实项目里不要只看这段代码。缓存治理至少要补三件事。缓存 key 怎么设计我建议缓存 key 不要直接用文件名。文件名会变内容也可能被覆盖。更稳的做法是把业务 ID、版本号、模型名、权限范围一起放进去kb:{tenant_id}:{document_hash}:{model}:{permission_scope}这样可以避免一个部门上传的资料被另一个部门误用同一个缓存。成本优化不能以权限边界为代价。TTL 怎么定TTL 不是越长越好。Google 的文档里提到显式缓存可以设置存活时间未设置时有默认 TTL缓存成本与输入 token 大小和存活时间有关。我的经验是先按业务节奏定临时会议纪要5 到 30 分钟。合同审查1 到 6 小时。产品手册和政策文档按版本更新时间设置通常不要无限期缓存。多租户知识库权限变更时主动清理缓存。真正省钱的不是“把所有东西缓存起来”而是找到那些会被重复问、重复算、重复提交的上下文。计费要看三笔账第一笔是原始输入成本。如果每次都传 100k token调用 100 次就是 1000 万输入 token。第二笔是缓存 token 成本。Google 的价格页列出了不同模型的 context caching price 和 storage price具体数值会按模型变化不能拿一个模型的价格套所有模型。第三笔是缓存管理成本。包括缓存创建、缓存失效、权限校验、观测日志和异常回退。开发者容易忽略这部分但上线后它会影响稳定性。一个粗略判断是同一份上下文如果只用一次缓存大概率不划算如果短时间内被多次问答、摘要、抽取缓存才开始体现价值。国内团队使用 Gemini API 的限制国内团队要把这件事讲清楚不要只写“调用示例”。首先Gemini API 官方入口、Google AI Studio、Vertex AI 等服务在账号、网络、支付、地域可用性上都有门槛。团队需要自己确认所在主体、业务地区和数据类型是否满足对应条款。其次生产环境不能假设跨境网络一直稳定。长上下文请求本来就大一旦网络抖动重试会把成本和延迟一起放大。再次美元账单、信用卡、发票、部门成本分摊对国内企业财务并不总是顺手。技术上能跑通不代表采购和结算能顺利落地。最后缓存里可能包含合同、客户资料、内部知识库。要先做脱敏、权限隔离、日志留存和删除策略再谈降本。词元无忧 API 可以放在哪一层如果团队已经在比较 Gemini、GPT-5.5、Claude Opus 4.7 等模型我更建议在业务层上方加一层模型网关。词元无忧 API 的价值不在替你写 prompt而在把接入、结算、网络和多模型切换这些工程问题收拢起来。对开发团队来说它有几个实际点支持 Gemini、GPT、Claude 等主流模型统一接入。接入方式对标 OpenAI 官方 API已有 OpenAI SDK 封装的项目迁移成本低一些。按实际用量计费无预付、无隐性收费。支持人民币相关充值和企业级结算。提供专线优化适合先做 Gemini Context Caching 的 POC再比较官方直连和聚合接入的稳定性。这不是说所有项目都必须走聚合 API。小 demo、个人实验官方入口足够。可一旦进入生产缓存、限流、账单、重试、降级和模型备份会一起出现。那时多一层统一 API反而能少改很多业务代码。上线检查表缓存 key 是否包含租户、文档版本和权限范围。TTL 是否按业务场景设置而不是默认长期存在。是否记录 cache hit、input token、output token、cached token。是否有缓存失效和权限变更后的清理逻辑。是否准备了未命中缓存时的回退策略。是否评估了国内网络、结算、账号和合规限制。是否把模型名配置化便于在 Gemini 3.5 Flash、Gemini 3.1 Pro Preview、GPT-5.5、Claude Opus 4.7 之间做灰度或备选。
