引言
AI 网关是一种位于应用或 AI Agent 与模型提供商之间的专用反向代理。它集中管理 LLM 流量的认证、路由、限流、安全策略、成本控制和可观测性。
本文介绍 AI 网关的工作方式、核心能力、常见架构模式，以及它与 API 网关和 MCP 网关的区别。如需了解部署模式、迁移顺序、请求生命周期和生产运维，请继续阅读 AI 网关部署与运维指南。如果要评估具体产品，可以访问 AISIX AI Gateway 产品页面，或查看 AI Gateway 对比。
什么是 AI 网关？
AI 网关是专为 AI 和 LLM 流量设计的反向代理。它会拦截应用或 AI Agent 与 OpenAI、Anthropic Claude、Google Gemini、DeepSeek 等 LLM 提供商之间的所有请求。网关先执行限流、认证、内容审核和可观测性等策略，再把请求转发给上游模型。
可以把它理解为传统 API 网关针对 LLM 流量独特特征扩展出的专用能力：
| 特征 | 传统 API 流量 | LLM / AI 流量 |
|---|---|---|
| 延迟 | 毫秒 | 数秒到数分钟 |
| 计费单位 | 请求 | Token（输入 + 输出） |
| 载荷 | 结构化 JSON/XML | 自然语言提示词 + 补全结果 |
| 流式传输 | 较少 | 常见（Server-Sent Events） |
| 安全风险 | 注入、DDoS | 提示词注入、PII 泄露、幻觉 |
| 成本模型 | 通常按请求或资源计费 | 通常按 Token 和模型计费 |
LLM API 成本高、对延迟敏感，而且具有独特安全风险，因此仅使用通用 API 网关往往不够。AI 网关在 API 网关模型之上增加了 Token 感知限流、提示词级安全、多模型路由和成本跟踪。
AI 网关如何工作？
AI 网关作为第 7 层反向代理，位于调用方与 LLM 提供商之间的请求路径上：
1┌─────────────┐ ┌──────────────┐ ┌──────────────────┐
2│ Web 应用 │ │ │ │ OpenAI │
3│ 移动应用 │────▶│ AI 网关 │────▶│ Anthropic │
4│ AI Agent │ │ │ │ Google Gemini │
5│ API 客户端 │◀────│ （策略） │◀────│ DeepSeek │
6└─────────────┘ └──────────────┘ │ 自托管 LLM │
7 └──────────────────┘
请求流程
- 客户端发送请求——应用或 AI Agent 向网关发送 LLM 补全请求，通常采用 OpenAI 兼容格式。
- 认证——网关使用调用方注册信息验证 API Key 或 JWT Token。
- 预处理策略——提示词防护检查注入攻击、PII 或有害内容；限流器检查 Token 与请求配额。
- 路由与负载均衡——网关根据路由规则、模型可用性、延迟或成本选择合适的上游 LLM。
- 转发到上游——请求被转发给选定的 LLM 提供商，并由网关注入凭证；提供商 API Key 保存在网关，而非客户端。
- 响应处理——响应流经网关返回，网关记录 Token 用量、执行内容审核并收集可观测性数据。
- 响应交付——处理后的响应返回客户端；流式补全通常使用 Server-Sent Events（SSE）。
AI 网关的核心能力
1. 多 LLM 负载均衡
AI 网关通过统一 API（通常兼容 OpenAI）把流量路由到多个 LLM 提供商。配置并测试兼容的备用模型后，可以降低对单一提供商的耦合并提高可用性。
- 加权路由——根据成本或质量偏好在主模型与备用模型之间分配流量
- 基于延迟的路由——自动把请求发送给响应最快的提供商
- 故障转移——一个提供商返回错误或超时时，自动使用另一个提供商重试
- A/B 测试——通过流量切分比较不同提供商的模型质量
2. Token 限流
传统 API 网关按请求数限流，而 AI 网关会按 LLM 的计费单位 Token 进行跟踪和限制。
- 为调用方、路由或模型设置**每分钟 Token 数（TPM）和每分钟请求数（RPM）**配额
- 集群级执行——在多个网关节点间保持一致限制
- 预算上限——按团队、项目或 API Key 设置硬性支出上限，防止成本失控
- 精细维度——为成本较高和较低的模型设置不同限制
3. 提示词防护与安全
LLM 流量带来了传统 API 网关不会处理的安全风险：
- 提示词注入检测——标记或拒绝疑似对抗性输入，同时应预期误报和漏报
- PII 处理——转发前脱敏已配置的数据类型，并单独验证覆盖率和提供商保留策略
- 内容审核——对已配置的输入和输出类别进行分类或过滤
- 提示词模板——执行标准提示词格式，保持一致性并防止滥用
- 审计日志——记录请求元数据和策略决策；只有确有必要时才记录提示词或补全内容，并配套脱敏、访问控制、加密和保留限制
防护规则属于纵深防御，不是授权边界。工具权限仍应确定且遵循最小权限原则，高影响操作需要人工批准。
4. 可观测性与成本跟踪
AI 网关提供传统监控工具容易遗漏的 LLM 使用情况：
- Token 用量指标——按调用方、模型和路由跟踪输入、输出及总 Token 数
- 成本归因——按团队、项目或单个 API Key 实时计算支出
- 延迟分布——监控首 Token 时间（TTFT）和总补全时间
- 错误率——按模型跟踪触发限流、提供商错误和超时的比例
- 集成现有工具——将指标导出到 Prometheus、Grafana、Datadog 或 ClickHouse
5. 凭证管理
AI 网关将提供商凭证与应用代码解耦：
- 虚拟 API Key——向团队和应用签发内部 API Key，由网关映射到提供商凭证
- 密钥轮换——无需修改应用配置即可轮换提供商 API Key
- 每 Key 访问控制——限制每个 API Key 可以访问的模型
- 提供商抽象——应用只访问统一的网关端点，无需知道实际由哪个提供商响应
6. 模型路由与编排
高级 AI 网关支持超出简单负载均衡的智能请求路由：
- 语义路由——根据内容或任务类型将请求路由到专用模型
- 成本优化——简单查询使用低成本模型，复杂查询使用能力更强的模型
- 缓存——仅缓存符合条件的响应；缓存键需要感知租户、身份、模型和策略，并采用加密与有限 TTL；敏感或用户专属提示词应绕过缓存
- 上下文窗口管理——自动截断或总结超出模型上下文窗口的提示词
AI 网关架构模式
模式一：独立 AI 网关
在现有 API 网关旁部署一个仅处理 LLM 流量的专用 AI 网关。
优点：针对 AI 场景设计，对现有 API 请求路径侵入较小；但共享网络、身份、观测或运维依赖仍需单独评估。
缺点：需要运维另一套系统，无法统一查看 API 与 AI 流量。
模式二：统一 API + AI 网关
由同一个网关处理传统 API 和 LLM 流量，通过插件或模块增加 AI 专用能力。
优点：只需运维一套系统，可统一可观测性和策略执行，并复用认证基础设施。
缺点：要求 API 网关原生支持 AI 专用能力。
Apache APISIX采用这种统一模式，通过插件为普通 API 网关路由增加 AI 能力。相比之下，AISIX是面向主要处理 LLM 和 AI Agent 流量团队的专用 AI 原生网关。
模式三：Sidecar / Service Mesh AI 网关
AI 网关作为 Sidecar 代理运行在 Kubernetes 服务网格中，在 Pod 层拦截 LLM 调用。
优点：可按服务隔离，对应用代码透明。
缺点：运维复杂度较高，全局策略更难执行。
AI 网关、API 网关与 MCP 网关的区别
如需详细比较 AI 网关与传统 API 网关，以及新兴的 MCP（Model Context Protocol）网关模式，请阅读配套文章：AI Gateway、MCP Gateway 与 API Gateway 有何区别？。
简而言之：
- API 网关管理传统 REST、GraphQL 和 gRPC 流量。
- AI 网关在 API 网关模型之上增加了面向 LLM 流量的 Token 感知和提示词感知能力。
- MCP 网关是面向 AI Agent 使用的 MCP Server 流量的专用代理。
合适的部署模式取决于需要治理的流量。团队可以为现有 API 网关增加 AI 能力，运行专用 AI 网关，也可以为工具访问引入 MCP 专用网关。
结论
AI 网关集中管理 LLM 与 Agent 流量。团队可以部署专用网关，也可以在现有 API 网关上增加 AI 能力；具体选择取决于流量从哪里进入系统，以及哪个团队负责提供商凭证、策略和可观测性。