現在很多團隊遇到的 AI 問題，已經不是「怎麼呼叫第一個模型」，而是「怎麼管理第十個模型」。當 OpenAI、Anthropic、Gemini、Azure OpenAI、Bedrock、Groq、Vertex AI 都開始進到同一家公司，同一套產品、甚至同一條請求鏈路裡，工程問題就會從 prompt engineering 很快轉向 平台治理：金鑰怎麼管、故障怎麼切流、成本怎麼歸戶、不同模型怎麼抽象成一致介面、上游 SDK 一改版是不是全公司一起痛。

LiteLLM 之所以值得研究，不在於它把 API 包成另一個 API；而在於它試圖把「多模型存取」變成一層可以被治理、觀測、路由與審計的基礎設施。對已經有 2 種以上模型供應商、或準備把 AI 能力開放給多個內部團隊使用的組織來說，這不是方便性問題，而是系統邊界該不該收斂的問題。

English TL;DR:

• LiteLLM is best understood as an AI gateway, not just a convenience SDK.
• It unifies provider APIs, routing, retries, spend tracking, and virtual keys behind an OpenAI-like interface.
• The upside is operational control across teams and models; the downside is an extra control plane you now need to own.
• It fits multi-team, multi-provider, production AI systems more than small single-model apps.

從星星曲線看，LiteLLM 已經不只是工具人專案

如果只把 LiteLLM 看成「幫大家把多家 API 包成同一個介面」的小工具，會低估它最近這波成長。它的 star growth 更像在反映一個更大的趨勢：當團隊同時接了 OpenAI、Anthropic、Gemini、Azure、Bedrock 之後，大家開始發現真正麻煩的不是 call model，而是怎麼把模型存取收斂成一層可以治理的入口。

這種圖不代表它一定最適合你，但很能說明一件事：LiteLLM 被關注，不只是因為它省幾行程式碼，而是因為越來越多團隊真的需要一個 AI gateway 類的控制平面。

LiteLLM 是什麼？

LiteLLM 是一個同時提供 Python SDK 與 Proxy Server / AI Gateway 的開源專案。它表面上是在統一多家 LLM 供應商的呼叫方式，但如果從實際系統角色來看，更接近公司裡負責轉接、分流、記帳與控權限的 AI 總機。

這個比喻之所以成立，是因為應用程式不用再各自直接面對 OpenAI、Anthropic、Gemini、Azure OpenAI、Bedrock 這些不同上游，而是先把流量接進同一層入口，再由這層決定：請求要走哪一家、失敗時要不要切備援、費用算到哪個團隊、哪些 key 可以用高價模型。

如果只從開發者角度看，它像「LLM 的統一 adapter」；但從系統角度看，它更接近 AI 時代的 API Gateway + policy layer。

為什麼這種東西會開始變重要

很多團隊一開始會直接在 app 裡寫死某家模型 SDK。這在 PoC 階段沒問題，但進入正式環境後，問題會快速浮現：

• 同一產品線開始混用多家模型，介面與參數語義不一致
• 某區域或某供應商暫時限流，需要快速切換部署
• 團隊想知道每個部門、每個 API key、每位使用者到底花了多少錢
• 安全團隊不希望每個服務都握有真實供應商金鑰
• 平台團隊想在不改動所有應用程式的前提下，替換模型版本或新增 fallback

LiteLLM 的 ROI 不在於「少寫幾行 SDK 程式碼」，而在於它把原本分散在十幾個服務裡的模型治理邏輯，集中到一個可維運、可觀測、可迭代的平面。這件事一旦做對，未來要換模型、擴區域、做成本控管、做權限分流，代價都會低很多。

哪些團隊會很有感，哪些其實先不用急

如果讀到這裡，你最值得先問的其實不是「LiteLLM 強不強」，而是「現在的系統複雜度，值不值得多引入一層 Gateway」。先把這件事判斷清楚，後面的架構細節才有閱讀價值。

適合

