DeepSeek并发能力非固定值，取决于部署方式、模型类型及资源策略；requests.post()并发报“服务器繁忙”是同步阻塞与服务端限流叠加所致，需显式配置连接池并改用异步调用。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 的并发请求能力不是固定值，它取决于你用的是什么部署方式、哪类模型、以及后端资源分配策略——直接看文档写的“支持 2000 QPS”没意义，真实场景下可能连 200 都卡住。
为什么 requests.post() 一并发就报「服务器繁忙」
这不是网络问题，是客户端同步阻塞 + 服务端限流双重叠加的结果。同步调用会把线程/连接占着不放，直到响应返回或超时；而 DeepSeek 默认对每个 IP 或 API Key 实施并发连接数限制（比如最多 10 个活跃连接），一旦超出，新请求立刻被拒绝或排队，超时后返回 503 Service Unavailable 或 429 Too Many Requests。
- 典型现象：发 50 个
requests.post()并发，前 10 个能进，剩下全卡在 connect 或直接 503 - 根本原因：
requests默认使用urllib3连接池，但未配置max_connections和pool_maxsize，导致底层复用混乱 - 正确做法：显式控制连接池大小，并搭配异步调用（如
aiohttp）避免线程阻塞
deepseek-r1 本地部署的并发上限怎么测
本地跑 deepseek-r1 时，并发能力由 GPU 显存 + 批处理（batch_size）+ KV Cache 管理共同决定，不是简单加线程就能堆高吞吐。
One API key for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- RTX 4090（24GB 显存）上实测：FP16 推理，
batch_size=4时平均延迟 85ms，QPS ≈ 47；升到batch_size=8，延迟跳到 142ms，QPS 反而降到 56 —— 因为显存带宽成为瓶颈 - 关键参数：必须设
max_batch_size和max_seq_len，否则动态批处理可能把长文本和短文本混在一起，导致显存碎片化、OOM - 容易踩的坑：用 HuggingFace
pipeline直接跑并发，它默认不共享 tokenizer 缓存和 KV cache，每请求都重建，吞吐暴跌 60%+
如何判断是服务端限流还是自己调用姿势错了
先看响应头和状态码，再查日志，别猜。
- 返回
429且响应头含Retry-After: 1→ 明确是服务端 QPS 限流，不是你代码写错 - 返回
503且无Retry-After→ 大概率是并发连接数超限，或后端数据库/预处理服务挂了 - 响应时间 > 10s 且偶尔成功 → 不是限流，是资源竞争（比如多个请求争同一块 GPU 显存，触发抢占调度）
- 本地
curl -v测单请求延迟正常，但压测时大量超时 → 客户端连接池或 DNS 解析成了瓶颈，不是 DeepSeek 的问题
真正难调的从来不是并发数字本身，而是显存分配策略、KV Cache 生命周期、以及 tokenization 和 decoding 之间的节奏是否对齐——这三个地方出一点偏差，QPS 就断崖下跌，而且错误表现和限流一模一样。
