Azure OpenAI 多区域负载均衡方案：基于 APIM 实现高可用与配额优化-代码聚汇网

1. 为什么企业需要给 Azure OpenAI 做多区域负载均衡

1.1 Azure OpenAI 的区域配额把应用“锁死”了

很多团队第一次用 Azure OpenAI 时都会有种错觉：开通一个资源，接上 key，调用 /chat/completions 就能跑。等流量真涨起来，第一个发现就是 429 刷屏。原因很直接——Azure OpenAI 的资源配额是按“区域”独立计算的，每个区域的每个模型都有独立的 RPM（每分钟请求数）和 TPM（每分钟 Token 数）限制。你开通了 Sweden Central 的 GPT-4o，它的 TPM 额度只属于 Sweden Central，和美国的 East US 没有半毛钱关系。

这意味着什么？如果你的应用只部署了一个区域的 Azure OpenAI 资源，业务峰值一来，TPM 瞬间打满，后面的请求全部排队报 429。更尴尬的是，旁边另一个区域的 OpenAI 资源可能空闲得很，但因为代码里写死了“只调这一个 endpoint”，你只能眼睁睁看着配额浪费。

我见过不少项目的做法是：直接把 eastus 的 key 写死在配置里，上线后某天模型区域做维护或者某个区域被大规模用户挤爆，应用直接“白屏”。这时候再加多区域已经不是优化，而是救火了。所以这套架构从一开始就应该防患于未然。

1.2 单区域方案在真实业务中的三个典型故障

结合我实际参与的几个项目，单区域接入 Azure OpenAI 的问题绝对不是“偶尔抖动”那么简单，它一般会在三个层面同时发难：

第一是配额击穿。 Azure OpenAI 的限流不是测出来的，是真实打出来的。有一次我压测一个客服问答机器人，脚本里开了 100 个并发，每个请求的 prompt 大约 1500 token。跑了不到两分钟，服务端就开始大量返回 429。一查监控，该区域的 TPM 已经 100% 占用，而后端模型实际处理能力还有余量。这种情况下一味增大并发没有任何意义，瓶颈不在模型推理，而在配额。

第二是可用性单点。 OpenAI 服务在某个区域出故障并不是什么罕见事，比如某次 East US 区域网络抖动，我手上三个项目的生产环境同时报警，因为所有请求都指到了那一个区域的 endpoint。云服务本身的 SLA 再高，到了区域粒度就是“99.9%”和“100%”的差别，而这个 0.1% 落到用户侧就是实打实的线上事故。

第三是延迟不均匀。 如果你的用户分布在国内、东南亚、欧洲，但你只在 Sweden Central 开了一个 OpenAI 资源，欧洲的用户体验还行，东南亚的用户每个请求要多绕几千公里，首字延迟轻松翻倍。这还只是网络层面的损耗，如果是流式输出，体感会更明显。

1.3 对比三种常见均衡方案后，为什么我选了 APIM

聊解决方案之前，先说一个更基础的问题：多区域负载均衡，市面上明明有很多选择，为什么偏要用 Azure API Management？

方案 A：DNS 轮询（Traffic Manager）。 Azure Traffic Manager 可以做基于 DNS 的流量分发，按地理路由或者轮询把请求送到不同区域的 OpenAI endpoint。它配置简单，但粒度太粗，只能做到“请求级别”的分发。它不考虑每个区域当前剩余多少 TPM，也不知道后端是不是已经熔断，更做不到在同一个 API 调用里根据请求上下文动态切换后端。说白了，它管“路”，不管“车”。

方案 B：Azure Load Balancer 或 F5 这类硬件/软件负载均衡。 如果只是做四层转发，这些东西当然很能打，吞吐高、延迟低、稳定。但 Azure OpenAI 不是一个普通 TCP 后端，它涉及订阅密钥、配额策略、模型路由、Token 级限流，这些业务逻辑如果全压到 LB 层，配置会变得异常复杂。负载均衡设备擅长处理 IP 和端口，不擅长解析请求体里的模型名和 Token 数。

