gemini 3.0 pro 价格

很多人第一次接 Gemini Pro，是先按印象估了个数，跑了两周才发现账单对不上：输入输出混着算、长上下文和高频小请求的价格感受完全不同。这篇不给你一个固定单价，而是告诉你价格该去站内哪几页核对、按什么口径把你的用量转成钱、以及怎么在动手前把预算框住。

第一次接 Gemini Pro 的人，十有八九是先估了个数就开工，跑两周看账单才发现对不上。常见原因不是谁算错了，而是口径没统一：输入和输出混在一起算、长上下文和高频小请求的价格感受完全不同、走的是云平台还是官方直连也没分清楚。所以这篇不给单价，只讲一件事——价格该去哪儿核对、按什么口径把用量折成钱、动手前怎么把预算框住。

顺便说清楚一个前提：任何写死的数字都会过期，包括站内文章里的。你要养成的习惯是「现场核对」，而不是「记住一个数」。下面每一节都会告诉你该打开哪一页、该看哪一栏、该拿什么数据去对。

价格别背，去这三个地方现场核对

查价最少要打开三类页面，各自解决的问题不一样。官方 API 价格页回答的是「按 token 计费时当期挂牌口径是多少」；订阅或地区价页回答的是「打包档位怎么卖」，这两个不是一回事，不能拿来互相换算。token 单价换算工具解决的是单位换算，避免你在脑子里做多次乘除。而价格本身是浮动的，去 /price-watch 看价格追踪的记录，比背一个数靠谱得多。

• 官方 API 价格页：看输入、输出分别挂什么口径，以及有没有分档的说明，别只看第一行就下结论
• 订阅 / 地区价页：看的是打包档位，跟按量计费比大小没意义，先分清你走的是哪条路
• token 单价换算工具：把你手上的原始数字换成统一单位，再拿去做预算，中间少一次心算就少一次错
• /price-watch 价格追踪：看的是变动历史，判断「现在这个数是不是临时状态」
• 模型资料库：确认你要调的这一档到底有没有单独的计费规则，别默认所有档位一个价

输入和输出是两笔账，先分开再合计

很多人的用量日志只有一列总数，做第一次预算时够用，等要对账就完全不够了。因为输入和输出的口径不一样，任务是「喂一份长材料、只回一句话」还是「喂一句话、生成一篇长文」，成本结构天差地别。把日志按输入 token、输出 token 拆成两列，再各自乘对应口径，这才是能对得上账的算法。

具体动作：从日志里捞一条典型请求，把它的输入 token 和输出 token 分别量出来，别用「感觉大概几百」这种估法。然后用这两个数乘各自口径，得到「一次调用的大致成本」，再乘你预期的日均调用量。这一步做完，你的预算才是有根的。

长上下文最容易被低估的那一段

长上下文之所以坑，不在于单次贵，而在于它是「每次请求都要重新付一遍」。一份材料如果只在一次问答里出现，那它贵不贵影响有限；但如果在多轮对话里反复带上，成本就变成「输入成本 × 轮数」，这时候真正决定开销的是重复次数，而不是单次单价。

1. 先量一次不带冗余的输入把那份长材料单独量一遍 token 数，记下来，这是基线。
2. 再看它会被重复带几次翻会话日志，数一下这份材料在同一个流程里出现了多少轮。数出来的数字乘以基线，才是真实输入量。
3. 判断该不该做预处理如果重复次数明显大于一次，优先做摘要或缓存，而不是先去调档位。判断标准很直接：重复次数越多，预处理回报越大。
4. 验证改完再跑一周，回到 /price-watch 看这段用量是不是真的降了，别凭感觉说「应该省了」。

长上下文的问题从来不是「贵不贵」，而是「同一份东西你付了几遍」。

直连官方、走云厂商、走中转，成本归属差在哪

同样调用一档模型，钱最后付给谁、按哪张表算，取决于你走的路径。直连官方按官方挂牌口径走；走云平台托管，分成和折算方式可能跟挂牌不是同一张表；走中转渠道，倍率折算的逻辑又是另一套。三种路径的单价数字放在一起比大小，基本等于没比——因为口径根本不对齐。

比价之前先做一件事：确认你这条链路最终是按哪张表出账。如果不确定，去中转站目录看它的说明，或者直接到 /sites 对照各家的接入方式，把「谁收钱、按什么算」这一栏先搞清楚。云厂商转售和自开账号之间的差价从哪来，站内有专门文章拆过，这里不重复。

• 直连官方：口径最直接，适合用量稳定、自己盯账单的团队
• 云平台托管：方便和现有云资源合并结算，但折算口径要单独确认
• 中转渠道：接入快、结算方式灵活，但倍率逻辑必须问清楚再比价
• 混合使用：多个来源一起跑时，对账要按来源分开统计，否则永远对不上

动手前把预算框住的四步

预算是给自己设的刹车，不是给别人看的表格。做法不复杂，关键是每一步都要有可验证的产出，而不是拍脑袋填个数。

1. 量一条典型请求从真实场景里挑一条最有代表性的请求，把输入和输出 token 分别量出来。不要用平均值代替，平均值会把长尾吃掉。
2. 乘出月度区间用这条请求的成本乘以预期日均调用量，再乘三十天左右，得到一个区间而不是一个点。区间上下限来自你对调用量波动的判断。
3. 留缓冲并写进告警在区间上限之上留一段缓冲，把缓冲对应的用量门槛写进监控告警，而不是等月底账单出来才发现超了。
4. 设定对账频率上线后第一周每天对一次，第二周起改成每周一次。频率递减的依据是第一周更容易暴露配置问题。

需要说清楚不适用的情形：如果你的调用量很小、或者还在验证阶段，上面这套四步可以简化成「量一次、看一眼、先跑起来」。预算框架的价值随调用规模上升，规模不够时它反而是负担。

月底对账：账单和你的估算差在哪

对账别一上来就怀疑单价，绝大多数偏差出在用量侧。按下面的顺序查，通常前三步就能定位到问题。

• 先查调用次数：次数偏差比单价偏差常见得多，配置错、循环没退出都会让次数翻倍
• 再查重试和失败请求：这部分同样计入用量，但没有产出，属于纯损耗
• 最后查 key 归属：多人共用一个账号时，别人的项目可能正在用你这个 key 跑
• 如果前三步都正常，再回去核对计费口径是不是变了，去 /price-watch 看变动记录

一个实用习惯：把对账结果记成一句话，比如「次数正常、单次输入偏长」。下次再出偏差，先翻这句话，比从头查一遍快得多。

要把这笔钱压下来，顺序是这样

降本最怕一上来就换服务商，因为迁移成本和风险往往比省下来的钱更难扛。正确顺序是先动自己这边能控制的部分，再考虑外部因素。

1. 先砍重复输入找那些在同一流程里被反复带上的长材料，做摘要或缓存。这一步改动小、见效直接，应该排第一位。
2. 再挪可批量的活把不要求实时返回的任务挪到批处理通道。代价是等待时间，所以先算清这部分时间对你有没有影响，再决定。
3. 然后才考虑换档位如果前面两步做完还是偏高，再看是不是真的需要当前这一档。判断标准是：任务质量对档位敏不敏感，不敏感就往下调。
4. 最后才想换服务商换服务商意味着重新验证接入、对账和稳定性，只在前面几步都做完、且用量足够大时才值得。规模小的团队做了往往是亏的。

还有一个常被忽略的点：降本之后要重新对账一次，确认降的是真实用量而不是把请求挪到了别的地方。如果只是把调用转移到另一个 key 或另一个来源，账单上不会变好看。