AI自动切模型，看似稳定其实更贵
主模型过载时，自动换一个模型继续回答，看起来像高可用。我却把这项功能关掉了。原因不是备用模型不好，而是它会把真实故障藏起来：你以为系统恢复了，实际已经换了脑子，长上下文可能重新发送，工具能力和表达风格也发生漂移。我的选择是保留同一模型，延长超时并做指数退避，让故障可见、成本可查、输出可复现。
“主模型挂了，就自动切备用模型。”
这几乎是所有AI网关都会宣传的卖点。
我也配置过。
后来我把fallback_providers从主配置里删掉，并且专门加了一条检查：升级、迁移、自动修复之后，只要它又出现，就视为配置漂移。
2026年8月22日再次回读当前配置：
1
2
3
provider: custom
default_model: gpt-5.6-sol
fallback_providers: null
这不是反对高可用。
恰恰相反：我不接受一种靠悄悄改变计算结果来伪装的“高可用”。
Hermes源码对备用链的注释很清楚：主服务发生限流、过载或连接失败时，按顺序尝试备用Provider和模型。
它能把一次失败请求救回来。
但从用户视角看，聊天窗口里只出现了一个正常答案。除非系统明确暴露路由信息，否则你很难立刻知道：
- 是主模型恢复了；
- 还是请求已经换到备用模型；
- 换了哪一个；
- 上下文是否重新发送；
- 工具调用是否仍然兼容；
- 本次成本按谁的价格计算。
接口成功不等于计算过程没变。
我长期使用的Agent不是一次性问答框。它带着系统规则、用户偏好、持久记忆、技能索引、工具定义和当前会话历史。
主模型请求失败后，如果备用上游无法复用原来的提示词缓存，整段上下文可能重新计费。
我能确认“不同Provider通常不能共享缓存”；但某次回退到底重发了多少、服务商如何计费，必须看各家usage记录，不能凭配置文件直接下结论。
所以我的判断不是“回退一定更贵”，而是：
跨上游回退有重复输入和缓存失效的成本风险，而且最容易在表面成功时被忽略。
模型不是可以随意替换的CPU核心。
同一个提示，在不同模型上可能出现这些差异：
一次普通聊天，这些差异可能无所谓。
一次配置修改、远程运维、文章发布或自动化写入，差异就可能变成事故。
比如主模型已经学会：修改复杂YAML必须完整解析后原子替换。备用模型没加载到相同经验，可能又用字符串替换硬改配置。请求“成功”了，系统却退回旧坑。
这是我最不能接受的一点。
假设主Provider从下午两点开始持续过载。备用链把请求全部接走，用户只感觉“今天回答风格有点怪”。
结果可能是：监控没有及时报警、主上游故障持续数小时、成本报表突然换了计费来源、输出质量下降却找不到切换时刻。
直到备用链也出问题，故障才一次性暴露。
高可用应该缩短故障，不应该隐藏故障。
对429、过载和短暂连接失败，我优先采用指数退避：
1
2
3
4
5
6
7
8
9
10
11
import random
import time
for attempt in range(6):
try:
return call_primary_model()
except TemporaryOverload:
delay = min(60, 2 ** attempt) + random.random()
time.sleep(delay)
raise RuntimeError("主模型持续不可用，保留真实故障")
等待时间大致是：
1
1秒 → 2秒 → 4秒 → 8秒 → 16秒 → 32秒
加一点随机抖动，是为了避免大量任务在同一秒重新撞回服务端。
这套方法的好处：
- 仍由同一个模型处理；
- 上下文和工具兼容性不变；
- 故障持续时间可观察；
- 重试耗尽后明确失败；
- 不会把“换模型”伪装成“服务恢复”。
代价也很直接：用户要多等，主模型长时间故障时任务会失败。
我接受这个代价。因为失败是诚实的，也是可诊断的。
我不是说所有系统都应该关闭回退。
这些场景适合自动回退：
- 无状态的短摘要；
- 批量分类和标签；
- 对模型差异不敏感的内容清洗；
- 已对主备模型跑过同一套评测；
- 每次切换都有明确日志、告警和成本归属；
- 业务目标是“尽量产出”，而不是“结果必须一致”。
这些场景我不建议静默回退：
- 有写入副作用的Agent；
- 配置修改与基础设施操作；
- 长会话和巨量上下文；
- 依赖特定工具调用格式；
- 对文风、判断和合规边界要求稳定；
- 故障必须被及时发现的生产系统。
日志中记录原Provider、原模型、失败原因、重试次数、切换时间和目标模型。
不要把所有异常都归为“换一家再试”。认证失败、参数错误、内容过长，换模型通常不会修好，只会制造第二份噪声。
用真实任务测工具参数、长上下文、JSON结构、副作用确认、文章与代码风格。
不能只看总Token。要知道哪次请求因回退产生了多少重复输入、是否命中缓存、备用模型单价是多少。
适合关闭静默回退的人：
- 有长期上下文的个人Agent；
- 对模型行为做过深度定制；
- 需要第一时间发现上游问题；
- 更在意可复现和可诊断，而不是每次都给出答案；
- 不想让切换模型重新消耗长上下文。
更适合保留回退的人：
- 请求短、无状态；
- 主备模型已经通过同一评测；
- 业务中断损失远大于输出差异；
- 有成熟的路由观测和成本报表。
我的选择不是普适答案，但边界非常明确：
主模型短暂过载，我愿意等；主模型真的坏了，我要看见。不能用另一个模型的正常回答，盖住第一个上游正在出事。
高可用不是永远显示绿色，而是出问题时仍然知道发生了什么。
「每天帮你踩一个 AI 的坑，省下一小时。」
你更能接受哪种故障：明确失败，还是悄悄换一个模型？