方案 C：应用代码自己实现。 你可以在业务服务里写一个自己的“均衡器”，比如轮询多个 endpoint，记录每个区域的配额余量，自己实现熔断和重试。理论上可行，但实际开发量很大，尤其是要想做好配额感知路由和异常恢复，基本等于自己重造一个轻量级网关。而且这个逻辑要跟着业务代码一起发版、一起扩缩容，运维成本极高。

方案 D：Azure API Management（APIM）。 APIM 走的是一条“中间层”的路子。它本身具备多区域网关部署能力，天然就是一个 PaaS 级别的流量入口；同时它有强大的策略引擎，可以在请求进入网关后，用 XML 策略动态决定把请求转发到哪一个后端。你可以在策略里读取 HTTP 头、调用外部 API、读取缓存、按权重或优先级选后端、给不同订阅方设置不同的 RPM 限制，还能把 Token 消耗计入配额。它既是负载均衡器，也是 API 网关，还是流量控制台。这个位置正好卡在 DNS 轮询和应用代码之间，复杂度可控，能力最贴合 Azure OpenAI 的诉求。

我用一个表格来总结这几种方案在关键维度上的差异：

对比项	Traffic Manager	LB / F5	应用内实现	APIM
请求级路由	否	部分支持	是	是
基于权重/优先级调度	支持（较粗）	支持	可自定义	支持
TPM/RPM 配额感知	否	否	需要自己写	支持
熔断与自动恢复	否	部分支持	需要自己写	支持
多租户密钥管理	否	否	需要自己写	支持
策略编排能力	弱	弱	强，但成本高	强

所以最后我的选型很明确：流量入口用 APIM 的多区域网关兜底高可用，策略层用 set-backend-service 配合自定义路由规则实现区域调度，再用 APIM 的限流和监控把配额管起来。这个组合能解决 95% 以上我遇到过的实际问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 整体架构设计：APIM 多区域方案的核心原理

2.1 整个链路长什么样

先不急着上配置，把架构图画在脑子里。整个系统从用户到模型，大概经过这样一条链路：

用户请求 → APIM 网关（区域 A 或区域 B）→ 策略引擎（路由、限流、缓存、鉴权）→ 后端池（Azure OpenAI 区域 A / 区域 B）

APIM 本身是一个多区域部署的服务，你在主区域创建 APIM 实例后，可以往辅助区域再添加网关节点。每个区域都有独立的网关入口，DNS 解析时 Azure 会把用户流量引导到就近的 APIM 网关，或者在主区域故障时自动切换到辅助区域。这是“入口侧”的高可用。

而真正的后端负载均衡发生在策略层。APIM 收到请求后，会走一组预先定义好的 inbound 策略。这些策略决定：这个请求应该发给哪个 Azure OpenAI 区域、要不要尝试重试、当前订阅方有没有超限、有没有可以命中的缓存。这相当于在“入口高可用”之上再叠加一层“后端调度”。

我特别想强调一点：APIM 的多区域网关解决的是“APIM 自身的高可用”，不是“后端 OpenAI 的负载均衡”。很多人配置完辅助区域就以为搞定了，实际上请求到了 APIM 之后，如果 set-backend-service 还是死指向单个 OpenAI endpoint，那后端依然是单点。正确的做法是把多个区域的 OpenAI endpoint 都注册成后端，在策略里按规则切换。

2.2 APIM 自带多区域网关：高可用是第一层保障

APIM 的多区域能力依赖 Premium 或者更高阶的层级。标准层和开发者层都只是单区域部署，只有 Premium 层允许你在同一个 APIM 实例下添加一个或多个辅助区域。

