Gemini 账单有结算延迟：长任务怎么就超出预算了
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
**Gemini API 的支出上限不是一道即时断路器，而是一道带延迟的闸门。**官方结算文档明确写了：结算流水线存在处理延迟，在这段延迟里可能产生超额用量；并且官方专门点名，批量模式与 Agent 这类长时间运行的任务，尤其容易在系统停止之前继续消耗。也就是说，你设了上限、系统也确实会执行，但从「实际用掉」到「系统看见并动手」中间隔着一段路，长任务恰好是最能在这段路上跑出距离的那类负载。所以看到账单高于预期时，第一步不是去改代码，而是先判断你看到的这个数到底属于哪一层：是已经确认结算的真实消耗，还是尚未刷新的展示值。这两者在 Gemini 的文档里是分开描述的，延迟量级也不一样。
先分清是「真的花了」还是「还没刷新」
官方在结算页里列出的延迟不止一条，而且每条的量级不同，混在一起看就会得出错误结论。
按官方的说法，结算流水线的处理延迟是分钟量级；赠金的扣减通常也在几分钟内完成；层级升级在成功付款之后同样是分钟量级。几项展示更新里滞后最久的是总费用明细图表，官方注明它的更新可能需要相当长的时间，量级是小时而不是分钟（具体时长以官方结算文档当前版本为准）。
这条差异直接决定了排查动作。如果你是在跑完一个大任务之后立刻去看费用图表，看到的数字偏低是正常的，因为图表还没追上；反过来，如果你已经停掉了所有调用、隔了足够久再看，数字仍然在涨，那说明还有没停干净的调用方在跑。把「图表没更新」当成「没花钱」，会让人在错误的时间点做出「还有预算，可以继续跑」的决定：图表那一档的更新量级是小时，而结算流水线那一档是分钟，两者读到的是同一批消耗的不同阶段。判断时要先问自己看的是哪一档，而不是把屏幕上的任意一个数字直接当成当前真实支出。
付款方向也有一段延迟需要单独看：官方说明银行卡付款多为即时到账，银行转账则可能需要若干天，而服务只有在点数购买被正式确认之后才会恢复或升级。这意味着你在余额告急时临时转账，恢复的时间点不由你按下汇款按钮的时刻决定。
长任务为什么正好撞在延迟上
官方点名的两类负载是批量模式与 Agent 这类长时间运行的任务，原因不难理解：它们的单次「作业」跨度远大于结算流水线的延迟窗口。
Batch API 在官方定位里就是异步处理大批量请求，按低于标准价计费（比例见官方定价页），官方给了一个目标周转时间，并说明多数情况会更快。它适合数据预处理、跑评估这类不需要立即响应的场景。但正因为它是异步的、一次提交一大批，从提交到系统真正把用量算清楚之间，你几乎没有中途干预的手感——你不是在一次次地按下按钮，而是交出去一整批之后等结果。
Agent 类任务的问题则在另一头：一次外部触发在内部可能展开成很多次模型调用。官方在接地（Grounding）计费上给了一个非常具体的例子——Google 搜索接地与 Google 地图接地是单独计费的，每月有一定的免费请求额度（数值见官方定价页），超出之后按请求数计费，而且官方特别注明：一次客户请求可能触发多次 Google 搜索查询，每次单独收费。你在自己这一侧数的是「一个用户提了一个问题」，账单那一侧数的可能是好几笔。放大倍数不在你的日志里，只在账单里。
如果你的成本模型是照着「请求数乘以单价」估出来的，这里就是它失真的地方。站内那篇API 成本监控怎么做讲的是跨厂商的通用监控骨架，Gemini 的特殊性在于要把这类隐含的请求放大也纳进去。
支出上限的两级作用域，和那个「实验性」标注
Gemini 的支出上限分两级，二者不等价：
- 结算账号级：按月生效，是主要的那一道。
- 项目级：官方标注为实验性，且适用范围有限；设置它需要项目的编辑者、所有者或管理员角色。
很多人默认「我给这个项目设了上限，这个项目就跑不飞」，但项目级那一档带着实验性标注，把它当作硬保障并不合适。更稳的思路是把预算隔离做在结构上——官方明确写了，层级、限流、账号上限都是在结算账号级别确定的，API 密钥没有独立的结算设置，它继承所属项目的层级与结算状态，而且一个项目内所有密钥的用量会合并计入。所以想让实验性负载不吃掉生产预算，靠多发几个密钥是无效的，得靠项目和结算账号的划分。
这里的两级作用域要分开读，否则容易读成自相矛盾：限流额度有多高，是在结算账号级别定下来的（层级、限流、账号上限都在这一级），而这份额度在使用时是按项目应用的，不是按 API 密钥应用的——同一个项目里的多个密钥共用同一份额度。详见Gemini 限流是按项目算的。换个结算账号，层级与限流会跟着新账号变；而在同一个结算账号内部拆项目，改变的是用量怎么聚合、额度落在谁头上。
还有一条搬迁时容易被忽略的细节：项目从一个结算账号迁到另一个时，支出上限的设置会保留，但累计支出会在新的结算周期里重置。上限还在，可计数器归零了，等于这个周期内你的可消耗空间被悄悄放大了一轮。做账号整理时如果没意识到这点，很容易在迁移当月看到一个反常的数字。
账单高于预期，先核这四个计费项
官方 FAQ 把计费依据列成四项：输入 token 数、输出 token 数、缓存的 token 数，以及缓存 token 的存储时长。第四项是与不少国产平台不同的结构性差异——缓存不只在命中时影响成本，它「存着」这件事本身也计入。长上下文场景下官方给出的主要优化手段正是上下文缓存，代价就是要为存储付费，用它换重复提问时输入成本的下降。
排查顺序上，建议按这几条挨个对：
- 思考 token 有没有算进来。官方定价页的表头明文写着输出价格包括思考 token。如果你在成本估算里只数了可见的回复文本，那这部分就是纯漏算。
- 服务档选对了没有。官方列了标准、批量（Batch）、Flex、优先级四种服务档，各自独立计价。同一个模型换一个档，成本结构就换了一套。
- 缓存的存储时长是不是没人管。缓存建了没清，存储那一项会持续记账。命中情况可以从响应对象的
usage.total_cached_tokens字段读，Python 与 JavaScript 都有。想知道怎么让隐式缓存真正命中，见Gemini 隐式缓存怎么命中。 - AI Studio 里的用量。官方写得很清楚：AI Studio 本身使用免费，但一旦在 AI Studio 中关联了付费 API 密钥，该密钥的 AI Studio 用量就开始计费。官方给的控制办法是在付费项目的密钥与免费项目的密钥之间切换。也就是说，在网页界面里反复调试提示词这件事本身并不天然免费，取决于当时选中的是哪一个密钥；核账单时这一项要单独想起来查，因为它不在你的代码调用日志里。
顺带一提，免费层与付费层的差别不只在钱上：官方说明免费层的内容会用于改进 Google 产品，付费层不会。选层时这是一个非价格的硬条件。
预付款账号：延迟会叠加成停机
如果你的结算方案是预付款，前面那些延迟的影响要重新分层来看。官方对预付款的描述是：先充值再用，费用近乎实时从余额扣除。所以余额这个数字并不属于前面说的「滞后一档」，滞后的是结算流水线与费用明细图表那一侧的展示。
预付款真正要盯的是停摆范围，而不是余额刷不刷新：官方写明，预付款余额归零时，该结算账号下所有项目的所有 API 密钥同时停止工作。停的不是某一个超支的项目，而是这个结算账号名下的全部密钥——一个跑飞的实验任务能把生产调用一起带停。再叠加上前面那条付款确认的时间差——服务只在点数购买被正式确认之后才恢复——余额见底之后能多快回到在线状态，并不完全由你决定。所以预付款账号的防线不该建在「快没钱了再充」上，而该建在自动充值与提前预留上。
几条相关的官方约定值得一并记住：预付款额度仅可用于 Gemini API 使用费，不能支付其他 Google Cloud 服务；购买的点数会过期且不可退款（切换账号类型除外），因非升级原因关闭预付费账号，剩余金额作废；若预付费账号有有效余额，系统会先用 Google Cloud 赠金再用预付款余额，余额归零后不再消耗赠金。预付款支持自动充值，并可以设置每月自动扣款的限额，但官方注明手动的一次性付款不计入该限额——把自动扣款限额当成月度总支出封顶，是另一处会失真的假设。
别把限流报错和超预算混为一谈
排查账单时会碰到一类容易误读的信号：Gemini 除了 RPM / TPM 那几个维度，还有一层基于支出的速率限制，按一个滚动窗口评估，是否适用取决于结算记录与账号状态，触发时返回 429 RESOURCE_EXHAUSTED。官方给的处置是等待后重试、降低高费用请求的速率（用更小的上下文窗口或更短的输出），持续触发就去申请提高限流。
这个 429 长得跟普通限流一样，但它的成因和你的花钱速度有关。值得留意的是官方处置里的第二条：除了等待后重试，官方还并列写了降低高费用请求的速率，并给了具体做法——用更小的上下文窗口或更短的输出。这半条是冲着成因去的，只调重试策略并不覆盖它。
还要提醒一句别搞混：官方错误码对照表里那两个 429，指的是 rate_limit_exceeded（分钟级请求或 token 限制，官方处置是等待加指数退避）与 quota_exceeded（每日配额耗尽，只能等重置或申请提额），处置完全不同；这里说的基于支出的速率限制是另一种成因。三者怎么对号入座，见Gemini 的两种 429。
收尾：把观测挪到自己这一侧
结论其实很朴素：既然官方那一侧的数字天然滞后，就别把预算防线全押在它身上。可以做的有三件事——用官方提供的 count_tokens 在发出请求之前先估一遍输入规模；在自己的调用层记录每次响应里的用量字段，包括缓存命中那一项；把长任务拆成有检查点的段落，让你有机会在中途停下来看一眼，而不是交出去一整批之后只能等。
回到开头那条：看到费用明细图表没涨就认为还有余量，于是又开了一批长任务。而官方在结算说明里明确写了结算流水线存在处理延迟、期间可能产生超额用量，并专门点名批量模式与 Agent 这类长时间运行的任务——等图表追上来的时候，那批任务早就跑完了。