LiteLLM vs Kong AI Gateway
兩者都能自託管，核心都開源。真正劃線的問題是：你的閘道器是一個 LLM 閘道器，還是一個「順帶能接模型」的通用 API 閘道器？
LiteLLM 和 Kong AI Gateway 被放在一起比，是因為它們是自託管選項裡最常進候選的兩家。但它們不是同一類軟體。LiteLLM 是 LLM 代理 —— 它的全部介面就是模型、廠商與 OpenAI 相容路由。Kong 是通用 API 閘道器（外掛、upstream、面向任意 HTTP 流量的限流），AI 外掛是加裝上去的。這個差別決定了下面每一行：協議入口、治理粒度，以及有多少東西要你自己造。
三家閘道器，五個準則
前兩列各自是對應對比頁的一句話濃縮。GateLLM 那一列是我們自己的立場，不是第三方評測 —— 請按此權重看待。
| 準則 | LiteLLM | Kong AI Gateway | GateLLM |
|---|---|---|---|
| 部署形態 | 自託管 OSS | 自託管 OSS（+ 託管 Konnect） | 全私有化部署（Docker / Helm），無廠商控制平面 |
| 計費基準 | OSS 免費；企業版按用量 | OSS 免費；外掛企業版門控 | 按執行個體授權；不加收 Token 費、不收席位費 |
| 協議入口 | OpenAI 中心 | OpenAI 相容 + AI 外掛 | 四入四出（OpenAI / Anthropic / Gemini / DashScope） |
| 治理粒度 | SSO（5 使用者上限）/ RBAC 在企業版 | RBAC / SSO 在企業版 | SSO / SCIM / RBAC + 金鑰組 ACL 與預算上限 |
| 供應商獨立性 | 獨立（BerriAI） | 獨立（Kong Inc.） | 獨立廠商（Fluxon LLC） |
什麼時候選 LiteLLM、什麼時候選 Kong、什麼時候兩個都不選
選 LiteLLM：如果你要治理的就是模型流量、僅此而已 —— 按模型路由、廠商 failover、成本歸因，不必先學一套外掛 DSL，且你願意維運一個 Python 服務。它是從「要調很多廠商」到「透過一個端點調很多廠商」最短的路。
選 Kong：如果你本來就在用 Kong 承載非 LLM 的 API 流量。複用已有的閘道器 —— 它的外掛、限流、既有維運手冊 —— 通常勝過為 AI 再引入另一個閘道器。AI 外掛只是這個決策裡較小的一半。
兩個都不選：如果單一廠商、單一團隊、月度花費可控就是你的真實情況。直接調廠商 API 比這兩個選項都簡單，而且在需要多廠商 failover、按團隊成本歸因、或廠商給不了的合規控制之前，任何閘道器都賺不回它的維運成本。