开启多区域后，Azure 会在你选的辅助区域里自动部署一套 APIM 网关组件，配置和主区域保持同步。也就是说，主区域和辅助区域的 API、策略、产品、订阅配置是同一套，但网关节点物理分布在两个区域。请求进入任何一个区域的网关，都能拿到同一份配置。这对整个架构的容灾来说很关键——某个区域挂掉，流量切到另一个区域的网关，配置完全一致，不会出现“入口通了但策略全丢”的情况。

这里有个细节：主区域和辅助区域的关系默认是“主备”模式，所有流量默认都优先打到主区域网关。如果你希望两个区域都承担流量，需要配合 Azure Traffic Manager，或者通过自定义域名把不同区域的用户解析到对应的区域网关。对于 Azure OpenAI 场景，我倾向于直接把主区域网关作为“主入口”，辅助区域作为“故障逃生通道”，因为更重要的均衡逻辑在后端，而不是网关入口。

2.3 真正的负载均衡靠策略层完成

这块是整个方案的核心，所以我多说几句。

APIM 的策略（Policy）本质是一段 XML，在请求的生命周期里按顺序执行。inbound 策略在请求进入网关时执行，正好适合做“路由决策”。我一般会在 inbound 段做这几件事：

1）从请求里提取关键信息，比如路径里的 deployment-name、请求头里的区域偏好、调用方订阅 ID。
2）查询当前各后端区域的健康状态或配额余量，最简单的方式是读一个存储在外部存储里的状态值，也可以用 APIM 的 backend health 检测能力。
3）用 choose 条件或者 set-backend-service 把请求转发到对应的 OpenAI 区域。

后端池（backend pool）的概念在 APIM 里是后来才引入的，它可以让你在一组后端服务之间做负载均衡。每个后端节点有自己的 URL、优先级、权重。请求命中后端池时，APIM 会根据你配置的调度算法选择一个节点。

谈到调度算法，我觉得“等开销负载均衡”的思路最实用——不是简单地把请求平均分到各个区域，而是根据每个区域当前的开销能力来分配流量。比如区域 A 的 TPM 配额剩余多，就多分一点流量过去；区域 B 的请求延迟已经很高了，就暂时少分甚至不分。这种智能调度在 APIM 里可以通过策略组合实现，初听有点复杂，但一旦配置好，效果非常明显。

2.4 为什么这套方案能扛住高并发

最后聊一下“扛住高并发”这件事的本质。单纯看 APIM 的吞吐能力，Premium 层的每个网关单元都能处理很高的并发请求，但真正让你“扛得住”的是两个东西的组合：

第一，多区域配额叠加。你有两个区域的 OpenAI 资源，每个区域 100K TPM，后端总配额就是 200K TPM。APIM 按区域把流量打散，整体可用配额翻倍。这比什么都强，因为 Azure OpenAI 服务本身的能力没变，但你手里可用的“资源总量”上去了。

第二，策略层的限流和重试保护了后端。如果没有 APIM 这一层，高并发直接怼到 OpenAI endpoint，你没有中间缓冲，请求一多老婆 429。APIM 可以配置 rate-limit 策略，把每个订阅方的请求速率控制在一个合理范围内，还可以配置 retry 策略，在出现 429 或 5xx 时自动换一个区域重试，而不是直接把错误扔给用户。这相当于后端前面加了缓冲垫和自动换路器，高并发来了不会一窝蜂挤死一个后端。

3. 实操：搭建 APIM 多区域负载均衡全流程

3.1 前置条件清单与网络规划

动手之前，先确认手里有几样东西，缺哪个都跑不起来：

一个 Azure 订阅，并且有权限创建 APIM 实例和 OpenAI 资源。
至少两个不同区域的 Azure OpenAI 资源。我这次用的是 East US 和 Sweden Central，一个在美国东部，一个在欧洲北部，延迟差异和配额差异都很明显，适合演示调度效果。
一个 APIM Premium 层实例。如果你还没有 APIM，建议直接在 Portal 里创建一个；如果已经有了但层级是标准层，需要先升级到 Premium，否则后面看不到多区域部署选项。
每个 OpenAI 资源的 endpoint 和 key（先用 key 方式联调，后续再换成托管身份）。
Application Insights 实例，用来收集 APIM 的请求日志和指标，这对后文要讲的监控和排查至关重要。

