LiteLLM vs OpenRouter：成本、控制權與故障切換

選擇 LLM 閘道，真正的差異不在 LiteLLM 和 OpenRouter 是否支援 OpenAI 風格 API，而在於誰負責營運路由層。對於尚未自行維護正式環境閘道的團隊，OpenRouter 是較省事的起點；當私有網路、客製政策或長期用量讓控制權值得投入人力時，LiteLLM 才更能展現價值。

這是營運模式的選擇，不是 API 格式之爭

LiteLLM 是開源軟體，可以 Python SDK 或自行託管 Proxy 的形式運作。OpenRouter 則是代管 API 與模型目錄：由 OpenRouter 維運閘道、整合各家供應商存取，並透過單一帳戶處理模型用量。

兩者都能提供相容於 OpenAI 的介面，但要承擔的責任完全不同：

這種差異也讓混合架構變得可行：LiteLLM 負責內部政策與成本核算，OpenRouter 則處理特定模型的存取。

先看哪項限制會最早成為瓶頸

正確選擇取決於團隊最不能妥協的第一項需求。

別只看 Token 帳單，也要算進工程成本

LiteLLM 與 OpenRouter 收取的是不同層級的費用。OpenRouter 會轉嫁底層模型價格，不加收推論加價，接著在購買點數時收取 5.5% 費用。LiteLLM 的開源 Proxy 沒有按 Token 計算的閘道費，但你必須自行負擔維運基礎架構與人力。

OpenRouter 的定價頁是目前費用條款的依據。這筆費用是購買點數時產生，並不是在每個模型的 Token 價格上簡單加收 5%。

什麼時候 OpenRouter 的費用反而更划算？

假設團隊購買足夠的 OpenRouter 點數，涵蓋每月推論支出：

• 每月用量為 $500 時，5.5% 的點數購買費為 $27.50。
• 用量為 $20,000 時，同樣的百分比就是 $1,100。
• 用量為 $50,000 時，費用為 $2,750。

這些數字代表 LiteLLM 在計入主機、部署、修補、告警、備份與工程時間後，必須擊敗的成本。每月 $500 的用量下，對尚未維護閘道的團隊來說，OpenRouter 通常是營運負擔較低的選項，除非私有網路是硬性要求。到了 $20,000，擁有平台維運能力的團隊就應該認真估算 LiteLLM。

什麼時候 LiteLLM 的零閘道費真的比較便宜？

當平台團隊原本就已吸收固定營運成本，或省下的百分比費用高於新增 Proxy 的維運成本時，LiteLLM 才會在財務上更具吸引力。

官方的 Docker 快速入門區分了簡易的無資料庫 Proxy，以及採用資料庫的部署方式。在 Compose 流程中，PostgreSQL 用來儲存模型、金鑰與支出記錄。LiteLLM 表示，沒有資料庫時，虛擬金鑰、支出追蹤與有效的預算強制執行都無法使用；設定 max_budget 也不能當成可靠的硬性上限。

Redis 則是另一個進入正式環境的門檻。LiteLLM 的 Redis requirements 建議，當 Proxy 執行超過一個 worker 或 replica 時，應使用共享 Redis 狀態。否則，速率限制、預算、冷卻時間、快取項目與路由觀測資料都會分散在不同 worker 之間。單一 worker 的測試成本很低；可水平擴充的正式環境閘道則是更大型的系統。

不要只比較 Token 價格，應該採用以下方式估算：

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

不存在一個適用所有團隊的損益平衡點。真正有用的輸入值包括每月推論支出、主機成本、工程時數、值班覆蓋，以及任何合規溢價。

比較你實際要維護的控制平面

LiteLLM 能讓平台團隊取得更多控制權，但不會替你建立供應商存取管道。OpenRouter 在探索模型與集中計費方面更簡單，但代管目錄不等於你擁有直接的供應商關係。

談到可靠性，兩者就不再像同一類產品

兩個產品都能重試或故障切換，但背後的責任歸屬不同。OpenRouter 管理供應商池；LiteLLM 讓你自行定義供應商池，也代表它必須成為你可靠性堆疊的一部分。

OpenRouter 的供應商路由文件指出，預設行為會在可用供應商之間進行負載平衡，同時考量價格與供應商近期的中斷情況。你可以指定供應商順序、允許或停用備援、要求特定參數、依資料政策篩選，或按價格、吞吐量與延遲排序。它的模型備援指南則說明了有順序的 models 清單；計費會以最終處理請求的模型為準。

LiteLLM 的路由文件記載了加權或隨機選擇、依用量路由、依延遲路由、最少忙碌路由、依成本路由，以及自訂路由策略。它也支援部署優先順序、冷卻時間、重試與備援群組。這些控制更具程式化彈性，但能否正確運作，取決於你的設定、健康檢查、共享狀態與事故應變。

Agent 延遲、快取與供應商漂移

對於一個持續串流很久的回答，多一個網路跳轉可能不太重要。但當 Agent 一次工作要發出數十個短模型請求時，閘道、網路與重試延遲會在多輪互動中不斷累積。自行託管的 LiteLLM Proxy 可以部署在應用程式附近；OpenRouter 則會在選定的供應商之前增加一層代管服務。任何一家供應商的通用文件，都不能取代針對你的區域、模型、串流模式與並行量所做的測試。

路由方式也會改變快取效益。OpenRouter 可能在同一模型的不同供應商端點之間選擇，LiteLLM 則可能在已設定的部署之間分配請求。如果工作流程依賴供應商端的提示快取，路由改變就可能影響快取命中位置與 Token 成本。應把快取行為納入工作負載測試。

