google gemini 3 pro 费用

很多人第一次给 Gemini 3 Pro 做预算，都是先按官方单价乘个大概用量，结果月底账单和预估对不上。问题通常不在单价，而在你没算清输入输出占比、长上下文和重试这三块。这篇不给你背数字，而是给一套能自己跑的流程：从口径对齐，到用量折算，到对账，到降本取舍。

很多人第一次给 Gemini 3 Pro 做预算，都是先按官方单价乘个大概用量，结果月底账单和预估对不上。问题通常不在单价，而在你没算清输入输出占比、长上下文和重试这三块。这篇不给你背数字，而是给一套能自己跑的流程：从口径对齐，到用量折算，到对账，到降本取舍。

先明确一件事：全文不写死任何价格、倍率、折扣，因为这些东西会变。你需要的不是记住几个数，而是知道每个数该去站内哪个页面核对当时的版本。下面按费用构成、口径、折算、长上下文、对账、降本、决策七步走一遍。

Gemini 3 Pro 的费用由哪几笔组成

按量计费的基本结构是：输入 token、输出 token、缓存相关的读与写，各自是独立单价，别混成一个数。很多人算预算时只记一个「每百万 token 多少钱」，然后拿总 token 乘上去，误差就出在这里——输入和输出往往不是一个价，缓存命中和未命中也不是一个价。

• 输入 token：你发出去的提示词、上下文、贴的材料，按输入档计价
• 输出 token：模型生成的内容，通常按输出档计价，和输入档分开
• 缓存写入：把固定内容存进缓存时产生的一次性费用
• 缓存读取：后续请求命中缓存时按读取档计价，通常比重新输入便宜
• 多模态输入：图片、文档、音频这类内容按各自单位折算成 token，再去套计价档

还有一个容易忽略的点：长上下文和多模态输入可能让单价档位变化。先确认你这类请求落在哪个计价档，再去算总价。档位在哪看？到 /official-api/providers/google 核对当时公布的模型规格和计价口径，别拿旧印象套。

订阅侧

Google 订阅档位看 /plans 系列页面，和 API 是两条独立的账

API 侧

按量计费看 /official-api/providers/google 的当期资料

不计入账单

网络出口、代理转发、日志存储这些要另算，别混进模型费用

先对齐口径：你看到的价和账单上的价为什么不是一回事

你看到的报价和账单上的扣费对不上，八成是口径问题，不是计费错误。常见的有三类：币种与结算口径、含税与否及结算顺序、多渠道倍率。这三类里，前两类几乎每个人都会踩一次。

判断标准：如果渠道差价在一个你能接受的范围内，且对方能提供用量明细，可以先用着；如果差价明显偏离，或者对方给不出按次明细，就必须逐条核。这两类情况的处理方式完全不同，别用同一套标准。

多家渠道的倍率差异，对比方式看 /ai-nav/category/ai-api。注意那里是导航和对比信息，不是最终报价，具体数字以你去核对时的页面为准。

把用量折算成预算：三步跑法

这一步的目标不是算出精确到分，而是得到一个能用来做判断的量级。方法是三步：抓日志、代入计算器、留余量。做完这三步，你对自家业务的成本结构会清楚很多。

1. 抓一段真实请求日志按输入、输出、缓存命中分别汇总 token，字段清单可以参考 /usage 的量级概念。至少覆盖一个完整业务周期，别只抓半天。
2. 代入计算器算当期价格用 /tools/model-cost-calculator 或 /tools/token-price-calculator 把当期价格代进去算，而不是背单价。价格变了，重算一遍就行。
3. 留出重试和失败余量把失败重发的比例单独乘一遍，别默认 100% 一次成功。这个系数通常比你想的大。

不适用的情况要说清楚：一次性批处理任务和持续在线服务，余量系数要分开设。批处理可以容忍更高失败率、更慢的返回，在线服务不行。用同一个余量系数去套两类任务，必然有一边估错。

长上下文和多模态：最容易被低估的部分

上下文越长，单次请求的输入 token 越高，而且会随着每一轮对话累积。多轮对话里，前面几轮的完整历史会被反复带上，输入量不是线性增长，而是接近累加。这是很多人预算翻倍的主要原因。

• 贴图、贴文档这类多模态输入按什么单位计费，先去 /models 看你用的具体模型规格
• 截断历史：能省输入，但会损失上下文连贯性，适合单轮任务
• 摘要压缩：把历史压成一段摘要，省得多但要额外一次调用
• 固定内容挪到缓存：适合反复出现的系统提示或知识片段，省的是重复输入

判断标准：任务对上下文完整度的依赖有多强。越依赖完整上下文的任务，越不该硬压。比如长文档问答，你压掉的那部分可能正好是答案所在；而简单的分类任务，压掉历史几乎没影响。

长上下文的成本不是「多一点点」，而是随着轮次累积的复利，预算时要按最坏轮次估。

账单出来之后怎么对：一份 15 分钟的对账清单

对账的目标是找出异常，不是纠结总额。总额对不对是结果，异常日才是原因。所以第一步就是把账单按天拆开，和你的用量日志按天对齐，先找异常日。

发现差异时，先确认是不是计量窗口的问题，再怀疑计费错误。常见的是账单按自然日切，你的日志按业务周期切，两边错位半天就会显示差异。确认窗口一致之后，再逐项往下查。

可复用的流程：账单核对方法可以参考 /about 里公布的检测口径思路，自己建一张对照表，每次账单来照着填一遍，比每次临时想省事。

真要把费用压下来，按这个顺序动手

降本有顺序，顺序错了会白费力气。先降无效消耗，再调参数，最后才动模型选型。很多人一上来就换模型，结果发现质量掉了、返工变多，总成本反而上升。

• 先降无效消耗：重试、超长提示、重复贴同一份材料，这三块通常最容易砍
• 再调参数：输出长度上限、是否需要完整推理过程、能不能换成更小的模型做前置处理
• 最后才动模型选型：同一个任务换档位能省多少，用 /tools/model-cost-calculator 跑一遍再决定
• 每次只改一个变量，改完跑一段真实流量再对比，别一次全改

不适用的情况：质量敏感型任务不要为了省钱降档，返工成本往往比省下的多。什么算质量敏感？就是输出错了要人工返工、或者会影响下游流程的任务。这类任务的成本大头是返工，不是模型调用。

什么时候该继续用，什么时候该换

这个问题没有统一答案，但有两个可操作的信号。继续用的信号是：单位任务成本稳定、可预测，波动来自业务量而不是计费异常。该重新评估的信号是：每次优化都要先改架构，说明当前模型和你的任务不匹配。

把「省下来的钱」和「改造成本」放在一张表里比，改造成本高就先不改。比如一家 5 人小团队，如果换模型要重写提示词、重建评测、再跑一个月验证，那省下来的调用费可能还不够覆盖这段时间的工时。

在哪看当期对比：去 /official-api 和 /ai-rankings 用当期数字做判断，本文不写死任何价格。这两个页面的数字会更新，你看到的才是当下有效的。