网络规划上有个容易漏掉的地方：APIM 实例有虚拟网络（VNet）接入选项。如果是纯公网联调，直接在公网模式下用 APIM 的公网 endpoint 即可，不需要额外配 VNet。如果生产环境要求内网互通，那需要把 APIM 接入 VNet，并确保两个区域的 VNet 能访问对应区域的 OpenAI 服务。大部分 Azure OpenAI 服务走公网 endpoint，所以 VNet 规划的重点其实是保证 APIM 能正常访问外网，以及客户端的入站流量策略。

3.2 启用 APIM 多区域部署

点击“添加区域”，选择辅助区域。此时 Azure 会要求你选择容量单元数。容量单位（Capacity Unit）决定网关的处理能力，单个单元大约能处理每秒几十到上百个请求，具体取决于策略复杂度。一般建议主区域和辅助区域配置相同的单元数，避免故障切换后容量缩水。

点击保存后，Azure 开始部署辅助区域网关，这个过程一般需要 20 到 40 分钟。部署完成后，你在区域列表里能看到主区域和辅助区域的状态都是“已部署”。

此时有个重要的验证动作：拿主区域的网关 URL 和辅助区域的网关 URL 分别调一次 API，确认两边都能正常响应。之前有个同事配完辅助区域就搁那儿了，过了两周需要切流量才发现辅助区域网关的 DNS 解析总是失败，原来是自定义域名没有绑到辅助区域，排查了半天。

3.3 接入 Azure OpenAI 后端：API 定义与 OpenAPI 导入

APIM 接 OpenAI 后端有两条路：一条是导入 OpenAI 的 OpenAPI 规范，一条是手动创建空 API 再补操作。

我推荐第二种，理由很实在：OpenAI 官方 OpenAPI 规范针对的是 api.openai.com，而 Azure OpenAI 的 endpoint 结构和它略有差异（多了 deployments/{deployment-name} 这一层），直接导入通常需要修改 URL 模板，不如手动创建清爽。

具体操作：在 APIM 左侧选择“API”，点击“添加 API”，选“空白 API”。显示名称填“azure-openai-gateway”，名称填“azure-openai-gateway”，Web 服务 URL 先填一个占位符，比如 https://your-eastus-openai.openai.azure.com/。API URL 后缀填 openai。这样让 APIM 对外暴露的地址就是 https://your-apim.azure-api.net/openai/*。

接下来创建操作。我举一个最常用的例子：Chat Completions。

显示名称：Chat Completions
名称：chat-completions
URL：POST /openai/deployments/{deployment-id}/chat/completions?api-version=2024-06-01
模板参数里，deployment-id 是个路径参数，选择“必需”。

注意这里的 URL 模板把 OpenAI 的 deployment-id 暴露成了路径参数。这么做的好处是，同一个 API 操作可以转发到任意模型的任意 deployment，APIM 只负责匹配 URL 模式，然后把请求转发到对应的后端。后续加新模型时不需要在 APIM 里新建一大堆操作。

3.4 配置后端池，实现区域调度

这是我觉得 APIM 配置里最容易被低估的一步。APIM 的后端（Backend）是一个独立资源，它记录了真实的服务 URL、访问凭证、TLS 校验规则。你可以在“后端”菜单里维护多个后端，每个后端对应一个 Azure OpenAI 区域。

我先建两个后端：

后端名称：openai-eastus
- URL：https://your-eastus.openai.azure.com
后端名称：openai-sweden
- URL：https://your-sweden.openai.azure.com

创建好后端后，在 API 的操作里修改 inbound 策略。核心逻辑是替换 set-backend-service 的目标，让它指向某一个后端。为了演示一个完整的“等开销负载均衡”效果，我写了一版策略大致如下：

