DeepSeek API TPM 超限与 429 怎么解决？先判断 Token 还是并发

1. TPM、429 与 Server Busy 不是同一个问题

公开 GitHub 讨论中的TPM 案例和Server Busy 案例说明，单看 429 数字不足以决定修复动作。

2. 先量化请求到底有多重

1. 记录失败前最后一次成功请求的输入和输出 Token。
2. 检查是否每轮重复发送完整仓库、日志或工具结果。
3. 关闭并行 Agent、批处理和工具调用，只保留一句短提示。
4. 固定一个模型，比较短上下文与原任务的状态码。
5. 记录连续请求间隔，判断是瞬时速率还是滚动窗口。

curl https://www.codex789.com/v1/chat/completions \
  -H "Authorization: Bearer API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-pro-0813","messages":[{"role":"user","content":"只回复 OK"}],"stream":false}'

模型代号需以当前密钥分组和DeepSeek V4 Pro 页面显示为准，不要从旧截图拼写。

3. AI API 中转站有两层额度

使用中转站时要同时看平台 API Key 的预算/并发和上游 DeepSeek 的模型限制。网关没有请求记录，先查 Base URL、DNS、代理和认证；网关有记录但平台拒绝，查密钥分组和额度；平台记录上游 429 或 Server Busy，再按错误正文判断模型窗口或上游容量。

本站统一入口为 https://www.codex789.com/v1，可以在同一项目中比较 DeepSeek、GLM、Qwen、MiniMax 和 Kimi，但每个模型的代号、倍率和可见权限仍以控制台为准。

4. 降载后只做有限退避

for attempt in range(4):
    response = request()
    if response.ok: return response
    if response.status_code not in (408, 429, 500, 502, 503, 504):
        raise RuntimeError(response.text)
    sleep(2 ** attempt + RANDOM_JITTER)
raise RuntimeError("rate limit still active")

恢复后按“短提示 → 中等上下文 → 工具调用 → 并发”逐级放大。涉及写入、发送或扣费的请求要避免自动重复执行。

5. 用请求重量和窗口证据定位

TPM 问题需要把“请求太重”和“请求太密”分开记录。为每次失败保存输入 Token、输出 Token、并发数、请求间隔、模型代号和响应头；不要只记录 429 这个数字。

1. 用一句短提示、并发 1、关闭工具调用建立基线。
2. 逐步增加上下文长度，记录首次触发限制的输入规模。
3. 保持请求大小不变，逐步缩短间隔，判断滚动窗口阈值。
4. 换同账户的另一个模型，区分模型级容量与账户级额度。

只有在窗口恢复并用同一基线请求成功后，才逐步恢复长上下文和并发；涉及写入或扣费的请求不要自动重放。

6. 常见问题

DeepSeek 429 一定是余额不足吗？

不一定。TPM、RPM、并发、模型容量和账户余额属于不同层级，必须结合错误正文和控制台请求记录判断。

换模型能绕过 TPM 吗？

换模型只能作为诊断实验；如果限制来自账户或网关全局并发，换模型不会解决根因。

中转站能保证 DeepSeek 永不限流吗？

不能。中转站可以统一记录和分层排查，但上游容量、模型窗口和账户额度仍会变化。