• 已經有 多個 LLM 供應商 的產品團隊
• 想建立 內部共用 AI 平台 的平台/Infra 團隊
• 需要 成本歸戶、虛擬金鑰、路由控制、fallback 的正式環境
• 想降低應用程式對單一模型供應商綁定的組織

不適合

• 還在單一模型 PoC 階段的小專案
• 沒有人負責平台維運，卻想把它當零成本中介層使用的團隊
• 期待它「自動幫你選最好的模型」而不是治理模型存取的使用者
• 對 provider-specific 能力高度依賴、且不願接受抽象層折衷的場景

場景一：客服或助理系統，需要多區域、多供應商備援

假設你在做一個企業客服助理，每天幾十萬次請求，白天尖峰很明顯。你可能同時買了 Azure OpenAI 與 OpenAI 官方配額，原因不是想炫技，而是怕：

• 某區域短暫異常
• 某 deployment 遇到 429
• 某模型升級時行為飄動

這種情況下，LiteLLM 的價值在於：把 gpt-4o 做成一個邏輯模型別名，背後掛多個實體 deployment，讓 Gateway 根據策略切流。你的 app 仍然打同一個入口，但平台可以在後面調整：

• 主要流量走延遲最低的區域
• 遇到 rate limit 自動重試其他 deployment
• 在特定時段把流量導向較便宜的替代模型

對應的效益不是模型更聰明，而是 故障域縮小、應用程式變簡單、流量控制集中化。

場景二：多個內部團隊共用 AI 平台，帳要算得清楚

如果你是平台團隊，最怕的通常不是第一個人把模型接上，而是十個團隊都接上之後，大家開始問：

• 哪個部門這個月花最多？
• 哪個產品其實把高價模型當預設？
• 哪個 API key 被濫用？
• 某個實驗 feature 值不值得繼續燒錢？

LiteLLM 的 spend tracking 與 virtual key 設計，剛好就是要解這類問題。你可以把平台發給每個服務的 key 視為「內部帳務身份」，讓請求即使最後流到不同供應商，回來仍能統一記錄成本、token 與使用者/團隊維度。

對公司來說，這很像把雲端費用裡的 FinOps 邏輯，延伸到 LLM 層。沒有這層，AI 成本通常只會在月底變成一張不好解釋的外部帳單。

場景三：Agent 不是 demo 了，你開始需要 A/B、fallback 跟治理

很多 Agent 系統一開始只有一條 happy path：固定模型、固定 provider、固定 prompt。等你開始真的上線，才會發現你需要：

• 某些任務優先用便宜模型，不夠再升級
• 某些企業客戶必須走指定地區或指定雲
• 某些高價模型只能給特定 key 使用
• 想在不影響主路徑的情況下做 silent experiment 或 traffic mirroring

LiteLLM 的路由與模型別名設計，適合做這類「平台側控制」。也就是說，Agent 團隊可以專注在任務設計與工具調用；模型供應、額度、備援與成本策略，盡量由 Gateway 層承接。

從架構上看，它到底把哪些事情接了下來

LiteLLM 的核心思路可以拆成四層來看。

1. 介面抽象層：先把呼叫入口統一

它提供接近 OpenAI 格式的請求介面，讓上層應用盡量用同一種方式發送 /chat/completions、/responses、/embeddings 等請求。這一層的價值不是「永遠完全相容」，而是把大部分共通能力抽出來，降低你在應用層直接綁死供應商 SDK 的機率。

2. 路由層：把同名模型映射到多個 deployment

LiteLLM 的 Router 可以把同一個 model_name 映射到多個實際 deployment。例如你的 gpt-4o 背後，可能同時對應：

• Azure 東亞區部署
• Azure 美國區部署
• OpenAI 官方 API
• 內部代理出去的某個帶配額限制的端點

當請求進來時，Gateway 不一定只會打固定單點，而是根據設定做 simple-shuffle、least-busy、latency-based、cost-based 等策略選擇。