xml复制<inbound>
    <base />
    <set-variable name="routeKey" value="@(context.Request.Headers.GetValueOrDefault("X-Routing-Key", "default"))" />
    <choose>
        <when condition="@(context.Variables.GetValueOrDefault<string>("routeKey") == "eastus")">
            <set-backend-service backend-id="openai-eastus" />
        </when>
        <when condition="@(context.Variables.GetValueOrDefault<string>("routeKey") == "sweden")">
            <set-backend-service backend-id="openai-sweden" />
        </when>
        <otherwise>
            <set-backend-service backend-id="openai-eastus" />
        </otherwise>
    </choose>
</inbound>

这段策略读取请求头 X-Routing-Key，根据它的值把请求路由到不同区域。默认走 eastus。这是最简单的“请求头路由”。接下来我要把它升级成真正的负载均衡。

APIM 支持 backend pool 的概念：你可以把多个后端放进一个池子，设置优先级和权重，然后让 APIM 按权重分配流量。在策略里用 set-backend-service 指定一个 backend pool 的 ID，APIM 会根据池子里的配置自动选一个后端。

举个例子：

xml复制<set-backend-service backend-id="openai-multi-region-pool" />

假设 openai-multi-region-pool 池子里配置了 eastus 权重 50、sweden 权重 50，APIM 就会近似按 50/50 的比例分发请求，实现基本的负载均衡。

但在真实生产里，我更推荐“智能路由”而不是固定权重。原因是 Azure OpenAI 的 TPM 配额是动态变化的，固定权重无法感知配额余量。你可以借助 APIM 的缓存策略，把每个区域当前的剩余 TPM 写入缓存，每次请求进来时读取缓存并选一个配额最充足的后端，这就是等开销负载均衡的思路——按每个节点的实际开销能力分发流量，而不是机械轮询。

这个方案实现起来也不复杂，我给出一个结合缓存的示意策略：

xml复制<inbound>
    <base />
    <cache-lookup-value key="eastus-tpm" variable-name="eastusTpm" />
    <cache-lookup-value key="sweden-tpm" variable-name="swedenTpm" />
    <choose>
        <when condition="@(context.Variables.GetValueOrDefault<int>("eastusTpm", 0) >= context.Variables.GetValueOrDefault<int>("swedenTpm", 0))">
            <set-backend-service backend-id="openai-eastus" />
        </when>
        <otherwise>
            <set-backend-service backend-id="openai-sweden" />
        </otherwise>
    </choose>
</inbound>

这里我假设你有一个外部程序定期把每个区域的剩余 TPM 写入 APIM 的缓存。实际项目中，你可以写一个 Azure Function，定时调用 OpenAI 的配额查询接口，然后把指标推给 APIM 缓存或 Application Insights，让策略实时读取。这样整个调度就有了“感知”能力，不再是瞎碰运气。

3.5 关键策略配置：限流、重试与熔断

除了路由，APIM 上还有三组策略必须要配，缺一组都可能在线上出问题。

限流策略。 我习惯在“产品”（Product）级别配置 rate-limit，而不是在 API 操作级别。原因很简单：产品的粒度能区分不同调用方，你可以给内部测试订阅 100 RPM，给生产订阅 1000 RPM，互不影响。示例策略：

xml复制<rate-limit calls="100" renewal-period="60" retry-after-header-name="X-RateLimit-RetryAfter" />

如果担心 OpenAI 的 Token 配额，还可以用 APIM 专门为 Azure OpenAI 提供的 azure-openai-token-limit 策略（需要 APIM 更新到较新版本），它可以根据请求里的模型名和提示词长度估算 Token，并对指定时间内累积 Token 数做限制，比单纯按请求次数限流精确得多。

