同样规模的调用量，有人每月只花几百块，有人却要掏几千，差距往往不在用了多少，而在四个配置开关开没开。上周朋友拿月底账单来找我，翻他的调用记录，症结一眼可见：一堆不赶时间的文档摘要、数据打标，全按同步请求的全价计费，缓存更是压根没启用。官方 Cookbook 里其实明摆着四本专讲省钱的教程，先读完再动手，账单能差出好几倍。这篇把四招逐一拆开讲。

折扣最狠的一招：批量模式

Batch API 是四招里力度最大的。官方宣传口径为批量请求最高享 90% 折扣。quickstarts 里的 Batch_mode 教程则标注 50% 起步，具体档位随任务浮动，但方向始终一致，结果不急着要的活，全该走批量。每晚定时跑的文档摘要，数据集打标，成批翻译，晚几个小时拿到结果毫无影响，丢进 Batch 模式，成本从砍半起步。

重复任务的生死线：上下文缓存

另一处烧钱的地方，是同一段长上下文被翻来覆去地传。想象给模型喂了一份 50 页的产品手册，之后每轮对话都原样重传一遍，token 费用便按次重复计。Caching 教程教的这一招一旦开启，长文本只付一次缓存费，后续命中缓存的调用，成本与延迟双双走低。做知识库问答、客服机器人的，这一项直接决定成本生死线，不开就等着账单膨胀。

Priority 还是 Flex：推理分层

Inference Tiers 教程把推理划成 Priority 与 Flex 两档：前者保速度，留给线上对响应时间敏感的请求。后者用更低价格换更高的吞吐弹性，适合后台任务。两档可以并用，用户在线等着的走 Priority，离线分析交给 Flex，再叠一层批量模式，省上加省。

告别傻等：Webhook 回调

批量任务和视频生成都吃时间，多数人的本能反应是写个循环，每隔几秒查一次状态。Webhooks 教程给出更聪明的做法：配好回调地址，任务一跑完 Google 主动来通知。省下的不只是代码，还有一连串毫无意义的轮询请求。

四本教程在 Cookbook 的 quickstarts 目录里各配一个 notebook，地址可在 Gemini 官方仓库查阅，每本都能在 Colab 直接运行。下手顺序我建议：批量模式先行（改动最小、见效最快），缓存其次（需要先规划上下文结构），推理分层最后按业务拆。别小看这几个配置，调用量一上去，就是”每月几百块”与”每月几千块”的分野。