案例性質：以下是一個假設示範案例，用來說明小型企業如何使用 LiteLLM 管理多模型、備援與成本。公司規模、案件量、模型安排與改善結果均為 SasaDaily 教學假設，不是真實企業或 LiteLLM 官方公布的導入案例。
一家六人的戶外旅遊公司，每週都要處理大量旅客詢問。
問題看起來都叫做「客服」。
實際上差很多。
有人問：
- 集合地點在哪裡？
- 需要自己帶雨衣嗎？
- 行程大約多久？
- 可以帶小孩嗎？
也有人一次貼上一大段英文保險條款，詢問行程取消問題。
還有人要求：
- 更改出發日期。
- 取消訂位。
- 退款。
- 修改付款資料。
公司原本把所有問題都送進同一個大型模型。
久了以後出現三個問題。
第一，簡單問題也在使用昂貴模型。
第二，主要模型一旦暫時故障，整個 AI 客服一起停。
第三，團隊為了避免服務中斷，差點把「換另一個模型」當成所有錯誤的解決方法。
於是他們開始使用 LiteLLM，重新設計整個入口。
第一步不是接更多模型，而是先把工作分開
團隊先把過去一個月的客服問題分成四組。
第一組：一般 FAQ。
- 集合資訊。
- 裝備清單。
- 一般行程內容。
- 已確認的交通方式。
第二組：需要閱讀較長資料的問題。
- 完整活動規則。
- 多份行前文件。
- 不同語言的旅客詢問。
- 需要綜合多項條件的問題。
第三組：資料不足。
- 沒有訂單編號。
- 沒有說明參加哪一場活動。
- 同行人數不明。
- 資訊前後矛盾。
第四組：正式交易與重要變更。
- 付款。
- 退款。
- 正式改期。
- 取消訂位。
- 修改已確認的旅遊安排。
這一步非常重要。
因為團隊很快發現：
「客服」不是一種 AI 工作。
不同問題需要的模型能力、成本與權限完全不同。
第二步：一般 FAQ 不再全部使用最強模型
像：
「需要自己準備水嗎？」
「集合前多久到？」
這些問題主要需要的是：
- 讀取已確認資料。
- 正確回答。
- 速度穩定。
- 成本低。
不需要每一次都動用公司最昂貴的推理模型。
所以團隊把這類工作設定成：
低成本主模型。
但不是因為便宜就直接上線。
公司先拿過去真實 FAQ 進行測試。
確認：
- 沒有改掉正式資訊。
- 回答格式正常。
- 不同語言仍可接受。
- 人工修改量沒有明顯增加。
通過後才正式接流量。
第三步：複雜問題才送能力較強的模型
另一位旅客可能一次提供：
- 原始訂位資料。
- 活動條款。
- 保險文件。
- 個人需求。
再問：
「如果遇到大雨，我應該怎麼處理？」
這類工作需要理解更多上下文。
團隊可以先讓系統判斷：
這是不是一般 FAQ？
如果不是，再送到能力較強、可處理較長資料的模型。
於是同一家公司就出現兩條模型路線：
大量簡單工作，用夠用又便宜的模型。
真正複雜的工作，再使用能力較強的模型。
這比所有事情都固定送往最高階模型，更接近實際成本管理。
LiteLLM 在中間做什麼？
LiteLLM 並不是替公司回答旅客問題的另一個模型。
它比較像模型入口。
公司自己的客服系統先把 Request 交給 LiteLLM。
再依照設定：
- 送到指定模型。
- 限制哪些模型可以使用。
- 管理不同模型部署。
- 遇到指定錯誤時 Retry。
- 必要時執行 Fallback。
所以真正產生答案的，仍然是後面的模型。
LiteLLM 管的是：
這一筆工作應該往哪裡走。
第四步：替一般客服準備一個真正測過的備援模型
假設平常 FAQ 使用模型 A。
模型 A 某天下午因 Provider 暫時故障無法使用。
原本公司只有兩個選擇：
AI 客服整個關掉。
或者工程師臨時改程式。
現在團隊事先準備模型 B。
而且 B 已經跑過同一批 FAQ 測試。
確認它可以：
- 正確讀取公司資料。
- 維持必要輸出格式。
- 回答主要語言。
- 達到最低品質標準。
於是流程可以設成：
模型 A。
暫時失敗。
先 Retry。
仍然失敗。
切模型 B。
這時才是真正有意義的 Fallback
因為模型 B 不是：
「剛好另一個帳號裡有的 AI。」
而是：
已經驗證可以完成這一類工作。
所以公司不是在故障發生後臨時賭運氣。
而是在故障以前，就準備好第二條路。
第五步：資料不足時禁止切模型
另一位旅客只傳來一句：
「我要改星期六那一場。」
但系統不知道：
- 他是誰。
- 訂單是哪一筆。
- 參加什麼活動。
- 原本日期是哪一天。
模型 A 因資料不足無法完成。
這時 LiteLLM 技術上就算可以切到模型 B，也不應該這麼做。
因為：
換模型不能把不存在的訂單資料變出來。
公司因此把這種情況設成：
不可 Fallback。
下一步是：
要求補資料。
這個規則可以避免一個很危險的錯誤
如果系統一直嘗試不同模型：
A 說不知道。
換 B。
B 也不知道。
再換 C。
最後可能剛好有一個模型開始猜。
結果系統反而把：
「缺少資料。」
變成：
「看起來有答案。」
所以公司設定：
資料不足不是模型故障，不得靠 Fallback 解決。
第六步：退款和正式改期不自動切模型
最重要的規則出現在交易流程。
旅客要求：
「幫我把明天的行程取消並退款。」
AI 可以先：
- 整理要求。
- 讀取公司取消規則。
- 確認目前還缺哪些資料。
- 建立真人處理摘要。
但公司規定：
真正的：
- 退款。
- 改期。
- 訂單金額變更。
- 正式取消。
都必須由真人確認。
所以主要模型如果在這裡失敗：
系統不會想：
「趕快找另一個 AI 繼續做完。」
而是：
停止自動流程，轉人工。
對這家公司來說，人就是最後一個 Fallback
這個觀念非常重要。
Fallback 不一定永遠是：
模型 A → 模型 B → 模型 C。
也可以是：
模型 A → 模型 B → 人。
甚至：
模型 A → 直接人。
差別只在：
這件工作如果出錯，代價有多大。
第七步：替不同客服工作設定不同預算
公司發現另一個問題。
如果全部模型都使用同一組 API Key，很難知道錢花在哪裡。
所以團隊利用 LiteLLM 的 Virtual Key 與 Budget 管理，把用途拆開。
例如：
一般 FAQ。
一個預算。
多語與複雜文件。
另一個預算。
測試環境。
另外限制。
這樣就能避免工程師測試新 Prompt 時，不小心使用正式環境的大額模型預算。
還要替備援模型設成本上限
假設備援模型 B 比主要模型 A 貴很多。
平常一天只切十次。
沒有問題。
但如果 A 故障四小時，幾千筆客服一起跑去 B：
帳單可能突然放大。
所以公司不能只設定：
「A 壞了全部去 B。」
還要設定：
- 允許哪些工作切換。
- 每分鐘最大流量。
- 可接受預算。
- 超出後怎麼降級。
例如超過預算後，不一定整個關掉
可以把服務縮小。
優先保留：
- 出發當日旅客問題。
- 正在進行中的活動。
- 緊急聯絡資訊。
暫時延後：
- 一般旅遊建議。
- 低優先度內容整理。
- 非即時 FAQ。
真正的可靠性不是：
不惜代價讓所有 AI 永遠回答。
而是：
資源不足時，最重要的工作仍然能繼續。
第八步：把 LiteLLM 和 Langfuse 接起來
昨天我們使用 Langfuse 處理另一個問題：
AI 每一筆工作到底：
- 花多少。
- 跑多久。
- 結果能不能用。
LiteLLM 官方支援把 LLM Request 的觀測資料送往 Langfuse。
所以這家公司可以進一步看到：
這一筆客服：
原本走模型 A。
A 發生錯誤。
最後切到模型 B。
模型成本是多少。
完成速度是多少。
然後再把客服自己的結果資料接進來。
例如一個月後，可以看到這些問題
哪種 FAQ 最常觸發 Fallback？
哪個模型最常 Timeout？
備援模型接手後，人工修改是不是增加？
哪一類客服根本不值得使用高階模型？
哪一類工作即使模型正常，最後仍大量轉真人？
這時多模型架構才真正開始產生管理價值。
假設原本一個月有 4,000 件 AI 客服
以下全部是假設數字，只用來說明分析方法。
其中：
- 一般 FAQ：2,500 件。
- 多語與長文件：900 件。
- 資料不足：400 件。
- 付款、退款與正式變更：200 件。
以前全部使用同一個高階模型。
重新設計後：
2,500 件簡單 FAQ 先走已測試的低成本模型。
900 件複雜問題才使用能力較強模型。
400 件資料不足的工作先補資料，不浪費模型一直重試。
200 件正式交易則保留人工確認。
這時真正省下的可能不是「換便宜模型」而已
還包括：
- 少用不必要的高階模型。
- 減少無意義 Retry。
- 資料不足時不再呼叫多個模型。
- Provider 故障時減少整體停機。
- 高風險工作不再讓 Agent 反覆嘗試。
所以真正的多模型成本管理不是：
找全世界最便宜的一個 API。
而是：
每一件工作只使用足夠完成它的資源。
第九步：每個月重新檢查主要模型與備援模型
備援不是設定一次就永遠不動。
模型會：
- 更新。
- 漲價。
- 降價。
- 改變限制。
- 出現新的替代方案。
所以團隊每個月抽一批真實工作。
重新測：
- 主要模型。
- 第一備援。
- 候選新模型。
比較：
- 成本。
- 正確率。
- 人工修改時間。
- 速度。
- 工具能力。
如果新的便宜模型真的通過測試，才逐步增加正式流量。
不要直接把所有流量一次搬過去
例如原本模型 A 每天處理兩千件。
模型 C 測試表現不錯。
公司不需要第一天把兩千件全部切走。
可以先讓一小部分低風險工作使用 C。
再觀察：
- 實際錯誤。
- 人工修改。
- 延遲。
- 真實使用成本。
沒有出現問題，再逐步增加。
這比一次更換所有正式流量穩定很多。
第十步：每個工作都要有最後停止條件
這家公司最後替每條 AI 路線加上一個共同原則：
系統不需要不惜代價完成每件工作。
例如：
- 主要模型不可用。
- 備援模型也不可用。
- 資料不足。
- 外部訂位系統故障。
- 即將修改正式交易。
遇到這些條件時：
正確答案可能就是：
停止自動化。
先留下目前已知資料。
建立人工待處理案件。
讓人接手。
可以直接使用的多模型客服設計 Prompt
你是我的多模型 AI 客服架構顧問。 公司業務： [描述] 目前客服工作： [列出常見問題] 目前模型： [主要模型與候選模型] 請不要直接替所有工作設定同一個模型，也不要讓所有錯誤都自動 Fallback。 第一步：工作分類 把客服分成： 低風險、重複性高。 需要較強模型或長上下文。 資料不足。 高風險或不可逆操作。 第二步：模型需求 對每一類列出真正需要： 文字。 圖片。 長文件。 多語。 結構化輸出。 Tool Calling。 再選擇最低能力已足夠的模型。 第三步：主要模型與備援 每一類工作分別指定： 主要模型。 已測試備援模型。 如果沒有符合最低能力的備援，寫「無自動備援」。 第四步：錯誤處理 把錯誤分成： 可 Retry。 可 Fallback。 要求補資料。 直接轉人工。 第五步：成本 替每個工作類別設定： 合理的模型成本。 Rate Limit。 月預算。 備援模型可以使用的最大流量。 第六步：人工邊界 付款、 退款、 正式改期、 合約變更、 重大承諾、 其他不可逆操作， 全部列出人工確認點。 第七步：正式上線測試 主要模型與備援模型必須使用相同真實案例比較： 正確率。 人工修改時間。 延遲。 成本。 輸出格式。 工具呼叫。 最後替每個工作建立： 正常路徑。 主要模型故障路徑。 資料不足路徑。 高風險路徑。 全部 AI 不可用時的人工路徑。 不要因為系統技術上可以切模型，就預設所有工作都應該自動切換。
這個案例最容易犯的四個錯
第一，為了省錢，把所有工作都送便宜模型。
應該先達到工作能力門檻，再比較成本。
第二，為了不中斷，所有錯誤都切備援。
資料不足與高風險操作不是換模型就能解決。
第三，只測模型會不會回答。
還要測輸出格式、人工修改與工具呼叫。
第四，把技術接手成功當成商業成功。
模型 B 成功回傳，不代表旅客問題真的被解決。
真正要追蹤的不是「用了幾個模型」
公司最後只需要幾個真正有用的指標：
- 每類工作平均模型成本。
- 主要模型故障率。
- Fallback 發生比例。
- 備援後成果可用率。
- 人工修改時間。
- 真正解決比例。
如果公司接了十個模型，卻不知道哪一個替哪種工作創造價值：
那不叫多模型策略。
只是多了十張帳單。
今天最重要的商業判斷
小公司沒有能力像 Microsoft 一樣自己設計 AI 晶片。
也不需要。
但可以控制另一種依賴：
不要讓所有 AI 工作只剩一條路。
LiteLLM 可以讓企業集中管理模型入口、Retry、Fallback、預算與不同 Provider。
但真正成熟的架構不是：
模型愈多愈好。
也不是：
任何問題都一定要找到另一個 AI 接手。
而是每一件工作都先回答：
需要多強的模型？
值得花多少？
哪個備援真的測過？
資料不足時要去哪裡？
什麼操作不能自動繼續？
如果所有 AI 都不能可靠完成，誰來接手？
當這六個問題都答得出來，多模型才真正從「技術選項」變成「營運能力」。
真正可靠的 AI 公司，不是永遠不會遇到故障。
而是故障來的時候，系統知道：
哪件工作可以換路、哪件工作應該停，以及什麼時候一定要把決定權交回人。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
