API 限流是服务方对请求频率和用量做的保护机制，429 是对应的 HTTP 状态码，含义是「请求过多」，表示你的请求因为超出了单位时间内的限额被服务器拒绝。通过 DeepSeek 这类平台的接口调用大模型时，遇到 429 并不代表程序写错或账号出问题，绝大多数情况只是触发了频率或用量上限，按正确节奏处理很快能恢复。
限流规则写在文档哪个位置
限流通常按几个维度计量：每分钟请求数，衡量调用频率；每分钟消耗的 token 数，衡量单次请求的体量；部分平台还设每日上限。这些数值会在平台的接口文档或控制台里公示，免费层级和付费层级的限额不同，有的平台还会随账户等级或充值情况动态调整，具体以官方文档为准。动手写代码前先查一眼自己的额度档位，比事后排错省时间得多。除了明面上的限流，部分服务在整体负载过高时也会临时收紧阈值，这种情况官方公告一般会有提示。
429 不是故障而是礼貌拒绝
把 429 和相邻的错误码放在一起看更容易理解。401 是身份没通过，检查密钥是否正确、有没有过期；403 是权限不够，确认账号是否有该模型的调用资格；500 系列是服务端自己出了问题，只能等官方修复。而 429 的潜台词是「请求本身没问题，但太快了，请等一等」，服务器主动拒绝是为了保护整体服务对所有用户的可用性。看到 429 就疯狂点重试是最常见的错误反应，请求越积越多，反而会让自己被限更久，甚至触发更严格的临时封禁。
| 状态码 | 含义 | 该怎么处理 |
|---|---|---|
| 401 | 身份没通过 | 检查密钥是否正确、有没有过期 |
| 403 | 权限不够 | 确认账号有没有该模型的调用资格 |
| 429 | 请求过多，被限流 | 按 Retry-After 等待，别立刻重试 |
| 500 系列 | 服务端自己出了问题 | 只能等官方修复 |
重试时机要跟着服务器走
规范的接口会在 429 响应里附带 Retry-After 字段，告诉你建议等待多少秒，程序里优先读这个值。没有这个字段时，工程上通行的做法是指数退避：第一次等两秒，再失败等四秒、八秒，依次翻倍，同时给等待时间加一点随机偏移，避免大量请求在同一时刻扎堆回来。应用层面还能做两件事降低触发概率：一是控制并发，把同时发出的请求排成队列逐个执行；二是合并请求，能用一次调用完成的多条小任务拼成一条。重试逻辑写进代码后，记得加日志记录触发时间和频率，方便回溯是哪个环节超限。
用量记账比事后排错更省心
长期跑批量任务的话，建议给自己建一份简单台账：记录每天调用的次数和 token 消耗，对照平台公布的限额，提前知道还剩多少余量。很多平台控制台自带用量统计面板，每天收工前看一眼，比报错后再排查从容得多。批处理任务还可以主动错峰，避开业务高峰时段，把大批量请求安排在凌晨执行，触发限流的概率会低不少。假设一个脚本每天要处理五千条短文本，按每条一次调用算，若限额是每分钟六十次，全程至少要分一个半小时跑完，提前规划好节奏就不会中途被拒。
延伸阅读：AI API 怎么接入、限流和排队有什么区别、有余量还报 429 怎么查。
限流台账记什么
- 每天调用次数与 token 消耗
- 对照公布的限额算剩余余量
- 批处理尽量安排在凌晨错峰
- 触发限流的时间和环节记一笔
最容易省掉的是「哪个环节超限」，缺了它只能反复试错。
429 报错的三个常见疑问
- 429 出现后，刚才那条请求算成功还是失败？：算失败，请求没有被处理，内容也不会生成，需要按重试策略重新发送，注意业务上别重复记账。
- 升级付费档位就能彻底避免限流吗？：能提高限额，但不能完全避免，任何平台都有总量保护，极端高峰下付费用户同样可能遇到临时限流。
- 网页版聊天也会遇到 429 吗？：普通聊天很少直接看到这个数字，但连续快速发送大量消息被暂时限制时，背后的机制是类似的，停一会儿自然恢复。
