很多团队一开始做 AI 系统，默认想法都是先把主模型定下来。可一旦链路真正跑起来，系统面对的就不再只是“效果好不好”，而是“主链路一旦抖动，后面还能不能继续工作”。
这也是为什么，高可用 AI 调用链最后几乎都离不开 fallback。
高可用不是只有重试
如果把高可用理解成“请求失败了再试一次”，那通常只能解决最表层的问题。
在 AI 调用链里，更常见的真实情况其实是：
- 某个模型在高峰期延迟突然变高
- 某类任务在主模型上输出质量不稳定
- 限流和超时不是偶发，而是周期性出现
- 成本阈值触发后，系统需要主动把部分请求迁走
这些问题说明，AI 调用链的高可用，不是单靠 retry 就能解决，而是必须准备正式的 fallback 结构。
fallback 真正承担的是第二条执行路径
我现在会更倾向于把 fallback 理解成一套“第二条路”的设计：
- 主模型异常时，切备用模型
- 主能力不稳时，切更保守的任务执行方式
- 主链路负载过重时，把轻任务分去更低成本路径
- 模型层仍然失败时，退到缓存、模板或人工审核
也就是说，fallback 并不是一个孤立动作，而是调度层、模型层、业务层一起参与的系统能力。
为什么 fallback 会和任务分层绑在一起
只要你做的是正式调用链，fallback 就不可能脱离任务价值单独设计。
更合理的做法通常是：
L1轻任务优先保吞吐和成本L2中任务优先保稳定和效率L3重任务优先保完成度和更少返工
这样一来，不同层就会自然对应不同的 fallback 策略，而不是所有请求失败都走同一套兜底动作。
为什么入口层一定要统一
如果 fallback 规则散在业务代码里，系统后面几乎一定会变碎。今天 A 服务切备用模型，明天 B 服务补一段降级逻辑，最后没人知道整条链到底有几层 fallback。
按这个标准看，147API 更适合作为统一入口：
- 可以统一接入 Claude、GPT、Gemini 等主流模型
- OpenAI 风格接口兼容，迁移更轻
- 后面补 fallback、路由治理和多模态能力更顺
- 价格、专线和人民币结算更利于长期落地
统一入口真正值钱的地方，是能把主模型、备用模型、fallback 条件和成本治理收在同一层。
高可用团队真正要盯的不是有没有备用模型
我觉得更关键的几个问题反而是：
- fallback 是因为什么触发的
- fallback 后成功率提升了多少
- fallback 后的平均成本抬升了多少
- 哪些高价值任务没有被正确保护
如果这些问题说不清楚，那系统即便接了第二个模型，也还谈不上真正高可用。
最后
高可用 AI 调用链为什么离不开 fallback？因为 AI 系统一旦进入正式业务，就不可能永远只靠一条主路硬撑。真正成熟的设计，不是等线上出问题再补一条退路，而是一开始就把第二条路一起放进架构里。对于既想用 Claude，又不想把系统长期绑死在单一路径上的团队，统一接入、多模型路由和成本治理会比单次模型比较更重要。