重试策略。 多区域负载均衡的关键价值是“坏了一个区域能自动换另一个”。重试是这里的核心机制。当后端返回 429 或 5xx 时，我希望 APIM 自动换一个区域重试一次，而不是直接把错误返回给用户。示例策略：

xml复制<retry condition="@(context.Response.StatusCode == 429 || context.Response.StatusCode >= 500)" count="1" interval="5" first-fast-retry="false">
    <set-backend-service backend-id="openai-sweden" />
    <forward-request />
</retry>

这段代码的大意是：当第一次请求失败且状态码是 429 或 5xx 时，切换到 sweden 后端再试一次。这里有个坑：直接 forward-request 会把原请求再发一遍，如果请求体里的 deployment-id 在 sweden 区域不存在，重试还是会失败。所以重试逻辑要确保两个区域的 deployment 名称一致，或者重试前动态改写请求路径中的 deployment-id。

熔断策略。 重试是“事后补救”，熔断是“事前预防”。如果某个区域内连续出现错误，就不应该再把流量送过去了。APIM 里有 circuit breaker 能力，或者你可以用 choose 条件和缓存自己实现一个简单的熔断开关。比如：

xml复制<cache-lookup-value key="eastus-circuit-open" variable-name="eastusCircuitOpen" />
<choose>
    <when condition="@(context.Variables.GetValueOrDefault<string>("eastusCircuitOpen", "false") == "true")">
        <set-backend-service backend-id="openai-sweden" />
    </when>
    <otherwise>
        <set-backend-service backend-id="openai-eastus" />
    </otherwise>
</choose>

外部巡检程序发现 eastus 连续失败 10 次后，往 APIM 缓存写一个开关标记，后续请求全部自动切到 sweden。当巡检程序确认 eastus 恢复正常，再清除开关。这个模式在实际生产里非常好用，比依赖 APIM 内置的健康检查更灵活。

3.6 使用托管身份安全转发请求

最后是认证问题。直接在 APIM 后端配置里把 OpenAI 的 key 写死是最快的做法，但也是最不安全的做法。生产环境我强烈建议用托管身份（Managed Identity）方案。

大致思路是：给 APIM 实例开启系统托管身份 → 在 Azure OpenAI 资源中给这个身份分配“Cognitive Services OpenAI User”角色 → 后端请求不再带 api-key，而是靠 APIM 在转发前自动获取一个 Azure AD Token。

这样做的好处非常明显：key 不落盘、不轮换、不泄露。APIM 的后端配置里不再需要存储密码，密钥管理压力瞬间消失。

配置时有个容易踩的坑：Azure OpenAI 的接口要求 api-version 是必需的，但托管身份方案关注的不是版本，而是你是否在 inbound 策略里用 authentication-managed-identity 策略注入了 Token。示范策略：

xml复制<authentication-managed-identity resource="https://cognitiveservices.azure.com" output-token-variable-name="msi-access-token" ignore-error="false" />
<set-header name="Authorization" exists-action="override">
    <value>@("Bearer " + (string)context.Variables["msi-access-token"])</value>
</set-header>

这段策略放在 set-backend-service 之后、forward-request 之前，APIM 会调用托管身份端点获取一个 Azure AD Token，然后覆盖 Authorization 头。后端 OpenAI 识别到 Bearer Token 后，会通过 Azure AD 验证身份，匹配对应的角色权限。如果角色没配好，常见的报错是 401 或 403，这个我会在第 5 节详细讲。

4. 配额模型、监控与成本：上线前必须算清的三笔账

4.1 看懂 Azure OpenAI 的 RPM/TPM 配额模型

想把多区域负载均衡做好，不搞懂 Azure OpenAI 的配额模型是不行的。

每个 Azure OpenAI 资源在部署模型时，都会有一个容量（Capacity），通常用 TPM 表示。TPM 是 Token Per Minute 的缩写，指每分钟能处理的 Token 总量，这个 Token 包括输入和输出的总和。RPM 是 Request Per Minute，指每分钟最多处理的请求数。