3. 韌性層：重試、降級、冷卻與故障轉移

這是它比較有基礎設施味道的地方。官方文件明確提供：

• 多 deployment 的 load balancing
• rate limit aware routing
• timeout / retry / exponential backoff
• deployment cooldown
• fallback ordering

也就是說，LiteLLM 並不是只做 request format translation，而是把「哪個 deployment 現在比較健康、哪個先用、哪個暫時冷卻」這類本來要自己在應用程式裡寫的控制邏輯，變成共用能力。

4. 治理層：虛擬金鑰、成本追蹤、權限與報表

這層通常才是平台團隊真正想要的。LiteLLM 提供 virtual keys、team/user spend tracking、按 key 或 team 的 budget 與用量報表。概念上，它讓你不必把真實供應商金鑰散發到每個服務，而是透過平台代理 key 去控管誰能用什麼模型、花多少預算、產生哪些用量紀錄。

下面用一張簡化圖描述它的角色：

  flowchart LR
  U["App / Agent / Internal Service"] --> G["LiteLLM Gateway"]
  G --> P["Policy & Virtual Keys"]
  G --> R["Router / Retry / Fallback"]
  G --> O["Spend Logs / Observability"]
  R --> A["OpenAI"]
  R --> B["Azure OpenAI"]
  R --> C["Anthropic"]
  R --> D["Bedrock / Vertex / Others"]

這張圖真正想表達的不是「它會轉發請求」，而是：它把原本散落在應用層的 cross-cutting concerns 拉到中間層。

如果你想自己試，最小起步大概長這樣

如果只是想試 LiteLLM，最小可行方式其實不複雜：

1. 啟動 LiteLLM proxy
2. 用一個 OpenAI 相容 client 指向它
3. 在 config 裡定義模型別名與實際 deployment

概念上你會有一份像這樣的設定：

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
      rpm: 500
  - model_name: gpt-4o
    litellm_params:
      model: azure/gpt-4o
      api_base: os.environ/AZURE_API_BASE
      api_key: os.environ/AZURE_API_KEY
      rpm: 300

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  timeout: 30

然後你的應用程式不一定需要知道後面有幾家供應商，它只需要對 Gateway 發送：

from openai import OpenAI

client = OpenAI(api_key="anything", base_url="http://localhost:4000")
resp = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "請摘要這份文件"}]
)

這種接法的好處是：未來你把 gpt-4o 換成別的實體 deployment，理論上不需要每個應用一起改。

它真正值錢的地方，其實是把替換成本先吃掉

很多人第一次看 LiteLLM，直覺會想：「這不就是再包一層？」

但如果你是從平台演進角度看，這一層其實很合理。因為它替你把以下替換成本先吃掉：

• 供應商替換成本：避免業務邏輯直接綁定某家 SDK
• 模型版本替換成本：用 alias 做平滑遷移
• 金鑰治理成本：減少真實 provider key 在各服務擴散
• 營運可視性成本：統一用量、成本與錯誤觀測
• 韌性實作成本：把 retry / fallback / cooldown 做成平台能力

如果你已經知道自己會進入多團隊、多模型、多環境共存階段，這層抽象常常不是過度設計，而是提前把未來一定會補的洞做成標準件。

但它不是沒有代價，幾個坑要先講清楚

這一段反而最重要，因為 LiteLLM 不是沒有代價。

1. 你引入了一個新的控制平面

一旦所有 AI 流量都經過 LiteLLM，它就變成新的關鍵基礎設施。這代表：

• 你要考慮高可用與水平擴展
• 你要處理設定管理與版本變更風險
• 你要觀測 Gateway 自己的延遲、錯誤率與狀態
• 若有 Redis / DB 依賴，還要管額外元件的可用性

換句話說，你把應用程式的複雜度下降了，但把平台層的責任提高了。

2. 「OpenAI 相容」不等於完全語義一致

