不代表。
今天我們替 LiteLLM 設定了一條比較完整的備援規則：
暫時故障，可以換模型。
資料或能力有問題，不要亂換。
高風險操作，直接交回人。
做到這裡之後，很容易產生下一個錯覺：
「我已經有主要模型和備援模型，所以 AI 服務現在不會停了。」
其實還差很遠。
因為：
有備援模型，和整套 AI 服務真的高可用，是兩件不同的事。
先看最簡單的情況
假設客服 AI 平常使用模型 A。
模型 A 暫時發生服務錯誤。
LiteLLM 自動切換到已經測試過的模型 B。
模型 B 正常回答。
客戶沒有感覺到中斷。
這就是備援最理想的情況。
但它只證明：
這一次模型供應商故障時，另一個模型成功接手。
它沒有證明整條系統永遠不會停。
第一個問題：如果備援模型也壞了呢？
模型 A 可能過載。
模型 B 也可能同時遇到：
- Rate Limit。
- 區域性故障。
- 網路問題。
- 帳號限制。
- 部署不可用。
特別是兩個模型如果最後其實依賴：
同一個雲端。
同一個網路。
同一個帳戶。
甚至同一個區域。
看起來有兩條路，實際上可能共享同一個故障點。
這叫做「共同故障點」
最簡單的例子：
你準備兩個模型部署。
但它們全部依賴同一組網路連線。
網路一斷：
兩個都不能用。
所以備援真正要問的是：
第二條路是不是也依賴第一條路會壞掉的東西？
第二個問題：如果 LiteLLM 自己停了呢？
LiteLLM 放在 App 和模型供應商中間。
請求先進 LiteLLM。
再由它決定：
- 送哪個模型。
- 要不要 Retry。
- 要不要 Fallback。
所以如果所有 AI 流量都只經過一個 LiteLLM Gateway，而這個 Gateway 本身停掉：
後面即使有十個模型，也可能一個都收不到 Request。
這就是為什麼：
模型有備援，不代表 Gateway 自己也有備援。
真正正式環境還要看 Gateway 本身
當 LiteLLM 只是自己測試時，一台機器可能就夠。
但正式服務如果不能輕易停機，就要進一步考慮：
- Gateway 是否有多個執行實例。
- 前面是否有 Load Balancer。
- 資料庫是否可靠。
- Gateway 是否能被健康檢查。
- 異常時有沒有警報。
這已經不是「換哪個模型」的問題。
而是一般正式系統本來就需要處理的可靠性問題。
第三個問題：模型看起來活著，就代表真的能工作嗎？
也不一定。
假設模型 Provider 的 API 還可以連線。
所以系統認為：
它是正常的。
但實際送一份複雜文件後：
一直 Timeout。
或者某個區域突然非常慢。
這時只知道：
「這個模型存在。」
還不夠。
你還需要知道：
它現在是不是健康到足以接正式流量。
LiteLLM 有 Health Check Routing
LiteLLM 提供健康檢查導向的路由方式。
一般路由可能要等到：
真正有一位使用者送出 Request。
某個 Deployment 失敗。
系統才知道：
這條路現在有問題。
Health Check Routing 則可以利用健康檢查結果，提前避免把新的流量繼續送向已知不健康的 Deployment。
這會比：
「每次都先讓一個客戶撞到故障，再換路。」
更合理。
但 Health Check 也不是保證
因為系統狀況可能在幾秒鐘內變化。
剛才檢查正常。
下一秒仍然可能故障。
而且不同錯誤也不一定都代表 Deployment 已經完全壞掉。
例如：
暫時的 Rate Limit。
短暫 Timeout。
可能只是瞬間流量問題。
所以健康檢查的功能是：
降低把流量送進已知故障路徑的機率。
不是替系統加上一張「永不故障」保證書。
第四個問題：技術接手成功，工作可能還是失敗
這可能是 AI 系統最容易被忽略的一點。
假設：
模型 A 故障。
LiteLLM 正確切到模型 B。
模型 B 回傳 200。
從系統監控來看：
成功。
但模型 B 把退款政策理解錯了。
那對公司來說：
這次備援還是失敗。
所以高可用不能只有 Uptime
一般軟體很常追蹤：
服務有沒有在線。
但 AI 還多一層：
服務雖然在線，產生的結果到底能不能用？
因此至少應該分開看：
- 系統可用性。
- 模型回應成功率。
- 工作成果可用率。
三個不是同一件事。
例如模型 B 成功接手 100 次
技術紀錄可能顯示：
100 次 Fallback 都成功收到 Response。
看起來非常漂亮。
但如果人工檢查後：
- 60 件可以直接用。
- 30 件需要修改。
- 10 件完全失敗。
那麼你真正擁有的不是：
100% 完美備援。
而是一條：
技術接得上，但工作品質還需要改善的備援路線。
第五個問題：備援可能變得非常貴
假設主要模型比較便宜。
備援模型價格高很多。
平常只偶爾切一次，問題不大。
但如果主要 Provider 故障兩小時：
幾萬筆流量全部切過去。
帳單可能突然上升。
所以備援還需要問：
- 備援模型單次成本多少？
- 最多可以接多少流量？
- 預算上限是多少？
- 如果預算達上限怎麼辦？
這也是為什麼 LiteLLM 同時提供 Spend、Budget 與 Rate Limit 管理。
高可用不等於「不惜代價永遠回答」
這點很重要。
假設一個一般 FAQ。
多花一點錢切備援，可能合理。
但如果：
主要模型長時間故障。
備援成本是原來十倍。
公司不一定要：
無限制一直燒。
可以預先設定：
超過某個成本或流量後：
- 只保留重要工作。
- 降低非必要功能。
- 讓部分工作排隊。
- 轉人工。
這同樣是備援策略。
第六個問題：備援模型可能需要不同 Prompt
有些團隊會期待：
同一份 Prompt 丟給任何模型。
答案都一樣。
實際上不同模型可能：
- 對指令格式反應不同。
- 結構化輸出穩定度不同。
- Tool Calling 行為不同。
- 對長上下文處理不同。
所以真正的備援測試，不一定只測：
模型 B 能不能吃模型 A 的 Prompt。
而要測：
怎麼設定才能讓 B 穩定完成相同工作。
必要時，兩個模型可能需要不同版本的 Prompt。
第七個問題：有些故障根本不是模型造成的
例如客服 Agent 需要：
- 讀 CRM。
- 查訂單。
- 讀公司知識庫。
- 最後呼叫模型。
今天 CRM 掛了。
這時模型 A 換模型 B。
沒有任何幫助。
因為兩個模型都讀不到訂單。
所以 AI 系統真正的依賴其實是一條鏈：
App。
Gateway。
模型。
資料庫。
工具。
網路。
身份驗證。
其中任何一個必要環節出問題，都可能讓工作無法完成。
這也是為什麼 Agent 特別需要看整條流程
單純聊天可能只有：
使用者 → 模型 → 答案。
Agent 則可能是：
使用者 → Gateway → 模型 → CRM → 搜尋 → 模型 → Email → 完成。
鏈愈長：
潛在故障點愈多。
所以：
多一個備援模型，只補了其中一個節點。
那什麼才叫真正比較可靠？
至少要看五層。
第一層：模型備援。
主要模型失敗，有已驗證的替代模型。
第二層：部署健康。
避免新流量持續送到已知故障 Deployment。
第三層：Gateway。
不要讓模型入口本身變成唯一故障點。
第四層：工作品質。
備援模型真的能產生可用成果。
第五層：人工降級。
AI 都不能可靠工作時，還有辦法讓重要工作繼續。
「人工降級」到底是什麼？
例如客服 AI 全部暫時不可用。
不一定要整個網站顯示：
服務失敗。
可以改成：
- 先收集客戶問題。
- 建立人工待處理案件。
- 保留聯絡方式。
- 由真人稍後處理。
功能變少了。
但核心服務沒有完全消失。
這就是降級。
真正的高可用不一定代表：
任何時候所有功能都一模一樣。
而是：
系統出問題時，最重要的工作仍有一條可以安全繼續的路。
不要等正式故障才第一次測 Fallback
這和消防演習很像。
如果公司只寫：
「火災時走這裡。」
但從來沒有人真的走過。
真正發生火災時才可能發現：
那扇門根本打不開。
AI 備援也一樣。
不能只確認設定檔裡有模型 B。
要真的模擬：
模型 A 不可用。
然後看：
- 有沒有正確 Retry。
- 有沒有切到 B。
- B 的結果能不能用。
- 成本是否正常。
- 系統是否留下紀錄。
- 需要人工的案件是否真的停下來。
還要測「復原」
這一步更容易漏。
主要模型恢復後：
系統會不會正常回到主要模型？
還是所有流量永遠留在備援？
恢復後是否突然一次處理大量排隊工作？
是否產生重複執行？
故障只是半場。
恢復正常，也是備援測試的一部分。
最簡單的「五問」檢查法
如果已經設定模型備援，可以直接問五個問題。
一、主要模型真的壞掉時，會自動切嗎？
不是看設定，是實際測。
二、備援模型真的做得了同一份工作嗎？
看成果，不只看 Response。
三、Gateway 自己壞了怎麼辦？
不要只替模型準備備援。
四、模型以外的工具壞了怎麼辦？
CRM、資料庫與其他 API 都是依賴。
五、所有自動路徑都不行時，工作去哪裡？
這就是最後人工路徑。
可以直接使用的 AI 備援檢查 Prompt
我要檢查目前的 AI 系統是不是只有「看起來有備援」，還是真的能在故障時繼續服務。 目前工作： [描述工作] 主要模型： [模型] 備援模型： [模型] AI Gateway： [例如 LiteLLM] 另外依賴： [CRM、資料庫、搜尋、Email、外部 API 等] 請不要因為我已設定第二個模型，就直接判定高可用。 請分成五層檢查。 第一層：模型 主要模型真正故障時： 會 Retry 幾次？ 何時切備援？ 備援是否用真實案例測過？ 第二層：Gateway 如果 Gateway 本身停止： Request 還有沒有其他入口？ 是否存在單一故障點？ 第三層：其他工具 列出完成這項工作所有必要依賴。 每一個依賴停止時回答： 換模型有沒有用？ 可以降級嗎？ 還是必須停止？ 第四層：工作成果 備援模型成功回應後，如何確認： 答案可直接用、 需要修改、 還是失敗？ 不要把 HTTP 成功直接等於工作成功。 第五層：人工降級 如果所有自動路徑都失敗： 哪些資料先保留？ 工作放到哪裡排隊？ 由誰接手？ 哪些高風險操作必須直接停止？ 最後替我產生一份故障演習清單，至少測： 主要模型故障。 備援模型故障。 Gateway 故障。 必要工具故障。 所有 AI 都不可用。 主要模型恢復。 每個測試都寫清楚預期結果。 如果目前沒有備援措施，直接標示缺口，不要假設系統會自己恢復。
哪種小公司需要做到這麼多？
不是每一家公司。
如果 AI 只是：
- 幫忙寫文案。
- 整理個人筆記。
- 偶爾研究。
模型停半小時可能沒有什麼大問題。
直接換另一個聊天工具就好。
但如果 AI 已經負責：
- 正式客服。
- 網站功能。
- 每天大量自動化。
- 企業內部工作流程。
- 客戶付費使用的產品。
可靠性就開始變成真正的商業問題。
備援程度應該跟「停機代價」一起決定
如果 AI 停一小時：
只是少產生幾篇文案。
不需要建立銀行等級的基礎設施。
如果 AI 停一小時：
幾千名付費客戶全部不能使用產品。
那麼多投入一些成本建立備援就比較合理。
所以不要因為：
「高可用聽起來很專業。」
就什麼都做成最複雜。
真正要問的是：
這項服務停多久，我的生意才真的開始受傷？
今天最重要的答案
設定備援模型是一個非常好的開始。
但它只回答：
「模型 A 不能用時，有沒有另一個模型？」
真正的 AI 服務還要再問：
- 模型 B 真的能完成嗎？
- Gateway 自己會不會停？
- 其他工具是不是正常？
- 成本會不會失控？
- 系統怎麼知道某條路已經壞了？
- 所有 AI 都不能用時，人怎麼接手？
所以：
有備援，不等於高可用。
真正的高可用也不是「永遠不會故障」。
而是：
故障真的發生時，系統知道哪條路不能走、哪條路可以接手，以及最後什麼時候必須把工作安全交回人。
備援模型只是第二條路。
真正重要的是：
你有沒有真的走過一次。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
