把 Gemini 3 Pro 的账单砍掉了三分之一：一个每天调用几千次的GD标注系统的省钱实录目录把 Gemini 3 Pro 的账单砍掉了三分之一：一个每天调用几千次的GD标注系统的省钱实录一份"看起来正常"的账单二、原理：Gemini 的"上下文缓存"到底是什么2.1 服务端到底做了什么2.2 计费的秘密2.3 一张图看懂三、代码怎么改：从 30 行到能上线3.1 核心一：LazyCacheManager（懒创建 + 线程安全）3.2 核心二：LLM 调用的极简改动3.3 核心三：把用量精确到 token 记下来3.4 别忘了打扫战场四、实测三个规模，让数据说话4.1 汇总表4.2 一张图看清楚趋势4.3 100 条实测细节五、几个我踩过的坑，一次讲清5.1 Vertex AI 有"隐式缓存"，会污染 A/B 测试5.3 TTL 不是"越长越好"5.4 线程安全的懒创建陷阱5.5 小任务不划算六、这套东西给你带来什么直接照搬关键词：Gemini · Vertex AI · Context Caching · 上下文缓存 · LLM 降本 · 提示词工程一份"看起来正常"的账单前几天做GD智能标注系统的月度复盘，翻到 Vertex AI 的账单，我盯着屏幕愣了几秒——每千条GD，纯 API 花费约¥150。系统跑得挺稳，客户体验也不错，可这数字放在长期视角下并不便宜。我们每天要处理几千条到上万条客服GD，用gemini-3.1-pro-preview做两级分类：一级路由：二级标注：dispatch 到 20 个提示词模板之一，做详细分类每条GD都会打两次 LLM。而我发现了一件事：每次调用的提示词，90% 的内容是重复的。模板动辄 20KB，GD对话数据只有几百字节。也就是说，我们每天上万次把同一份长文档一遍一遍塞进 API，然后按输入 token 单价 $1.25/1M 老老实实付钱。这时候我意识到：不是模型贵，是我们在为重复内容重复付费。二、原理：Ge