用 glm-4-flash 起 8 个协程并发跑问答，陆续返回 1302，原文是您当前并发量过高，请稍后再试，单个请求单独跑又完全正常，换成 glm-4-air 也一样。
一开始怀疑是「每次请求都新建连接，握手开销让瞬时并发更高」，查了一圈，方向不对。
原因不止一个，得分开看。免费档的并发上限很低，8 个协程已经超了。少数情况下是限流按账号维度统计，多个 key 也共用额度。
另外，异步任务里没等响应就发起下一条，队列越堆越长。
动手时先用信号量把并发限制在账号允许的档位
async with asyncio.Semaphore(2): await call_glm(prompt)然后确认接口地址与鉴权头没写错
curl https://open.bigmodel.cn/api/paas/v4/chat/completions -H "Authorization: Bearer $ZHIPU_KEY" -d '{"model":"glm-4-flash","messages":[{"role":"user","content":"hi"}]}'复用长连接并加一次轻量重试
client = httpx.AsyncClient(http2=True, timeout=60)剩下的就是记录每分钟成功与 1302 的比例
print({'ok': ok, 'limit': limited})恢复的判定其实很直接。并发跑完没有 1302，错误日志里只剩正常业务返回，吞吐比原来稳定，平均响应时间略有下降。
1302 和 1305 都会提示请求过多，前者是并发超限后者是频率超限，处理手段一个降并发一个降速率，看错就会白改。报错文案容易误导，真正的原因往往在相邻那一层的日志里。