先做地区判断：截至 2026-07-22，Google 当前的 Gemini API 可用地区列表没有列出中国大陆。本轮中文研究使用的 gl=CN 只是搜索市场参数，不代表服务在中国大陆自助可用。
因此，下面的结算检查只适用于：实际位于官方可用地区、符合当前条款，并且能在自己的账号中合法完成结算设置的读者。不要使用 VPN 切区、借用结算主体、购买账号、代绑卡或共享 Key 绕过地区、身份或付款规则；无法确认资格，就不要把这条路线作为生产依赖。
通过地区闸门后，最容易误判的并不是价格，而是下面三个状态：
- 已经显示 Tier 1，API 仍然不能调用：Tier 是资格，不等于 Prepay 已配置、余额为正或账号状态健康。
- Cloud Console 里能看到赠金，AI Studio 却显示“无积分”：Cloud 赠金与 Gemini Prepay 余额不是同一个钱包，也不一定符合 Gemini 使用条件。
- Prepay 还有余额，请求仍然暂停：可能是其他 Cloud 欠款、账号月度上限、项目限额、429 配额或数据延迟，不能继续盲目充值。
状态一：有 Tier 1，为什么仍不能调用？
Tier 1 只说明项目关联了有效的 Cloud Billing 账号。它不证明这个账号已经完成当前要求的付款设置，更不证明项目拥有可用余额或足够配额。
先看 AI Studio 的状态文字：
设置结算：项目还没有关联结算账号。此时应给这个项目关联或创建符合条件的账号，而不是给另一个账号充值。设置预付款：结算账号已经关联，但该账号要求的 Prepay 尚未完成。无积分：预付款支付账号缺失，或可用 Prepay 余额已经耗尽。- 没有上述提示但请求失败：继续查 Cloud Billing 账号状态与项目的活动限额，不要从 Tier 名称推断原因。
Google 当前的 Gemini API 结算说明把 API Key、项目和付款方分成三个对象：Key 只是项目凭证；项目聚合同项目下所有 Key 的用量和活动限额；Cloud Billing 账号提供付款历史、结算方案、层级资格与账号级月度上限。同一项目多建 Key，不会增加配额，也不会绕过账号停止状态。
层级资格到底看什么
截至本次核验，公开条件是：
- Free：有效项目或免费试用状态；具体免费模型、地区和活动限额仍需另查。
- Tier 1：关联有效的结算账号；若账号被分配为 Prepay，还要完成设置并保持正余额。
- Tier 2：已支付 100 美元，且距首次成功付款至少 3 天；账号月度上限为 2,000 美元。
- Tier 3：已支付 1,000 美元，且距首次成功付款至少 30 天；账号月度上限为 20,000–100,000 美元。
Tier 1 当前账号月度上限为 250 美元。Tier 2/3 的付款历史按结算账号统计，包含该账号在 Google Cloud 服务上的累计符合条件支出，不只看某个项目的 Gemini token。满足公开条件通常足以升级，但不保证审核、提额或容量一定获批。
付款确认与界面同步也不是同一个时钟：Free → Tier 1 通常较快，后续层级一般约 10 分钟更新，费用明细图可能延迟最多 24 小时。先确认交易状态，再决定是否真的需要第二次付款。
状态二：有 Cloud 赠金，为什么仍显示“无积分”？
因为同一个 Cloud Billing 账号可以同时存在两种收费周期：其他 Google Cloud 服务走 Postpay，Gemini API 却走独立的 Prepay。Cloud Billing 账号显示“有效”，不等于 Gemini Prepay 有可消费余额。
Prepay 当前的关键边界是：
- 最低购买 10 美元，最高购买或余额上限 5,000 美元；当地可见金额、币种、税费和付款方式以账号 checkout 为准。
- 未用额度 12 个月后过期；除官方记录的符合资格并成功切换 Postpay 的退款路径外，通常不可退款。
- 可以设置自动充值与每月自动扣款限额，但手动购买不计入这个自动扣款限额。
- 余额到 0 后，该结算账号下所有关联项目的 Gemini API Key 一起停止，不会自动回到 Free。
Cloud 赠金还要再过一层资格判断。当前 300 美元 Google Cloud 迎新/免费试用赠金，对 2026 年 3 月之后新开账号的 Gemini API 和 AI Studio 用量不适用。其他促销赠金各有规则；即使某项赠金符合 Gemini 使用条件，Prepay 账号也必须先有正余额，系统才会开始消耗该赠金。余额归零后，符合条件的 Cloud 赠金也会停止消耗。
所以看到“有赠金但无积分”时，正确顺序不是继续寻找新的 Key，而是确认：赠金类型与日期是否符合 Gemini 条件、Prepay 是否已经建立、余额是否为正、检查的是否正是目标项目所关联的结算账号。
状态三：Prepay 有余额，为什么仍然暂停？
正余额只排除了一个原因。下面四类问题仍可能阻止请求。
1. 其他 Cloud 账单影响了整个账号
同一 Cloud Billing 账号还可能承担其他服务的 Postpay 费用。欠款、扣款失败、付款方式失效或账号被停用，都可能暂停 Gemini API，即使 Prepay 仍有额度。此时应在 Cloud Billing 中修复付款健康状态，而不是向 Gemini 余额继续加钱。
2. 触及了项目或账号的月度控制
项目支出上限是实验性、有限开放的 project-level 控制，需要相应 IAM 权限。结算处理约有 10 分钟延迟，Batch 或代理等长任务也可能继续产生少量超额，所以它不是零延迟硬闸。
结算账号月度上限则跨项目聚合。达到当前 Tier 的账号上限后，该账号下启用 Gemini API 的相关项目都会暂停，通常要等下个账期（每月 1 日）恢复。把项目迁移到另一个结算账号，会让项目继承新账号的方案、层级上下文与账号上限；已设置的项目 cap 可以保留，但新账期的累计项目支出会从 0 重新计算。
3. 收到 429，但它不是余额错误
429 RESOURCE_EXHAUSTED 可能来自 RPM、TPM、RPD、模型专属限制或 10 分钟滚动支出速率限制。当前公开的支出速率限制为 Tier 1 10 美元、Tier 2/3 200 美元。它是项目级配额，不是 Prepay 余额，也不是账号月度上限。
先在登录后的 Rate Limits 查看真实命中项，再决定等待、降低请求频率、缩短上下文/输出或申请提额。完整重试与配额判断在 Gemini API 速率限制排查，不要用充值代替 429 诊断。
4. 数据还没同步
余额使用通常在几分钟内反映，层级变化一般约 10 分钟，费用图表可能落后 24 小时。付款完成后先核对交易与项目状态；不要因为一个图表没更新就重复购买或突然放大 cap。
一张表分清“提醒、上限、余额和配额”
| 看到的控制项 | 它真正控制什么 | 触发后的影响范围 | 不能把它当成什么 |
|---|---|---|---|
| Prepay 余额 | 结算账号的 Gemini API 可消费额度 | 余额为 0 时，全部关联项目停止 | 自动回到 Free 或完全零超额 |
| 自动充值月限额 | 系统自动购买额度的金额 | 达到后停止自动充值 | API 用量上限；手动购买不计入 |
| 项目支出上限 | 单个项目的月度支出 | 目标是在项目触及 cap 后暂停 | 实时、普遍可用的硬停机 |
| 账号月度上限 | 当前 Tier 下跨项目聚合的 Gemini 支出 | 相关项目一起暂停到新账期 | 每个项目各自独立的预算 |
| Cloud Billing 预算 | 选定 Cloud 范围的监控和阈值提醒 | 发送通知 | 默认自动停止 API |
| 支出速率限制 | 项目的 10 分钟滚动支出速度 | 返回 429 | 月度账号 cap 或余额归零 |
Cloud Billing Budgets 官方文档明确说明：Budget 本身不限制用量或费用。程序化通知可用于自动化，但可能延迟或重复；停用 billing 还可能影响其他资源，不能把它包装成无需测试的一键停机方案。
模型 token 单价又是独立合同，会随模型、上下文、缓存、Batch、工具和媒体单位变化。需要计算真实工作负载时查看 Gemini API 当前价格指南，不要拿账号上限反推模型单价。
现在应该做什么：按证据选择，不按名词猜
- 项目显示 Free：先确认所需模型、地区和活动限额是否仍适用；当前免费边界见 Gemini API 免费层级指南。
- 出现
设置结算或设置预付款：只处理目标项目和它关联的付款方，完成界面要求后再做一次低风险请求验证。 - 出现
无积分：核对正确结算账号、Prepay 设置、余额和赠金资格；不要假设会自动回 Free。 - 余额为正但账号暂停：依次查 Cloud 付款健康、账号月度上限、项目 cap、活动配额与同步延迟。
- 希望回到 Free：为目标项目明确解除关联或停用结算，再确认项目显示 Free，并重新检查模型、地区和活动限额；余额耗尽不会替你完成降级。
400 FAILED_PRECONDITION 可能表示请求地区不提供 Free，需要启用结算；403 PERMISSION_DENIED、500、503、504 有不同原因，没有匹配证据时不要归咎于计费层级。Google 还说明，失败的 400/500 请求不按 token 收费，但仍会占用配额。
最后只保留一条判断链：先过地区闸门，再用 Key 找到项目，用项目找到付款方，最后按登录态状态定位余额、账号或配额问题。这比按注册日期、Tier 名称或 Cloud 赠金金额猜结算状态更可靠。
