Microsoft 已在 Azure API Management (APIM) 中新增了专用的 AI Gateway 层级。此举表明，LLM 调用现在被视为一种独立的负载，而不仅仅是另一个 API 端点。

为什么 LLM 流量会使传统网关失效

单个提示词（prompt）的成本可能比另一个高出百倍，但标准的 API 网关会将两者都视为单个请求。网关统计的是调用次数，而不是模型处理的 token 数量。一个发送几百个 token 的请求与一个发送数千个 token 的请求会产生相同的请求计数指标，尽管后者的成本可能高出几个数量级。

以下四个事实使得基于请求的限制对 AI 无效：

  • 成本 ≠ 请求数。 计费与 token 相关，而不是取决于你进行了多少次 HTTP 调用。
  • Token 数量波动巨大。 一个查询可能只是一个短问题，而另一个可能包含一份长文档。
  • 模型选择会改变价格。 不同的 LLM 每 token 的收费标准不同。
  • 流式传输会掩盖最终账单。 当响应以流式传输时，在流结束之前无法得知总 token 数量。

如果你只测量请求数，最终得到的监控数据将无法反映实际支出。

AI Gateway 层级带来了哪些变化

用于管控 token 使用的大多数策略其实已经存在于标准的 APIM 层级中——它们以 XML 规则的形式编写，并显示在自定义仪表板上。AI 层级将这些功能整合到了一个专门构建的体验中：

  • 为 AI 流量提供独立的扩展能力。
  • 简化的配置，无需再手动编写 XML 策略。

核心转变在于运维层面：你不再需要编写复杂的代码或维护独立的仪表板来执行 token 预算。该层级为这些控制功能提供了一个开箱即用的界面。

何时切换——基于流量的指南

  • AI 仅占你流量的一小部分。 继续使用现有的 APIM 层级，如果需要精细化控制，可以添加 token 策略。
  • AI 占据了你的调用大头。 迁移到 AI 层级，以实现扩展隔离并保持成本治理的清晰。
  • 你想避免工程开销。 该层级的内置工具可以省去构建和维护自定义策略的时间。

最大的开销不是订阅费用，而是为了修补通用网关的缺陷以使其理解 token 经济学而投入的工程工时。

预览阶段执行方案

Microsoft 目前仍以预览版形式提供 AI 层级。请将其视为测试平台，而非正式生产环境。

  1. 选择一个高容量的内部 AI 负载。 选择产生最多 token 流量的服务。
  2. 将该负载路由到 AI 层级。 使用新配置来捕获每个消费者的 token 使用情况。
  3. 收集几周的 token 支出数据。 将 token 数量及相关成本与现有的监控数据进行对比。
  4. 利用基准数据进行预算规划。 评估该层级的成本控制优势是否超过了其预览阶段的局限性。

在服务进入正式发布（GA）阶段之前，请勿将关键业务的生产负载迁移到预览版服务。

反方观点：并非每个人都需要独立的层级

如果你的组织只是偶尔调用 LLM，那么 AI 层级的额外成本可能并不划算。你可以利用现有的策略框架实现 token 级别的治理，尽管需要投入更多的手动工作。当 AI 流量成为 API 服务中占比重大且不断增长的部分时，该层级的优势才会显现。

总结

AI Gateway 层级承认了 LLM 流量的行为模式与传统 API 调用有着本质的区别。通过从请求计数转向基于 token 的治理，它为开发者提供了一种切实可行的方法来控制 AI 支出，而无需深陷于自定义代码中。对于 AI 使用量已经很大或预计会增长的团队来说，现在测试预览版有助于建立 token 支出的基准。