Gemini API速率限制与配额提升：高并发请求超限与报错解决方案

当你的客服系统每分钟向Gemini API发起200次调用却反复收到429错误，或是文档摘要任务因TPM耗尽而突然中断，基本可以断定：你触发了Google Cloud项目级的硬配额限制。这不是代码逻辑问题，而是资源调度规则在发挥作用。

先说一个诊断方法。最直接的操作是登录Google Cloud Console，进入目标项目，在左侧菜单选择“API和服务”，然后进入“配额”页面。

在顶部的服务筛选框中输入 generativeai.googleapis.com 并选中该服务，下方的指标列表会显示两条关键配额：Requests per minute per project（RPM）和Tokens per minute per project（TPM）。注意，免费层的默认RPM为60、TPM为32,000，且这两个指标相互独立。举例来说，即使你只发送了一个超长请求消耗了30,000 token，这一分钟内剩余的请求仍会因TPM超限而被拒绝——这与RPM是否用完无关。

接下来，快速验证这是否属于限流问题。先看HTTP状态码——只有返回429时才需要进入限流排查路径；如果是400、403或404，则应立即修正请求体、密钥权限或模型名，重试无效。也可以用curl做一次最小化复现： curl -H "Authorization: Bearer YOUR_API_KEY" "https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=YOUR_API_KEY" -d '{"contents":[{"parts":[{"text":"hi"}]}]}' 如果连这个最简单的请求都返回429，基本可以排除输入内容的问题。另外别忘了检查响应头中的Retry-After字段。有这个字段就是明确的限流信号，数值单位为秒，必须严格执行；如果没有该字段但持续出现429，多半是TPM被耗尽，或者配额已被静默冻结。

确认是限流问题后，就该实施指数退避重试机制了。首先，在客户端初始化HTTP client时，显式设置总超时为75秒（文本类设35秒，多模态设75秒），并禁用无限等待。捕获429响应后不要立刻重试，而是按这个公式计算等待时间：【wait_time = min(60, base_delay * (2 ** attempt)) + jitter】。其中base_delay取1秒，jitter为0到1秒之间的随机值，attempt从0开始计数。单次重试最多执行3轮，第3轮失败后直接抛出异常并记录原始请求上下文——这样可以避免雪崩式重试挤占其他正常请求的额度。实现起来很简单，把退避逻辑封装成公共函数即可复用；但必须加jitter，否则所有实例在同一毫秒发起重试，反而会加剧拥塞。

还有一个容易被忽略的技巧：压缩请求内容以降低TPM占用。对于长文档摘要类请求，发送前先做预处理——移除连续空行、合并重复段落、将表格转化为简洁的描述性句式，这样可使token数下降30%到60%。图像类请求务必使用WebP格式，并将分辨率压缩到1024px短边，Base64编码前先用gzip压缩二进制流——实测可减少45%的传输token。另外，不要在prompt中堆砌示例模板。Gemini 1.5系列对few-shot提示的敏感度已经下降，保留1个高质量示例足矣；多余的示例不仅消耗token，还可能干扰输出稳定性。

如果以上方法都试过后仍然不够用，就需要提交配额提升申请。进入Google Cloud Console → 对应项目 → “API和服务” → “配额” → 点击RPM或TPM配额行右侧的铅笔图标 → 填写提升理由。这里有个关键点：新创建的项目默认无法当日获批，审核周期通常为1到3个工作日。如果业务上线时间紧迫，建议同步启用降级策略（比如切换回本地小模型兜底）。申请时避免使用“测试需要”“未来可能增长”这类模糊表述，正确写法应为：“电商大促期间客服机器人QPS峰值达到180，当前RPM 60导致37%的请求失败，申请提升至300”。

来源：互联网