google ai studio模型调用限制是多少

用 Google AI Studio 调模型，跑着跑着突然报限额或者干脆被拒，第一反应往往是「我是不是被限流了」，但限流到底按什么维度算、去哪个页面看真实额度，很多人没查过。这篇把限流的几个维度、自查配额的动作、以及批量和并发场景下怎么少踩坑讲清楚，数字和档位一律以站内官方页面当时的显示为准。

用 Google AI Studio 调模型，跑着跑着突然报限额或者干脆被拒，第一反应往往是「我是不是被限流了」。但限流到底按什么维度算、去哪个页面看真实额度，很多人其实没查过。同一个账号，有时候文本能跑、图像却被拒，或者昨天还行今天集体报错，原因多半就藏在限流口径上。

这篇不讲玄学，只讲三件事：限流卡在哪几层、配额去哪查、撞上之后按什么顺序处理。所有数字和档位一律以站内官方页面当时的显示为准，别背死数，口径是会变的。

限流不是只有一个数，先分清卡在哪一层

很多人以为限流就是一个「每秒能发几次」的数字，实际它更像一叠叠关卡，报错文案通常只会点出其中一层，你得自己判断卡的是哪道门。分不清层，改的地方就是错的。

• 账号或项目级的总量额度，多项目共用还是分开计量，会直接影响你能并行跑几个任务，动手前先在控制台确认计量粒度。
• 模型或方法级的每分钟请求数，不同模态可能分开算，文本、图像、音视频各占各的池子。
• 每分钟与每天的处理量，注意这层卡的是 token 不是次数，长 prompt 很容易先撞这堵墙。
• 并发或同时在飞的连接数，批量脚本最容易在这层翻车，因为请求几乎同时发出。

配额去哪看：三个查数入口和对应结论

限流这件事，最忌讳靠猜。至少要有一个能看的数，才知道自己是顶到上限还是偶发波动。下面三个入口分工不同，配合起来用。

1. 看控制台配额与用量页这是唯一权威来源，看的是「当前用量 / 上限」两个数。重点不是记住上限是多少，而是判断当前用量是不是已经贴着上限跑。
2. 记下完整报错响应响应头和状态码通常会带限流标识，把完整响应体存下来，比只记一句「报错了」有用得多，事后复盘全靠它。
3. 核对模型与计费口径具体数字和档位以页面当时显示为准，到 /official-api/providers/google 与 /ai-nav/category/ai-model-platform 对照模型规格与计费口径。
4. 先量一条链路基线拿不准是网络慢还是被限流时，用 /tools/speed-test 测一条基线延迟，别把网络抖动误判成限流。

撞上限流之后的处理顺序

撞限流之后，最怕的就是「不管三七二十一先加个重试」。处理顺序错了，不但没救回来，还可能把限流窗口拖得更长。下面这个顺序建议照着走。

• 第一步确认报错类型：配额用尽、速率超限还是并发挤占，三种原因的解法完全不同，改错地方等于白折腾。
• 第二步降速而不是硬重试：按固定间隔指数退避，给每次重试加抖动，避免多个任务在同一秒集体重试。
• 第三步做请求合并与缓存：把重复的同类请求合并成一次，对结果稳定的调用做本地缓存，能省掉相当一部分配额。
• 第四步才考虑多项目、多通道分流，这一步要留意平台条款，别为了绕限流做出违规操作。

工程侧的可执行清单

限流不是意外，是必然会遇到的状态。把它当成正常分支写进代码，比出事之后再打补丁省心得多。下面这份清单可以直接对着改。

• 把限流当成正常分支处理，而不是异常：代码里预留退避与排队逻辑，失败任务进队列稍后重投。
• 批量任务分批跑，控制同时在飞的请求数，宁可拉长总时长也别一次性打满。
• 日志里固定记录请求时间、模型名、tokens 用量与响应状态，方便事后判断是偶发还是稳定触发限流。
• 上线前做一次小规模压测，摸清自己这条链路的实际可用速率，再决定生产环境的并发配置。
• 给关键调用设置降级路径，比如切换到更轻的调用方式或稍后再试，避免单个限流把整条业务拖死。