Gemini 的层级体系怎么升：限流跟着结算账号走
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
Gemini API 的层级不是挂在项目上，更不是挂在 API 密钥上，而是挂在结算账号上。 官方文档写得很清楚：层级、限流、账号上限这三样东西都在结算账号这一级确定。免费层只需要一个有效项目或免费试用；升到第 1 层级唯一要做的事情是设置并关联一个有效的结算账号；第 2、3 层级的门槛则是两个条件同时满足——累计支付的金额，以及自首次成功付款起经过的天数。而且资格判定看的是这个结算账号在 Google Cloud 服务整体上的累计总支出，不限于 Gemini API 这一项。搞清楚这个归属关系，很多让人抓狂的现象立刻就有解释了：为什么新建一个项目并不能让你拿到更宽的限流规模，为什么多申请几把密钥没有任何用，为什么把项目换个结算账号绑，限流会跟着一起变。
层级挂在结算账号上，这句话有三个直接后果
第一个后果是密钥没有独立的结算设置。官方明确写了：API 密钥继承所属项目的层级与结算状态，一个项目里所有密钥的用量是合并计入的。所以「给不同业务发不同的密钥来分摊限流」这个做法从机制上就不成立——密钥只是身份凭证，不是配额单元。这一点与限流的作用范围是同一件事的两面，站内另有一篇专门讲这个误解：Gemini 限流是按项目算的，不是按 API 密钥算的。
第二个后果是项目换结算账号，层级和限流会跟着新结算账号走。这在做环境隔离、把测试项目并入生产结算账号这类操作时值得先想一遍：你搬的不只是账单归属，还包括这个项目此刻能享受到的层级。官方还补充了一条容易被忽略的细节——项目迁移到其他结算账号时，支出上限的设置会保留，但累计支出会在新的结算周期重置。也就是说，配置项跟着走，累计数从头算。
第三个后果是层级是可以退回去的。官方文档写明，解除项目与结算账号的关联，可以退回免费层。这不是惩罚性的机制，而是一条正常路径，但它反过来提醒你：任何对结算账号关联关系的改动，都可能是一次静默的降级。
免费层升到第 1 层级：门槛只有一个，副作用有两个
第 1 层级的资格条件在官方文档里只有一句话：设置并关联一个有效的结算账号。官方为这一级只列出了这一个条件；累计支付金额与自首次成功付款起的天数这两道门槛，是从第 2 层级才开始出现在条件清单里的。真正需要提前想清楚的，是随之而来的两个变化。
变化一是数据使用政策不同。 官方在计费说明里区分得很直白：免费层的内容会用于改进 Google 产品，付费层不会。对于内部代码、客户资料、未公开的产品文档这类输入，这条差异往往比价格更重要——它决定了你能不能把这个通道用在真实业务数据上，而不只是拿来做玩具级验证。做技术选型时如果只对着单价算账，漏掉的往往就是这一条——省下来的那点钱，换来的是合规上不该冒的风险。
变化二是 AI Studio 的用量会开始计费。 官方写明：AI Studio 本身的使用是免费的，但一旦在 AI Studio 中关联了付费 API 密钥，该密钥在 AI Studio 里的用量就开始计费。官方同时给出了控制办法：在付费项目的密钥与免费项目的密钥之间切换使用。这意味着如果你习惯在网页界面里长时间试提示词、反复跑长上下文，升级之后这部分行为不再是白用的了。想让日常调试保持零成本，就得有意识地在界面里挂免费项目的密钥，把付费密钥留给正式调用。
第 2、3 层级：两个条件必须同时满足，且看的是整个 Cloud 的支出
这一格最容易理解偏的地方在「同时」两个字。官方给的条件是累计支付金额与自首次成功付款起的天数两者同时满足——不是达到金额就能升，也不是等够天数就能升。所以对着账单猛充一笔，天数不够照样升不上去；反过来，账号开了很久但支出没到线，也一样卡着。具体的金额门槛与天数门槛本文不复述，请去官方的限流与结算文档看当前数值。
另一个反直觉的点是资格判定的口径比你以为的宽：官方说明中，判定基于该结算账号在 Google Cloud 服务整体上的累计总支出，并不限于 Gemini API。如果你所在的团队本来就在这个结算账号下用着别的 Google Cloud 产品，那些支出是算数的。这条对于「要不要把 Gemini API 单独开一个干净的结算账号」这种决策有实际影响——单独开确实账目更清楚，但你放弃的是既有支出带来的层级资格。
还有一条必须说在前面：满足条件不等于自动获批。官方保留了否决权，原话的意思是满足条件通常足以获批，但升级申请仍可能因为审核中的其他因素被拒。所以做容量规划的时候，不能把「下个月升到某一层、限流会翻上去」当成已经拿到手的东西写进方案。
付了款层级却没动：先查付款有没有被正式确认
付了款而层级没动，第一件要确认的不是层级本身，而是这笔付款有没有被正式确认——官方的结算延迟说明里其实已经把答案摆好了。关键那句是：服务只在点数购买正式确认之后才恢复或升级。而付款确认本身的耗时是分渠道的——官方写明银行卡付款多为即时，银行转账则可能需要数天。也就是说，你转账的那一刻并不是层级开始计算的那一刻，确认到账才是。
顺着这条往下排查，官方还列了另外几段各自独立的延迟：结算流水线本身有延迟，赠金扣减通常在几分钟内完成，层级升级在成功付款之后生效（官方给出了一个具体时长，本文不复述，以官方结算文档为准），而总费用明细图表的更新是所有环节里最慢的一段。所以排查顺序应该是：先确认付款状态，再看结算是否已入账，最后才去看图表——如果一上来就盯着费用图表判断「钱是不是花出去了、层级该不该升了」，看到的很可能是一份还没追上现实的视图。同一套延迟机制也会在别的地方咬人，站内另有一篇讲它怎么导致预算被冲破：Gemini 结算有延迟：长任务怎么就超出预算了。
升上去之后，限流具体变了什么
官方的说法是：层级越高限流越高，并且随用量与支出自动升级，当前限流可以在 AI Studio 中查看。这里有几件事需要分开看。
基础的三个维度不变。 限流仍然按 RPM（每分钟请求数）、TPM（每分钟输入 token 数）、RPD（每日请求数）三个维度计算，超出任何一个维度就触发限流错误，不是三项综合评估。部分模型还有额外维度：能生成图片的模型会计 IPM（每分钟图片数），部分模型有 TPD（每日 token 数）。另外 RPD 的配额在太平洋时间午夜重置，不是本地时间也不是 UTC——跨时区团队排班时这条会直接影响「什么时候额度回来」的判断。这几个维度的通用含义可以参考站内的API 限流 RPM 与 TPM 机制。
还有一层不按维度走的限流。 官方文档里另外写了一种「基于支出的速率限制」，它按滚动时间窗口评估（窗口长度以官方文档为准），是否适用取决于结算记录与账号状态，触发时返回 429 RESOURCE_EXHAUSTED。官方给的处置有三条：等待后重试；降低高费用请求的速率，办法是改用更小的上下文窗口或更短的输出；如果持续触发，就申请提高限流。注意这条限流卡的是「费用」而不是「次数」，所以单纯把并发调小、请求数压下来未必解决问题——真正要压的是单次请求的贵重程度。
有几类调用不吃这套层级限流。 官方写明 Batch API 的限流完全独立于非批量调用，另有并发作业数、输入文件大小、文件存储总量、每模型排队 token 数四类约束；优先级推理也有自己的一套限流。还有一条要记住的前提：实验性模型与预览版模型的限流更严格。所以遇到「我明明在高层级，为什么这个模型还是很快就限流」这种情况，要先确认的不是层级，而是你调的是不是实验性或预览版模型。
最后是官方自己给的免责，值得原样记住：指定的速率限制无法保证，实际容量可能有所变化。把限流值当成 SLA 写进架构假设，是一个从文档层面就站不住脚的做法。
第 3 层级之后：后付费这道门是单向的
官方文档里，第 3 层级还连着一个结算形态上的开关：满足第 3 层级条件之后，可以手动从预付款切换到后付费，而且这个切换不可逆——切过去就回不到预付款了。需要补充说明的是，官方在核实当日注明，手动切换到后付费的选项暂时处于停用状态；这是截至核实时点的临时状态，实际以你打开结算页面时看到的为准。
为什么这件事和层级绑在一起，是有道理的：预付款是先充值再扣，费用近乎实时从余额扣除，最硬的一条约束是余额归零时，该结算账号下所有项目的所有 API 密钥会同时停止工作。后付费则是在月底或达到支出上限时自动扣款，节奏完全不同。把切换权放在第 3 层级之后，等于要求你先有稳定的付款记录，再拿到这种「先用后付」的资格。
配套的护栏是支出上限，官方把它分成两级：结算账号级（按月）与项目级，其中项目级被官方标注为实验性、适用范围有限，设置它需要项目编辑者、所有者或管理员角色。也就是说，真正可靠的那道闸在结算账号这一级，项目级的那道不要当成主力防线来用。
收尾：这件事上最容易栽的三个坑
第一，把层级当成项目属性来管理。新开项目、换密钥、拆环境，这些动作都不会改变你所处的层级，也不会抬高限流的上限规模；官方把层级、限流、账号上限统一放在结算账号这一级确定，能改变它们的只有结算账号这一层的变动。
第二，只盯 Gemini API 的支出来估算升级进度。官方的判定口径是整个结算账号在 Google Cloud 服务上的累计总支出，估进度时算漏了别的产品，会把时间点估得偏晚；而反过来，为了账目清爽单独新开结算账号，则会把已有的支出资格丢掉。
第三，默认「升级了就一定更快更宽松」。层级只抬高限流上限，而限流上限官方明确说了无法保证；Batch、优先级推理、预览版模型各自另有一套约束。如果你的瓶颈其实在预览版模型的严格限流上，升多少级都不解决问题。
真正该做的下一步是：先去 AI Studio 里确认当前项目对应的是哪个结算账号、这个结算账号处在哪一层级、限流页面上显示的当前值是多少，把这三样对齐之后，再决定是等自动升级、主动补支出，还是把负载迁到 Batch 这类独立限流的通道上去。