现场是这样的。GLM-4-Flash 免费额度上做压测，返回 1305，原文 当前并发数过高，同一时间日志里 1302 也在报，两个码混在一起，不知道该降并发还是降请求频率。
中间走过弯路，把「SDK 默认重试把并发推得更高」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。1302 是账户级限流 1305 是模型级并发；免费档的并发上限只有个位数；多个服务共用同一份 key 没有汇总。
先按错误码分组统计占比
python -c "import collections;print(collections.Counter(['1302','1305','1302']))"单并发跑三十秒拿基线
python bench.py --concurrency 1 --model glm-4-flash随后逐级加并发找拐点
python bench.py --concurrency 4 --model glm-4-flash剩下的就是在网关统一排队把并发锁在上限内
python -c "print('use semaphore at gateway')"恢复的判定其实很直接。拐点以下并发不再出现 1305，1302 也清零，日志里两个码的计数都归零。
这里还有个坑。同厂不同错误码对应不同限流维度，压测要按码分组，否则只看到一片限流却不知道该调哪个参数。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。