限流与运行状态

请求不稳定不一定是模型故障。额度边界、请求速率、并发、客户端超时和任务等待都可能产生相似现象。

429 通常指向请求频率或并发限制；余额或额度问题则应结合实际状态码与控制台记录判断。不要把所有限制都归结为“余额不足”。

五层运行约束

层级	约束什么	典型信号
账户层	账户状态、余额或总额度	多把 Key 同时受限
Key 层	单 Key 状态、有效期与独立额度	只有某个应用失败
请求层	速率、并发、请求体和模型参数	高峰时出现 `429` 或延迟上升
任务层	排队、执行与终态	请求已受理但结果尚未完成
客户端层	连接、读取超时与自动重试	平台仍在执行，客户端却显示失败

同一现象可能跨越多层。例如客户端超时后自动重试，会同时增加并发、用量和重复任务风险。

按症状快速判断

现象	优先检查	不要先做
所有请求立刻失败	Base URL、鉴权、账户与总额度	盲目增加重试次数
只有一把 Key 失败	Key 状态、有效期与单 Key 额度	随意更换模型掩盖问题
高峰期偶发 `429`	并发、请求速率和退避策略	立即并发重放全部请求
请求越来越慢	输入规模、并发、服务状态与超时	无限延长客户端等待
异步请求没有最终结果	任务 ID、任务状态和轮询停止条件	反复创建新任务
客户端失败但用量增加	超时后平台是否继续执行、是否自动重试	只看最后一次前端提示

稳定性排查流程

固定一个最小请求

使用已验证的 Key、模型和短输入，先确认基础链路。排障过程中不要同时修改地址、模型、参数和并发。

记录单请求基线

保存正常状态码、首段或完整响应耗时、用量和请求 ID。没有基线时，很难判断“慢”到什么程度才算异常。

逐步增加并发

从单请求开始，分阶段提高并发并记录成功率、429 比例和延迟。找到变化点后停止继续放大压力。

检查客户端行为

确认超时设置、连接池、自动重试与页面重复提交。客户端策略经常会把一次短暂异常放大为请求峰值。

回到控制台核对

结合 API Key 管理、任务中心和用量与账单，判断请求是否已受理、是否仍在执行以及是否产生消耗。

重试策略应有边界

规则	原因
只重试适合重试的临时错误	参数、鉴权和权限错误不会被重试修复
使用退避并加入次数上限	避免在服务受限时继续放大流量
每次尝试使用可追踪的请求标识	区分原请求与后续尝试
流式已返回内容时谨慎重试	防止重复展示和重复消耗
异步创建请求先查任务	防止客户端超时后创建重复任务

提高超时、并发或额度都会改变系统行为，但不等于修复根因。每次只调整一个变量，并保留调整前后的对照数据。

上线前的运行基线

核心接口的正常耗时范围
每个应用允许的并发与请求速率
客户端连接超时、读取超时和最大重试次数
异步任务的轮询间隔、总等待时间与停止条件
429、5xx、任务失败和用量异常的告警阈值
发生异常时需要保留的请求 ID、任务 ID、Key 名称和时间范围

继续排查

计费规则 Anthropic Claude 定价