刚把 DeepSeek 接入生产环境的那几天，测试一切正常。等到晚高峰用户一涌进来，日志里突然开始刷屏 HTTP 429。这不是你代码写错了，而是并发限制在起作用。
DeepSeek 的并发限制以账号为粒度计算，与用了几个 API Key 无关。不同模型的默认配额差距很大：deepseek-flash 给到 2500，而 deepseek-v4-pro 只有 500。对重度依赖 v4-pro 处理复杂任务的业务来说，这个数字触顶的速度可能比你预想的快。
这篇文章不讨论"限流好不好"，只解决一个工程问题：当并发限制真实存在时，代码怎么写才能不把 429 抛给用户。
一、先搞清楚：哪些行为会触发 429 官方文档写得很明确：一个请求从发出到模型响应完成，占用一个并发名额；超出账号配额，直接返回 429，不排队。这意味着你的请求封装层不能假设"发出去就一定成功"。
但 429 的成因不止一种，从实际排查经验看，常见情况大致分三类。第一类是高峰期集中报错、平时正常，这大概率是并发数触顶，优先动作是加信号量或队列削峰。第二类是持续调用一直报、不分时段，多见于批量任务，原因是 RPM/TPM 超限，需要加缓存、错峰或合并请求。第三类是偶尔报一次、重试后恢复，纯粹是缺乏退避重试机制，加指数退避和抖动即可。
前两类需要调整架构或申请扩容，第三类纯粹是代码健壮性问题。很多团队在第二类上翻车，是因为把"并发限制"和"频率限制"混为一谈——批量跑数据时并没有同时开几百个请求，但一分钟内砸了几百次调用，照样触发限流。
二、user_id 不是可选参数，是多租户场景的必需品 如果你只记住一个工程实践，那就是这个：为业务侧每个终端用户传入不同的 user_id。
官方给 user_id 定义了三层隔离能力：内容安全隔离、KVCache 隔离、调度隔离。前两个是合规和性能层面的收益，第三个直接关系到限流行为。
关键在于：对于申请了扩容的账号，DeepSeek 会同时做两层限制——账号总并发有上限，每个 user_id 的并发也有单独上限（deepseek-flash 2500，deepseek-v4-pro 500）。如果你把所有流量堆在同一个 user_id（或者干脆不传）下，即使账号总配额很高，单用户那层限制依然会卡住你。
设置方式很简单，但有个容易踩的坑。如果你用的是 OpenAI SDK，user_id 不能直接放在常规参数里，必须塞进 extra_body：
python response = client.chat.completions.create( model="deepseek-flash", messages=[{"role": "user", "content": "..."}], extra_body={"user_id": "tenant_abc_001"}, # 不能直接传 user_id ) user_id 的格式要求是 [a-zA-Z0-9-_]+，最长 512 字符，绝对不要塞邮箱或手机号，用内部 opaque 标识符就行。
三、429 重试：指数退避是底线，抖动是加分项 超限直接报错的设计，倒逼你的代码必须处理 429。最朴素的写法是 except 到 429 就 sleep 一下重试，但生产环境建议带上指数退避和抖动：
python import random import time
def call_with_retry(fn, max_retries=5): delay = 0.5 for attempt in range(max_retries): try: return fn() except RateLimitError: # 429 jitter = random.uniform(0, delay * 0.5) time.sleep(delay + jitter) delay = min(delay * 2, 16) # 上限 16 秒 raise MaxRetryExceeded("重试耗尽，建议降级或告警") 抖动的意义在于避免"惊群效应"：当一批请求同时被限流，如果所有客户端都按相同间隔重试，下一波又会同时撞上去。加上随机偏移，重试流量就被打散了。
另外，429 和 5xx 的重试策略应该分开。429 是你超了配额，退避后大概率能恢复；5xx 是服务端不稳定，需要更长的退避窗口，甚至触发降级开关。
四、两个容易被忽略的细节 请求保活机制。 请求发出后到推理开始前，服务器会保持连接。非流式请求持续返回空行，流式请求返回 SSE 注释 : keep-alive。如果你自己解析底层 HTTP 响应而不是用官方 SDK，需要确保解析器能正确跳过这些内容，否则可能在等待阶段就抛解析错误。10 分钟后仍未开始推理，连接会被关闭。
扩容免费，但别等到触顶才申请。 官方明确写了扩容"不增加额外费用"。这意味着并发限制更多是防滥用的保护机制，不是付费墙。如果你的业务曲线显示两周后 v4-pro 的峰值并发会逼近 500，现在就提工单，不要等用户开始投诉了再走流程。
五、回到工程本身 DeepSeek 这次把并发限制的规则摆得比较清楚：数字透明、扩容免费、user_id 的隔离逻辑也写明白了。对开发者来说，真正要做的只有三件事——代码里接住 429、业务里传对 user_id、架构上别把并发当无限资源来设计。
如果你现在还停留在"测试环境没问题就不管"的阶段，建议翻一下最近一周的日志，看看 429 的出现频率。它可能还没影响到用户，但已经在提醒你了。
常见问题（FAQ） Q：DeepSeek 并发限制是按 API Key 算还是按账号算？ 按账号。同一个账号下多个 API Key 共享总并发配额，扩容申请也作用于账号整体。
Q：deepseek-flash 和 deepseek-v4-pro 的默认并发分别是多少？ deepseek-flash 默认并发 2500，deepseek-v4-pro 默认并发 500。扩容后单 user_id 在 v4-pro 上仍有 500 的独立上限。
Q：超出并发限制会排队还是直接报错？ 直接返回 HTTP 429，不排队。所以请求封装层必须自带重试或削峰逻辑。
Q：不传 user_id 会怎样？ 流量会集中到默认隔离维度，多租户场景下容易先撞到单用户那层限制，同时也失去 KVCache 隔离和内容安全隔离的收益。
Q：扩容要付费吗？ 官方说明扩容不增加额外费用，走申请流程即可。
本文基于 DeepSeek 官方 API 文档（限速与隔离页）及实际接入经验整理。具体配额数字以官方最新文档为准。
关键词：DeepSeek API 并发限制、DeepSeek 429 错误、deepseek-v4-pro 并发、deepseek-flash 并发、DeepSeek user_id 隔离、API 限流重试、指数退避、DeepSeek API 扩容、大模型 API 限流、多租户 API 设计。