失效的降级链：当备用模型成为仅剩的选项

降级链的静默失效：一张账单揭开的真相

上周的云账单比往常低了一截——这本该是好事，却让我脊背发凉。追查后发现，所有请求都由降级链的最后一个模型应答。应用没有报警，延迟在可接受范围，用户零投诉。我沾沾自喜的「高可用架构」，实质上已经依托应急路线运行了数周，而我把这称作生产环境。

问题的根源很直接：链首的 OpenAI 模型已被退役。退役模型会返回 HTTP 404 和 not_found_error/model_not_found，这是硬性拒绝，不是时好时坏的超时。我的降级链捕获了这个拒绝，顺畅地切换到下一条路线——这正是它被设计出来的目的。等错误抵达我这里时，它早被吞掉并重新标记成了正常流量。

降级链隐藏了它本应承受的故障。 这是第一个反直觉的教训。

为什么降级链对「退役」和「临时故障」一视同仁

降级链的本质赌注是：某条路线失败只是暂时现象。赌对了，你得到一个短暂波动和稍微不同的答案。当路线永久消失时，降级链依然在做看起来正确的事：用剩下的资源服务请求。一条只剩一个存活成员的链，在监控面板上是一片绿色，但它同时也是一个你不再理解的系统——因为出问题的恰恰是那个本该保护你免受故障影响的东西。

更不舒服的是：因合理原因触发的降级，和因主路线被删除而触发的降级，从外部看完全一样。两者都产生成功响应，唯一区别是哪个模型写的。除非你记录这一点，否则你没有任何信号。我当初没记，所以有一段时间，我唯一的监测工具就是账单。

降级链（Fallback Chain） 是多模型调用架构中常见的容错模式：将多个模型端点按优先级串联，当主路线因超时、限流或服务错误失败时，自动尝试下一优先级。其设计前提是失败被假定为暂时性——因而链在每次切换时不区分“临时抖动”与“永久消失”，只关心是否还有可用成员。这一模式在提升可用性的同时，也引入了可观测性盲区：成功的降级响应与正常响应在外部指标上完全同构，除非显式记录实际应答的路线，否则运维者无法感知系统已长期运行于应急路径。

退役是公开数据，只是藏在字段里

模型退役并非无迹可寻。OpenAI 的模型列表暴露了时间表：GET /v1/models 和单模型「检索」接口都携带可选的 shutdown_date 字段，值为 YYYY-MM-DD 或 null。官方通知窗口表面上很宽裕——正式模型通常六个月以上，专用变体至少三个月，预览模型有时只有约两周。微调模型遵循其基础模型的关停时间表，这一条最容易被忽视：你的微调模型保留自己的名字，却继承了别人的截止日期。

Anthropic 用生命周期框架描述同一件事：Active、Legacy、Deprecated、Retired，并明确表示对已退役模型的请求会失败。其保证是最低通知窗口适用于「拥有活跃部署的客户」。仔细读这个限定词——如果你的流量已因降级链悄悄接管而变得安静，你远没有自己想的那么「活跃」，你指望的通知可能根本不会来。

模型退役（Model Retirement/Deprecation） 指供应商停止对某模型版本提供推理服务，通常伴随通知窗口和迁移期。OpenAI 通过模型列表接口的 shutdown_date 字段公开关停日期；Anthropic 则以 Active/Legacy/Deprecated/Retired 四阶段生命周期管理，并承诺对“拥有活跃部署的客户”提供最低通知窗口。关键风险在于：微调模型保留自有名称，但继承其基础模型的关停时间表，容易被忽略；同时，若流量已因降级链静默切换而减少，客户可能不再被判定为“活跃部署”，从而错过通知。

更安静的断点：参数、额度与上限

退役只是路线死亡最响亮的方式。另外两种断送路线的方式，甚至不会出现「已弃用」字样。

