模型API持续返回429，怎样按服务返回的等待信息控制重试？

区分请求速率令牌额度与并发限制

适用于并发任务同时失败、短时间连续请求被限流，或看起来只发少量请求却仍触发429的情况。记录发生时间、工作负载与响应头，保留安全请求标识。计量窗口可能同时受输入、输出和并发影响，不能只按页面点击次数估计；不同项目或模型也可能有不同限制。

核对重试头及SDK已有重试行为

核对服务错误类型及重试等待提示，检查所用SDK是否已经自动重试以及实际尝试次数。再计算业务层是否对每次失败重复启动全任务，造成重复调用。区分短时速率限制与额度不足，后者未必能靠等待几秒恢复；不要把所有429都解释成同一种可自动解决的临时问题。

按预算排队并使用有限退避

优先遵循服务重试头，在合理范围内使用退避和随机抖动，并限制并发与排队长度。总重试预算应包含SDK内部行为，避免两层循环相乘。对有副作用动作继续遵守幂等与结果查询规则；达到预算就保留进度和明确失败原因，不通过换账号或绕过限制继续扩大请求。

验证流量下降与最终失败报告

在授权测试或已有安全日志中核对等待间隔、尝试次数与峰值请求量，确认不会忙循环。测试重试后成功及持续失败两条路径，后者应按预算停止并说明未完成部分。成功不只是某次最终返回正常，还需确认没有重复业务写入，也没有把部分结果错误标为完整。

本文没有触发限流测试或消耗接口额度，也未提供适用于所有账号的固定等待时间。具体窗口与响应字段依服务版本不同，需要现场核对。退避能减少重试压力，不会自动增加可用额度；长期超出容量时应调整工作负载或按正式流程安排容量，而不是无限延长等待。