当客服系统每分钟200次Gemini调用频现429错误或摘要任务因TPM耗尽中断，表明触达Google Cloud项目级RPM/TPM硬配额；免费层默认RPM=60、TPM=32,000且独立计算，超限即拒，需通过Console配额页确认用量、用curl最小化复现、查Retry-After头，并实施带jitter的指数退避（最多3次）、压缩请求内容降TPM、提交具体业务场景的配额提升申请。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你的客服系统每分钟发起200次Gemini API调用却频繁收到429错误，或文档摘要任务因TPM耗尽而卡在中途，说明你已撞上Google Cloud项目级的硬性配额墙——这不是代码缺陷，而是资源调度规则在生效。
确认当前RPM/TPM使用量与硬上限
登录 Google Cloud Console → 进入目标项目 → 点击左侧菜单“API和服务” → 选择“配额”页面。
在顶部服务筛选框中输入 generativeai.googleapis.com，确保选中该服务；在下方指标列表中定位两行关键配额：Requests per minute per project（RPM）和Tokens per minute per project（TPM）。
注意：免费层默认 RPM 为60、TPM为32,000，且这两个值独立计算。哪怕你只发1个超长请求消耗了30,000 token，这一分钟内其余请求仍会因TPM超限被拒，与RPM是否用完无关。
快速验证是否为429限流而非权限或参数错误
方法一：检查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”。
