APIM AI Gateway：LLM 流量成本管理新方案

一个 prompt 的成本可能是另一个的 100 倍，而你的 gateway 却分辨不出两者的区别。举个例子：一个请求携带 500-token 的 prompt，另一个请求则把 50,000 tokens 的检索上下文塞进同一个 endpoint；在请求计数器看来，两者完全一样，但按 token 计量时，成本却相差两个数量级。Azure OpenAI 定价页面上的每 token 费率相同，token 数量增加 100 倍，成本也就增加 100 倍。这只是算术，不是什么 benchmark。

这正是 Azure 上的 AI 成本治理在采用基于请求的策略时会失效的原因，也是 Microsoft 刚刚为这个问题推出专用 tier 的原因。Tech Community 的公告中写道：“今天，我们推出 Azure API Management 的 AI Gateway tier，目前已进入 public preview。它为平台团队提供了一套专门打造的体验。”Microsoft 在产品结构中设立专用 tier，本身就是在承认：LLM 流量并非又一种普通的 API 工作负载。Azure API Management 的 AI gateway 最初只是附加在现有 tier 上的一组 policy，如今它已经成为一个产品。这种转变所传递的信息，比功能列表本身更值得关注。

为什么 Azure 上的 AI 成本治理会击穿通用 gateway

每一种传统 gateway 控制机制，都假设各个请求的成本大致相同。rate limit、quota、分级 throttling、按调用量分摊成本——所有这些机制都默认 Team A 的 1,000 个请求，与 Team B 的 1,000 个请求成本相近。LLM 流量彻底打破了这个假设。每次请求的 token 数量可能相差几个数量级，模型选择会进一步放大每 token 的价格差异，而 streaming response 甚至意味着：请求被放行时，你还不知道这次调用最终会产生多少成本。

因此，每分钟 1,000 个请求的 rate limit 并不是成本控制。它只是戴着成本控制徽章的并发控制。两个团队可能都严格遵守相同的请求 quota，但其中一个团队产生的 token 账单却是另一个团队的数倍，而 gateway telemetry 显示的却是两个表现良好的消费者。

社区文章和 Microsoft 自己的示例中，都详细记录了常见的变通方案：从 completion response 中解析 usage block，发送 custom metric，再由你自己构建成本归属 dashboard。它在 demo 中确实可行。但一旦加入 streaming——usage 要等到 stream 结束时才会到达，而且是否提供还取决于 API options——再加上价格不同的多个 model deployment，以及跨 region failover，这套方案就会迅速崩塌。原本能够处理单个 deployment 的 custom policy，一旦 deployment 数量增加，就会立刻变成维护负担。

如果你的 gateway 衡量的是请求而不是 token，那么你拥有的只是监控，而不是治理。我曾在一篇论证 token-level 成本控制工程价值的文章中更完整地阐述过这一观点，而这个新 tier 的出现，说明 Microsoft 也认同它。

Azure API Management AI gateway tier 实际包含什么，又有哪些只是重新包装

下面说说这些能力的真实来历，因为那些只会改写公告的人不会告诉你。大多数主打能力并不是随着这个 tier 才出现的。Microsoft 早已把它们作为 GenAI gateway policies，发布在现有 APIM tiers 中；Microsoft Learn 的 API Management AI gateway capabilities 文档也记录了这些功能：用于基于 token 限流的 azure-openai-token-limit 和与模型无关的 llm-token-limit policies、用于生成消费者级 token telemetry 的 emit-token-metric policies、通过 cache lookup 和 store policies 实现且由 Redis-compatible cache 支撑的 semantic caching，以及通过 backend pools、load balancing 和 circuit breakers，实现多个 model deployment 之间的 routing 与 failover。

因此，“Premium tier 加 GenAI policies”与新 tier 之间的能力差距，比营销材料暗示的要小。按照公告自己的说法，这个 tier 真正改变的是运营模式：它为主要处理模型调用的平台团队提供了一套“purpose-built experience”，不再要求团队手写 XML policy 片段、单独配置 cache，并在 Application Insights 中自行拼装 token dashboard。

