?? 高可用不是“永遠不報錯”，而是報錯時業務不掉下去

很多團隊第一次談高可用時，直覺是多準備幾個模型名，等主模型不通了再切。這個思路只對了一半。真正影響業務體驗的，不是切換動作有沒有發生，而是切換發生時，用戶有沒有明顯感知、任務有沒有中斷、賬單有沒有失控。

所以高可用接入的核心，不是簡單的備用模型列表，而是一整套降級秩序：什么錯誤允許重試，什么錯誤應該立即切換，什么請求必須保持同模型一致性，什么任務可以接受能力差異。

把這些規則提前寫明白，切換才是工程動作；不寫明白，切換就只是情緒化應對。

?? 先分清三類故障，再決定怎么切

第一類是連接層問題，比如超時、**抖動、短時擁堵。這類問題通常適合小次數、短間隔重試，不一定需要馬上換模型。

第二類是模型層問題，比如上游返回不可用、限流、當前模型維護中。這個時候繼續撞同一個目標意義不大，更適合直接切到預設備選模型。

第三類是業務層問題，比如提示詞不合法、格式校驗失敗、上下文過大。這類問題不是容災能解決的，應該直接返回清晰錯誤，讓調用方修請求。

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

?? 故障切換一定要配“切換邊界”

并不是所有請求都適合自由切換。像批量摘要、分類、標題生成這類任務，對模型一致性要求沒那么高，切換后通常只會帶來風格差異；但如果是合約審校、代碼生成或需要穩定結構化輸出的接口，隨意切換可能造成結果漂移。

因此建議把任務按容錯等級分層：可自由切換、可有限切換、不可切換。這個分層一旦建立，接入側就不會為了追求表面的成功率，把所有請求都硬切到另一家。

高可用真正值錢的地方，就是在出故障時仍然保持邊界感，而不是為了一次成功把后續排查全部搞亂。

?? 實際接入時，先把主備順序和超時閾值定下來

主模型通常負責質量最穩定的默認任務，備模型負責在擁堵或限流時接住請求。這里最容易犯的錯誤，是所有模型共用一套超時值。不同模型、不同任務長度，對等待時間的容忍度完全不同。

更實用的做法是：短問答用更短超時，長文本生成適當放寬；同步接口只保留一次重試，異步任務可以允許進入隊列后再切。只要規則和任務類型掛鉤，容災效果會比“統一重試三次”強很多。

統一入口配置時，常見做法就是把端點固定到 https://www.lnsns.com/，讓請求都從一個地方進入，再在內部做模型選擇和切換。

?? 沒有觀測，就沒有高可用

一套看起來很漂亮的主備方案，如果沒有日志和指標支撐，最后通常只會留下“系統好像更復雜了”。至少要盯住四個數據：主模型命中率、切換率、切換后成功率、切換后平均成本。

如果切換率很低但成功率高，說明主鏈路穩定；如果切換率很高但切換后成功率一般，說明你的備鏈路只是安慰劑；如果切換后成功率高但成本暴漲，說明策略需要更細，而不是繼續放大流量。

高可用不是一次性搭完的功能，更像持續調參。

?? 穩定鏈路的終點，不是更復雜，而是更可預測

真正成熟的中轉站，不會把所有問題都交給上游。它會在接入層先完成分流、重試、熔斷、切換，再把結果以可解釋的形式還給業務。

這樣做的好處很直接：白天流量上來時，團隊不會因為一波報錯就滿屏排查；晚上跑批時，也不會因為模型切換把預算徹底打散。

高可用做得好的系統，看起來往往不熱鬧，因為大多數問題還沒冒到用戶側，就已經在中間層被消化掉了。