Gemini 预付款和后付费怎么选：切过去就回不来了
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
先把结论摆在前面：Gemini API 的结算方案有预付款（prepay）和后付费（postpay）两种，你的账号被分到哪一种，可以在 AI Studio 的结算页面查看。两者真正的差别在扣款方式与失败模式——预付款是先充值再用、费用近乎实时从余额扣除，余额归零时该结算账号下所有项目的所有 API 密钥同时停止工作；后付费则是月底或者达到支出上限时自动扣款。更要紧的是这两种方案之间只有一条单向通道：官方写明满足第 3 层级条件之后，可以手动从预付费切换到后付费，而且这个动作不可逆，切回预付款是不可能的。另外官方还注明，截至核实时点，手动切换到后付费的这个选项暂时处于停用状态。所以在开工之前就得想清楚：你更怕哪一种事故，是服务突然全线停摆，还是账单在月底才被发现已经跑高。
先确认自己现在到底是哪一种
很多人从来没查过这件事，直接就开始按自己的想象做预案。官方给的查法很直接：在 AI Studio 的结算页面里可以看到自己被分配到哪种方案。这一步必须先做，因为两种方案的日常运维动作是完全不同的——预付款要盯余额，后付费要盯支出上限，两者盯错了对象，预案就等于没做。
还有一层结构必须先理顺：官方明确写了层级、限流、账号上限都在结算账号级别确定，不是项目级别。API 密钥本身没有独立的结算设置，它继承所属项目的层级与结算状态，同一个项目内所有密钥的用量会合并计入。所以「给团队每人发一把独立的 key，各自结算、各自限额」这种做法在 Gemini API 上是行不通的，key 只是凭证，钱和额度都挂在上面的项目与结算账号上。想按人或按业务线切开成本，只能从项目和结算账号这一层去切。
预付款：近乎实时扣款，自动充值那道闸只管一条线路
预付款的机制是先充值、再消费，费用近乎实时地从余额里扣除。官方支持自动充值，并且可以设置每月的自动扣款限额，用来防止余额被无限续上去。
这里有一个特别容易读漏的限定条件：手动的一次性付款不计入这个每月自动扣款限额。也就是说这道闸只管住了自动充值这条线路，你自己手动补的那几笔它不管。如果团队里有多个人有权限补款，只依赖这个限额来控制月度总支出，判断就会偏。要把这条限制当成「自动充值的护栏」，而不是「本月总支出的天花板」。
后付费：月底扣，或者撞到支出上限时扣
后付费的扣款时点是月底，或者达到支出上限时自动扣款。这意味着支出上限在后付费方案里不只是一个提醒，它同时也是一个扣款触发条件。
官方把支出上限分成两级。一级是结算账号级别的每月上限，另一级是项目级别的上限，而项目级这一档官方专门标注为实验性、适用范围有限——引用它做架构设计之前要留意这个标注，别把一个实验性能力当成稳定的成本护栏来依赖。设置项目级上限还有权限门槛，需要项目的编辑者、所有者或者管理员角色，普通成员点不动。
另外有一条在做账号搬迁时才会暴露的行为：当项目从一个结算账号迁移到另一个结算账号时，支出上限的设置会保留下来，但累计支出会在新的结算周期里重置。设置保留、计数清零，这两件事同时发生的直接后果是——迁移当月你可能相当于把这个月已经烧掉的额度重新归了零，上限还是那个上限，但可用空间凭空多出来一截。如果迁移是在月中做的，月度预算的口径就得重新算一遍。
那道单向门：满足第 3 层级条件才能切，切了回不来
官方对这两种方案之间的切换给的条件很具体：满足第 3 层级条件之后，可以手动从预付费切到后付费，并且这个切换不可逆，切回预付款是不可能的。同时官方注明，手动切换到后付费的选项暂时处于停用状态——这是核实当日的临时状态，真要做这个动作之前，还是得回官方结算页确认它当前是否已经恢复。
顺带把第 3 层级的门槛机制也说清楚，因为它是这道门的前置条件。官方对第 2、第 3 层级给的判定方式是两个条件同时满足：累计支付的金额，以及自首次成功付款起算的天数。注意是「同时」，光把钱付够、天数没到一样不行。更容易被忽略的是资格判定的口径——它基于该结算账号在 Google Cloud 服务整体上的累计总支出，并不限于 Gemini API 这一项。如果你的结算账号本来就在跑其他 Google Cloud 服务，累计支出的进度会比只看 Gemini 账单估出来的快。反过来，官方也保留了否决权：满足条件通常足以获批，但升级申请仍然可能因为审核中的其他因素被拒。层级这条线怎么走，可以配合Gemini 层级体系与限流的关系一起看。
预付款那笔钱有三条规矩，条条都关系到退路
第一条是用途受限。预付款额度仅可用于 Gemini API 的使用费，不能拿去支付其他 Google Cloud 服务。所以它不是一笔通用的云预算，充多了也没法挪去别处消化。
第二条是会过期而且不可退款。官方写明购买的点数会过期且不可退款，只有切换账号类型属于例外情况；如果因为非升级的原因关闭了预付费账号，剩余金额作废。这条决定了充值策略的方向——预付款不适合为了图省事一次性充一大笔当长期缓冲，充值节奏应该贴着实际用量走。
第三条是消耗顺序，这条最容易被理解反。官方的说法是：若预付费账号有有效余额，系统会先使用 Google Cloud 赠金，再使用预付款余额；而余额归零之后就不再消耗赠金。请留意后半句这个限定——赠金并不是一张永远兜底的备用卡，它的消耗是绑在「账号有有效余额」这个前提上的，余额一旦扣干净，赠金也跟着停止消耗，服务不会因为还有赠金就继续跑。
赠金这边还有一条政策分界值得知道：官方按 Google Cloud 账号的开立日期划了一条线，在该日期之后开立的新账号，其迎新赠金不能用于 Gemini API 与 AI Studio，只能用于其他 Google Cloud 产品（具体的分界日期以官方结算文档为准）。拿新账号的赠金去规划 Gemini 的启动预算，很可能一开始就落空。
余额归零不是降级，是整个结算账号一起停摆
这是预付款方案里最值得单独拎出来的运维风险点：官方写明预付款余额归零时，该结算账号下所有项目的所有 API 密钥会同时停止工作。
请注意爆炸半径的单位——不是某一个 key 失效，也不是某一个项目降级，而是结算账号底下的全部项目、全部密钥一起停。如果你把线上生产服务和内部测试脚本挂在同一个结算账号下，那么某个跑飞了的测试脚本把余额啃光，线上服务会跟着一起断。想隔离这个风险，隔离的粒度必须是结算账号，而不是项目、更不是 key。
余额监控这件事还有两个会让人误判的延迟因素。官方明确指出结算流水线本身存在延迟，在这段延迟期间可能产生超额用量，而批量模式和 Agent 这类长时间运行的任务尤其容易在系统真正停止之前继续消耗；另外总费用明细图表的更新也可能明显滞后于实际用量（具体的延迟时长以官方文档为准）。这两条叠在一起的意思是：你在控制台上看到的那个余额数字，天然落后于真实消耗，越是跑长任务落后得越明显。要做告警就得放在自己这一侧的监控里，而且不能只在余额快见底的时候才报，得留出足够的提前量。这一块的细节可以接着看Gemini 结算延迟与超额是怎么产生的，通用的做法则可以参考API 成本监控怎么搭和API 账单暴涨怎么排查。
怎么选：先看你怕哪种事故，再看非价格因素
如果服务是对外的、断了会被投诉，那么预付款的停摆特性就是一个需要正面处理的风险，要么把自动充值配起来、同时在自己这一侧的监控里做余额提前量告警，要么把关键业务隔到单独的结算账号里去。这里要说明一句：官方结算文档里写到的余额侧能力只有自动充值、每月自动扣款限额、支出上限这三项，至于 Gemini API 或 AI Studio 是否内置余额告警、能不能在余额低于某个水位时主动推消息给你，官方文档里没有找到相关说明。所以稳妥的做法是不要预设它有，把告警这一层按「需要自己补」来规划。如果是内部使用、更怕的是月底突然收到一张没预料到的账单，那么支出上限就是主要的控制手段，只是要记住项目级上限被官方标为实验性、适用范围有限，别把它当唯一防线。
选方案时还有一个和钱无关但影响很大的因素：官方写明免费层与付费层的数据使用政策不同——免费层的内容会用于改进 Google 产品，付费层不会。这属于价格之外的一条因素，对于处理业务数据、客户内容的场景，它往往就是决定性的那一条。反过来，如果确实想退回免费层，官方给的路径是解除项目与结算账号的关联。
最后是一个和结算方案强相关、但很多人是在账单上才发现的坑：AI Studio 本身的使用是免费的，但一旦在 AI Studio 里关联了付费的 API 密钥，该密钥在 AI Studio 中的用量就开始计费了。官方给出的控制办法是在付费项目的密钥与免费项目的密钥之间切换使用。也就是说，你在网页界面里随手做的那些调试和试玩，只要挂的是付费 key，就会真实地扣进账单，而这部分消耗和你代码里的调用混在同一份账单里，事后很难拆开归因。养成的习惯应该是：调试用免费项目的 key，生产代码用付费项目的 key，两把钥匙别混着插。
下一步建议先做三件很小但很值的事：去 AI Studio 结算页确认自己是预付款还是后付费；确认关键业务与实验性用途是不是共用了同一个结算账号；把结算账号级的支出上限设起来，并在自己这一侧的监控里按前面说的提前量搭一条余额告警。这三件事都不难做，但每一件都能挡住一类真会发生的事故。