半夜跑批处理，前面几百条都好好的，突然开始报错、超时、返回半截就断——你第一反应是站点跑路了，还是自己额度用完了？这三件事症状很像，但处置完全相反：限速等一会儿就好，额度耗尽充钱也没用（可能是分组不对），渠道降级则该考虑换线路。这篇给一张症状对照表，加一套从报错到日志的核对顺序。
半夜跑批处理，前面几百条都好好的，突然开始报错、超时、返回半截就断，第一反应通常是站点跑路了，或者自己额度用完了。但这两件事的处置方向几乎相反：限速等一会儿或者降并发就恢复，额度耗尽你干等一晚上也没用，渠道降级则要看是不是该换线路。
这篇不讲原理，只给一张症状对照表，加一套从报错文本到日志字段的核对顺序。你按顺序走一遍，基本能在十分钟内把「到底是什么问题」缩小到一个方向，再决定是重试、充值还是提工单。
三类现象的症状对照
三者最容易混的地方在于：表面上都是「变慢了、报错了」。真正的区别在时间维度和并发维度上。限速和并发强相关，额度耗尽和并发无关，渠道降级则和两者都不太相关，只跟这条线路的质量有关。
| 现象 | 报错形态 | 延迟表现 | 成功率 | 和并发的关系 |
|---|---|---|---|---|
| 限速 | 集中在短时间窗内，多为限流类报错 | 单条请求本身延迟正常，尾部偶发尖刺 | 短窗内骤降，窗口过后恢复 | 并发一降就明显恢复 |
| 额度耗尽 | 持续稳定报错，文本偏鉴权或额度类 | 请求往往在很靠前就被拒，几乎不产生延迟 | 稳定失败，不随时间波动 | 换并发、换时段都不变 |
| 渠道降级 | 报错零散，甚至不报错只是返回不完整 | 整条延迟曲线整体平移抬高 | 缓慢下滑，按小时看是趋势 | 并发高低都差，但不至于全挂 |
先读三个信号：报错文本、延迟曲线、成功率
核对之前先把这三个信号采到手，否则后面全是猜。报错文本要拿原始返回，不要拿你自己客户端包装过的提示；延迟曲线要分「首 token 慢」和「整体慢」，前者更像排队，后者更像线路问题；成功率按请求条数算，而不是按「今天能不能用」这种体感记录。
- 报错文本先按站内 /api-errors 的分类对一遍，429、401、5xx 指向完全不同的原因，别一看到红字就当限流
- 延迟基线要事前量：用 /tools/speed-test 在同机同网下先跑一轮，没有参照物就没法判断是变差还是本来就慢
- 成功率按小时切片记录，混在一起看平均数会掩盖掉突发的尖刺或者缓慢的下滑
- 把重试次数和原始报错都落到日志里，否则一次失败经过三次重试，你看到的就只剩「不稳定」
这三个信号不需要专业监控，跑批处理时把每次请求的时间戳、耗时、状态码、原始报错写进一个 CSV 就够用了。关键是别丢原始信息。
逐项核对清单：从最便宜的动作开始
- 换 Key 打同一请求拿一个已知可用的 Key，用同样的提示词和参数打一次。还报错，基本排除自身 Key 失效或被停；恢复正常，那就是原 Key 的问题，去控制台看状态。
- 把并发降到 1同样的量、同样的时间窗，只把并发压到 1 再跑一遍。能恢复稳定，基本可判定为限速，下一步不是换站点而是改调用节奏。
- 查剩余额度与重置时间看控制台或账单页的剩余额度、重置时间，特别注意分组口径是否和你实际调用的模型一致。分组口径怎么对照，去 /markup-group-pricing-columns 核对当时的说明，别凭印象。
- 换渠道做 A/B同一个提示词、同一组参数，在另一个渠道分组或另一个站点各打一遍。两边都差，问题偏模型侧；只有一边差，就是渠道问题。
- 看整体状态前四步都不是，再去 /ai-status 和服务监控页看上游是不是整体波动。这一步放最后，是因为它最省事但也最容易误判。
这个顺序的原则是：先做成本最低、能排除最多可能性的动作。换 Key 和降并发几乎不花钱，查额度看一眼控制台，换渠道 A/B 贵一点，看状态页最便宜但最容易被当成万能解释。
三种结论对应的处置动作
结论定了，动作才有意义。限速、额度耗尽、渠道降级三者的处置方向完全不同，做反了只会浪费时间和钱。
- 限速
- 加退避重试、削峰填谷、把批处理挪到非高峰时段，先把并发压到你实测能稳住的水平，别急着换站点
- 额度耗尽
- 先确认是套餐额度还是账户余额，再看分组有没有用错，充值前按 /prepaid-verification-flow 走一遍流程，避免充完还是不通
- 渠道降级
- 留存请求 ID、时间戳、原始返回，先向站点提工单，沟通无果再按 /stop-loss-and-migrate 的节奏迁移
不管最后是哪种结论，日志字段都建议一次性补全。字段清单和常见缺失项可以参考 /usage-log-fields，补完之后下次再出问题，你至少能拿数据说话，而不是从头猜一遍。
什么情况下这套判断不成立
这套对照的前提是「你能拿到干净的原始信号」。有几个常见情况会让它失效，遇到了别硬套。
- 你在客户端做了自动重试但没打印原始报错，所有症状都会被糊成「不稳定」，先关掉重试或把原始返回单独记一份
- 多 Key 混在一个池子里轮询，限速和额度问题会互相掩盖，你看到的失败率根本对应不到具体原因
- 上游本身在灰度或维护期，短时间的延迟和成功率数据没有参考价值，先看 /ai-status 再下结论
- 免费额度或试用 Key 常有更严格的限速策略，这类线路的症状不能直接套用到付费线路上，分开记录
如果你的场景正好踩中上面任意一条，正确做法是先改造采集方式，而不是急着换站点。数据不干净的时候，任何切换都是赌博。
下一步拿你手头最近的失败请求，按上面的核对清单走一遍，再把结论和站内 /rankings、/price-watch 里对应渠道的近期表现对一下，看看是偶发还是趋势。→常见问题
限速和额度耗尽，最省事的区分办法是什么？
把并发降到 1 再打同样的请求。能立刻恢复正常，基本就是限速，等窗口过去或加退避重试即可；降并发后照样报同样的错，更像是额度或权限问题，去账单页和对账页面核对剩余额度、有效期与分组口径。
渠道降级会不会报错？
多数时候不报错，只是成功率慢慢下滑、延迟整体抬高、偶尔返回截断内容。这类问题最难查，因为单条请求看起来是成功的。建议按小时记录成功率和 P95 延迟，连续两三个时段偏离基线再判定。
核对的时候该留哪些证据？
至少留四样：原始报错文本、请求时间戳（含时区）、请求 ID 或响应头里的追踪标识、以及同一请求换 Key 换渠道的对比结果。留证的意义在 /stop-loss-and-migrate 里讲过，沟通和迁移时都靠这几样说话。
