模型列表只是起点，失败分类才是关键

多数模型服务降级系统一开始都只维护一张模型列表：主模型、备用模型、再备用模型。这个做法有用，但远远不够。真正难的地方在于，要判断哪些失败才应该把流量切到下一个路由。

配额耗尽、上游临时过载、无效的接口密钥、格式错误的请求、以及部分流式输出后超时，这些并不是同一种事件。如果把它们都当成“重试并降级”来处理，就会产生重复调用、掩盖配置错误，还会让用量记录难以解释。

一个可用的路由层，需要为每次尝试记录一组小而规范的结局信息：服务商和模型、协议路径、尝试标识、错误类别、输出是否已经到达客户端、请求是否适合安全重试，以及可用的重试等待或重置信息。

不同失败需要不同策略

有了这些信息，策略才能明确。无效凭证应该快速失败，继续尝试更多服务商通常只会掩盖配置错误。已知时间的配额重置应该进入冷却期，而不是立刻触发一连串重试。

临时过载可以支持一次有边界的降级尝试。部分流式输出后的超时，则需要感知下游状态，盲目重试可能重复输出、重复执行工具或重复计费。因不支持的参数被拒绝，属于能力不匹配，修复方式是调整请求形态，而不是再做一次相同的重试。

真正有用的指标不是“有多少次降级成功”，而是系统是否在不产生模糊重试、重复副作用或无法追踪成本的情况下完成了工作流。

路由语义不能假设完全一致

Your Model 的构建也围绕同一个实际问题：如何在真实工作流中比较不同服务商和模型路径，而不是假设每条路由的语义都完全相同。

当前的技术栈里，配额耗尽、临时过载和部分流式失败，到底是怎么区分的？如果还没有区分，那么降级策略很可能正在制造更多难以解释的用量和成本。