北京
模型列表只是起点，失败分类才是关键
多数模型服务降级系统一开始都只维护一张模型列表：主模型、备用模型、再备用模型。这个做法有用，但远远不够。真正难的地方在于，要判断哪些失败才应该把流量切到下一个路由。
配额耗尽、上游临时过载、无效的接口密钥、格式错误的请求、以及部分流式输出后超时，这些并不是同一种事件。如果把它们都当成“重试并降级”来处理，就会产生重复调用、掩盖配置错误，还会让用量记录难以解释。
一个可用的路由层，需要为每次尝试记录一组小而规范的结局信息：服务商和模型、协议路径、尝试标识、错误类别、输出是否已经到达客户端、请求是否适合安全重试，以及可用的重试等待或重置信息。
不同失败需要不同策略
有了这些信息，策略才能明确。无效凭证应该快速失败，继续尝试更多服务商通常只会掩盖配置错误。已知时间的配额重置应该进入冷却期，而不是立刻触发一连串重试。
临时过载可以支持一次有边界的降级尝试。部分流式输出后的超时，则需要感知下游状态，盲目重试可能重复输出、重复执行工具或重复计费。因不支持的参数被拒绝，属于能力不匹配，修复方式是调整请求形态，而不是再做一次相同的重试。
真正有用的指标不是“有多少次降级成功”，而是系统是否在不产生模糊重试、重复副作用或无法追踪成本的情况下完成了工作流。
路由语义不能假设完全一致
Your Model 的构建也围绕同一个实际问题：如何在真实工作流中比较不同服务商和模型路径，而不是假设每条路由的语义都完全相同。
当前的技术栈里，配额耗尽、临时过载和部分流式失败，到底是怎么区分的？如果还没有区分，那么降级策略很可能正在制造更多难以解释的用量和成本。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
