今天早報談到一個很大的產業變化：
Microsoft 想掌握更多自己的 AI 晶片。
Nvidia 想讓更多長期資本進入 AI 基礎設施。
但如果把問題縮小到一家公司，還有另一種依賴很容易被忽略：
你的整套 AI 工作，是不是只要一個模型供應商出問題，就全部停下來？
例如公司現在所有功能都直接寫死：
- 客服只能用某一家模型。
- 摘要只能用某一家 API。
- 某一家漲價就只能接受。
- 某一家 Rate Limit，整個流程就卡住。
今天介紹的工具，就是處理這一層問題。
它叫做：
LiteLLM。
LiteLLM 是什麼？
最白話的理解方式是：
它像一個放在你的 AI App 和各家模型中間的轉接站。
原本你的程式可能分別連：
- OpenAI。
- Anthropic。
- Gemini。
- Azure。
- Amazon Bedrock。
- 其他模型服務。
每一家都有自己的模型名稱、API 設定與部分不同格式。
LiteLLM 則把大量不同模型包成一個比較一致的呼叫方式。
你的 App 先送請求給 LiteLLM。
再由 LiteLLM 決定這一筆工作應該送去哪個模型。
這有什麼實際好處？
假設一家小型 SaaS 原本所有客服都直接連模型 A。
有一天模型 A 暫時故障。
原本結果是：
客服一起停。
如果中間有 LiteLLM，就可以先設計：
主要模型失敗一定次數後，改送到模型 B。
這叫做：
Fallback。
也就是備援。
但先別把 Fallback 想成「隨便換一個 AI 都一樣」
這是今天最重要的限制。
模型 A 和模型 B 即使都能回答同樣的 Prompt，也不代表：
- 答案品質相同。
- 工具呼叫格式完全相同。
- 速度相同。
- 價格相同。
- 長文件能力相同。
- 安全行為相同。
所以備援真正正確的意思不是：
「A 掛掉就亂找一個模型。」
而是：
事先測過 B 可以完成這項工作，A 不可用時才切過去。
第一個最實用功能：一套程式接很多模型
LiteLLM 支援大量不同 AI 模型與供應商。
常見的包括：
- OpenAI。
- Anthropic。
- Gemini。
- Azure。
- Amazon Bedrock。
- Vertex AI。
- Qwen。
- 多種開放模型與第三方推論服務。
所以開發者不必替每一家公司重新建立一整套完全不同的呼叫架構。
這對未來想換模型尤其重要。
例如：客服第一天用模型 A
假設公司開發一個客服功能。
第一版選模型 A。
半年後出現模型 B。
B：
- 價格更低。
- 回答速度更快。
- 客服品質也已經通過測試。
如果整套產品和 A 綁得非常深，換模型可能要改很多程式。
如果中間已經使用統一 Gateway，模型切換會比較容易管理。
但「比較容易切換」不代表不需要測試。
真正切正式流量以前，仍然應該用相同真實案例重新驗證。
第二個功能：同一模型也可以做 Load Balancing
有時問題不是要換不同模型。
而是同一種模型有多個部署。
例如：
- 不同 Azure 區域。
- 不同雲端帳戶。
- 不同推論端點。
LiteLLM Router 可以把工作分散出去。
如果某個部署發生 Rate Limit 或暫時不可用，可以換其他健康部署處理。
這就是 Load Balancing。
對一般使用者來說可以理解成：
不要讓所有車子都只能走同一個入口。
第三個功能：失敗後先 Retry，再 Fallback
一個 API 呼叫失敗，不一定代表模型完全不能用了。
可能只是：
- 暫時連線錯誤。
- 某個部署過載。
- Rate Limit。
LiteLLM 的 Router 可以先重試。
同一組部署仍然失敗後，再依事先設定的 Fallback 轉到其他模型群組。
這比應用程式自己到處寫：
如果 A 失敗，試 B。
如果 B 又失敗，再試 C。
容易集中管理很多。
但哪些工作不適合無條件自動 Fallback？
例如：
- 正式法律文件。
- 重要財務判斷。
- 醫療相關工作。
- 付款。
- 正式報價。
- 高度依賴特定模型工具能力的 Agent。
假設原模型失敗。
你不能因為「系統一定要回一個答案」，就立刻把工作送給一個沒有驗證過的模型。
這種工作比較合理的 Fallback 可能是：
停止，轉人工。
所以備援不一定永遠是另一個 AI。
有時最正確的備援就是人。
第四個功能：替不同工作設定預算
模型愈多，另一個問題就出現了。
帳單也愈多。
LiteLLM 可以追蹤不同模型的 Spend。
也能利用 Virtual Key 把模型權限與預算分開。
例如：
客服團隊：
每月最多使用某個預算。
內容團隊：
另一個預算。
實驗環境：
限制更低，避免測試程式失控燒錢。
甚至可以替不同 Agent 設 Rate Limit 或 Budget。
為什麼 Virtual Key 比大家共用原始 API Key 好？
假設十名員工全部直接拿到同一把模型供應商金鑰。
月底帳單突然變高。
你很難知道：
- 哪個團隊用了。
- 哪個 App 花最多。
- 哪個測試程式失控。
LiteLLM Gateway 可以替不同團隊或系統建立自己的 Virtual Key。
再分別設定：
- 可使用模型。
- 預算。
- Rate Limit。
這樣控制會比到處散落原始 Provider Key 更清楚。
但 LiteLLM 不是另一家模型公司
這一點也很重要。
它本身不是：
另一個 ChatGPT。
也不是：
自己訓練一個模型替你回答。
它比較像：
AI 模型流量的管理層。
真正產生答案的，仍然可能是 OpenAI、Claude、Gemini 或你設定的其他模型。
所以模型費還是照付
使用開源版 LiteLLM，不代表：
OpenAI API 免費。
Claude API 免費。
Gemini API 免費。
模型供應商仍然依自己的價格收費。
LiteLLM 做的是：
統一管理它們。
而不是替你吸收模型帳單。
LiteLLM 本身免費嗎？
官方目前提供可自行部署的免費開源版本。
官方網站目前把開源方案標示為免費，包含多模型整合、Virtual Keys、預算、Load Balancing、Guardrails 與多種 Observability 整合。
企業若需要更進階的組織管理、支援與服務等級，則另有 Enterprise 方案。
企業價格依部署規模洽詢。
自己部署也不是零成本
和所有 Self-hosted 工具一樣。
軟體可以免費。
你仍然要負責：
- 伺服器。
- 資料庫。
- 部署。
- 更新。
- 安全修補。
- 備份。
- 監控。
所以對完全沒有技術團隊的小公司來說，不一定因為免費就適合立刻自己架。
今天介紹它，不代表每個 ChatGPT 使用者都需要
如果你只是：
- 每月付 ChatGPT Plus。
- 平常直接打開 Claude。
- 偶爾使用 Gemini。
你不需要為了切換聊天工具就安裝 LiteLLM。
直接開不同 App 還比較簡單。
LiteLLM 真正適合的是：
- 自己做 AI App。
- 使用模型 API。
- 建立 Agent。
- 使用 n8n 串接多個 AI。
- 團隊開始管理多家模型。
和昨天 Langfuse 有什麼不同？
兩個工具很容易被混在一起。
LiteLLM 比較像交通警察。
它決定：
- 這個請求送哪裡。
- 失敗後去哪裡。
- 可以花多少。
- 哪把 Key 可以用哪些模型。
Langfuse 比較像行車記錄與分析系統。
它更專注：
- 這次工作經過哪些步驟。
- 花多少。
- 跑多久。
- 品質怎麼樣。
而且 LiteLLM 官方本身也支援把 Logging 接到 Langfuse。
所以兩個工具不是一定二選一。
一個負責入口與路由。
一個負責更深入觀察 AI 工作。
最實際的第一種用法：替客服準備第二模型
假設現在客服正式使用模型 A。
不要第一天設定：
A 失敗 → 隨便切模型 B。
先準備 20 到 50 個真實客服案例。
讓模型 B 跑同樣資料。
比較：
- 正確率。
- 格式。
- 工具呼叫。
- 人工修改時間。
- 成本。
確認它真的能接手，再設定成 Fallback。
這才叫備援。
第二種用法：便宜模型處理簡單工作
公司不一定需要所有工作都用最強模型。
例如：
簡單分類：
便宜模型。
一般客服：
中階模型。
複雜研究：
高階模型。
LiteLLM 可以成為中間入口。
讓不同類型工作走不同模型。
這就是 Model Routing。
但不要把「自動選最便宜」當唯一目標
便宜模型如果一直答錯，最後還是更貴。
所以模型路由最好不是：
哪個最便宜，就全部給它。
而是：
符合這項工作的最低能力門檻後，再比較成本。
這和我們之前談過的 20 題真實工作測試是一樣的概念。
第三種用法：不同地區準備不同 Provider
一家公司可能同時服務不同地區。
某些模型：
- 在不同地區可用性不同。
- 資料處理要求不同。
- 延遲不同。
這時 Gateway 可以讓企業把「哪個地方走哪個模型」集中管理。
但地區與資料合規仍應依真正使用的 Provider 條款、企業政策與當地要求確認。
不能因為中間加了一層 LiteLLM，就把底層供應商的資料規則一起消除。
第四種用法：限制某個 Agent 最多花多少
Agent 和一般一次問答不同。
它可能：
- 規劃一次。
- 搜尋五次。
- 呼叫模型三次。
- 失敗後再重試。
如果沒有上限，一個失控流程可能產生大量模型呼叫。
所以除了工作品質，還可以替 Agent 設定：
- RPM。
- TPM。
- Session 執行次數。
- 金額預算。
這種限制很實際。
因為安全不只有：
不要刪檔案。
也包括：
不要讓一個錯誤流程一直燒錢。
第五種用法：主要供應商故障時不要讓服務整個消失
對正式產品來說，模型服務也是供應鏈。
就像：
- 網站主機。
- 付款服務。
- Email。
都可能出現暫時故障。
AI 也一樣。
所以企業可以提前設計：
正常：
主要模型。
主要模型暫時故障：
已驗證的備援模型。
兩者都不能安全完成：
停止或轉真人。
三層會比「永遠一定要給答案」可靠很多。
最容易設定錯的地方：備援能力比主模型弱
假設主模型支援：
- 超長文件。
- 特定 Tool Calling。
- 圖片。
- 某種結構化輸出。
備援模型卻沒有。
這時 API 雖然成功切換，工作還是可能失敗。
所以每組 Fallback 都應該先列：
- 需要哪些輸入。
- 需要哪些工具。
- 需要什麼輸出格式。
- 最低 Context 長度。
- 可接受品質。
只要其中一項不符合，就不應當無條件備援。
如果兩個模型答案風格不同怎麼辦？
這在正式產品尤其重要。
例如主模型回答：
簡短、固定格式。
備援模型突然：
非常長，而且改變結構。
後面的程式就可能出錯。
所以正式切換前，不只測「內容有沒有答對」。
還要測：
- 輸出格式。
- JSON。
- 欄位。
- Tool Call。
- 錯誤處理。
LiteLLM 可以取代模型測試嗎？
不能。
它解決的是：
怎麼接。
怎麼路由。
怎麼備援。
怎麼管預算。
它不能替你證明：
模型 B 在你的工作上真的和模型 A 一樣好。
所以正確順序應該是：
先測試，再路由。
不是：
先把十個模型接進去，再期待系統自己知道哪個最好。
可以直接使用的 LiteLLM 路由規劃 Prompt
你是我的多模型 AI Gateway 架構顧問。 我目前的 AI 工作是： [描述工作] 目前主要模型： [模型] 希望加入的候選模型： [模型 A、模型 B、模型 C] 目前使用量與預算： [填寫] 請不要直接叫我把所有模型都設定成自動 Fallback。 先替每一項工作整理： 一、工作需求 需要： 文字？ 圖片？ 長文件？ Function Calling？ 結構化輸出？ 網路搜尋？ 多步驟 Agent？ 二、主要模型 目前為什麼使用它？ 它最不能被替代的能力是什麼？ 三、備援候選 哪些模型具備相同最低必要能力？ 如果缺少某項能力，直接排除，不要因為價格便宜就列為備援。 四、Fallback 條件 請區分： 暫時 Rate Limit。 Provider 故障。 Timeout。 內容安全拒絕。 模型能力不足。 資料不完整。 哪些情況可以自動切換？ 哪些情況不應自動切換？ 五、成本 替每個模型設定合理的月預算與使用上限。 六、人工停止 如果所有已驗證模型都無法安全完成，請把最後 Fallback 設計成人工處理，而不是繼續嘗試未知模型。 最後產生： 主要模型。 第一備援。 第二備援。 人工停止條件。 並列出正式上線前必須使用同一批真實案例測試的項目： 正確率、 人工修改時間、 成本、 延遲、 輸出格式、 工具呼叫。 不要假設不同模型可以無痛互換。
完全沒有工程能力適合用嗎？
大多數情況下：
不需要急著用。
LiteLLM 主要還是工程與平台層工具。
如果你目前只是自己用 AI 工作，不需要建立 API 服務。
真正值得先學的是：
不要把重要工作只綁在單一工具。
例如：
- 保留原始文件。
- 保存 Prompt。
- 知道第二個可用工具。
- 重要成果能匯出。
等工作真正進入自動化與 API，再考慮 Gateway。
今天最重要的判斷
AI 公司開始做自己的晶片，是在減少基礎設施依賴。
小公司不可能自己設計 Maia。
但可以處理自己能控制的那一層：
不要把整個 AI 產品寫死在一個模型上。
LiteLLM 的真正價值不是讓你一次擁有一百種 AI。
而是讓公司開始把：
- 主要模型。
- 備援模型。
- 成本。
- 權限。
- 路由。
放在一個更集中管理的位置。
這樣有一天：
模型漲價。
供應商故障。
新模型變得更便宜。
或某一項工作需要不同能力時。
你不需要把整間公司的 AI 工作從頭拆掉重做。
但最重要的一句仍然是：
能切換，不代表可以亂切換。
真正成熟的多模型架構，不是永遠有另一個 AI 接手。
而是事先知道：
哪個模型真的能接手。
什麼時候可以切。
什麼時候應該停止。
以及如果所有模型都不適合，最後仍然有一個人可以接回工作。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
