DeepSeek_API_Key被限流如何办？

DeepSeek API限流需先识别429/503错误类型，再通过响应头字段或控制台查QPS/RPM/TPM/并发上限，最后用固定延迟、滑动窗口或换模型等策略精准应对。

DeepSeek API Key被限流时，请求会返回429或503错误，此时不能靠反复重试解决，必须定位是QPS、RPM、Token还是并发连接数哪一维超限，并针对性调整策略。

确认当前触发的是哪种限流类型

第一步：发起一次正常请求，用curl或Postman调用任意模型接口（如/chat/completions），在响应头中查找X-RateLimit-Limit、X-RateLimit-Remaining和X-RateLimit-Reset三个字段。

第二步：若X-RateLimit-Remaining为0且X-RateLimit-Reset时间戳距离现在不足60秒，说明是RPM（每分钟请求数）超限；若响应头缺失这些字段但状态码为503，大概率是并发连接数超标；若错误信息明确含“token limit exceeded”，则是TPM（每分钟Token数）触顶。

第三步：登录DeepSeek开发者控制台→进入「API密钥管理」→点击目标Key右侧「详情」→重点核对「按模型划分的速率限制」表格中对应model的QPS、RPM、TPM和并发上限值。这一步不可跳过，【不同模型的RPM值差异极大，deepseek-chat默认60，deepseek-coder可能仅30】。

立即生效的客户端节流方案

方法一：固定间隔法（适合单线程/低并发场景）

在每次请求前插入硬性延迟，例如对deepseek-chat模型设置1050ms间隔——这样每分钟最多发57次，低于60 RPM阈值，留出缓冲余量。这一步操作起来很简单，直接在HTTP客户端配置里加一行sleep即可。

方法二：滑动窗口计数器（适合高并发服务）

用Redis ZSET存储最近60秒内所有请求的时间戳，每次请求前执行ZCOUNT key (now-60) now，若结果≥RPM×0.95则阻塞等待。注意ZSET key需按API Key+model维度隔离，否则多实例共用同一key会导致误判超限。

临时绕过限流的应急操作

第一步：将请求体中的model字段从deepseek-chat临时改为deepseek-chat-li——该轻量版模型RPM阈值通常更高，且输出质量损失可控。

第二步：检查是否有多处服务共用同一个API Key。如果是，立刻为每个服务分配独立Key，避免局部高频请求拖累全局配额。

第三步：若错误集中在某类长文本请求（如输入>8000 token），改用分块提交+流式响应，把单次Token消耗压到阈值内。不这样做会导致TPM快速耗尽，即使QPS/RPM都未超也照样被限。