Understanding DeepSeek API Rate Limits in Production

您已连接`deepseek-v4-flash`，烟雾测试通过，但第一次实际批次因HTTP 429错误而崩溃。这是大多数团队发现DeepSeek API速率限制不是一个固定的数字表，而是一个随着服务器负载和账户突发行为动态调整的并发控制机制的时刻。没有发布的“10 RPM，200K TPM”等级卡。唯一记录的行为是API在需要时进行节流，并通过429错误信号，有时在长时间保持连接等待后。

本指南将介绍DeepSeek实际记录的内容，网络层面的情况，以及保持V4流量畅通的生产模式。

DeepSeek实际记录的关于速率限制的内容

DeepSeek官方的速率限制页面异常简短，这种简洁正是其目的所在。 根据DeepSeek API文档，API根据服务器负载动态限制用户并发，一旦达到限制即返回HTTP 429错误，请求被接受后可能需要一些时间才能响应。没有发布的每分钟请求配额，没有每分钟令牌表，也没有您可以购买的超越的分层计划。

常见问题解答部分回答了显而易见的下一个问题。目前DeepSeek不支持提高单个账户的动态速率限制，并且有一个统一的定价标准，没有分层计划。在实践中，这意味着对于在生产环境中运行DeepSeek V4的任何人来说有两件事：

• 限制值在变动。 有效上限取决于您请求到达时的全局流量。非高峰时段与高峰时段的行为非常不同。
• 您无法付费跳过队列。 花费更多，同样的动态逻辑仍然适用。在限制范围内进行工程化是唯一你能控制的杠杆。

这是一个故意的权衡。正如Simon Willison 在2025年1月首次提出该政策时所指出的，一个灵活的容量限制允许团队在平静时段内并行发送数百个请求，这在大规模数据处理中正变得越来越具有竞争力，但另一方面，你没有一个明确的上限来作为规划依据。

当前API接口：V4、旧版ID以及429错误来源

速率限制适用于整个DeepSeek V4系列，其中 于2026年4月24日发布. V4以两个开放重量的专家混合模型发布，这两个模型都通过相同的OpenAI兼容端点访问：

• deepseek-v4-pro — 前沿级别，总参数量1.6T / 活跃参数量49B。
• deepseek-v4-flash — 性价比级别，总参数量284B / 活跃参数量13B。

思考模式是任一模型上的一个请求参数，不是一个独立的模型ID。设置为最大努力推理。响应将返回。 reasoning_effort="high" with extra_body={"thinking": {"type": "enabled"}}, or reasoning_effort="max" 。默认启用思考模式；传递以禁用思考。 reasoning_content alongside the final content以启用思考。 extra_body={"thinking": {"type": "disabled"}} 以禁用思考。

如果您维护旧版集成：遗留的 deepseek-chat and deepseek-reasoner ID仍然有效，目前路由到 deepseek-v4-flash in non-thinking and thinking modes respectively (these are the only legacy IDs in the retirement notice; DeepSeek 编码器 不是一个当前托管端点）。它们是 在 2026-07-24 15:59 UTC 完全退役。在此日期之后，使用这些 ID 的请求将失败。迁移只需一行 model= swap; base_url 并不会改变。对于更广泛的迁移剧本，请参阅我们的 DeepSeek API documentation overview.

快速入门：尊重动态限制的请求

Chat requests hit POST /chat/completions，OpenAI兼容端点。最小可行的Python调用使用DeepSeek的基础URL和OpenAI SDK：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.deepseek.com",
    api_key="YOUR_DEEPSEEK_KEY",
)

resp = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "You are a precise assistant."},
        {"role": "user",   "content": "Summarise this changelog in 3 bullets."},
    ],
    max_tokens=512,
    temperature=1.3,
    timeout=120,  # generous read timeout — see keep-alive notes below
)
print(resp.choices[0].message.content)

