国产大模型 API 报错横评：哪家的错误信息最有用
数据截至 2026-07，价格与限额以各官网为准。
衡量一个大模型 API 好不好用，别只看价格和跑分，还要看它报错时说人话的程度。同样是调不通，有的平台一行 message 就把你按到具体那个填错的字段上，有的只丢回一句”请求参数错误”，你得自己二分法删参数试半小时。更麻烦的一类是压根不报错——平台悄悄把你的请求路由到了别的模型，你以为一切正常，直到某天对账才发现跑的根本不是你以为的那个模型。
常见的误解是：报错信息是平台的”售后细节”，做技术选型时不值得占权重。真到线上出问题的时候你会发现刚好相反。模型能力差一点，业务上通常还能忍；错误信息含糊，代价是每次故障多花的排查时间，而这个成本是随调用量线性增长的。更现实的是，绝大多数团队接一家平台不会只跑通就完事，后面要处理限速退避、配额告警、模型下线迁移，这些全都依赖错误信息里能不能拿到稳定可判别的信号。
先约定评的是什么：六个维度
“错误信息有用”是个模糊说法，拆开就清楚了。下面这六条可以直接拿去当自测表用，每条给 0/1/2 分，满分 12 分。
第一，HTTP 状态码用得对不对。 鉴权失败该是 401，参数不合法该是 400，限速该是 429，服务端崩了该是 5xx。有些网关图省事，所有错误一律回 200，把真实错误塞在 body 里，这会让所有依赖状态码做重试判断的客户端全部失效——SDK 看见 200 就认为成功，你的重试逻辑一次都不会触发。这一条不合格，后面五条再好也补不回来。
第二，错误码是不是稳定且可枚举。 message 是给人看的，随时可能改文案；程序判断必须依赖一个结构化字段。好的平台会在 body 里给一个固定的 code，并且在文档里列出这个 code 的完整清单。差的平台只有一句自然语言描述，你想在代码里区分”余额不足”和”并发超限”，只能去匹配中文子串，人家一改文案你的线上逻辑就静默失效。
第三，message 有没有指到具体位置。 “参数错误”和”messages[2].content 不能为空”，排查耗时差一个量级。多模态、函数调用这类嵌套结构复杂的请求，能不能报出出错的具体路径，差别尤其明显。
第四，有没有给出下一步动作。 优秀的错误信息会顺手告诉你怎么办：超限了建议等多久、模型名不对时提示去哪个页面查当前清单、上下文超了告诉你当前请求算出来多少 token、上限是多少。这条最考验平台是不是真的有人在用自家 API。
第五，限速、配额、欠费三件事分不分得清。 这三种情况的处理方式完全不同：限速要退避重试，配额用尽要等周期重置或提额，欠费要去充值。如果平台把它们混在同一个 429 里、message 也含糊，你的重试逻辑就会在一个永远不会自己好转的错误上死循环，把日志刷爆。
第六，有没有可追溯的请求 ID。 响应头或 body 里带一个 request id，你去提工单时对方能直接定位这一次调用。没有这个字段，工单往返基本就是互相猜。
国产平台的错误信息，大致是三种形态
按我实际接的几家看，错误信息的组织方式可以归成三类，认出属于哪类，排查思路就定了。
第一类：OpenAI 兼容层派。 平台提供一个兼容 OpenAI 格式的端点，错误体也照抄 OpenAI 的结构（error 对象里带 message / type / code）。好处是生态成熟，你原来那套针对 OpenAI 写的错误处理代码基本能直接复用；坏处是兼容层往往只保证成功路径的字段对齐，错误路径上各家塞的 code 值并不统一，你以为可以复用的分支判断，换一家就全落到 else 里去了。另外还有个坑：用 openai 这个 SDK 打兼容端点时，SDK 会把非标准的响应体包装成自己的异常类型，平台原本写得挺清楚的那句中文提示，有可能在包装过程中被吞掉，只剩一个干巴巴的状态码。遇到这种情况，把原始 HTTP 响应打出来看，比对着 SDK 异常猜有效得多。
第二类：自研原生 code 派。 平台有自己的一套错误码体系，文档里列表格。这类的上限更高——因为码是自己定的，可以定得很细，一个码对应一种确切原因。但它有个前提：文档必须跟着代码更新。如果线上返回了一个文档里查不到的码，这套体系的优势就归零了，甚至比只有自然语言描述还糟，因为你连猜都没得猜。判断一家平台属于”码体系做得好”还是”只是有码”，最快的办法是随便触发几个错误，把返回的码拿去文档里搜，看能不能搜到。
第三类：网关抢答派。 你的请求还没到模型服务，就被前置网关拦下来了，返回的是网关自己的一套错误格式，跟文档里写的模型服务错误格式完全不一样。最典型的是鉴权失败和限速这两类，经常由网关处理，返回体可能是一段 HTML 或者一个跟平常完全不同的 JSON 结构。碰到”报错格式跟文档对不上”，先别怀疑自己，很可能只是被网关截胡了，这时候看状态码比看 body 靠谱。
一个完整实例：拿 GLM 走一遍这六条
只讲抽象维度容易空转，这里用一家公开文档比较完整的平台做次演练。智谱 GLM 的 OpenAI 兼容端点的 base URL 是 https://open.bigmodel.cn/api/paas/v4/，官方建议把密钥放进环境变量 ZAI_API_KEY（来源：官方文档站 docs.bigmodel.cn 的 OpenAI API 兼容页）。用这个链路能演出好几种典型错误。
模型名一字之差。 官方模型清单里同时存在 glm-4-flash-250414 和 glm-4-flashx-250414，前者是免费模型，后者是付费的轻量高速版。一个 x 之差，账单结果完全不同。这类问题的价值全在错误信息上：如果平台在模型名不存在时能回一句”该模型不存在，请查看模型概览页”，你三十秒就能改对；如果只回”参数错误”，你可能会先去怀疑 messages 结构。而更棘手的是名字确实存在、只是不是你想要的那个——这时候不会有任何报错，只有月底账单会提醒你。所以模型名这件事，别指望错误信息兜底，接入时就该把常量抽出来集中管理。
不报错的那类问题，才是真正的坑。 官方文档明确写着 glm-4.5-flash 已于 2026-01-30 下线，请求会自动路由到 glm-4.7-flash。从可用性角度这是好事，业务不会因为模型下线而中断；但从可观测性角度，这恰恰是最难查的一类情况：你的代码里写的还是老模型名，调用全部成功，返回一切正常，你完全不知道自己跑的已经是另一个模型了。如果你的提示词是针对老模型调过的，效果变化可能要好几周才被发现。应对办法只有一个：不要只看有没有报错，把响应体里返回的实际模型标识记进日志，定期跟你代码里写的名字比对一次。
上下文和最大输出超限。 这两个限制经常被混为一谈，其实是两回事。按官方模型概览页，GLM-4.5 的上下文窗口是 128K、最大输出 96K；GLM-4.6、GLM-4.7、GLM-5 这几个都是 200K 上下文、128K 最大输出；GLM-5.2 的上下文到了 1M、最大输出仍是 128K。请求超出上下文窗口，是你发进去的内容太多；超出最大输出，是模型一次能吐出来的长度不够。前者要你裁剪历史消息，后者要你改分段生成的策略。如果错误信息只说”超出长度限制”而不说是哪一个超了，你很可能会朝错误的方向优化半天。
费用相关的报错。 关于价格，官方文档里能逐字查到的是 GLM-4.5 的”输入 0.8 元/百万 tokens、输出 2 元/百万 tokens”这一条，另外官方明确 Batch API 走批量接口只需五折费用。其余型号的具体单价，官方定价页是前端渲染的，我这边没法逐字核到，所以这篇不给数字，请以 bigmodel.cn 的定价页当前显示为准。这跟错误信息有什么关系？关系在于：当你收到一个疑似余额相关的报错时，你需要能立刻算出”我这个请求大概值多少钱”来判断是不是真的用超了。计费单位这里还有个容易翻车的点——官方原始展示口径可能是”每千 tokens”，跟你脑子里”每百万 tokens”的习惯差三个数量级，换算方向搞反了，你会得出一个完全离谱的余额判断。
免费档的限速。 GLM-4-Flash-250414 和 GLM-4.7-Flash 是官方文档确认的免费文本模型，用它们跑通链路零成本，这是个很实用的做法：调试接入逻辑的阶段用免费模型，把参数、鉴权、错误处理全跑对了，再换成付费模型。但要注意免费不等于无限制，并发和速率仍然有限，具体的每分钟请求数之类的数字官方页面上我没核到，遇到限速报错时以你控制台里显示的为准。
那到底哪家最好？为什么这篇不给排行榜
诚实说：我不给点名打分的总榜，理由有两个。
一是各家网关和错误体的改动频率，比模型发布还高。今天测出来某家 message 不带字段路径，下个月一次网关升级就可能加上了。一个写死在文章里的排名，三个月后大概率变成误导。二是错误信息的表现跟你的调用方式强相关——同一家平台，用官方原生 SDK 和用 OpenAI 兼容层打过去，拿到的错误体可能完全不同；再套一层聚合中转，中转服务还会再改写一遍。脱离具体链路谈”哪家报错最清楚”，意义不大。
更靠谱的做法是自己跑一次。找半天时间，对你正在候选的每一家，用同一段脚本刻意触发这六种错误：故意写错密钥、故意写一个不存在的模型名、故意把 messages 里某项置空、故意塞超长上下文、故意用循环打满限速、故意用一个已知余额不足的账号。把每次的状态码、完整响应体、响应头全部原样打印出来，摆在一起对比，按上面六个维度打分。这份记录还有个长期价值：它就是你写错误处理代码时的对照表，比任何文档都准，因为它是你自己的链路上实测出来的。
顺带说一句为什么这篇只谈国产平台。海外几家厂商的错误信息设计确实有值得学的地方，但涉及中国大陆使用时得先说清前提：这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，具体以各自官网的地区政策页为准。本文不提供也不背书任何第三方中转渠道。既然要谈的是能稳定放进生产环境的选型，那就从确实能合规接入的这批开始谈更实际。
拿到这份对比之后怎么用
打分只是第一步，真正的收益在于据此写出更耐用的错误处理代码：
- 判断分支只依赖状态码和结构化 code，不匹配 message 子串。 message 随时会改，你的线上逻辑不该建立在别人的文案上。
- 限速类错误单独一条退避路径，配额与欠费类错误直接告警不重试。 把这两类混在一起重试，是把小故障放大成大故障的经典方式。
- 所有非预期错误，原样落一条完整日志，含状态码、响应头、完整 body。 只记一句
str(e)，等于把排查线索扔了。 - 把实际返回的模型标识记进日志。 前面那个自动路由的例子说明，“没报错”不等于”跑的是你想的那个”。
- 给每家平台的错误处理留一层适配。 如果你同时接了不止一家，别指望兼容层帮你抹平错误路径，在自己这边收敛成一套统一的内部错误类型，换供应商时改一个文件就够。
局限
这篇没做的事得说清楚：我没有对每一家国产平台的错误码清单逐条实测和逐字核对，因此文中除了 GLM 那几条有官方文档出处的事实之外，不给任何平台的具体错误码字符串、具体价格数字和具体限速数值。文中对三类错误信息形态的归纳，是结构层面的观察，不构成对某一家当前版本的评价。你真要做选型，还是得按上一节的方法自己跑一遍——这活儿花不了半天，但能省下后面无数次的猜。
小结
错误信息的质量是个被严重低估的选型维度，它决定的不是能不能接通，而是出问题时你要花多久。判断标准可以收敛成六条：状态码用得对不对、错误码稳不稳定、message 指不指得到具体位置、给不给下一步、限速与配额分不分得清、有没有可追溯的请求 ID。国产平台的错误体大致分兼容层派、自研码派、网关抢答派三类，认清属于哪一类，排查方向就定了一半。比”哪家最好”更要紧的，是留意那些根本不报错的情况——模型下线自动路由这类设计对可用性是好事，对可观测性却是陷阱，只能靠自己把实际模型标识记进日志来兜。最后，别信任何写死的排行榜（包括这篇如果给了的话），花半天按同一套脚本把候选平台挨个触发一遍，那份自测记录比什么都管用。