AI 网关 vs API 网关：核心差异与选择方法
API 网关管理通用 API 流量，AI 网关则增加面向大语言模型（LLM）和其他 AI 服务的流量控制。两者存在重叠：AI 网关同样需要路由、身份认证、限流、故障处理和可观测性，同时还要处理模型供应商、Token、提示词和流式模型响应。
AI 网关与 API 网关概览
| 维度 | API 网关 | AI 网关 |
|---|---|---|
| 主要上游 | Web API 和微服务 | 模型供应商和 AI 服务 |
| 用量单位 | 请求、连接或字节 | 请求以及输入、输出 Token |
| 路由 | Host、路径、Header、权重和服务健康状态 | 通用控制，加上配置型模型实例或供应商路由 |
| 请求处理 | 通用协议和载荷策略 | 供应商请求转换和提示词处理 |
| 响应模式 | 同步、异步或流式 API | 常见长时间运行或流式模型响应 |
| 故障处理 | 重试、超时、熔断和上游健康检查 | 类似控制，加上模型供应商 fallback 和 Token 相关约束 |
| 可观测性 | 请求速率、延迟、状态、日志和追踪 | 网关指标，以及能力支持时的模型、Token 和首 Token 延迟摘要 |
这种区别描述的是额外工作负载和策略，并不意味着必须部署独立产品。有些组织使用专用 AI 网关，另一些组织则在已有 API 网关上增加 AI 专用插件。
API 网关负责什么
API 网关位于客户端和后端服务之间，提供统一入口并实施共享流量策略，例如：
- 请求路由和负载均衡；
- 网关侧身份认证；
- 限流与流量整形；
- TLS 终止和网络层访问控制；
- 重试、超时和熔断；
- 网关日志、指标和链路追踪集成。
这些控制可以减少各 API 重复实现基础设施逻辑。业务授权、资源级权限、领域行为和服务特定遥测仍由服务负责。
AI 网关增加了什么
AI 网关将网关控制用于模型流量，并增加符合 LLM 服务特点的能力。
供应商请求转换
模型供应商可能使用不同的端点、凭证和请求格式。AI 网关可以向应用提供稳定入口，并为其支持的供应商转换请求。实际兼容性仍取决于所选供应商和网关实现。
配置型模型路由与 Fallback
AI 网关可以按照权重或一致性哈希等明确策略，在模型实例之间分配请求。有些实现还提供有限重试、健康检查或 fallback 策略。
这属于网络流量管理，而不是自主模型选择。除非网关明确提供且配置了相应能力，否则判断哪个模型最适合某项任务、评估回答质量并根据业务结果改变路由，需要由应用逻辑或独立评估系统负责。
Token 感知的限制
传统限流统计单位时间内的请求数。LLM 工作负载还可能需要根据输入和输出 Token 设限，因为不同请求的大小和成本差异很大。Token 控制可以在网关限制用量，但定价、预算和成本分摊仍由外部系统负责。
提示词与内容控制
AI 网关可能分别提供提示词模板、提示词装饰、基于模式的提示词检查、内容审核或检索增强。每项能力都有明确范围。提示词规则或审核集成不能替代应用授权、数据治理、模型评估或合规审查。
AI 流量遥测
如果供应商响应提供所需数据，AI 网关可以记录模型名称、Token 用量、请求耗时和首个 Token 返回时间。网关遥测补充应用链路追踪和供应商监控，但无法单独衡量最终用户满意度、回答正确性或幻觉率。
流式响应并非 AI 独有
LLM 应用常使用 Server-Sent Events（SSE）增量返回生成内容，但流式传输并非 AI 独有。传统 API 同样可以使用 SSE、WebSocket 或其他流式模式，而且部分模型调用也是同步的。
实际区别在于模型流可能持续更长时间，并且用量信息可能要到响应完成后才可获得。团队应先验证网关如何处理流式响应、超时、重试、日志和部分响应，再决定是否沿用短 Web 请求的策略。
什么时候使用 API 网关
当主要需求是为 Web API 或微服务提供统一入口和流量策略时，应使用 API 网关。典型场景包括：
- 在后端服务之间路由请求；
- 集中实施网关身份认证和限流；
- 在 Kubernetes、虚拟机或混合环境中公开 API；
- 应用共享的故障处理和可观测性控制。
即使组织没有 LLM 工作负载，API 网关仍然有价值。
什么时候增加 AI 网关能力
当模型流量产生普通请求策略无法覆盖的需求时，可以增加 AI 网关能力，例如：
- 多个应用需要共享模型供应商访问层；
- 团队除请求限流外还需要基于 Token 的限制；
- 模型实例需要配置型负载均衡、重试或 fallback；
- 提示词模板、提示词检查、审核或受支持的 RAG 处理需要在网关执行；
- 运维人员需要在现有网关遥测中查看模型和 Token 摘要。
只调用一个模型供应商的应用未必需要立即部署专用 AI 网关。随着应用、供应商、环境和共享策略数量增加，网关的运维价值会更明显。
使用同一网关处理 API 与 AI 流量
Apache APISIX 是开源 API 网关，也可以通过插件实施 AI 专用控制。其通用网关能力处理路由、身份认证、故障策略和可观测性，AI 插件则增加供应商代理、配置型多模型路由、Token 限制、提示词处理、检索增强和 AI 流量摘要。
例如：
ai-proxy连接文档列出的模型供应商和 OpenAI 兼容端点。ai-proxy-multi在模型实例之间提供配置型负载均衡、重试、fallback 和健康检查。ai-rate-limiting执行基于 Token 的用量限制。ai-prompt-guard根据配置模式允许或拒绝提示词。ai-rag提供文档支持的 Azure OpenAI 与 Azure AI Search 检索流程。
这种方式让团队可以复用同一套网关运维模式，同时不会把 APISIX 描述成应用运行时或完整的 AI 治理平台。Apache APISIX AI 网关概览进一步列出了工作负载需求及其对应插件。
总结
API 网关和 AI 网关解决的是相互重叠的流量管理问题。API 网关提供适用于 API 和微服务的通用基础；AI 网关增加供应商、Token、提示词、检索和模型遥测控制。
团队应根据工作负载所需策略做选择。组织可以根据技术或组织边界部署独立网关，也可以使用 Apache APISIX，在同一个开源平台中管理普通 API 和已配置的 AI 流量。