相当的 curl 调用遵循相同的模式： POST to https://api.deepseek.com/chat/completions 使用Bearer令牌。DeepSeek还针对相同的基URL发布了一个Anthropic兼容的接口，因此Anthropic SDK通过交换 base_url and api_key。无论哪种方式，速率限制行为都是相同的。如果您仍在配置密钥，请参阅我们关于如何获取 DeepSeek API 密钥的 指南，该指南通过控制台进行说明。 最让大多数团队感到意外的是，不是 429 错误本身——而是在

在底层感受到的“动态并发”是什么样子

发生在 429 错误之前 before 429状态码。当你的请求等待被调度时，DeepSeek会保持TCP连接活跃而不是断开。对于非流式请求，服务器在等待请求被调度时返回空行；对于流式请求，它返回SSE保持活跃的注释（: 保持连接),并且自行解析HTTP响应的客户必须适当地处理这些空行或注释。

值得设计的两个后果：

1. 长尾延迟是真实存在的。 在高峰时段，“成功”的请求可能仍然在队列中等待了数分钟。设置宽泛的读取超时，并确保您的反向代理、无服务器运行时或API网关不会提前切断连接。
2. 如果在约10分钟后推理尚未开始，服务器将关闭连接。 将此视为单个正在进行的请求的实用上限，并据此设计您的重试逻辑。

触发429错误的是什么

官方原因是并发，而不是原始请求量。实践中常见的触发因素包括在短时间内发送请求爆发、单个IP/单个密钥集中、忽略提示以及并发进行的请求超过了当时动态限制允许的数量。第三方描述与文档一致：DeepSeek不设置固定的严格上限，但如果服务负载较重或某个账户发出的调用数量异常高，系统可能会标记并限制它，因此一次性爆发过多仍然会触发429错误。 重试时间 一个简单的心理模型：将限制想象成一个令牌桶，平台的填充速率会实时调整。您很少会在单个顺序客户端上达到这个限制。您会在第一次通过没有控制器的线程池分发200个并行调用时达到这个限制。

A simple mental model: think of the limit as a token bucket whose refill rate the platform adjusts in real time. You will rarely hit it on a single sequential client. You will hit it the first time you fan out 200 parallel calls through a thread pool with no governor.

能够应对429错误的实际生产模式

由于没有具体的数字来制定计划，唯一可持续的方法是让你的客户表现得更好。四种模式涵盖了绝大多数的实际工作负载。

1. 带抖动的指数退避

429状态码上的标准重试循环是指数退避：等待，重试，每次后续失败时将等待时间加倍，并添加一个小的随机偏移（抖动），以防止同步客户端同时重试。一个可行的Python实现：

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.deepseek.com", api_key="...")

def call_with_backoff(messages, max_retries=6):
    delay = 1.0
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model="deepseek-v4-flash",
                messages=messages,
                max_tokens=512,
            )
        except RateLimitError:
            if attempt == max_retries - 1:
                raise
            sleep_for = delay + random.uniform(0, delay * 0.5)
            time.sleep(sleep_for)
            delay *= 2

限制最大延迟（60-120秒是合理的）和重试次数。这种模式符合DeepSeek对短暂429/5xx类别的自身指导，并且是大多数具有内置指数退避支持的API客户端库中的默认推荐。

2. 有界并发池

退避本身是反应性的。主动的伴随措施是一个信号量，它限制了您一次可以有多少个请求正在飞行。从8-16个并发请求开始，监控429的比率，并据此调整。这比调整RPM更有效，因为DeepSeek强制执行的限制一开始就是针对并发性的。

3. 针对持续失败的断路器

当滚动一分钟内25-30%的调用返回429或5xx时，停止发送以进行冷却窗口（30-120秒），然后发送一到两个测试请求。只有当测试请求成功时才恢复全部流量。这可以防止DeepSeek事件期间的重试风暴，并防止您的队列填满。一个有益的副作用：一个横幅说“API正在限流：我们将很快恢复”是诚实的用户体验，远比一个假装有进展的旋转器要好。

