竞品对比与选型
LiteLLM 与 Kong AI 网关 模型代理，还是企业 API 平台？
厘清 LiteLLM 与 Kong AI Gateway 在模型代理功能、API 治理与平台运维方面的职责边界。
快速结论
当核心任务是多供应商模型访问、虚拟密钥、预算、回退和自主运营 AI 代理时更合适。
当 AI 流量必须接入现有服务、身份、插件、策略、部署模式和 API 运营体系时更合适。
更大平台可以减少工具碎片，但会增加控制面、插件、许可、配置和运营决策。
如果 Kong 已治理关键 API，扩展同一策略平面可能比引入独立 AI 网关更简单。
先决定 AI 是否需要独立平面
LiteLLM 把模型访问视为专门的网关问题。其代理通过 OpenAI 风格接口标准化供应商，并增加路由、虚拟密钥、预算、支出追踪、缓存、护栏和集成。
Kong 把 AI 视为 API 平台中的另一类受治理流量。官方文档介绍 AI 代理/Advanced，以及语义路由、缓存、提示词控制、Token 限流、可观测性、护栏、MCP 与 A2A 插件，并支持 Konnect、自托管、混合、DB-less 和 Kubernetes 模式。
LiteLLM 与 Kong AI 网关并排比较
| 决策面 | LiteLLM | Kong AI Gateway |
|---|---|---|
| 平台范围 | AI 模型代理、SDK 与网关治理 | 带 AI 感知插件的企业 API 网关 |
| 流量体系 | 主要是模型供应商流量 | AI、REST、gRPC、服务、MCP、A2A 与传统 API |
| 策略模型 | 虚拟密钥、团队、预算与模型/供应商规则 | Service、路由、Consumer、Group、Plugin 与控制面 |
| 部署 | 自主运营代理与周边存储 | 托管、传统、混合、DB-less 与 Kubernetes |
| 扩展性 | 回调与 AI 集成 | 大型插件体系与自定义插件开发 |
| 最佳适配 | 需要独立模型访问平面的团队 | 统一标准化全部 API 与 AI 流量的组织 |
让平台重力决定
团队需要快速建立 AI 专用代理、直接控制供应商路由与预算，且不需要通用 API 平台。
现有 Kong 运营、身份、插件、混合网络、Kubernetes、合规与非 AI API 应保留在一个控制面。
架构增加第二个网关却没有明确策略边界，或所需 AI 插件、版本与部署模式尚未验证。
避免无意形成网关链
把客户端、边缘、API 网关、AI 网关、模型供应商、遥测和工具调用画成一条请求路径。如果两者都保留，应明确 Kong 负责企业入口、LiteLLM 负责模型标准化，并防止认证、限流、重试、缓存和内容策略重复；全链路保留一个调用链 ID。
架构规则：每个同步跳点都必须有唯一存在理由和唯一故障负责人。
平台范围验证
- 盘点现有网关、身份、服务、插件、证书、策略、区域和值班责任。
- 用工具调用、流式、结构化输出、长上下文与供应商故障在两者上运行相同模型流量。
- 测试一次企业身份流、Token 预算、提示词护栏、审计导出、Kubernetes 发布和回滚。
- 测量 p99 延迟、策略正确率、重复调用、配置交付时间和事故诊断时间。
- 计算许可、控制面、数据面、存储、遥测、平台人力和升级窗口成本。
按策略域迁移
为身份、Consumer、密钥、路由、模型、供应商、预算、限流、重试、回退、缓存、护栏、日志、追踪和审计建立矩阵；把每项要求映射到唯一目标系统与版本。镜像流量并比较语义和策略结果，再按 Consumer Group 逐步迁移并保留已验证回滚。
API 平台仍需要能力发现
LiteLLM 或 Kong 控制模型与 API 流量；QVeris 作为互补层，帮助智能体发现哪个外部 API、数据集或工具能满足意图，并在受治理凭证与契约下调用。应把模型、网关和能力追踪连接为一条动作记录。
常见问题
Kong 文档把 AI 网关描述为在 Kong 网关支持的部署模式中使用的一组 AI 插件与能力。
它提供虚拟密钥、预算、支出追踪、路由、护栏等控制；仍需验证所需深度与支持模式。
可以，但要有意划分企业入口与模型标准化，并消除重复同步行为。
取决于现有能力与体系。已运营 Kong 的组织可能更简单；新建 Kong 体系可能比聚焦代理更重。