API · 2026-11-10

DeepSeek API 错误码排查手册 从 402 到 429 的应对

为什么现在聊错误码

DeepSeek API 侧最近有两个变化值得单独拎出来讲。Search 与 Fetch 接口从 11 月 1 日起计费，每 1000 次成功请求收费 5 元，余额不足的报错场景会相应变多。峰谷定价也在改变不少团队的调用曲线，请求量爬坡时撞上 402 与 429 的概率随之上升。于是我把官方文档目前列出的七个错误码整理成一份手册，附上一套可以直接抄走的重试逻辑。

七个错误码逐一对应

官方文档列出的七项是这么分的。400 是格式错误，请求体格式有问题，按错误信息里的提示修改即可。401 是认证失败，先检查 API key 是否传对。402 是余额不足，去控制台充值后重试。422 是参数错误，请求体参数没通过校验。429 是速率超限，降低并发或等待后重试。500 是服务器故障，可在己侧重试。503 则是服务器过载，服务暂时繁忙。

报错响应带着统一的 JSON 结构，error 字段里装着 message、type 与 code 三个值。三个都记进日志，后面排查会省很多事。还有一个容易踩的坑，生产环境里网关与代理可能插入自己的状态码，HTTP 状态和错误体要放在一起读，定位才准。

重试逻辑直接写在代码里

429 与 5xx 值得自动重试，用指数退避加随机抖动，免得所有请求在同一时刻扎堆回来。

import time, random

def with_retry(fn, max_tries=6):
    for i in range(max_tries):
        try:
            return fn()
        except (RateLimitError, ServerError):
            pause = min(60, (2 ** i) + random.random())
            time.sleep(pause)
    raise RuntimeError("retries exhausted")

两个细节要单独说。402 千万不要盲目重试，程序里加一道余额预检并在低水位时触发提醒，比反复撞接口实用得多。503 的重试间隔则要拉长，服务过载时密集重试只会让恢复更慢。

限流与计费的延伸阅读

限流数值与账号等级挂钩，本站有专文讲生产环境中的 DeepSeek API 限流，覆盖并发与配额的处理思路。模型名、峰谷定价与并发限额速查见deepseek-flash 与 deepseek-v4-pro 接入速查。若你在用 11 月起计费的搜索接口，Search 与 Fetch API 指南里有端点与计费细节。本文内容选自网上公开资料。