LiteLLM vs OpenRouter
決定性的一行不是功能，而是你的 prompt 實際走向哪裡。LiteLLM 跑在你的 VPC 裡；OpenRouter 是託管中轉。
LiteLLM 與 OpenRouter 被反覆拿來比，而這類比較常常一開始就跑偏 —— 它們是兩種不同形態的產品。OpenRouter 是託管聚合器：一個端點、很多模型、什麼都不用部署。LiteLLM 是你要自己跑的庫與代理。兩者都給你「一個 API 調很多廠商」。但只有一個能讓資料路徑留在你自己的網路裡 —— 對受監管的買方，這就是全部決策。
三家閘道器，五個準則
前兩列各自是對應對比頁的一句話濃縮。GateLLM 那一列是我們自己的立場，不是第三方評測 —— 請按此權重看待。
| 準則 | LiteLLM | OpenRouter | GateLLM |
|---|---|---|---|
| 部署形態 | 自託管 OSS | 純 SaaS | 全私有化部署（Docker / Helm），無廠商控制平面 |
| 計費基準 | OSS 免費；企業版按用量 | Token 透通 + credit/BYOK 手續費 | 按執行個體授權；不加收 Token 費、不收席位費 |
| 協議入口 | OpenAI 中心 | OpenAI 相容 | 四入四出（OpenAI / Anthropic / Gemini / DashScope） |
| 治理粒度 | SSO（5 使用者上限）/ RBAC 在企業版 | 按 key 控制，無組織級 RBAC | SSO / SCIM / RBAC + 金鑰組 ACL 與預算上限 |
| 供應商獨立性 | 獨立（BerriAI） | 獨立（B 輪） | 獨立廠商（Fluxon LLC） |
什麼時候選 LiteLLM、什麼時候選 OpenRouter、什麼時候兩個都不選
選 LiteLLM：如果路由邏輯必須落在你自己的基礎設施裡，且你願意維運它。你得到廠商 failover、成本追蹤與 OpenAI 相容面，而請求路徑上沒有第三方。
選 OpenRouter：如果你要零部署、要最快接上很多模型 —— 原型、內部工具、或 prompt 本身不敏感的業務。它確實比自己跑任何東西都省事。
兩個都不選：如果單一廠商、單一團隊就是你的真實情況。OpenRouter 多了一跳你不需要的，LiteLLM 多了一個你不需要的服務。閘道器在需要多廠商 failover、按團隊成本歸因、或資料駐留要求時才開始回本。