先把当时的情况摆出来。1.8 万条批处理跑到 92% 停了 40 分钟，日志里全是 429，前面 1.6 万条很快，最后一批正好撞上整点配额刷新，重试也没有间隔。
把日志和配置对完，能解释这个现象的基本就这几处。剩余小批次集中重试把令牌打空。也可能是重试没有退避，失败请求又占配额。
另外，进度按完成数算，看不出还在重试。少数情况下是并发没有随剩余量下调。
先看 429 在时间轴上的分布
python parse_log.py --log batch.log --pattern 429 --bucket 1m --out rate.csv给重试加指数退避和抖动
python retry.py --max 5 --base 2 --jitter 0.5 --respect-retry-after剩余量小于一千时把并发降下来
python batch.py --concurrency 4 --resume progress.json补齐失败条目并核对总数
python reconcile.py --input all.jsonl --done done.jsonl --retry failed.jsonl这台环境是别人交接的，不少默认值被动过，只能一项项核。
别只看报错消失，验证要多做一步。剩余条目在十分钟内补齐，429 数量降到个位数，最终结果条数与输入一致。
补一句。卡在九成是末尾小批次在硬重试，把退避和降并发补上，比直接扩容更有效。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。