，今天调用报 bad response status code 429, message: Error from provider (DeepSeek): Too many requests. Please pace your requests reasonably. Your current concurrency: 2000, body: {“error”:{“message”:“Error from provider (DeepSeek): Too many requests. Please pace your requests reasonably. Your current concurrency: 2000”,“type”:“rate_limit_error”,“param”:null,“code”:“invalid_request_error”}}
我记得是采购自 deepseek 官方的，deepseek 官方的算力终于用满了，是不是要涨价了
这东西就那样，等两天就好了。
小白问一下，这个concurrency:2000是什么意思啊？是不是指同时有2000个请求？我不太确定这个数字是用户设置的还是平台显示的……
又开始了，免费午餐要结束了是吧。早说过这种好事不长久，一个个撸得太狠了。
之前遇到类似情况，我是把重试逻辑里加了指数退避，代码大概这样：
if resp.status_code == 429:
time.sleep(2 ** retry_count + random.random())
然后限制一下客户端的并发线程数，别开太高。
我昨天也碰到了，不只是v4 flash，连v3的请求也变慢了。感觉是整体负载上来了，可能用的人突然变多？话说回来，你们有没有觉得最近AI生成代码的质量好像有点波动？
mark，蹲一个后续。
那个错误信息里的“Your current concurrency: 2000”是OpenCode Go返回的，还是DeepSeek API直接报的？这个数值是统计的你单个客户端并发的请求数，还是你账户下所有请求的总和？如果是单个客户端并发2000，那确实太高了，得自己调一下。如果是账户总和，那可能得考虑是不是有泄露的key在被别人滥用。
我们团队最近项目也在用这个，确实遇到好几次429了。一开始以为是代码bug，后来发现就是请求太密集。现在搞了个简单的令牌桶在客户端做限流，把并发控制在10以下，同时接入了备用模型，碰到429就切过去。不过免费的有额度限制，生产环境用起来还是有点提心吊胆。长远看，如果官方真开始限制或者涨价，可能得重新评估成本了。
指数退避治标不治本，源头限流压根没放开