报错是这么冒出来的。用 16 个线程调 SiliconFlow 上的 Qwen2.5-72B，QPS 算下来不到 2，仍然大量返回 429，原文 Request rate increased too quickly，响应头里 x-ratelimit-remaining-requests 还显示几百。
中间走过弯路，把「瞬时突发被令牌桶判为超速」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。限制按并发而不是按分钟请求数。另一种情况是同一账号下多个 key 共享并发池。
另外，重试没有退避 把短时拥塞放大。
先把响应头里的限流字段打出来
curl -i -s https://api.siliconflow.cn/v1/chat/completions -H "Authorization: Bearer $SF_KEY" -H 'Content-Type: application/json' -d '{"model":"Qwen/Qwen2.5-72B-Instruct","messages":[{"role":"user","content":"hi"}]}' | Select-String -Pattern 'ratelimit'然后把并发降到 4 观察 429 比例
python load.py --concurrency 4 --seconds 60再往下加指数退避和随机抖动
python retry.py --backoff 1.5 --jitter 0.3需要更高并发时走工单提额
python -c "print('request quota raise instead of multi-key')"改之前先确认了最近有没有人动过配置，避免白查一遍。
恢复的判定其实很直接。并发 4 时 429 比例为零，P95 延迟稳定，响应头里的 remaining 缓慢下降而不是瞬间归零。
提醒一点。这类平台的 429 常常卡在并发窗口而非 RPM，只看 remaining-requests 会误判，得同时看并发和突发速率。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。