deepseek 并发 限制

本地测一个人用着很顺，一上批量任务或者多人共用就开始排队、超时、报限流，这是接 DeepSeek 时最常见的落差。问题往往不在模型本身，而在账号档位、请求节奏和你的调用方式。这篇按「先确认是不是限流、再决定加并发还是改节奏」的顺序，给一套能照着做的排查与调优清单，并说明哪些场景下这些做法不适用。

本地测一个人用着很顺，一上批量任务或者多人共用就开始排队、超时、报限流，这是接 DeepSeek 时最常见的落差。问题往往不在模型本身，而在账号档位、请求节奏和你的调用方式。先别急着怀疑模型慢，多半是你这一侧触发了上游的保护机制。

这篇按「先确认是不是限流、再决定加并发还是改节奏」的顺序，给一套能照着做的排查与调优清单。数字类的东西一律以站内当天的口径为准，别拿别处的截图当结论。

先搞清楚是什么在限你

很多人一遇到限流就去搜「api并发限制多少」，但这个问题没有统一答案。你得先分清是哪一层在拦你，否则调参就是瞎试。不同层的表现差异很大，认错了方向会白折腾很久。

• 账号档位、是否实名、走官方直连还是中转，都会改变实际能拿到的并发，具体数字到 /price-watch 核对当时的说明
• 同一把 Key 被多个服务或多个进程共用，是最常见的「莫名限流」来源，先确认没有别人在偷偷用
• 如果你用了自建网关或 SDK 的连接池，先排除是自己这层在排队，别一上来就怪上游

排查顺序：先量再调

调优之前先拿数据。没有基线的加压都是猜，猜出来的参数换台机器就不成立了。下面这套顺序按「由小到大、由单到多」推进，每一步都要留记录。

1. 量基线用单并发、单请求跑通，记下延迟与成功率；再去 /tools/speed-test 对一下自己网络这一层有没有拖后腿。
2. 阶梯加压从 2、4、8 逐档往上加，记录哪一档开始出现超时或限流返回，那一档就是你的实际可用区间。
3. 看返回体区分「请求被拒」和「请求被接受但排队很久」，前者要降速，后者要调超时与重试。
4. 留记录把每档的并发数、成功率、平均延迟记成一张表，后面调参和提额申请都用得上。

如果你的中转线路本身在限流，加压只会让失败率更高。走中转的话，建议先到 /sites 对照各家的可信度检测结果，确认线路是否适合高并发场景。

想提吞吐，能动的几个旋钮

确认是自己这侧节奏问题之后，再考虑提吞吐。顺序上，减少请求数通常比提高并发数收益更大，也更稳。下面这几项按性价比从高到低排。

• 优先做请求合并与批处理：能一次问完的别拆成十次，减少请求数的收益通常大于调并发数
• 把并发做成有限队列而不是无脑 for 循环，队列长度按实测可用区间设置，宁可慢一点也别触发大面积失败
• 控制上下文长度与输出长度，长上下文会让单次占用时间变长，间接压低你能跑的实际并发
• 对失败请求做指数退避加随机抖动，避免所有请求同一时刻重试造成二次拥堵

队列长度和退避参数没有通用值，取决于你实测出来的可用区间。一个务实的起点是把队列上限设成「阶梯加压时最后没报错的那一档」，跑一天看失败率再微调。

# 伪代码：有限队列 + 指数退避 + 抖动（参数按实测填，别抄死数字）
worker_n = 4           # 来自阶梯测试的可安全并发
base, cap = 0.5, 8.0   # 退避起点与上限，跑完再调
for req in task_queue:
    for attempt in range(5):
        resp = call(req)
        if not is_rate_limited(resp):
            break
        sleep(min(cap, base * 2 ** attempt) + random() * 0.3)

如果你需要横向对比不同线路或不同方案在高并发下的表现，可以到 /rankings 看当时的整理结果，再决定值不值得换线或提额。

这些做法什么时候不适用

上面这套是给「批量任务、后台处理、能容忍排队」的场景准备的。有几类情况套上去反而更糟，需要换个思路。

• 实时对话类场景不适合排队缓冲，用户等不了，这时该做的是降级到更轻的模型或减少上下文，而不是硬扛并发
• 合规或数据隔离要求高的业务，不能靠多账号拼池子来解决并发，得走正式提额流程
• 如果限制来自你自建网关的连接池或超时配置，调大上游并发没用，要回头看自己那层的参数

先量出你的可用区间，再决定是加并发还是改节奏——顺序反了，怎么调都别扭。