这类问题我又碰上了一次。本地调试一天后被 429 拦住，错误体写 quota exceeded for quota metric generate_content_free_tier_requests，控制台看不到实时用量。
第一反应是「失败请求也计入调用次数，重试进一步恶化」，验证下来不成立。
排查方向其实有限，先把可能性排一排。免费层按模型和地区分别计算每分钟与每天上限；并发请求会瞬时打满每分钟配额；同一个项目开了多个 key，配额其实是共享的。
上来先把错误体里的 metric 名打出来定位是哪条配额
python -c "import json;d=json.load(open('err.json'));print(d['error']['details'])"请求之间加间隔并退避重试
python -c "import time;time.sleep(4);print('throttled')"末了把批量调用改成带队列的串行
python run_queue.py --qps 0.5 --max-retries 3那几天正好在做别的变更，先把时间线对齐才敢动手。
怎么算真的好了，看的是同一批现象。批量任务连续跑完不再出现 429，错误体里的 quota metric 不再触发，日志中每分钟调用数低于上限。
免费层的额度更适合验证链路，不适合压测，用它评估吞吐会得到完全错误的容量结论。这类问题最好一次改到位，反复小改反而容易把原因搅混。