接口本地跑得好好的，上线后突然报配额不足、请求被拒或者延迟飙升，这类问题多半不是代码写错了，而是踩到了用量限制的不同层级。这篇把 Google AI 接口的配额口径拆开讲：哪些限制按分钟算、哪些按天算、哪些跟账号和项目绑定，撞上之后按什么顺序排查、优先动哪一步。不给死数字，只给判断标准和可执行动作。
接口本地跑得好好的，上线后突然报配额不足、请求被拒或者延迟飙升，这类问题多半不是代码写错了，而是踩到了用量限制的不同层级。很多人第一反应是去改代码、换 key，结果折腾半天发现方向从一开始就偏了。
这篇把 Google AI 接口的配额口径拆开讲：哪些限制按分钟算、哪些按天算、哪些跟账号和项目绑定，撞上之后按什么顺序排查、优先动哪一步。不给死数字，只给判断标准和可执行动作，具体数值一律去站内页面按当时的口径核对。
用量限制分几层，别把它们混成一件事
很多开发者一说「超限」就以为是同一个东西，其实至少能拆成四层。不同层报的错不一样，影响的范围也不一样，处理方向更是南辕北辙。先把层次分清，后面才有得聊。
- 单次请求上限
- 一次调用里输入和输出各自的长度天花板，超了直接拒绝，跟频率无关
- 请求速率限制
- 单位时间能发多少次请求，看的是次数而不是内容大小
- token 吞吐限制
- 单位时间内累计消耗的 token 数，请求次数正常但内容很长时先撞这层
- 账号或项目总额度
- 绑定在账号或项目上的可用总量，用完就得等重置或走提额通道
账号级和项目级是两回事：同一个账号下开多个项目，额度一般不互相兜底，一个项目打满不代表另一个不能跑。反过来也一样，别指望某个项目富余就能匀给另一个。免费层与付费层的限制口径也不同，同一模型在两个层里的速率和额度往往不是简单倍数关系。
判断方法很朴素：把报错原文读一遍，看它说的是「太快」还是「没了」。前者要削峰和退避，后者要提额或换接入方式。搞混这一步，后面的动作全是白费。
在哪看自己到底用了多少、还剩多少
最常见的坑是只看结算页。结算页是钱的口径，用量页才是调用次数的口径，两者对不上很正常，因为失败请求、缓存命中、不同模型的计费方式都会让它们分叉。
- 优先在控制台的项目维度看用量统计，别只看账号总览，项目维度才能定位到具体业务
- 把用量页的统计周期和你的告警周期对齐，否则会出现「以为没超实际已超」的错觉
- 自建一份用量日志，至少记录时间戳、模型、输入输出 token 数、状态码，四样缺一不可
- 外部口径和本地日志对不上时，以本地日志定位哪一类请求在放大消耗，再回头核对外部统计
日志这块很多人偷懒只记成功请求，结果一限流就抓瞎。失败请求同样要记，因为部分错误在服务端已经开始处理，会占掉速率额度但不产生可用结果，不记就永远算不清真实消耗。
当期具体数字和口径入口会变，去官方 API 价格页和厂商目录页核对，不要照抄别人文章里的旧数值。站内一般会有整理好的对照入口，比自己翻文档快。
查当前口径价格与配额口径经常调整，动手前先核对当时的数字，避免按旧数值做容量规划→一次调用到底吃掉了哪些配额
搞清楚「吃配额」的路径，才能算出峰值时到底是谁先把额度打满。这件事比想象中反直觉：看起来请求数不多，实际消耗可能已经过半。
| 消耗来源 | 是否计数 | 容易忽略的点 |
|---|---|---|
| 输入 token | 通常计数 | 长上下文任务里输入侧往往是大头 |
| 输出 token | 通常计数 | 输出更慢也更贵，流式场景尤其明显 |
| 失败请求 | 部分计数 | 服务端已开始处理的错误会占速率额度 |
| 重试请求 | 全额计数 | 重试会成倍放大消耗，是限流后最危险的动作 |
流式返回和一次性返回，在速率限制上可能被算作不同的请求形态。压测时如果一种用流式、一种用非流式，得到的限流结论会完全不一样。要做容量评估，先把请求形态统一。
撞上限流之后的第一反应应该是退避，而不是立刻重发；重试是最快把临时限流变成持续限流的办法。
撞限额最常见的四种真实形态
限流不是一个孤立事件，背后往往对应某种固定的使用模式。认得出是哪一种，处理起来就有针对性。
- 突发流量批处理脚本一次性并发几百个请求，速率限制先于总额度被打满。特征是报错集中在几秒内，之后又恢复正常。
- 长任务堆积单个请求输入很长，token 吞吐先耗尽，但请求次数看起来还很正常。特征是按次数看没超，按 token 看已经爆了。
- 多实例叠加同一个 key 被多台机器共用，每台都觉得自己量很小，加起来就超了。特征是单机压测永远压不出问题。
- 共享账号一个项目下挂了好几个业务，谁也不知道是谁把额度用掉的那部分。特征是限流时间点跟任何一个业务的峰值都对不上。
这四种形态有时会叠加出现，比如多实例叠加加上突发流量，报错会显得毫无规律。排查时先按时间窗口把请求按实例、按业务拆开看，通常一眼就能看出是谁在放大。
撞限额后的排查顺序（照着走）
顺序很重要。先确认错误类型，再看影响面，然后算消耗速率，最后才决定动作。跳步去做优化，很容易优化错地方。
- 第一步确认错误类型：速率类还是额度类，这决定了后面所有动作的方向
- 第二步看影响面：只一个实例报错还是全项目报错，只在一个实例上出现多半是并发配置问题
- 第三步算消耗速率：拿最近的调用记录倒推峰值每分钟请求数和 token 数，跟你能申请到的上限对比
- 第四步再决定动作：削峰、排队、换更轻的模型、还是申请提额，先动最容易回滚的那一步
第三步的消耗速率最容易被跳过，但它恰恰是决定「能不能扛住」的关键。没有这个数字，你说不清是该扩额度还是该降并发，只能凭感觉调参数。
限流与超额的可执行处理动作
确认完层级和原因，接下来是具体动作。下面几条按投入从低到高排，建议从前面开始试。
| 动作 | 适用场景 | 验证方式 |
|---|---|---|
| 客户端队列加退避 | 突发流量 | 观察限流报错是否从集中变成零星 |
| 请求分通道 | 实时与批量混跑 | 看实时业务的延迟是否不再被批量任务拖累 |
| 长输入裁剪 | 长任务堆积 | 对比裁剪前后单次调用的 token 消耗 |
| 模型分级路由 | 多业务共用额度 | 检查低复杂度请求是否不再走最贵档位 |
| 预算告警加硬闸 | 共享账号 | 确认额度到阈值时非核心流量确实被停掉 |
退避策略要带抖动，否则所有实例会在同一时刻集体重试，把限流变成周期性雪崩。并发留出余量，具体留多少按你业务的延迟容忍度定，别把上限当成目标值去打。
告警阈值和硬闸比例属于业务决策，不是技术决策。核心链路和边缘链路的容忍度不一样，具体数值按业务能承受的损失来定，别照抄别人的配置。
哪些情况下这套处理不管用
上面那套方法针对的是用量型限制。有些情况报错长得像，但根因完全不同，硬套只会浪费时间。
- 限制来自账号层级的资质或地区可用性，而不是用量，那么调并发和削峰都没用，得走申请或换渠道
- 服务端整体故障时，报错看起来和限流很像，但退避只会让你等更久，先去服务状态页确认
- 业务本身要求固定低延迟时，排队和退避不适用，只能靠提额或换到限额更宽的接入方式
- 临时活动冲量，搭复杂调度系统不划算，手动临时提额加时间窗控制就够了
判断是不是服务端故障，有个简单办法：看同一时间其他模型、其他区域是不是也在报错。如果都报，那大概率不是你这边的问题。
把它变成团队例行动作
限流这件事，临时救火一次就够难受的了。把它变成例行动作，能省掉大部分深夜被告警叫醒的机会。
- 上线前对账预估峰值请求数和 token 数，跟你能拿到的上限做对比，差距写进上线检查清单，别口头说说。
- 每周看用量曲线重点看有没有非工作时段的异常调用，那通常是脚本泄漏或 key 外泄的信号。
- 配额和成本放同一张表单独的用量数字说明不了问题，得跟任务产出挂钩，才知道是浪费还是真需要。
- 固定查会变的信息额度重置、提额通道、当前限速数值这类会变的信息，固定去站内对应页面查，不要依赖记忆或聊天记录。
中转站的可信度也会影响你实际能拿到的配额和稳定性，选渠道前可以先去站内看看检测结果和价格追踪，别等上线了才发现对接方本身就不稳。
下一步想对比各家中转渠道的稳定性和当前价格口径，去站内信誉页看检测结果与追踪记录，再决定接哪条线→常见问题
Google AI 的用量限制是看请求次数还是看 token？
两套都看，而且是同时生效的。单位时间内的请求数管的是你发得多快，token 吞吐管的是你一次吃得多重。短请求密集的场景通常先撞请求数上限，长上下文场景往往先撞 token 上限，所以排查时得把两个指标一起看，只盯一个容易找不到真正的原因。
免费层和付费层的限制差别大吗？
口径不一样，但具体数值会调整，不要照抄别人文章里的旧数字。更稳的做法是去官方 API 价格和厂商目录页核对当期结构：付费层通常额度更高、也更稳定，但两者在请求速率和 token 吞吐上的倍率关系并不统一，需要分别确认。
被限流之后再重发，算不算重复消耗额度？
看错误发生的位置。如果请求已经在服务端开始处理才被拒，部分计数已经产生；如果是网关层直接挡回，一般不计入。稳妥做法是重试前先确认错误类型，并把重试次数和间隔写进日志，这样后面核对消耗时能对得上账。
多个项目共用一个账号，额度和限流会互相影响吗？
多数情况下项目和项目之间是分开统计的，但账号层面的约束可能共用。实际影响取决于限制绑定在哪一层。最省事的验证方法是看报错里提到的是账号还是项目，再去控制台按项目维度核对用量，不要凭感觉猜。
额度不够用是先提额还是先优化调用？
先做一次消耗测算再决定。把峰值请求数和单次平均 token 数倒推出来，如果发现大部分消耗来自重试、超长输入或不必要的重模型调用，那就先优化，能省下不少提额需求；如果调用方式已经很克制还是不够，那说明确实需要提额或换接入方式。