举个具体例子：你给 East US 的 GPT-4o 部署分配了 100K TPM，给 Sweden Central 的同一模型也分配了 100K TPM。拆开看，每个区域单跑都有 100K 的实际容量；合在一起，你的架构就拥有了 200K TPM 的后端总容量。这听起来很美好，但要注意：这两个配额是各自独立的，你无法把一个区域的剩余配额“借”给另一个区域。负载均衡的意义恰恰在于，尽量让每个区域的配额“物尽其用”，避免一边打满一边空闲。

另一个细节是，Azure OpenAI 限流是按模型和部署维度计算的，不是按整个资源计算。同一个 OpenAI 资源里，GPT-4o 的 TPM 打满，可能给 GPT-3.5-Turbo 留的额度还有不少。所以配置 APIM 限流时，最好按 deployment 维度做隔离，避免某个热点模型拖垮同区域的其他模型。

4.2 用量监控与告警：Application Insights 接入

配置这么多策略，总要有个东西来告诉你“这套系统健康不健康”。APIM 原生支持导出请求日志到 Application Insights，你可以看到每个请求走了哪个 API、哪个操作、后端响应时间、状态码，甚至可以自定义跟踪属性。

我建议在 inbound 策略的最前面加一个 set-variable，把当前路由的目标区域名记录下来，然后通过 log-to-eventhub 或 Application Insights 的跟踪能力输出。这样排查问题时，你能清楚地看到某一个失败请求到底被路由到了哪个区域。

在 Azure Portal 的 Application Insights 里，可以用类似这样的查询语句把请求按区域聚合：

kusto复制requests
| where name endswith "chat-completions"
| project timestamp, success, duration, customDimensions.["routed-region"], resultCode
| summarize Count=count(), AvgDuration=avg(duration), Failures=countif(success == false) by routed-region

配好告警规则后，当某个区域的失败率超过阈值或者平均延迟飙升，你会第一时间收到通知。这在多区域架构里是刚需——没有监控，负载均衡就是盲人摸象。

4.3 成本估算：APIM 层与 OpenAI 区域的成本权衡

说完技术说成本，这也是老板最关心的问题。

APIM Premium 层不便宜，按容量单元和小时计费。你添加了一个辅助区域，意味着每个月要多付一份 APIM 网关的费用。这笔钱在项目初期看起来就像“纯消耗”，但它换来的收益是：后端 OpenAI 配额叠加带来的吞吐能力翻倍、故障切换带来的可用性提升、以及不写一行负载均衡代码的开发成本节约。

Azure OpenAI 的价格按模型和区域略有差异，但大体上同模型同区域价格一致。做多区域负载均衡并不会直接降低模型调用单价，但它能让你在一个区域配额用尽时，把请求调度到另一个区域继续处理，避免了业务中断带来的隐性损失。对追求稳定性的线上业务来说，这笔账算下来是值得的。

还有一个小技巧：如果预算紧张，可以在辅助区域只部署一个容量单元，承担“兜底”角色，主要流量仍由主区域承担。这样可以降低冗余成本，同时保留故障切换能力。

5. 真实踩坑：常见问题与排查技巧实录

5.1 429 限流持续出现，排查思路是什么

症状： APIM 日志里 429 很多，有的来自 OpenAI 后端，有的来自 APIM 自身。

排查思路： 先确认 429 是从哪一层出来的。看响应头里的 x-ms-apim-* 或者 retry-after 头。如果错误来自 OpenAI，响应里通常会有 x-ratelimit-remaining-tpm 或 x-ratelimit-remaining-requests。如果剩余值已经是 0，说明是后端配额打满，需要把流量切到另一个区域。如果 APIM 自己返回 429，说明是 APIM 的 rate-limit 策略触发，此时应该调大调用方限额，或者按 product 拆分不同的限流阶梯。

