Gemini 预付款余额归零，名下所有密钥会同时停摆
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
Gemini API 的预付款方案有一条写在官方账单文档里、但很多人是在事故现场才第一次读到的规则：预付款余额归零时，该结算账号下所有项目的所有 API 密钥会同时停止工作。 不是”超支的那个项目停”，也不是”某个密钥被禁用”，而是整个结算账号的爆炸半径。这条规则之所以杀伤力大，是因为它和另外两条官方规则叠在一起：一是 API 密钥没有独立的结算设置，它继承所属项目的层级与结算状态；二是层级、限流、账号上限统统在结算账号级别确定，不在项目级别。三条连起来的意思就是——你按项目做的那些隔离，在余额这件事上一格都不生效。所以真出事的时候，排查顺序不该是”去看哪个密钥坏了”，而应该是”先确认自己是不是预付款方案，再去看余额”。
第一步：先确认你到底是哪种结算方案
Gemini API 的结算有两种方案，预付款（prepay）和后付费（postpay）。官方说明是可以在 AI Studio 的结算页里查看自己被分配到了哪一种。这一步不能跳过，因为”余额归零全停”这条规则本身是挂在预付款方案上的：官方对预付款的描述是先充值再用，费用近乎实时从余额里扣，而余额归零那条规则写的正是预付款账号。后付费这边官方给的表述只有扣款时点——月底或者达到支出上限时自动扣款；至于达到支出上限之后服务会不会跟着停、以什么形态停，官方文档里没有找到相关说明，这一点不要凭直觉往上补。
所以这一步真正要拿到的结论只有一个：确认自己是不是预付款方案。是预付款，后面几步的排查前提才成立；不是预付款，那么”充值恢复""余额被吃光”这条线索链对你就不适用，得回到账单本身按另一套逻辑去查。这个判断只要打开结算页看一眼就有答案，花的时间远比在密钥和项目之间乱试要少。
顺带提一句方向性问题：官方说明里，满足第 3 层级条件之后可以手动从预付费切到后付费，而且这个切换是不可逆的，切过去就没有切回预付款这条路。另外官方在核实当日还注明，手动切换到后付费的选项暂时处于停用状态——这是一个临时状态，看到本文时是否还成立请以官方文档当前版本为准。也就是说，如果你现在在预付款方案上，短期内大概率还得在预付款的规则下过日子，那就得把归零这件事当成一个必须防的运维风险，而不是一个”到时候再说”的问题。
第二步：搞清楚爆炸半径，别在密钥层面浪费时间
事故现场容易顺手做的两个动作，是新建一个 API 密钥试试看，或者换一个项目的密钥再试试看。在余额归零这个场景下，这两个动作都是白费力气，官方文档已经把原因写死了。
密钥这一层：官方明确 API 密钥没有独立的结算设置，它继承所属项目的层级与结算状态，而且同一个项目内所有密钥的用量是合并计入的。所以新建密钥不会得到一份新的额度，只是在同一个池子里多开了一个口子。
项目这一层：官方对预付款归零的表述是”该结算账号下所有项目的所有 API 密钥”同时停止工作，范围直接跨过了项目边界。同样地，层级与限流也是跟着结算账号走的——项目从一个结算账号换到另一个，层级与限流会跟着新结算账号变。这条规则的另一面在层级怎么升那篇里更有用，但在排查场景下，它给你的结论是：换项目不解决余额问题，除非你换的是结算账号。
真正能改变状态的动作只有两个方向：往这个结算账号里补钱，或者按官方说明解除项目与结算账号的关联、退回免费层。后者要特别小心一件事——官方明确写了免费层与付费层的数据使用政策不同，免费层的内容会用于改进 Google 产品，付费层不会。所以”先解绑顶一下”这个应急操作，代价是数据政策的变化，生产环境上做这个决定之前得先问清楚这个代价能不能接受。
第三步：复盘余额是被什么吃光的
如果你的用量曲线看上去平稳，余额却突然见底，官方文档里有几条容易被忽略的消耗路径值得逐条对一遍。
结算流水线本身有延迟。 官方明确写了结算流水线存在延迟，在这段延迟里可能产生超额用量，并且特别点名批量模式与 Agent 这类长时间运行的任务，尤其容易在系统停止之前继续消耗。具体的延迟时长以官方文档当前版本为准，这里要记住的是机制：你看到的余额不是此刻的余额，是延迟之前的余额。这一条单独展开可以看结算延迟怎么把预算撑爆。
缓存的存储时长是单独计费项。 Gemini 官方 FAQ 把计费依据列成四项：输入 token 数、输出 token 数、缓存的 token 数，以及缓存 token 的存储时长。长上下文那份文档也写明，缓存起来的文件是按小时为存储付费的。这意味着这部分开销和你当下有没有发请求并不完全绑定——机制细节见缓存存储为什么要单独计费。
接地（Grounding）是按请求数另算的。 官方说明里，Google 搜索接地与 Google 地图接地每月有免费请求额度，超出后按请求数计费；而且官方专门注明，一次客户请求可能触发多次 Google 搜索查询，每次单独收费。也就是说这里的计费单位和你自己代码里的请求数不是一一对应的关系，用了接地又只按自己的调用次数估算成本，估出来的数会偏小。
AI Studio 的用量也会走这个余额。 官方说明 AI Studio 本身使用是免费的，但一旦在 AI Studio 中关联了付费 API 密钥，该密钥的 AI Studio 用量就开始计费。官方给的控制办法是在付费项目密钥与免费项目密钥之间切换。团队里有人拿生产密钥在界面上做调试，这笔账最后是记在同一个余额上的。
赠金和余额的消耗顺序是固定的。 官方说明是：预付费账号如果有有效余额，系统会先用 Google Cloud 赠金，再用预付款余额；而余额归零之后，就不再消耗赠金了。这个顺序有点反直觉——它意味着余额归零并不等于”还有赠金兜底”，归零之后赠金也一起停。另外官方给赠金政策划了一条按账号开立日期的分界线，分界之后开立的新 Cloud 账号，迎新赠金不能用于 Gemini API 与 AI Studio，只能用于其他 Google Cloud 产品，具体日期以官方文档为准。
第四步：充完钱之后，服务不一定立刻回来
这是排查流程里最容易被漏掉的一环。官方在延迟说明里写得很直白：服务只在点数购买正式确认之后才会恢复或者升级。而付款确认本身的耗时取决于付款方式——银行卡付款多为即时，银行转账则可能需要数天。层级升级则是在成功付款之后的一段时间内完成，具体时长以官方文档为准。
把这几条串起来的实际后果是：如果你的付款方式是银行转账，那么”余额归零”对你来说不是一次分钟级的中断，而可能是一次跨天的服务不可用。这个风险只能靠事前配置来消掉，事后再补是补不上的。
同一段延迟说明里还有一条对复盘很关键：总费用明细图表的更新是有延迟的，最长延迟以官方文档为准。所以你在事故当天打开费用图表想看清楚钱花在哪儿，很可能看到的还不是完整数据，别拿一张没更新完的图表去下结论。
官方文档没有说明的几件事
这一节是刻意留的，因为凭想象补上去比空着更危险。
一是余额归零时 API 到底返回哪个错误码。官方的错误码参考里列了 authentication、permission_denied、quota_exceeded、rate_limit_exceeded 这些码及其含义，但并没有把”预付款余额归零”这个状态映射到其中任何一个上，官方文档里没有找到相关说明。所以监控告警不要去猜某个特定错误码，更稳的做法是同时盯余额本身。
二是余额低到什么程度会有提醒、提醒发给谁。官方文档里没有找到相关说明。
三是停摆之后已经在跑的批量作业会怎么处理——是排队等待还是直接失败。官方只写了长时间运行的任务在结算延迟期间容易继续消耗，没有说停摆之后这些作业的最终状态，官方文档里没有找到相关说明。
事前该配的几样东西
官方在预付款方案下给出的可配置项有这么几个，值得在出事之前就摸一遍。
自动充值：官方说明预付款支持自动充值，并且可以设置每月自动扣款限额。这里有一个容易读漏的细节——手动的一次性付款不计入这个每月限额。也就是说这个限额约束的是自动扣款那条线，不是你这个月的总支出。
支出上限：官方把支出上限分成两级，结算账号级（按月）和项目级。项目级这一层官方自己标注为实验性、适用范围有限，另外设置项目级上限需要项目的编辑者、所有者或管理员角色。还有一条迁移相关的规则：项目迁移到其他结算账号时，支出上限的设置会保留，但累计支出会在新的结算周期重置。
用量预估：官方给的 token 计数方法是 GenerativeModel.count_tokens，配合通用的 API 成本监控做法可以把月度开销先估个大概，而不是等余额告急才去算。
最后说一条这件事上最容易栽的坑：预付款额度仅可用于 Gemini API 的使用费，不能拿去支付其他 Google Cloud 服务；而且官方写明购买的点数会过期且不可退款（切换账号类型的情形除外），因非升级原因关闭预付费账号时剩余金额作废。所以充值这件事既不能太抠——抠到随时可能归零、拖垮整个结算账号下的所有密钥，也不适合一次性堆得太多——堆多了受过期与不可退款的约束。在这两者之间找平衡的前提，是你先把自动充值和支出上限都配好，让余额有一条自动兜底的线，而不是靠人盯着。