关于下表需要说明一点：左栏内容目前可以通过 Learn 的 policy 文档验证；右栏则反映了公告对一个 preview 产品的定位。请把它视为 Microsoft 的产品描述，而不是经过独立测试的能力清单。在围绕它设计架构之前，应根据 preview 文档逐项核实。

结论是：评估这个 tier 时，应关注它在运营层面带来的变化，而不是功能 checklist。这些功能大多早已存在，真正新增的是产品包装，而这种包装决定了你的平台团队能否真正以一致的方式运营它。

平台团队的权力转移：遏制 shadow AI

我的立场很明确：让每一次模型调用都经过中央 gateway，才是正确的架构。它不是多个可选方案之一，而是正确答案。散落在各个应用团队手中的 OpenAI 和 Azure OpenAI key，就是新一代 shadow IT，而且问题更加严重：成本会动态变化，数据暴露的形态取决于 prompt，审计时也没人能回答“上个月我们向哪个模型发送过什么内容”。

Microsoft 自己的架构指南也支持这种模式。Learn architecture center 发布了通过 gateway 为 Azure OpenAI 提供统一入口的指南：客户端持有 gateway credentials，gateway 通过 managed identity 访问模型 backend，而所有消费者都在同一个 enforcement plane 上接受计量、throttling 和 content filtering。把它放进 Microsoft 正在构建的更广泛 AI governance framework 中，职责划分就很清楚了：policy 和 identity 构成 control plane，APIM AI gateway 则是 enforcement plane。我曾在一套真正可落地的 Azure AI governance framework 中梳理过这个更大的结构；gateway 正是让框架不再停留于文档、而是开始真正拒绝请求的那一层。

接下来是文档没有告诉从业者的注意事项。onboarding 听上去很顺利，直到你遇到那些早在 gateway 建立之前，就已经把原始 Azure OpenAI key 嵌入应用的团队。第一步必须是发现 shadow usage，而这个过程就像考古：credential audit、egress inspection，所有手段都要用上。cutover 不可能一次完成，因此你需要让新旧两条路径并行运行一段时间，而这会暂时破坏你引入 gateway 时所追求的“单一 enforcement point”保证。中央 gateway 还会成为新的 choke point：你必须为 high availability 和额外一跳的 latency 做好预算，因为你刚刚把自己放到了公司所有 AI 功能的关键路径上。

结论是：gateway 只能治理流经它的流量。在推动接入的同时，还要轮换 backend key，并通过 network control 阻止直接访问模型 endpoint，让绕过 gateway 不再成为团队可以自行选择的选项。

定价与定位：APIM AI gateway tier 何时胜过改造现有方案

关于 preview pricing，坦率的答案是：在撰写本文时，Azure API Management 定价页面列出了 classic 和 v2 tiers，但尚未公布 AI Gateway tier 的专用定价。在正式数字出现之前，对这个 tier 所做的任何成本比较都只能基于结构，而不能基于具体数值。任何向你报出单 unit 价格的人，都只是在猜测。

但这个结构性问题依然存在明确答案，而且关键在于定价模型的形态，而不是 rate card。改造现有方案意味着：你要为一个按整个 API 体系规模配置的现有 tier 付费，还要支付 Redis-compatible cache、observability plumbing，以及为所有面向 AI 的 API 编写和维护 policy XML 所需的工程工时。如果专用 tier 按照公告的平台团队定位，以独立 instance 的形式部署，那么 AI 流量将拥有自己的 capacity，并在账单上单独列项。

这给出了真正可用的决策标准：

Traffic mix。如果 AI 调用相对于你的 REST 体系只是一个零头，那就改造现有方案。现有 tier 上的 GenAI policies 已经足够。如果 AI 在 gateway 流量中的占比较大，或者增长迅速，专用 instance 就能隔离它的扩缩容需求和 blast radius。

Operational overhead。如果你的平台团队早已熟悉 APIM policy XML，那么 DIY 路线的成本没有看上去那么高。如果他们并不熟悉，purpose-built experience 才是你真正购买的产品。

Isolation and scope。独立 deployment 会让 AI 流量拥有自己的 failure domain 和成本归属边界，仅凭结构就解决了 chargeback 问题的一半。