参数表面。 在 Claude 4.7 及更高版本中，传入非默认值的 temperature、top_p 或 top_k 会产生 HTTP 400。我的请求构造器多年来一直发送 temperature，因为某个时候它让输出更顺眼；在新模型上，这个习惯直接让调用失败。如果它位于降级链之后，这条路线就无声消失了。

信用与上限核算。 Anthropic 的使用额度自发放起一个日历年到期，不可退款，到期日不可延长；关闭账户会销毁剩余余额。在流量侧，错误形态和错误消息一样重要。429 的 rate_limit_error 也可能是触及层级支出上限的响应——没有 retry-after，且会一直持续到访问恢复。自设支出上限表现为 400。计费问题以 402 billing_error 抵达。这些都不是「模型没了」，却都能让一条路线停摆得比退役模型更久。

HTTP 错误码的语义分层 在此类架构中至关重要。404 model_not_found 表示模型永久不存在，重试无意义；400 可能源于参数不兼容（如 Claude 4.7+ 对非默认 temperature/top_p/top_k 的硬性拒绝）或自设支出上限；429 rate_limit_error 可能是临时限流，也可能是层级支出上限耗尽（无 retry-after 且持续至访问恢复）；402 billing_error 则指向计费问题。这些错误在降级链中均被捕获并触发切换，但对应的修复动作截然不同——模型替换、代码修改、充值或调额。不加区分的降级逻辑会掩盖这些差异，使路线无声停摆。

以 max_tokens=1 单独探活每一条路线

能捕获这次故障的测试小得几乎侮辱人：单独、逐个地直接请求每条路线，使用 max_tokens=1，绝不经过降级链。一个 token 足以拿到 HTTP 状态码和错误体，成本低到可以随意定时运行，不用多想。

curl -sS -o /tmp/route.json -w '%{http_code}\n' \
  https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"<chain entry exact model string>","max_tokens":1,"messages":[{"role":"user","content":"ping"}]}'

重点在于你怎么解读返回。如果响应体携带 not_found_error/model_not_found，路线不是不稳定，而是没了，重试逻辑再强大也救不回来。如果是你以为无害的参数导致的 400，那是代码修复，不是事故。如果是 429 或 402，路线没问题，问题在钱包。三种不同的病，三种不同的应对——而一条对所有情况都回以相同动作的链，不是监控策略。

探活（Health Probe） 指绕过业务逻辑与容错层，直接对每个依赖端点发起最小化请求以验证其可用性。使用 max_tokens=1 可将成本压至最低，同时仍能获取 HTTP 状态码与错误体。关键原则是：探活必须直连每条路线，绝不经由降级链，否则链的容错行为会再次吞掉故障信号。解读响应时需按错误类型分流：model_not_found 意味着路线已死，应触发配置更新；参数类 400 是代码缺陷；429/402 是配额或计费问题。将探活结果与供应商模型列表 diff 结合，可在请求触及降级链之前发现失效条目。

别信监控面板，去和实时模型地图做 diff

我的uptime检查指向降级链本身。这是根本错误。一个经过「只剩一条活路」的降级链的健康检查，在构造上永远为绿——它衡量的是链愿意回答，而非链内任何路线的健康。我有一个永远不会失败的监控，且每天早上读它。

替代方案枯燥得多。降级链以数据形式放在文件中，而非嵌套的 if 分支。一个任务抓取供应商的模型列表，读取 shutdown_date，将列表与降级链做 diff。任何链条目名称已不存在，或关停日期已过，在请求触及之前就被标记。任何被 Anthropic 标记为已弃用却仍在承载流量的模型，可以用供应商推荐的方式发现：Console → Usage → Export，按 API 密钥和模型导出的 CSV，显示哪些已弃用模型仍在被哪个密钥调用。我也记录每个请求实际由哪条路线应答，因为从「主路线」到「最后手段」的偏移本身就是症状，而它在所有只统计成功次数的仪表盘里都是隐形的。

最终告诉我出问题的数字是账单。下次我希望它是 diff。