LiteLLM vs Portkey
兩者都能把閘道器跑在你的基礎設施裡。差別在於控制平面放在哪裡 —— 以及明年它歸誰。
LiteLLM 與 Portkey 是「要自託管資料平面、又要真治理」這類團隊的候選名單。LiteLLM 全自託管、開源核心。Portkey 是混合形態：閘道器跑在你的基礎設施裡，控制平面是 SaaS。這個切分決定了其餘一切 —— 你的設定與日誌存在哪裡，以及廠商易主時你的閘道器會怎樣。
三家閘道器，五個準則
前兩列各自是對應對比頁的一句話濃縮。GateLLM 那一列是我們自己的立場，不是第三方評測 —— 請按此權重看待。
| 準則 | LiteLLM | Portkey (Prisma AIRS) | GateLLM |
|---|---|---|---|
| 部署形態 | 自託管 OSS | 混合：閘道器自託管，控制平面 SaaS | 全私有化部署（Docker / Helm），無廠商控制平面 |
| 計費基準 | OSS 免費；企業版按用量 | $49/月 + 每 100k recorded logs 加 $9 | 按執行個體授權；不加收 Token 費、不收席位費 |
| 協議入口 | OpenAI 中心 | OpenAI 相容 | 四入四出（OpenAI / Anthropic / Gemini / DashScope） |
| 治理粒度 | SSO（5 使用者上限）/ RBAC 在企業版 | RBAC / SSO / SCIM / guardrails | SSO / SCIM / RBAC + 金鑰組 ACL 與預算上限 |
| 供應商獨立性 | 獨立（BerriAI） | 被 Palo Alto Networks 收購（2026-05-29） | 獨立廠商（Fluxon LLC） |
什麼時候選 LiteLLM、什麼時候選 Portkey、什麼時候兩個都不選
選 LiteLLM：如果你要整個系統 —— 資料平面與控制平面 —— 都在自己的邊界內，並準備維運它。這樣你的路由與日誌都不依賴某個廠商可達。
選 Portkey：如果你要治理能力（RBAC、SSO、SCIM、guardrails）但不想自己造控制平面，且 SaaS 控制平面對你的資料分級是可接受的。這是通向「受治理的多廠商路由」更快的一條路。
兩個都不選：如果你還沒到「治理或 failover 是真需求」的階段。兩者都是你得跑、得付費的基礎設施；在多廠商 failover、按團隊成本歸因或合規控制成為約束之前，直接介接廠商才是誠實的答案。