阿里云百炼「错误码」全表实测：128 个错误分组里，同一句话在 400 和 429 各挂了一遍

数据来源：阿里云百炼官方《错误码》文档（help.aliyun.com/zh/model-studio/error-code）
抓取时间：2026-10-15 21:0x（Asia/Shanghai），页面标注「更新时间：2026-10-15 15:04:27」
抓取方式：Chrome headless 1440 宽实拍 + HTML 全量结构化解析，128 个错误分组 / 345 条错误文案，全量非抽样

百炼的错误码页面被官方归在「API参考（模型）→ 使用 API → 错误码」下面，是所有 API 文档里最短的一篇。但它其实是一张失败语义账本：写重试逻辑时，你能不能睡得安稳，取决于你有没有把这张表看完，而不是取决于你看过 429 和 500 这两个数字。

我们把这一页完整解析了一遍，得到 128 个二级错误分组、345 条三级错误文案。有几个发现直接指向生产代码的重试策略。

一、这张表的基本盘：128 个分组，68 个挂在 400 上

先看整体分布。二级分组按 HTTP 状态码归类：

两个数字值得停一下：

• 400 一组就占了 68 个分组、215 条文案，其中 400-InvalidParameter 单独一个分组塞了 116 条。也就是说，把「参数错误」当成一个笼统的错误类型去处理重试，基本等于什么都没处理。
• 500 有 17 个分组、33 条文案，最大的 500- InternalError.Algo 占 13 条。500 通常被当作「无脑重试」，但这 33 条里混着明确要求改请求的。

还有 9 个分组、54 条文案根本不带 HTTP 状态码，而是客户端库层面的异常名：APIConnectionError、SDK 报错、NetworkError、mismatched_model、duplicate_custom_id、WebSocket 报错、Coding Plan。这部分在很多重试实现里是直接漏掉的。

二、最关键的发现：同一句文案，在 400 和 429 各挂了一遍

这是本次全表解析里最有工程价值的一条。我们按「错误名」跨分组做交叉统计，发现 3 组错误名同时出现在两个不同 HTTP 状态下：

前两行是实打实的重复登记：同一个 CosyVoice 声音复刻的音频解码失败、采样率不支持，文案一字不差，分别挂在 400 和 430 下。官方没有解释这两个状态码的分工依据，我们把它记为 UNKNOWN。

但即使文案和解决方案完全一致，状态码不同也足以让重试逻辑做出相反的动作——这就是下面这张表的问题所在。

三、429 的 11 个分组里，只有 6 个该重试

429 通常被视作「标准限流码，等一等就好」。但在百炼这一页上，11 个 429 分组里至少 5 个的重试语义完全相反：

也就是说：5/11 的 429 分组重试永远不会成功，它们要么要改账号配置，要么要改账单，而客户端的自动重试只会安静地重复失败。

Throttling.AllocationQuota 这条尤其值得单独说——它的解决方案明确写着「前往限流文档查看模型限流条件并调整调用策略；如果默认额度无法满足业务需求，请联系商务经理申请提额」。这是容量规划问题，不是瞬时抖动。

BudgetLimitExceeded 还带一个官方警告值得抄进代码注释：

服务停止存在一定延迟，延迟时段内产生的费仍将正常收取。若已达预算阈值触发停机后，又发放了免费额度，停机不会自动恢复，需手动调整预算阈值。

最后半句是纯工程陷阱：预算停了之后，你后来发的免费额度不会让它自动恢复。

四、400 那一族其实是「上传前置校验表」，不是「参数错误表」

68 个 400 分组里，藏着两套非常完整的媒体文件前置校验表，它们跟文本参数校验完全是两回事。

4.1 InvalidFile.* 家族：22 个分组、38 条文案

数字很能说明问题：一个 400-InvalidFile. 前缀下有 22 个独立分组：

DownloadFailed、AudioLengthError、NoHuman、BodyProportion、FacePose、Resolution、FPS、Value、FrontBody、FullFace、FaceNotMatch、Content、FullBody、BodyPose、Size、Duration、ImageSize、AspectRatio、Openerror、Template.Content、Format、MultiHuman。

它们覆盖的是人体、服饰、音视频的内容级校验——有没有人、人体比例对不对、人脸朝向、分辨率档位、FPS、模板内容、音视频时长、宽高比、格式、多人场景。FaceNotMatch（人脸不匹配）和 MultiHuman（检测到多人）这种，单靠检查文件大小和 MIME 类型根本拦不住。

4.2 BadRequest.* 家族：9 个分组、11 条文案

EmptyInput、EmptyParameters、EmptyModel、IllegalInput、InputDownloadFailed、UnsupportedFileFormat、TooLarge、ResourceNotExist、VoiceNotFound。

另一套命名法，描述同类问题。同一类「文件不行」的语义，官方用了 InvalidFile.* 和 BadRequest.* 两套码，你在写映射表时不能只匹配其中一套。

4.3 数据审核是独立一支，且有一个反直觉项

审核类错误分散在 4 个分组里：DataInspectionFailed/data_inspection_failed（3 条）、Contain.Forbidden.Label.Error、InvalidParameter.DataInspection、FaqRuleBlocked、IPInfringementSuspect，以及 500- InternalError.DataInspection（内容审核服务不可用）。

InvalidFile.Content 下的 6 条文案里，有一条明确写着：

Qwen rejected the input image before model inference; no actual ad/porn/OCR result was produced.

