這個比較幾乎在所有出現的地方都被錯誤地框定了，而搜尋結果中的第四項就揭示了原因：那是LiteLLM 自己的 OpenRouter 文件頁面。LiteLLM 提供 OpenRouter 整合，是因為兩者並非替代品——它們處於不同層級。 LiteLLM 是您部署在自己持有的供應商帳戶之上的代理；OpenRouter 是替您持有供應商帳戶並轉售模型存取權的託管服務。代理需要來源；OpenRouter 就是其中一個。許多團隊會有意同時使用兩者。
偏見聲明：Kunavo 是我們的產品，它在本頁應歸於 OpenRouter 一側——它是託管式模型來源，而不是代理。它不是 LiteLLM 功能的替代方案，本頁也沒有如此主張。
用一張表看懂層級差異
| LiteLLM | OpenRouter | |
|---|---|---|
| 它是什麼 | 您部署的軟體 | 託管服務 |
| 誰持有供應商憑證 | 您 | OpenRouter |
| 它是模型來源嗎？ | 不是——它背後需要一個模型來源 | 是 |
| 誰負責營運 | 您：部署、修補、擴展、處理警示 | 您這一方沒有人需要負責 |
| 推論成本 | 您自己的供應商費率 | 供應商費率，加上購買點數時的費用 |
| 提示詞文字可以留在您的基礎設施上嗎？ | 是 | 否 |
沿著「它是模型來源嗎」這一列往下看，整個框架就清楚了。其他所有差異都源自這一點。
一起使用它們，這才是常見情況
前端使用 LiteLLM，後端使用 OpenRouter：您的應用程式連線到一個內部端點，LiteLLM 執行每金鑰預算與團隊路由，而 OpenRouter 提供模型目錄，讓您不必在每個供應商處開設帳戶。任何 OpenAI 相容端點都能以相同方式串接，因此新增一個故障轉移來源只需幾行設定：
# LiteLLM and OpenRouter are layers, not rivals. This is a
# LiteLLM config with two model sources behind one proxy.
model_list:
- model_name: claude-sonnet
litellm_params:
model: openrouter/anthropic/claude-sonnet-4.6
api_key: os.environ/OPENROUTER_API_KEY
# A second source behind the same proxy — any OpenAI-compatible
# endpoint works the same way.
- model_name: claude-sonnet-backup
litellm_params:
model: openai/claude-sonnet-5
api_base: https://api.kunavo.com/v1
api_key: os.environ/KUNAVO_API_KEY「vs」問題通常真正應該問的是這種配置：不是選哪一個，而是在託管式來源之上是否還需要代理層。
何時確實只需要一個
- 只使用 OpenRouter——您沒有供應商帳戶，也不想擁有任何帳戶，而且託管式 Gateway 已提供的功能足以滿足您的路由需求。在這種情況下加入 LiteLLM，只會多出一項需要營運的服務，幾乎沒有其他收穫。此類替代方案：OpenRouter 綜合整理。
- 只使用 LiteLLM——您已持有供應商帳戶，可能還享有協議費率，而您缺少的是控制能力：單一端點、每金鑰預算、路由政策，以及永不離開您基礎設施的提示詞文字。轉售商無論收取多少費用，都無法提供最後一項。
- 兩者都不用——您想要路由與治理，但不想執行一項服務。這就是託管式 BYO-key 控制平面，屬於兩者之外的第三類：LLM Gateway 的四種類別。
在決定使用其中一個之前，應檢查的兩件事
LiteLLM 一側：營運面。 自託管代理是您建置中的一個套件，這會讓您的 CI/CD 與叢集落入其影響範圍——對這個專案而言並非假設，正如2026 年 3 月的供應鏈事件所顯示。LiteLLM 的回應相當完整，對於使用 v1.83.0 或更新版本的人而言，事件已結束；但對每個自託管代理而言，結構性問題依然存在。
OpenRouter 一側：價格底線。 將牌價轉嫁給使用者、並在購買點數時收費的轉售商，不會自動比您自己的帳戶便宜；但如果您的帳戶使用公開牌價，也不會自動更貴。值得進行的比較，是針對您使用的模型，將您的實際費率與 Gateway 的實際費率逐模型比較。Kunavo 將大多數模型列在低於供應商官方費率的價格，這是從另一方向進行的相同比較：Kunavo 與 OpenRouter 的比較。
線路相容性，讓切換成本維持低廉
兩者都使用 OpenAI 線路協定，其他所有託管式替代方案也一樣（OpenRouter 文件 · LiteLLM 文件）。無論您選擇哪一個，選錯的代價只是base_url與金鑰變更，這是本頁最實用的事實：這項決策不值得某些團隊投入數週時間。詳細資訊請參閱OpenAI 相容 API 指南。
常見問題
OpenRouter 與 LiteLLM 有什麼差異？
它們位於不同層級。LiteLLM 是您部署的軟體——它是一個使用您持有的 API 金鑰、位於模型供應商前端的代理，而且本身不是模型來源。OpenRouter 是託管服務，持有供應商憑證，透過單一錢包轉售模型存取權，因此它是模型來源，但不是您執行的東西。實際結果是：LiteLLM 至少需要一個背後的供應商帳戶，而 OpenRouter 可以充當該帳戶。
可以同時使用 LiteLLM 與 OpenRouter 嗎？
可以，而且這是有文件記載的配置，不是權宜之計——LiteLLM 提供 OpenRouter 供應商整合。常見架構是由應用程式連線至 LiteLLM 作為代理，再由 OpenRouter 作為其背後的其中一個來源，這樣您就能透過 OpenRouter 的目錄使用 LiteLLM 的每金鑰預算與團隊路由，而不必在每個供應商處持有帳戶。
LiteLLM 比 OpenRouter 便宜嗎？
LiteLLM 不增加推論成本，因為它不轉售任何東西——您支付自己供應商帳戶的費用，再加上您執行它所需的基礎設施與維運工程時間。OpenRouter 收取供應商費率，並在購買點數時加收費用。因此，就單位價格而言，只要您已擁有費率良好的供應商帳戶，LiteLLM 就較便宜；反之，若您沒有帳戶，情況就會相反：以牌價建立的帳戶，不會因為沒有 Gateway 抽成，就自動比轉售商的費率便宜。
我應該選 OpenRouter 還是 LiteLLM？
不要問哪個較好，而要問您缺少什麼。如果您已有供應商帳戶，需要對它們進行路由、預算與治理，這就是 LiteLLM 的工作。如果您沒有供應商帳戶，也不想管理任何帳戶，這就是 OpenRouter 的用途。如果兩個問題都尚未解決，您可能會想同時使用兩者；如果您想要路由功能卻不想營運服務，那麼兩者都不是答案——您需要的是託管式 BYO-key 控制平面。
2026 年供應鏈攻擊後，使用 LiteLLM 安全嗎？
在 2026 年 3 月 24 日事件後，LiteLLM 透過重建的 CI/CD 管線發布了 v1.83.0，並輪替維護者憑證、採用 Mandiant 鑑識分析及簽署的 Docker 映像。如果您使用 1.83.0 或更新版本，該事件對您而言已結束。完整事件經過及其結構性含義——自託管代理是建置中的一個套件——在選擇自託管方案前值得閱讀。
Kunavo 在這個比較中處於什麼位置？
它位於 OpenRouter 一側，而非 LiteLLM 一側：Kunavo 是託管式 Gateway，持有上游供應商憑證，因此是模型的替代來源，而不是您部署的代理。LiteLLM 部署可以像指向 OpenRouter 一樣指向 Kunavo，透過 LiteLLM 的 OpenAI 相容供應商，設定好 base URL 即可。它不是 LiteLLM 功能的替代品。