这里只做示意性计算，采用行业常见的输入值——请根据自己的数据校准，实际情况会有所不同：如果一个团队每月花费 20 个工程小时维护自定义 token-metering policies，那么它实际上是在为这个 tier 承诺通过配置解决的问题，消耗约八分之一个全职工程师。按高级工程师的综合人力成本计算，这部分持续发生的八分之一 FTE 成本，会超过大多数可能出现的 rate-card 差价。这与我在那些实际上并不能真正限制开支的 spend cap 中反复得出的结论相同：AI 成本控制中最昂贵的部分从来不是 SKU，而是你为了填补 SKU 的能力缺口所投入的工程工作。

Preview 就是 preview

在根据这个 tier 确定预算或作出架构承诺之前，请先阅读 Microsoft 针对 preview 的补充条款。preview 功能可能发生变化或被撤回，不提供 SLA，生产环境支持承诺也与 GA 服务不同。不要假设 preview 阶段看到的定价、条款或 region coverage 会原封不动地延续到 GA。

应根据 traffic mix 和组织范围作出决定。功能 checklist 无法替你得出结论，因为两条路径上的大多数功能本来就已经存在。

Preview 注意事项与第一周采用手册

现阶段不要做的事包括：承载生产关键型工作负载、执行可能阻断收入链路的强制预算控制，以及全面迁移 APIM。preview 的用途是建立 baseline，而不是建立依赖。

下面是我建议采取的第一步。请注意，这是建议，不是实测结果：

选择一个高流量的内部 AI 工作负载。之所以选择内部工作负载，是因为把 preview gateway 放到面向客户的链路上，无异于主动制造事故。之所以选择高流量，是因为你希望尽快观察到 token 波动。

让它通过 AI Gateway tier。保留现有的直接访问路径，并让它保持可用，以便随时 fallback。没错，这会暂时违反单一 enforcement point 原则。pilot 阶段可以接受这一点。

连续两到四周按消费者记录 token 支出。按团队、应用和 model deployment 分别统计。这个时间窗口只是为了得到可用分布而给出的建议，并非实测结论；波动较大的工作负载需要观察更长时间。

与当前的归属数据进行比较。对大多数组织来说，可供比较的现状是什么都没有，而这一点本身就是你应该汇报给管理层的发现。

还有一个注意事项：服务处于 preview 阶段时，region availability 和功能范围都会发生变化。因此，应根据当前文档确认你的 region 中实际可以部署哪些功能，而不是依赖任何博客文章——包括本文。

结论是：现在就利用 preview 建立 token 支出 baseline。这样做的团队，在 GA 时只需要作出定价决策；选择等待的团队，到时还得先启动一项调查工程。

更大的信号：Azure 正在围绕 AI 推动基础设施垂直化

把这次发布与它的同类产品放在一起，方向就很清楚了：AI Foundry 是专用的开发界面，Agent 拥有专门的 runtime 和 tooling，现在，一个已经 GA 超过十年的 gateway 产品也拥有了 AI 专用 tier。Azure 正在给予 AI 工作负载一等基础设施待遇，而不是把 AI 功能附加到通用服务上，就宣称工作已经完成。

下面是我的预测——明确说明，这只是个人观点，没有任何内部消息支持：相邻服务中还会出现更多 AI 专用 tiers 和 SKU。networking、observability 和 identity 是最明显的候选，因为 token-shaped traffic 会以 request-shaped traffic 从未有过的方式给它们带来压力。规划平台架构时，应假定 AI 流量将拥有独立的 control point，因为供应商显然也是这样规划的。

这改变了 Azure AI 成本治理的基准。token-level governance 不再是需要自行编写脚本实现的高级模式；它正在成为产品默认能力，而 request-level control 则正在沦为 legacy debt。设计治理模型时，应让 AI 专用 enforcement layer 成为一个可以直接填入的插槽，而不是一项需要整体消化的架构改造。那些把 AI Gateway tier 当作插槽的组织，早已提前接好了插座。其他组织则很快就会发现，事后改造究竟有多昂贵。

本文最初发布于 az365.ai。我是 Alex Pechenizkiy，一名 Azure 和 Power Platform solutions architect，专注于撰写坦诚且 vendor-neutral 的 Microsoft AI 技术栈分析。更多内容见 az365.ai。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。