批量摘要任务走 RabbitMQ 3.13，消费者起了 8 个进程，每个进程 16 个协程，峰值瞬间 128 路并发打向模型接口，网关开始回 429 rate limit。队列积压涨到 1.2 万条，把并发压到 32 之后又慢得跑不完，一个晚上只处理了 4000 条。
一开始怀疑是「消费端没限制 prefetch，消息一次全推给单个进程」，查了一圈，方向不对。
把日志和配置对完，能解释这个现象的基本就这几处。并发数是进程数乘协程数算出来的，实际远超账号的 TPM。也可能是没有令牌桶，瞬时突发全部撞在限额上。
少数情况下是429 直接抛出没退避，消息重回队列造成重复消费。
上来先确认账号真实的 TPM 与 RPM 上限
curl -s https://gw.local/v1/limits -H "Authorization: Bearer $KEY" | jq .接着按单条平均 token 反推可持续并发
python -c "print(600000//1200)"给消费者设 prefetch 并用令牌桶控速
python worker.py --prefetch 4 --rate 20 --burst 5429 时按 Retry-After 退避并把失败落死信
python worker.py --retry-after-header --dlq dlq.jsonl恢复的判定其实很直接。队列积压在两小时内回落到零，429 比例低于 0.5%，每分钟处理条数稳定在限额的八成左右。
补一句。并发上限应该由 TPM 除以单条平均 token 推出来，凭感觉定进程数只会把限流问题拖成积压问题。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。