DeepSeek-V4.1-Flash 429 报错排查与解决

DeepSeek API 返回 429，官方定义是 Rate Limit Reached，也就是请求触发了速率限制。对 deepseek-flash（模型版本为 DeepSeek-V4.1-Flash）来说，最常见的触发点是账户维度的并发超过上限，而不是余额不足。

什么情况下会看到 429

先对号入座，下面三种场景最容易命中：

1. 批量脚本或并发 Agent 同时发请求，瞬时并发冲高。
2. 多用户共用一个账号，某个业务线突然放量。
3. 客户端失败后立刻重发，重试没有退避，自己把并发顶上去。

官方对 429 的说明很直接：原因是请求发得太快，建议合理安排请求节奏，并在必要时临时切换到其他大模型服务商的 API（官方举例为 OpenAI）。

原因一：账户并发超过上限

官方在限流与隔离文档给出的并发上限是：deepseek-flash 为 2500，deepseek-v4-pro 为 500。

计算口径有三个细节要知道：

1. 一个请求从发出到模型响应完成，算一个并发连接。
2. 并发按账户计算，跟你用哪个 API Key 无关。也就是说同一个账号下换 Key、新建 Key 都没用，大家共享同一个并发池。
3. 在并发上限之内的请求会得到响应，超过上限就会拿到 HTTP 429。

如果业务确实需要更高并发，官方提供了并发扩容申请入口，按实际业务需求匹配并发，并且扩容本身不额外收费。

原因二：某个 user_id 单独超限

如果你给请求传了 user_id，还要多查一层。官方说明 user_id 有三个作用：内容安全隔离、KVCache 隔离，以及调度隔离。

在限流计算上，规则分两类：

1. 普通 API 用户：所有 user_id 合并起来计算并发。
2. 已申请扩容的用户：账户总并发受限之外，每个 user_id 也会被单独限流，deepseek-flash 每个 user_id 为 2500，deepseek-v4-pro 为 500。某个 user_id 超限时，该 user_id 下的请求会返回 429。

参数约束也要注意：user_id 必须匹配 [a-zA-Z0-9\-_]+，最长 512 个字符，并且不要放用户隐私信息。

原因三：发送节奏太快

官方对 429 的定义就是发送请求太快，所以它和并发上限是叠加关系：即使平均并发不高，短时间内的突发也会触发。

典型写法是在 for 循环里同步调用接口，或者用固定的 time.sleep(0.1) 硬撑，一旦上游响应变慢，等待中的请求就会堆积成突发峰值。

解法：按原因逐条处理

1. 先统计业务侧的峰值并发，确认是否超过 2500 或 500 这两个上限。
2. 用并发池加队列限流，把同时在途的请求数压在账户上限之内，别让客户端无限并发。
3. 对 429 做指数退避重试，不要立即重发，这是最容易被忽略的一条。
4. 确实需要更高并发就提交官方扩容申请，扩容不额外收费，比堆小号更稳。
5. 多用户业务一定传独立的 user_id，避免单个用户把整个账号的并发吃满。
6. 任务允许错峰的话避开高峰时段。官方说明高峰时段为 UTC 周一至周五的 01:00 到 04:00 和 06:00 到 10:00，其余时间（含周末和中国法定节假日）都算非高峰。

一个最小可用的退避重试写法示例：

import time, random, requests

def call_with_backoff(payload, headers, max_retry=5):
    for i in range(max_retry):
        resp = requests.post("https://api.deepseek.com/chat/completions",
                             json=payload, headers=headers, timeout=60)
        if resp.status_code != 429:
            return resp
        time.sleep(min(2 ** i + random.random(), 30))
    return resp

别把 429 和这些错误搞混

DeepSeek 的错误码里，最容易和 429 混的是 402，两者处理方式完全不同：

一句话区分：看到 429 先查并发和节奏，看到 402 才去查余额。

官方口径与两个排查提醒

官方的错误码文档对 429 的口径是：请求过快，建议放慢节奏，必要时临时改用其他服务商 API。如果确认不是自己的调用问题，也可以先看官方状态页。

另外两个容易被误判成限流的现象也一并提醒：

1. 请求发出后可能长时间保持连接，非流式请求会持续返回空行，流式请求会持续返回 : keep-alive 注释，这不是限流，解析响应时要兼容。
2. 如果请求超过 10 分钟仍未开始推理，服务端会关闭连接。遇到长等待时，先确认是排队、限流还是任务本身太慢。