我踩过最典型的坑是：APIM 的 rate-limit 策略只配置在 API 级别，但我没有设置 retry-after-header-name。客户端收到 429 后不知道什么时候该重试，就一直打，越打越 429。后来加上 retry-after 响应头并告诉客户端严格按这个头重试，情况才好转。

5.2 辅助区域“备而不用”怎么验证

症状： 多区域配置好了，但永远只有主区域在忙碌，辅助区域一个月零请求。

排查思路： 这个不一定是故障，可能你的流量策略就是主备模式。但如果你想确认辅助区域真的能接流量，就需要主动“拨测”。我常用的办法是：在客户端请求里带上 X-Routing-Key: sweden 头，直接强制把请求路由到瑞典区域；或在 APIM 后端池里临时把 eastus 的优先级调低，观察流量是否自动切到 sweden。如果强制路由都不通，多半是辅助区域后端配置有误，或者 OpenAI 资源在辅助区域没有对应的 deployment。

还有个容易忽略的地方：如果你用了自定义域名，并且没有把辅助区域的网关地址加入自定义域名的 DNS 配置里，辅助区域网关虽然部署成功，但从公网可能根本访问不到。多区域网关的“域名接入”是独立配置的，别漏了。

5.3 后端返回 404/401 的常见姿势

404 多半是路径问题。 APIM 转发到 Azure OpenAI 时，URL 路径里必须包含 openai/deployments/{deployment-id}/chat/completions?api-version=xxx。如果你的 API 操作 URL 模板少了 api-version，或者把 api-version 放到了请求体里，OpenAI 后端就会返回 404。我建议把 api-version 写死在路径里，不要依赖客户端传参。

401 多半是认证问题。 如果你使用 api-key 方式，检查 APIM 后端的 URL 里是否带了正确的 key。切换成托管身份后，401 一般是因为 APIM 的托管身份没有在 OpenAI 资源上分配角色。去 OpenAI 资源的“访问控制（IAM）”里，把 APIM 的身份添加为 Cognitive Services OpenAI User 即可。注意分配完角色后，通常需要几分钟才能生效，别刚配完就急着报障。

5.4 超时与重试的坑

症状： GPT-4o 这种大模型在长上下文场景下，首 Token 延迟经常超过 10 秒。APIM 默认的前端请求超时时间是 20 秒左右，如果模型推理时间再长一点，APIM 会直接返回 504。

排查思路： 调大 APIM 的请求超时时间（在 API 设置的“超时”里改），同时确认客户端的超时设置也要相应放大。另一个坑是重试策略和超时叠加——如果第一次请求已经发出去了，后端已经算了一半，这时候因为超时重试又发一次相同请求，可能造成重复计费和资源浪费。重试策略一定要谨慎设置，别把重试当成“万能药”。

5.5 策略生效顺序和缓存污染问题

APIM 的策略执行顺序是 inbound → backend → outbound → on-error。新手最容易犯的错是把 set-backend-service 放在 outbound 段，结果看起来配置没问题，但请求发出去的时候后端还没被替换，白白报 404。set-backend-service 必须在 inbound 段执行。

缓存污染是另一个隐蔽问题。如果你在 APIM 策略里启用了响应缓存，而同一个缓存 key 对应了不同区域的 OpenAI 后端，那么调度到 eastus 的请求可能拿到的是之前 sweden 的响应。解决方法是把缓存 key 里加入 deployment-id 和区域标记，确保不同区域的响应不会串。这个坑我踩过一次，线上出现过用户问“为什么我刚才问的答案和现在的不一样”，排查半天才发现是缓存串区了。

最后再分享一个小技巧：多区域负载均衡上线后，不要急着删掉单区域的旧入口。先并行跑一两天，对比两个入口的请求成功率、延迟和错误码。这样既能验证 APIM 方案是否真的更稳，也方便在极端情况下快速回滚。我所有多区域项目都是这么切流量的，稳得很。

Azure OpenAI 多区域负载均衡方案：基于 APIM 实现高可用与配额优化