4. 不仅减少速率，还要减少工作量

你没有发送的每个令牌都是你无法被节流的令牌。有两个使用点：

• 上下文缓存。 重复的系统提示将自动降至缓存命中价格层。将此与 DeepSeek context caching 结构化提示的指南相结合，以便缓存实际上能够命中。
• 流式传输。 流式传输不会提高限制，但它能更快地将有用的令牌传递给用户，这意味着您通常可以在更少的总往返次数内完成工作。 DeepSeek API streaming 指南涵盖了SSE形状。

值得了解的头部和参数

V4中与速率限制行为交互的参数简要说明。V4各等级默认值为：代码/数学为0.0，聊天/翻译为1.3，创意写作为1.5——DeepSeek官方指南。 100万个令牌的上下文窗口 输出高达 384,000 tokens，因此你遇到的大部分“限制”将是并发性，而不是大小。

文档暗示但并不总是明确声明的两点注意事项。首先，该API是 无状态 ——客户端必须在每个请求中重新发送完整的对话历史，与保持会话状态的网页聊天不同。其次，FIM（中间填充）补全处于Beta测试阶段，仅在非思考模式下工作。

速率限制与成本交互的示例

限流不仅仅是延迟问题——它还决定了如何设置预算的大小。下面的数学计算使用了 deepseek-v4-flash 按照DeepSeek定价页面发布的费率（请在 官方定价页面 查证，截至2026年4月；欲深入了解，请参阅我们的 DeepSeek API pricing 指南）。

场景：每月100万次调用，使用2000个token的系统提示（首次调用后缓存），200个token的用户消息（每次调用不缓存），以及300个token的响应。

在 deepseek-v4-pro 上执行相同工作负载，通过2026年5月31日的75%促销（缓存命中$0.003625，未命中$0.435，输出$0.87）将降至 $355.25 — 大约是Flash计费的三倍（列表价格为0.0145美元/1.74美元/3.48美元，提供1,421.00美元，约14倍于Flash）。关于速率限制的角度：如果Pro在负载下的每调用延迟更高，那么每个请求也会消耗更多的并发秒数。许多团队将Flash作为高流量路径的默认选项，并将Pro保留用于真正从前沿层推理中受益的那一小部分请求。

状态页面、监控和何时升级

持续429秒且不响应退避通常意味着以下三种情况之一：

1. 平台事件。 检查 DeepSeek的状态页面 首先，如果它是红色的，你的重试就是徒劳的工作。
2. 您的客户端行为异常。 审计无界扇出、缺失回退或持续数小时仍在触发的卡住的重试循环。
3. 您的工作负载在那个小时确实超过了动态容量。 平滑负载（队列），将其转移到更安静的窗口，或者在提供商之间分配流量作为备选方案。DeepSeek明确不会提高单个账户的限额，因此联系支持以“请求更高等级”并不是一个存在的路径。

对于DeepSeek发出的每个状态码的更深入故障排除，请参阅 DeepSeek API error codes 参考是这篇文章的配套文章。同时运行DeepSeek和其他提供商的团队也应审查我们的 DeepSeek API best practices 更全面的投产清单，以及更广泛的 DeepSeek API docs and guides 开发者界面的中心枢纽。

这在实践中意味着什么

将DeepSeek的速率限制视为天气，而不是架构。平台记录了行为（动态并发、在争用时的429、等待期间的保活、无账户拨号），其余的取决于您：有界并发、带抖动的指数退避、持续失败的熔断器，以及依赖上下文缓存的快速设计。做好这四件事，429错误就会变成日常的背景噪音，而不是事件。不做任何一件，您将在每个星期二的下午交通高峰时重新发现限制。

DeepSeek AI Guide is an independent resource and is not affiliated with DeepSeek or its parent company. Model IDs, pricing and API behaviour change; check the official DeepSeek documentation and pricing page before committing to a production decision.