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、按团队成本归因、或厂商给不了的合规控制之前，任何网关都赚不回它的运维成本。