问题出现得很突然，日志倒是留得挺全。DashScope 上 qwen-plus 给四个业务各发了一个子 key，每个业务配 5 路并发，晚高峰全部返回 429 Throttled by concurrency limit，控制台里单个业务显示的并发明明是 5。
刚开始盯着「429 之后立刻重试，瞬时并发被进一步推高」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。并发配额按主账号汇总，子 key 不单独计量。还有一种是四个业务的上限相加超过了主账号配额。
少数情况下是没有排队层，所有请求直接怼到接口。
动手时先查主账号当前的并发配额
curl -s https://dashscope.aliyuncs.com/api/v1/quotas -H "Authorization: Bearer $DASHSCOPE_KEY"随后抓一次 429 的响应头确认是哪类限制
curl -s -D - -o /dev/null https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions -H "Authorization: Bearer $DASHSCOPE_KEY" -H 'Content-Type: application/json' -d @req.json然后在网关层按业务分配固定信号量
python -c "import asyncio;sem=asyncio.Semaphore(3);print(sem)"剩下的就是把四个业务的峰时错开十分钟再观察
python -c "print('stagger schedule 00/10/20/30')"改完先别撤，确认这几项。四个业务各自压到 3 路后 429 归零，主账号总并发稳定在配额以内，错峰后晚高峰的 P99 从 12 秒降到 4 秒。
云厂商的并发配额基本都挂在主账号上，子 key 只是权限隔离，做容量规划时要按总和算而不是按单个业务算。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。