各家模型供應商即便都走類 OpenAI 介面，能力邊界、參數語義、工具調用細節、回傳結構與新功能推出節奏仍然不同。LiteLLM 可以幫你統一大部分 common path，但它不能消滅供應商差異本身。

這表示：

• 你仍需要針對關鍵工作流做真實模型驗證
• 某些 provider-specific 功能不一定能被無痛抽象
• 升級後的相容性問題，仍可能回到應用層浮現

3. 成本追蹤不代表成本治理自動完成

LiteLLM 很適合做 spend tracking，但追蹤只是第一步。真正的治理還需要你自己定義：

• 哪些團隊可用哪些模型
• 哪些場景允許高價模型
• 超過預算時該 block、降級還是告警
• 不同客戶等級該對應什麼模型 policy

也就是說，它提供的是能力底座，不是完整治理策略本身。

4. 對小團隊、單模型、單應用來說，可能太重

如果你只有一個內部工具、只用單一供應商、每月流量也不高，那直接用官方 SDK 通常更簡單。這時候引入 LiteLLM，可能只是多了一層需要維運的中介服務，價值未必大於成本。

5. 功能面很廣，但也意味著學習與選型面變大

LiteLLM 現在已經不是單純的小 adapter，而是一個能力面相當廣的 AI Gateway。這很好，但也代表設定項、路由策略、權限、資料庫、觀測與企業功能邊界都需要讀文件。對沒有平台工程能力的團隊來說，這會是一個真實門檻。

當然，也不是非 LiteLLM 不可

如果你不想引入 LiteLLM，大致有幾條替代路線：

1. 直接用官方 SDK

最簡單，也最少中介延遲。缺點是多供應商時，治理與切換成本幾乎都落在應用層。

2. 在 API Gateway / Backend for Frontend 自己做抽象

理論上可行，也能完全客製；但你等於自己重做模型路由、金鑰治理、成本統計與錯誤處理。除非你本來就有很強的平台團隊，不然重造輪子機率不低。

3. 採用更偏 Agent framework 的方案

像某些框架會幫你做 agent orchestration、workflow、memory，但它們不一定擅長做「跨供應商的統一治理入口」。如果你的核心痛點在平台治理，不一定要用 agent framework 解。

4. 使用雲供應商自己的單一入口

例如全部綁在某一雲廠商的 AI 平台上。好處是整合深、治理一致；壞處是你把 portability 和多供應商議價能力交出去。

從這個角度看，LiteLLM 最適合的位置不是取代所有 AI framework，而是成為 它們共同往外呼叫模型的底層閘道。

結論：值得看，也值得小規模試點

比較務實的結論是：LiteLLM 值得關注，也值得在有多模型治理需求的團隊裡做試點；但不適合被當成所有 AI 專案的預設必備元件。

它最有價值的地方，不是讓工程師少背幾種 SDK，而是把 LLM 存取從「應用內部細節」升級成「平台級治理能力」。這件事一旦做起來，會對後續的成本、韌性、安全與供應商替換能力產生長尾影響。

但反過來說，如果你的系統還沒複雜到需要平台治理，先用官方 SDK 把產品價值跑出來，通常仍是更健康的做法。不要為了看起來專業，就過早引入一層自己還接不住的控制平面。

比較穩健的導入方式是：

1. 先挑一個真實服務做 LiteLLM 試點
2. 把目標定成三件事：切換成本下降、失敗率改善、成本可視性提升
3. 如果這三件事有量到實際收益，再把它升級成共用平台

這樣導入，風險和回報會比較平衡。

來源

• GitHub：BerriAI/litellm
  https://github.com/BerriAI/litellm
• README
  https://raw.githubusercontent.com/BerriAI/litellm/main/README.md
• Docs: AI Gateway / Proxy
  https://docs.litellm.ai/docs/simple_proxy
• Docs: Routing / Load Balancing
  https://docs.litellm.ai/docs/routing https://docs.litellm.ai/docs/proxy/load_balancing
• Docs: Spend Tracking
  https://docs.litellm.ai/docs/proxy/cost_tracking