AI Gateway 不是“给大模型套一层反向代理”这么简单。真正进入生产以后，模型调用同时带着长连接、流式响应、令牌计费、供应商限额、敏感数据和不可预测的输出。普通 API 网关能处理其中一部分，却很难独自回答三个问题：
- 一个模型变慢或限流时，请求应该转向哪里？
- 某个团队本月已经花了多少钱，还能调用哪些模型？
- 出现错误答案或数据泄露时，能否还原请求经过的策略，而不是只找到一条 HTTP 500？
AI Gateway 的价值，是把这些重复而危险的判断从每个应用里收回来，放到一个可审计的策略执行点。但“集中”并不天然等于“治理”。如果网关没有明确的故障边界、成本归属和数据策略，它只是把分散的风险集中成一次更大的故障。
本文依据截至 2026 年 7 月可查的官方文档，对 LiteLLM、Kong AI Gateway、Apache APISIX、Cloudflare AI Gateway 与 Portkey 做一次面向落地的比较。功能和授权会继续变化，文中的结论应当被当作验证起点，而不是采购合同的替代品。
AI Gateway 到底是什么
在一个较完整的系统里，AI Gateway 位于应用与模型供应商之间，承担统一协议、身份与额度、路由容错、内容策略和调用遥测：
用户 / Agent
│
业务 API：会话、权限、产品语义
│
AI Gateway：虚拟密钥、模型别名、预算、路由、护栏、日志
│
OpenAI / Anthropic / Gemini / Bedrock / Azure / 自托管模型
它不应该取代业务服务。谁可以阅读某份文档、一次工具调用是否需要人工批准、回答能不能被写回数据库，这些仍是业务授权问题。网关擅长的是“这次模型流量能否通过、如何通过、通过后留下什么证据”。
也不要把三种东西混为一谈：
- 传统 API Gateway 管理通用南北向流量，强项是认证、限流、路由、WAF 和 API 生命周期。
- AI Gateway 理解模型、令牌、流式响应和供应商差异，主要治理应用到模型的出站流量。
- Agent/MCP Gateway 还要理解工具、资源和委托身份。它面对的是带副作用的行动，不只是一次推理请求。
一家公司可以使用同一个产品承载三层，也可以组合两种网关。关键不是组件数量最少，而是责任边界清楚。
两条架构路线
AI 原生网关
LiteLLM 与 Portkey 从模型调用出发，优先解决 OpenAI 兼容接口、多供应商适配、重试、回退、成本和护栏。它们接入快，尤其适合 Python/JavaScript 为主的 AI 团队。
代价也很直接：当需求扩展到复杂的 API 产品管理、多协议流量、成熟的 Kubernetes 网络治理时，团队往往仍需外层网关。此时要警惕“双重重试、双重限流、双重日志”——两个组件都以为自己是最后一道控制面，最终会让一次失败变成请求风暴。
传统网关演进
Kong 与 Apache APISIX 从成熟的 API 网关扩展 AI 插件。它们适合已经有统一网关平台、希望复用消费者身份、证书、插件和运维体系的组织。
这条路线的风险是“插件存在”不等于“能力完整”。正则式提示词拦截、真正的语义护栏、精确缓存和语义缓存不是一回事；基础代理、跨模型负载均衡、成本优化也可能处在不同授权层。选型必须落实到具体插件、版本和许可证，而不是停在产品名。
Cloudflare 则是另一种答案：把网关做成全球托管服务，用极低的接入和运维成本换取对部署形态、日志驻留与定制深度的让渡。
六个维度的能力对比
下表描述的是默认产品重心，不表示每一格都能在同一版本、同一许可证中开箱获得。
| 方案 | 路由与容错 | 缓存 | 预算与限额 | 安全治理 | 可观测性 | 部署与授权边界 |
|---|---|---|---|---|---|---|
| LiteLLM | 模型别名、加权/延迟等策略、重试与回退；供应商适配面广 | 本地及 Redis 等后端，支持精确和语义缓存配置 | 虚拟密钥，可按 key、用户、团队跟踪花费并设预算/RPM/TPM | 主密钥、虚拟密钥、模型访问和 Guardrail 集成；高级 RBAC、审计等需逐项确认授权 | 回调、日志与 Prometheus/OpenTelemetry 等集成，成本数据细 | 核心代理可自托管；密钥管理通常引入 PostgreSQL，横向扩展常引入 Redis；部分治理功能为 Enterprise |
| Kong | AI Proxy 做协议转换；跨模型负载、重试与回退主要看 AI Proxy Advanced | 语义缓存可接 Redis/Valkey 或 pgvector | 可结合消费者、限流与 AI 指标治理，完整成本治理依赖所选插件/控制面 | 继承成熟 API 认证生态；语义提示词/响应护栏、PII 等高级能力需 AI Gateway Enterprise 授权核对 | 可把模型、令牌和延迟送入 Kong 日志/指标体系 | 适合已有 Kong 的平台；基础与 Advanced/AI License 插件边界必须按插件页核验 |
| Apache APISIX | ai-proxy-multi 支持权重、优先级、健康检查、重试及按 429/5xx/限额回退 | 没有与专用产品等价的开箱语义缓存，通常组合外部缓存或自行扩展 | ai-rate-limiting 可按 prompt、completion、total token 或表达式限额 | ai-prompt-guard 是 allow/deny pattern 校验，不应当被描述为完整的语义安全平台 | 访问日志可记录模型、token、首 token 时间等，复用既有日志插件 | Apache 2.0，自托管和插件扩展透明；适合已有 APISIX/OpenResty 能力的团队 |
| Cloudflare | 托管重试、回退；Dynamic Routing 可按条件、配额选择模型 | 当前官方缓存针对完全相同请求，仅覆盖文本和图像响应，不是语义缓存 | 有请求级 rate limit；预算、部门成本中心等深度治理不如专用控制面 | 可利用 Cloudflare 边缘安全能力；业务级 PII/提示词策略仍需额外设计 | 托管分析与日志，开通即用；需核验保存期限、采样、导出和地域要求 | 完全托管，核心功能当前免费且供应商推理价格不加价；不可当作可自托管 OSS |
| Portkey | 重试、回退、加权负载、条件路由、超时和多模态适配 | 精确/语义缓存能力需区分 OSS、托管与 Enterprise 配置 | 有使用分析、虚拟密钥及成本能力，但组织治理深度依赖产品层级 | OSS 有 guardrail 框架；RBAC、入站规则、PII、合规与私有部署重点在 Enterprise | 本地控制台可看日志；完整日志、追踪、分析和提示管理多与 Hosted/Enterprise 控制面相关 | MIT 网关核心可自托管；官方仓库正推进 2.0 能力合并，生产前应锁版本并核对功能表 |
这张表刻意没有打一个总分。总分会掩盖约束：对强合规团队而言，日志驻留可能是一票否决；对三人创业团队而言，一个需要维护 PostgreSQL、Redis 和多副本状态的“免费方案”，总成本可能高于托管服务。
逐个方案看适用边界
LiteLLM：最快建立统一模型入口
LiteLLM 的虚拟密钥文档 明确给出了 key、用户、团队维度的花费跟踪，也说明密钥管理需要 PostgreSQL。它的优势不是单项功能最强，而是把大量供应商收敛成开发者熟悉的接口，同时给小团队一条从代理、路由走向成本治理的短路径。
适合：
- 模型供应商变化快，需要用模型别名降低迁移成本；
- 团队以 Python 和 OpenAI 兼容 SDK 为主；
- 希望先自托管，再逐步增加虚拟密钥、预算与观测。
不适合直接拍板的场景：
- 团队没有数据库、Redis、升级和高可用运维能力；
- 需要复杂 API 产品、开发者门户或统一管理大量非 AI API；
- 把“支持某个模型”误解为该模型所有新端点、流式工具调用都完全等价。
最后一点尤其重要。兼容层能统一常见字段，却无法抹平供应商语义。工具调用、结构化输出、图片、音频、批处理和 Responses 类接口，都应逐项做契约测试。
Kong：已有 API 平台上的增量选择
Kong AI Proxy 可以转换多家供应商的请求与响应、代理自托管模型并记录使用数据。Kong 的真正优势，是 AI 流量可以进入既有消费者、插件、证书和运维体系，而不是再造一座孤岛。
但要认真看每个插件页顶部的授权提示。例如，AI Semantic Cache 明确要求 AI Gateway Enterprise，并依赖向量数据库与嵌入模型。AI Proxy Advanced、语义护栏、PII 处理等也不能因为出现在产品总览里，就推断为免费版能力。
适合：
- 已经稳定运行 Kong，平台团队能维护插件与升级；
- AI API 和普通 API 需要统一身份、入口及策略；
- 愿意为企业支持和高级 AI 插件付费。
如果只是给两个模型做统一接口，引入完整 Kong 平台通常过重。
Apache APISIX：开源透明、网络治理优先
APISIX 的 AI 能力已经不只是基础转发。ai-proxy-multi
支持负载均衡、重试、回退和健康检查；ai-rate-limiting
可以按 token 维度限额，并在高优先级实例额度耗尽时回退。
它的边界也很清楚：ai-prompt-guard
基于 allow/deny pattern 检查输入。它适合明确规则和快速阻断，却不能证明系统理解了提示词语义，更不能单独抵御间接提示注入。
适合：
- 已有 APISIX、Nginx/OpenResty 或 Kubernetes 网关体系；
- 更看重开放许可证、性能与统一网络策略；
- 能自行组合缓存、成本看板和更专业的内容安全服务。
Cloudflare：运维最轻，但控制权最少
Cloudflare AI Gateway 提供托管日志、分析、重试、回退、缓存和限流。Dynamic Routing 还能用条件与配额组织模型选择。对已经运行在 Workers 或 Cloudflare 网络上的产品，它往往是最快的生产化路径。
需要纠正一个常见误会：截至本文核验时，官方缓存文档 说明只有完全相同的请求才会命中，而且当前限于文本和图像响应。把它写成“语义缓存”会直接导致错误的成本预期。
适合：
- 团队很小，希望把网关运维交给服务商；
- 接受 Cloudflare 控制面与日志模型；
- 主要需求是快速获得基础分析、缓存、限流和容错。
受监管数据、私有网络模型或严格日志驻留场景，应先完成法务与数据路径审查。
Portkey：开发体验与治理控制面的折中
Portkey 开源网关 以 MIT 许可证提供路由、重试、回退、负载均衡和 guardrail 框架，也能本地运行。它对 LangChain、LlamaIndex 和 Agent 框架的接入友好。
不过，仓库说明同时把完整日志/追踪、组织治理、入站规则、PII、合规和私有企业部署放在 Hosted 或 Enterprise 语境中；2.0 还在进行能力合并。选它时不能只看功能名称，应该把“当前稳定版本能否离线自托管”“控制面是否必须联网”“哪些数据会离开网络”写进验收。
适合：
- 想要比纯代理更完整的 AI 开发体验；
- 重视条件路由和可插拔护栏；
- 能接受在开源核心与商业控制面之间做清晰取舍。
缓存不是免费的正确答案
精确缓存按请求体哈希命中，容易解释；语义缓存用向量相似度复用“意思接近”的回答，命中更多，也更危险。
以下请求通常不应跨用户直接复用：
- 含身份、权限或私有检索结果的提示；
- 实时价格、库存、政策和运维状态；
- 带工具调用、随机性或会话历史的请求；
- 医疗、法律、财务等需要可追溯新鲜度的回答。
缓存键至少应包含租户、模型与版本、系统提示词版本、工具集合、知识库版本、温度等影响结果的参数。语义缓存还要记录相似度阈值、嵌入模型和命中来源，并提供强制绕过与删除机制。省下的 token 看得见，错误复用造成的损失往往晚得多才出现。
路由与预算应当怎样设计
不要一开始就追求“智能路由”。生产上最可靠的顺序通常是：
- 用稳定的模型别名隔离业务代码与供应商名称；
- 先做同模型、不同区域或密钥的负载均衡；
- 只对明确的错误类别配置重试，限制总尝试次数和总时长；
- 再加入跨模型回退，并验证工具调用、输出结构和安全策略是否仍等价；
- 最后才根据成本、延迟或任务类型做动态选择。
预算也不等于账单看板。至少要同时具备：
- 事前限制：模型白名单、RPM、TPM、并发数、单次最大 token；
- 事中熔断：团队或 key 达到日/月额度后拒绝或降级；
- 事后归属：能按租户、团队、应用、环境和模型核对供应商账单。
供应商价格表会变化，返回的 usage 也可能延迟或缺失。因此网关成本是估算值，月底仍要与供应商账单对账。把“预算达到 100% 才停止”当作精确刹车，通常会留下并发超支窗口。
上线前验证清单
选型会议不该以演示结束，而应以一组可复现的失败实验结束。
1. 协议与流式响应
- 验证 Chat/Responses、embedding、图片、音频、工具调用等实际使用的端点；
- 检查 SSE 首 token 时间、客户端取消、超时和半途断流；
- 比较经网关前后的错误码、usage、finish reason 与结构化输出。
2. 路由与故障
- 人为制造 429、5xx、DNS 失败、连接超时和流式中断；
- 确认哪些错误会重试，重试是否跨区域或跨模型；
- 给整个请求设置时间预算，避免三次回退把十秒 SLA 拉成一分钟；
- 确认非幂等工具调用不会因代理重试重复执行。
3. 成本与限额
- 为测试 key 设置极小预算、RPM、TPM 和并发限制；
- 用并发请求验证超额窗口和重置周期；
- 抽样比对网关成本、供应商 usage 与最终账单；
- 验证流式失败、缓存命中和回退请求如何计费。
4. 缓存正确性
- 证明租户、权限、系统提示词与知识库版本进入缓存隔离；
- 测试模型升级、政策更新后的失效；
- 检查敏感请求的
no-store或绕过路径； - 对语义缓存进行“相似问题、不同正确答案”的反例测试。
5. 安全与隐私
- 不让供应商密钥进入客户端、日志和错误响应；
- 验证提示词注入、PII、恶意文件与超长输入的处理；
- 明确原始 prompt/response 是否记录、保存多久、存在哪里、谁能查；
- 校验管理面和数据面的 RBAC、审计、密钥轮换与网络出口。
6. 可观测性与运维
- 指标至少包含请求量、错误率、TTFT、总延迟、token、成本、缓存命中和回退次数；
- trace 能贯通业务请求、网关和供应商调用，并对敏感内容脱敏；
- 压测时观察网关自身 CPU、内存、连接数、队列与数据库瓶颈；
- 演练升级、回滚、配置误发布、控制面不可用和单区域故障。
一个务实的选择顺序
如果从零开始，不妨按约束而非品牌来选：
- 三到十人的 AI 产品团队：先评估 Cloudflare 托管方案与 LiteLLM。前者换取最少运维，后者换取更强的供应商自由和自托管控制。
- 需要开发体验、路由与护栏一体化：评估 Portkey，但先钉死 OSS、Hosted、Enterprise 的功能和数据边界。
- 已有 Kong 平台：优先做 Kong 插件的增量验证，不要再增加一套身份与观测系统；同时把 AI License 成本算完整。
- 已有 APISIX/OpenResty 平台，重视开放与性能：用 APISIX 承担统一流量治理，再按需补语义缓存、成本控制和内容安全。
- 强合规或大规模平台团队：先写数据驻留、审计、SLA、RTO/RPO 和采购约束，再评产品。此时“功能最多”远不如“边界可证明”重要。
还有一种常被忽略的答案：暂时不引入独立 AI Gateway。如果只有一个应用、一个供应商、流量很小，先用 SDK 封装、秘密管理和基础遥测，可能更诚实。基础设施应该消化已经出现的复杂度，而不是预支想象中的规模。
结论
没有普遍最好的 AI Gateway，只有与团队约束最匹配的控制面。
LiteLLM 适合快速统一模型接口并逐步建立预算治理；Kong 适合把 AI 纳入成熟 API 平台；APISIX 适合重视开源透明和网络能力的团队；Cloudflare 用最少运维提供托管入口；Portkey 在 AI 原生路由、护栏与商业治理之间提供另一种组合。
真正耐用的选型，不是押中一个永远领先的产品，而是保留迁移能力：业务代码只依赖稳定别名，供应商特性有契约测试，策略可以版本化，日志可以导出，密钥不被控制面绑死。
网关最好的状态不是让人感到它无所不能，而是当模型、供应商和组织都在变化时，系统仍知道每一次请求为什么被允许、为什么被路由，以及出了问题该由谁接住。
读者回响