AI網關多模型災備：當Claude宕機時自動降級

生產環境里，LLM調用失敗只有兩種結局：要么服務掛掉，要么用戶看到報錯。但很多人直到第一次踩坑才意識到——單模型架構本身就是單點故障。

這篇技術文檔展示了一套基于Kubernetes網關的自動降級方案。核心思路不復雜：在主模型不可用時，網關自動把流量切到備用模型，整個過程對上游應用透明。

先搭基礎架構。需要三個組件：Gateway負責流量入口，AgentgatewayBackend定義后端模型，HTTPRoute做路由規則。以Anthropic的Claude Opus為例，先把API Key存成K8s Secret，再創建Gateway對象監聽8080端口，允許同命名空間流量。Backend里指定模型名稱claude-opus-4-6，并關聯認證Secret。最后用HTTPRoute把/v1路徑的請求全部轉發到這個Backend。

到這里只是單模型配置。災備的關鍵在Backend的擴展能力——同一個HTTPRoute可以綁定多個Backend，并設置優先級和觸發條件。當Opus返回429（限流）或5xx（服務異常）時，網關自動嘗試下一個Backend。備用選項可以是同廠商的輕量模型，也可以是其他廠商的API，比如把Claude 3 Haiku或GPT-3.5作為降級方案。

這種設計解決兩個真實痛點。一是成本突發：業務高峰時頂級模型token耗盡，自動降級到便宜模型保證服務可用。二是廠商故障：某家LLM API區域性宕機時，流量秒級切換到備用線路，無需人工改配置發版。

實現細節上有幾個權衡。降級策略需要定義清楚——是嚴格按優先級順序嘗試，還是根據錯誤類型智能選擇？超時時間設多長？備用模型和主模型的輸出格式是否兼容？這些沒有標準答案，取決于業務對延遲、成本、質量的容忍度。

最后提醒一個常見坑：很多團隊會把災備模型配置成"永遠不用"，結果真 failover 時發現備用模型早已下線或API Key過期。建議把降級流量常態化，比如把5%的請求隨機打到備用模型，既驗證鏈路健康，又能持續對比模型效果。