Azure API Management 和 Microsoft Foundry 中的 AI 网关
INFRO vs Azure AI Gateway
Azure 的 AI 网关是 Azure API Management 中的一组 AI 能力,也可以从 Microsoft Foundry 为其中的模型部署开启。它位于 Foundry 和 Azure OpenAI、其他提供商的 OpenAI、Anthropic 和 Vertex 形态的 API、自托管模型、MCP 服务器和智能体 API 之前,并对它们应用 APIM 策略:每个密钥的每分钟 token 限制和 token 配额、语义缓存、Azure AI Content Safety 检查、带熔断器的加权和优先级负载均衡,以及 Azure Monitor 中的 token 指标。对于已经运行 API Management 的企业,它延伸的是平台团队今天就在运维的网关,这一点很难超越。
何时 Azure AI Gateway 是更好的选择
- 你已经在运行 Azure API Management。你的 AI 流量使用与其他 API 相同的实例、网络、身份、开发者门户和策略语言,由已经负责这些的团队来运维。
- 你是基于 Foundry 的 Azure 原生企业。在 Foundry 门户中开启网关后,每个项目在共享实例上拥有自己的 token 限制和配额,通过托管身份访问模型,无需分发 API 密钥。
- 语义缓存是硬性需求。APIM 使用 Azure Managed Redis 和一个嵌入部署,为语义相近的提示词返回缓存的答案;INFRO 的响应缓存仅限精确匹配,且仅用于聊天补全。
- 你需要可编程的策略管道。带表达式的 APIM 策略可以根据请求中的任何内容进行转换、路由和限制;INFRO 的控制是在控制台和 API 中配置的固定功能,而不是一门策略语言。
- 你的容量是 Provisioned Throughput,问题在于每分钟 token 数,而不是美元。APIM 的 AI 策略正是围绕 token 限制,以及跨 PTU 和按量付费部署的优先级负载均衡构建的。
这一节不是客套。如果其中某一条说的正是你,请选择 Azure AI Gateway——一个听了我们的建议却用错了这一层的客户,对我们来说比从未成为客户更糟。
两者真正的分歧所在。
- 你自己运维的网关,还是你使用的服务
- Azure 的 AI 网关就是 API Management:一个位于你订阅中的实例,服务层级由你选择,用 XML 策略配置,由你的平台团队运维——Foundry 默认创建 Basic v2 实例,并建议生产环境使用 Standard v2 或 Premium v2。对于已经运行 APIM 且有相应人员的公司,这是合适的形态。INFRO 的套餐是托管的,预算、路由、允许列表和审计日志在控制台或通过其管理 API 配置,无需部署任何东西;企业协议也可以把它部署到你自己的基础设施中。
- 以 token 计,还是以美元计
- APIM 的 llm-token-limit 策略限制的是 token:每分钟的速率、每小时、每天、每周、每月或每年的配额,或两者兼有,以订阅、IP 地址或任意表达式为键,返回 429 或 403。token 是共享某个部署容量的合适单位,却不适合作为预算的单位,因为不同模型的一个 token,价格相差几个数量级,而以 token 计的配额在团队每次更换模型时都要重写。INFRO 的预算以预估提供商费用的美元计——从 Team 套餐起按你的协商价——作用于组织、项目、成员和密钥,在调用提供商之前检查,没有余量时以 402 拒绝。
- 成本是一条记录,而不是需要自己构建的指标
- APIM 会把 token 数量连同你添加的任意维度发送到 Azure Monitor 和 Application Insights,并在你开启后记录提示词和补全内容。要把这些变成按团队划分的成本,需要你自己给 token 定价。INFRO 在记录每个请求时为其定价,说明采用了哪种费率——你的协商价、厂商公布的费率,或未定价——并把它归因到项目、密钥、模型、路由或终端用户。在 Business 套餐中,当月估算会与 OpenAI 和 Anthropic 自己的成本 API 核对,并说明差异。
- 不是二选一
- Azure OpenAI 是 INFRO 可连接的提供商类型之一,通过你资源中的部署及其自己的密钥连接。公司可以把 APIM 继续放在 Azure 资源的前面,再用 INFRO 在该资源以及旁边的直接提供商合同之间统一提供预算、归因和审计轨迹。
并排对比。
我们这一栏也有横线。一方全是勾的对比没人会信,而且理应如此。
| 能力 | Azure AI Gateway | INFRO |
|---|---|---|
| 一套 API 访问众多提供商 | 是Foundry、Azure OpenAI,以及 OpenAI、Anthropic 和 Vertex 形态的 API | 是你所连接的提供商能提供的一切 |
| 无需部署或运维任何东西 | 否你订阅中的一个 API Management 实例 | 是托管服务 |
| 以 token 计的限额 | 是按每分钟和按周期,可用任意密钥 | 否改为每个密钥的请求速率限制 |
| 以美元计、会拒绝请求的预算 | 否仅 token 配额 | 是组织、项目、成员、密钥;402 |
| 每个请求的成本,已归因 | 部分按自定义维度的 token 指标 | 是项目、密钥、模型、路由、终端用户 |
| 响应缓存 | 是语义缓存,使用 Azure Managed Redis | 部分精确匹配,仅限聊天补全 |
| 内容安全 | 是Azure AI Content Safety 策略 | 部分模式匹配加可选的分类器检查;聊天补全;Business 套餐 |
| 负载均衡和故障转移 | 是加权、优先级、熔断器 | 是优先级或加权路由,任意模态 |
| 可编程的策略 | 是APIM 策略表达式 | 否已配置的功能,而不是策略语言 |
| MCP 服务器和智能体 API | 是MCP 和 A2A | 部分MCP 网关,Business 套餐 |
| 现已可用 | 是 | 是自助注册 |
这是我们对各产品公开文档的解读,截至 2026年10月。我们不引用竞争对手的价格——他们的价格会变,对别人的业务给出一个错误的数字,不如不给。认为某一行有误?请告诉我们,我们会更正。
已经在用 Azure AI Gateway?阅读从 Azure OpenAI 迁移的指南:哪些代码要改,哪些可以沿用,哪些不行。