即模型在真正推理前就拒了图，并不存在实际的审核结论。

400-FaqRuleBlocked 和 400-IPInfringementSuspect 只有「原因」，没有「解决方案」——这两类是策略拦截，不是可自查的参数问题，重试没有意义。

五、401 的 3 个分组，全是「Key 和 Base URL 配对」问题

401 在很多实现里直接被归为「token 过期，刷新重试」。但百炼的 3 个 401 分组里，没有一个是「刷新一下就好」：

InvalidApiKey 那条里，官方给了一个具体到可以直接抄进 code review 的错误写法：

错误写法：api_key=os.getenv("sk-xxx")

系统会去读名为 sk-xxx 的环境变量，而不是把 sk-xxx 当密钥。正确写法是 api_key=os.getenv("DASHSCOPE_API_KEY")。

更值得注意的是，官方在这一节里给出的三地域 Base URL 表，说明 API Key 和 Base URL 是成对的：

混用地域会直接落到 401，而不是一个更容易识别的错误码。

官方同时建议华北2（北京）和新加坡迁移到业务空间专属域名（https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com、https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com），并注明现有域名仍可正常使用。

六、403 的 7 个分组是「资源类型矩阵」，403 不是「没权限」

403 这一族把「拒你」的原因拆成了六类对象，每类一个错误名：

access_denied 下的 4 条里，有两条是同步/异步调用方式不匹配：

• Current user api does not support asynchronous calls. → 移除 X-DashScope-Async 或设为 disable
• current user api does not support synchronous calls. → 设置 X-DashScope-Async: enable

而 429 的 Throttling.RateQuota 分组里有一条反向说明：若单次调用即返回 429，要检查是不是设了 X-DashScope-Async: enable。官方点名某些模型（如 qwen-image-3.0-pro）不支持异步调用，此时即使单次请求也会返回 429，移除该请求头或设为 disable 后改用同步调用重试。

同一个请求头，一个地方要加、一个地方要去，取决于模型。

七、还有一类错误根本不在 HTTP 层：200 与控制台态报错

页面最后列了 2 个 HTTP 200 的报错分组：BailianGateway.Workspace.NotAuthorised（控制台显示「部分功能使用受限」）和 BailianGateway.Team.NotAuthorised。

这两个只在控制台出现，API 调用看不到。成因是 RAM 子账号访问未授权的业务空间或团队——如果你只在 API 层做错误监控，这两类会完全静默。

Coding Plan 的 6 条报错同样不带 HTTP 码，全靠消息文本匹配：Connection error、hour allocated quota exceeded、week allocated quota exceeded、month allocated quota exceeded、concurrency allocated quota exceeded、usage allocated quota exceeded. please try again later.。

注意最后一个：官方说它通常等待一小时后恢复，并建议把大型任务拆成多个小任务、分时段提交——这与前三个「等 5 小时 / 等到周一 / 等到订阅日」的固定重置窗口是不同的语义。

八、把这张表变成代码：一个可落地的分类

把上面的发现收敛成一个分类，直接对应到你项目里的 shouldRetry()：

一条务实的结论：不要按 HTTP 状态码分支，按错误名分支。 状态码在这张表上既不唯一（同名跨状态），也不完备（200 和无状态码组各有一批）。错误名虽然也存在跨状态重复，但那是同一语义的重复登记，反而是更安全的分组键——就像第二节里那两条 400/430 同名项，重试动作本来就该一致。

九、本文的证据口径与未知项

以下是本文明确没有验证的部分，请勿当作结论：

1. 430 与 400 的分工依据 UNKNOWN。官方文档未解释为何 CosyVoice 的同一批音频错误会同时出现在 400 和 430，本文只陈述重复事实，不推断规则。
2. 未在阿里云控制台实测任何一条错误。本文全部数据来自官方文档页的静态解析，没有登录控制台、没有发起真实调用、没有触发任何一条错误码。
3. 分组与文案的计数口径为二级标题（HTML 的 h2 标签）与三级标题（h3 标签），部分分组内文案以「/」并列多种写法（如 “A. / B.”），本文按一条计。
4. 页面为持续更新内容。抓取时页面标注「更新时间：2026-10-15 15:04:27」，若官方后续新增分组，本文数字会变化。
5. Throttling.AllocationQuota 在 400 与 429 下的具体条目不同，本文在第二节表格中标注为「语义不同」，未合并统计。
6. Coding Plan 的 6 条报错位于页面末尾独立章节，不属于 HTTP 错误码体系，本文单独归类。

十、来源与可核验链接

方法说明：HTML 请求返回 HTTP 200、464,153 字节；解析出 128 个二级标题（h2 标签）分组与 345 个三级标题（h3 标签）文案，按 HTTP 状态码前缀归类统计；跨分组同名错误通过解析错误名（去除状态前缀后按 / 拆分、小写归一）做交叉比对得出第二节与第六节的矩阵。配图三张均为该页面 2026-10-15 21:0x Chrome headless 1440 宽实拍裁切，非占位图。

与本站既有千问文章的分工：本站已发布的百炼系列分别覆盖限流容量层（162 张表 500 倍 RPM 差）、《Coding Plan 订阅制》（请求次数计费）、《免费额度规则层》（249 行 7 类额度）、《模型家族全景》、《可选模型清单》等角度；错误码 / 失败语义层此前未被开采，本文是该角度的首篇。