跑得好好的商汤日日新接口，突然返回一句模型上限相关的报错，第一反应通常是「是不是欠费了」。但这类报错背后至少有三层原因：账号侧额度用尽、请求侧并发或频率受限、单次请求本身超出模型可接受的输入输出范围。三者处理方式完全不同，按错的顺序排查会白折腾半天。这篇给一套从读报错、分症状到定位动作的顺序，每一步都说明什么情况下不适用。
跑得好好的商汤日日新接口，突然返回一句模型上限相关的报错，多数人第一反应是「是不是欠费了」。但这类报错背后至少有三层原因：账号侧额度用尽、请求侧并发或频率受限、单次请求本身超出模型可接受的输入输出范围。三者处理方式完全不同，按错的顺序排查会白折腾半天。这篇给一套从读报错、分症状到定位动作的顺序。
需要提前说明：下文只讲排查路径，不涉及任何具体额度、并发数或上下文长度数字。这些数字会随账号等级、模型规格、活动政策变化，一律以你控制台当前显示和站内资料页为准。下文里凡是提到「去看数字」的地方，都指到对应站内页面核对当时的实际情况。
先别改代码：把报错原文读完整
很多人看到报错第一反应是改重试参数或者换 Key，其实应该先停下来把报错读完整。同一句「模型上限」，可能是额度类、并发类，也可能是长度类，改错地方会浪费一轮联调时间。先把响应体、状态码、发生时间三者一起留档，后面无论自查还是找人核对都用得上。
| 报错关键词 | 指向的问题 | 先看哪里 |
|---|---|---|
| quota / 额度 / 余额 | 账号或项目额度用尽 | 控制台额度页 |
| rate limit / 频率 / 并发 | 请求过快或并发过多 | 你自己的调度逻辑 |
| max tokens / 长度 / 上下文 | 单次请求超出模型范围 | 请求体参数与模型规格 |
- 区分报错关键词属于额度、并发还是长度三类，三类处理路径完全不同。
- 判断报错出现在请求发出前还是响应返回时：本地参数校验失败多半是你自己的问题，服务端返回才是服务侧拦截。
- 完整记录响应体、HTTP 状态码、发生时间，不要只截图半句。
- 报错含糊到只有一句 model limit 时，先按下一节的症状对照缩小范围，别猜。
症状对照：三种「上限」分别长什么样
排查的关键动作只有一个：用最简单的请求测一次。能过一次，说明不是全局性问题，可以按症状往下分；一次都过不了，先怀疑账号侧额度或授权，不要先去改业务逻辑。下面这张表按症状帮你对号入座。
| 表现 | 更像哪一类 | 下一步动作 |
|---|---|---|
| 所有模型、所有 Key 都失败，简单请求也不行 | 额度型 | 去控制台核额度与有效期 |
| 单请求能通，批量或并发一上来就挂 | 并发或频率型 | 降到单请求、拉大间隔重试 |
| 短请求正常，长文档必挂 | 长度型 | 缩短输入或调输出上限 |
| 换个模型名就失败，其他模型正常 | 授权范围型 | 核 Key 绑定的模型范围 |
- 三种限制可能同时出现，先确认是不是全局性问题，再分辨具体类型。
- 拉长请求间隔后恢复正常，基本可以排除额度问题。
- 缩短输入就能过，说明问题在请求体而不是账号。
- 换模型名才失败，先查 Key 或子账号授权范围，别急着改代码。
账号侧：额度和权限怎么核
账号侧要看的不是「有没有钱」一个维度。额度、有效期、Key 的模型授权范围、不同额度档位的上限，任何一项卡住都会表现为上限报错。逐项核一遍比反复猜要快。注意：下面说的具体数字都不写死，去站内页面看当时的数值。
- 看额度页登录控制台，找到额度或用量页面，确认已用量、剩余量和有效期。是个人额度用完还是整个项目被限，两者处理方式不同。
- 核 Key 授权确认这把 Key 或子账号绑定了哪些模型。有些 Key 只授权部分模型，换个模型名就会被拒，报错看起来却像额度问题。
- 分额度档位试用额度、赠送额度和付费额度常常有不同的上限。看清楚是哪一档被卡住，不要把不同档位混在一起算。
- 对照规格页整体口径不确定时，拿模型规格和计费口径做对照，到站内资料页核对该模型当时的参数与限额说明。
请求侧：并发、频率与请求体自查顺序
确认账号没问题后，把注意力放到请求本身。自查顺序建议从外到内：先降并发和频率，再看请求体参数。顺序反了容易改了一堆参数发现根本不是那个问题。每一步都要用可复现的测试验证，而不是凭感觉判断。
- 先把并发降到 1、请求间隔拉大，重跑一次；能过说明是限流而不是额度。
- 检查 max tokens 类参数：输出上限设得比模型允许值大，或输入加输出超过可接受范围，都会被拒。
- 排查是否存在重试风暴或循环调用，短时间重复请求会让频率类限制更早触发。
- 看批量任务是否一次全量投放，先小批验证再放量，失败不要立刻全量重投。
- 请求参数里混入了空字段或超长字段，也会触发看起来像长度限制的报错。
定位之后的动作：找谁、给什么信息
定位到原因后，动作分三类：属于账号额度或授权的走官方渠道；属于并发或频率的改自己的调度逻辑；属于长度限制的改请求内容或换模型。不管哪一类，改完都要做一次回归，用同一个真实任务重跑，确认报错消失且结果可用，再恢复原有并发。
- 额度或授权类
- 带上账号、Key 标识、报错原文和发生时间，走控制台工单或客服渠道；这类问题你本地改代码解决不了。
- 并发或频率类
- 改的是你自己的调度逻辑，不要先去动模型参数；恢复并发要逐步加，不要一次跳回原值。
- 长度类
- 考虑切分输入、做摘要压缩，或换支持更长上下文的模型；换模型前先到站内资料页核对规格。
- 改完用同一个真实任务做回归，不要只测一个 hello world 就收工。
- 记录本次定位到的原因和对应的报错关键词，下次同类报错可以跳过前面几步。
- 涉及账号权益的问题优先看站内政策说明，口径变化比代码快。
- 如果换模型或换接入方式，重新核对一次请求体参数映射，别沿用旧模板。
常见问题
报错写着模型上限，是不是一定欠费了？
不一定。额度用尽只是其中一种，并发和频率限制、单次请求超出输入输出长度上限也会给出类似的措辞。先做一次最简单的单请求测试：能通就说明不是全局额度问题，重点查并发和请求体；不通再去看控制台额度。按这个顺序能省掉大量无谓的充值。
同样的代码昨天能跑今天挂，是平台改了吗？
先排除自己这边的变化：任务量、并发数、输入长度、是否加了重试，这几项任何一项变大都可能触发上限。再看账号额度和试用期是否有到期。都排除之后，才考虑平台侧调整，这时候拿完整报错原文和发生时间去问客服更有效率。
怎么区分是限流还是额度用完？
限流的典型特征是单个请求能过、并发一上来就失败，把并发降到 1 并拉开间隔后恢复正常；额度用完则是任何请求、任何模型都失败，间隔再长也没用。两个现象对照跑一轮，基本就能分清，处理方式也完全不同。