共用的模型 slug 也不代表行為完全一致。不同供應商的實作可能在上下文限制、工具呼叫支援、延遲、量化、快取與供應商專屬參數上有所差異。OpenRouter 提供 require_parameters 等供應商篩選條件，而 LiteLLM 則把不同供應商的呼叫標準化成共同介面。請務必測試 Agent 實際使用的工具結構與模型參數。

設計時不能忽略的故障情境

OpenRouter 會把基礎架構事故轉化為對供應商的依賴；LiteLLM 則會把事故變成平台團隊可以自行檢查與修改的問題。

可觀測性與隱私，看的不是同一條邊界

「自行託管」不等於「私有」，「代管」也不代表「每個提示都會被記錄」。真正重要的是：哪一層儲存內容、哪一層儲存中繼資料，以及請求最後會送到哪些供應商。

OpenRouter 的Zero Data Retention 文件指出，ZDR 可以套用到整個帳戶、模型群組、guardrail 或單一請求。文件也區分了不保留資料的端點，以及不拿資料訓練、但可能暫時保留資料的供應商。ZDR 適用於推論路由；啟用的工具與外掛仍需另外審查。

LiteLLM 能讓你更完整地控制閘道的網路、資料庫、驗證與日誌，但責任也由你承擔。你必須保護 Proxy、修補軟體、限制管理路由、妥善保管供應商金鑰，並確認每家上游供應商的資料保留與訓練條款。

混合架構通常才是最務實的答案

當你需要穩定的內部端點與治理能力，又不想為每個模型或供應商各自開設直接帳戶時，可以在 OpenRouter 前方使用 LiteLLM。敏感或行為穩定的流量直接送往核准的供應商；探索性流量或依賴模型目錄的請求，則透過 OpenRouter。

簡化後的設定模式如下：

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

這會讓 LiteLLM 負責套用內部金鑰、預算、標籤與日誌。但它不會消除 OpenRouter 的費用、代管傳輸，或透過 OpenRouter 路由時所存在的供應商政策邊界。這種架構也會多出一個跳轉與一個故障網域，因此不要預設讓所有請求都經過兩層閘道。

較合理的切分方式是：

1. 敏感資料、穩定的正式環境模型，或已有議定供應商合約的流量，直接走供應商路由。
2. 模型探索、長尾供應商與需要代管供應商備援的流量，走 OpenRouter。
3. 由 LiteLLM 負責應用程式金鑰、團隊、預算與內部成本歸屬。
4. 針對直接供應商流量與 OpenRouter 流量，分別建立儀表板與告警。

遷移成本：哪些會變，哪些不會

對相容於 OpenAI 的客戶端來說，在兩個閘道之間切換可能只需少量修改；但正式環境工作負載的遷移，絕不只是改一下 base URL。

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter 通常使用 https://openrouter.ai/api/v1（API reference）；LiteLLM Proxy 通常會提供像 http://localhost:4000 這樣的私有端點（proxy quickstart）。不過，模型 ID、供應商前綴、驗證方式與選用參數仍可能不同。

切換正式流量前，請先測試：

1. 串流與逾時行為。
2. 使用實際 JSON 結構的工具呼叫。
3. 結構化輸出與嚴格 JSON 處理。
4. 推理、快取與供應商專屬參數。
5. 主要模型回傳 429、5xx 或驗證錯誤時的備援行為。
6. 成本歸屬，因為計費事件發生的層級可能與應用程式請求不同。

API 相容性只能協助你完成初次整合，不能保證輸出、延遲、供應商選擇或計費語意完全一致。

團隊在做決定前最常問的問題

LiteLLM 和 OpenRouter 可以一起使用嗎？

可以。LiteLLM 能把 OpenRouter 當作上游路由，讓 LiteLLM 處理內部金鑰、預算、日誌或政策，同時由 OpenRouter 提供特定模型的存取與供應商路由。這條組合路徑會多一個跳轉，而經過 OpenRouter 的流量仍適用其費用與代管資料邊界。

哪個用在正式環境 API 比較便宜？

對尚未維護閘道基礎架構的小型團隊而言，OpenRouter 通常是營運負擔較低的選項。當用量提高、團隊已經在維護所需基礎架構，並希望避開按比例計算的閘道費時，LiteLLM 可能更便宜；請比較總成本，不要只看 Token 成本。

LiteLLM 能存取 OpenRouter 的完整模型目錄嗎？

不能單靠 LiteLLM 做到。LiteLLM 在Proxy 快速入門中說明支援 100+ 個 LLM 與廣泛的供應商，但它只能連到你設定並提供憑證的供應商。將 OpenRouter 加為上游，可以擴大可存取的模型目錄；不過這些請求就會依照 OpenRouter 的模型與供應商可用性運作。

哪個比較適合隱私與合規需求？

自行託管 LiteLLM 能讓你更完整地控制閘道部署、日誌、憑證與網路邊界。OpenRouter 提供內容記錄控制、供應商政策篩選、ZDR 路由，以及 Enterprise EU／US 區域選項，但它仍會位於請求路徑中；做決定前，請確認實際使用的供應商與合約要求。

選擇你有能力維護的邊界：用實際閘道營運成本來衡量百分比費用，先分類哪些請求可以經過代管中介服務，再針對應用程式需要的路由與工具呼叫行為進行故障測試。如果團隊沒有能力負責 LiteLLM 的資料庫、Redis、升級與值班維運，OpenRouter 是更務實的預設選擇；如果你已具備這些平台能力，LiteLLM 或混合路由就能換回更多控制權，並降低持續性的閘道費用。

如果想了解更多 OpenRouter 替代方案，請參考 OpenRouter alternatives；本文刻意縮小比較範圍，聚焦在 LiteLLM 的營運模式選擇。