🌐 高可用不是“永远不报错”，而是报错时业务不掉下去

很多团队第一次谈高可用时，直觉是多准备几个模型名，等主模型不通了再切。这个思路只对了一半。真正影响业务体验的，不是切换动作有没有发生，而是切换发生时，用户有没有明显感知、任务有没有中断、账单有没有失控。

所以高可用接入的核心，不是简单的备用模型列表，而是一整套降级秩序：什么错误允许重试，什么错误应该立即切换，什么请求必须保持同模型一致性，什么任务可以接受能力差异。

把这些规则提前写明白，切换才是工程动作；不写明白，切换就只是情绪化应对。

🧱 先分清三类故障，再决定怎么切

第一类是连接层问题，比如超时、**抖动、短时拥堵。这类问题通常适合小次数、短间隔重试，不一定需要马上换模型。

第二类是模型层问题，比如上游返回不可用、限流、当前模型维护中。这个时候继续撞同一个目标意义不大，更适合直接切到预设备选模型。

第三类是业务层问题，比如提示词不合法、格式校验失败、上下文过大。这类问题不是容灾能解决的，应该直接返回清晰错误，让调用方修请求。

retry:
  **x_attempts: 2
  timeout_ms: 20000
fall*ack:
  - claude-sonnet
  - gpt-4.1
  - glm-4.5

🔁 故障切换一定要配“切换边界”

并不是所有请求都适合自由切换。像批量摘要、分类、标题生成这类任务，对模型一致性要求没那么高，切换后通常只会带来风格差异；但如果是合约审校、代码生成或需要稳定结构化输出的接口，随意切换可能造成结果漂移。

因此建议把任务按容错等级分层：可自由切换、可有限切换、不可切换。这个分层一旦建立，接入侧就不会为了追求表面的成功率，把所有请求都硬切到另一家。

高可用真正值钱的地方，就是在出故障时仍然保持边界感，而不是为了一次成功把后续排查全部搞乱。

⚙️ 实际接入时，先把主备顺序和超时阈值定下来

主模型通常负责质量最稳定的默认任务，备模型负责在拥堵或限流时接住请求。这里最容易犯的错误，是所有模型共用一套超时值。不同模型、不同任务长度，对等待时间的容忍度完全不同。

更实用的做法是：短问答用更短超时，长文本生成适当放宽；同步接口只保留一次重试，异步任务可以允许进入队列后再切。只要规则和任务类型挂钩，容灾效果会比“统一重试三次”强很多。

统一入口配置时，常见做法就是把端点固定到 https://www.lnsns.com/，让请求都从一个地方进入，再在内部做模型选择和切换。

📉 没有观测，就没有高可用

一套看起来很漂亮的主备方案，如果没有日志和指标支撑，最后通常只会留下“系统好像更复杂了”。至少要盯住四个数据：主模型命中率、切换率、切换后成功率、切换后平均成本。

如果切换率很低但成功率高，说明主链路稳定；如果切换率很高但切换后成功率一般，说明你的备链路只是安慰剂；如果切换后成功率高但成本暴涨，说明策略需要更细，而不是继续放大流量。

高可用不是一次性搭完的功能，更像持续调参。

🏁 稳定链路的终点，不是更复杂，而是更可预测

真正成熟的中转站，不会把所有问题都交给上游。它会在接入层先完成分流、重试、熔断、切换，再把结果以可解释的形式还给业务。

这样做的好处很直接：白天流量上来时，团队不会因为一波报错就满屏排查；晚上跑批时，也不会因为模型切换把预算彻底打散。

高可用做得好的系统，看起来往往不热闹，因为大多数问题还没冒到用户侧，就已经在中间层被消化掉了。