OpenAI 按请求选择处理地区：一个 API Key，任意地区，无需新建项目

多地区 API 部署过去需要给每个目标地区单独建一个 OpenAI 项目，拿一个单独的 API Key。8 月 21 日起，OpenAI 改变了这件事。用 Global 地域项目的单个 API Key，就可以在发请求时按条目选择处理地区，办法是切换 base_url。

机制直接，在 domain 前加前缀。us.api.openai.com/v1 把推理和存储路由到美国，eu.api.openai.com/v1 路由到欧洲（EEA 及瑞士）。两个调用用同一个 API Key，不换项目，不换凭证。

实际请求长什么样

from openai import OpenAI

client = OpenAI()  # 从环境变量读取 Global 项目 Key

# 默认，不指定地区
response = client.responses.create(model="gpt-5.6-terra", input="Hello")

# 强制美国处理和存储
response = client.with_options(
    base_url="https://us.api.openai.com/v1",
).responses.create(model="gpt-5.6-terra", input="Hello")

# 强制欧盟处理和存储
response = client.with_options(
    base_url="https://eu.api.openai.com/v1",
).responses.create(model="gpt-5.6-terra", input="Hello")

with_options 在支持按调用覆盖 base URL 的 OpenAI SDK 版本上都可以用。它生成一个短生命周期的 client 变体，不修改父 client，并发安全。

哪些地区支持处理，各自有什么要求

并非所有地区端点等价，存储和处理的区别在合规上有实质意义。

美国处理可以立即使用，不需要任何手续。欧盟处理需要先获得 Modified Abuse Monitoring（MAM）或 Zero Data Retention（ZDR）审批，这两项是现有的企业级数据控制，但都需要走销售流程。

其他地区（澳大利亚、加拿大、日本、印度、新加坡、韩国、英国）只提供地区存储，数据静态存在对应地区，但推理仍可能跨地区。如果你把请求发到这些端点并期待地区内推理，得不到这个效果。路由策略里要把支持处理的端点和只支持存储的端点区分开来。

这件事如何改变路由决策

以前多地区的做法是这样的。

1. 在 OpenAI 控制台给每个目标地区建一个项目
2. 为每个地区分别申请、轮换 API Key
3. 在网关里配置 N 份凭证，映射到 N 个地区
4. 根据合规标签把请求分发到对应凭证

用单个 Global 项目 Key 之后，流程变成这样。

1. 网关凭证库里只有一个 API Key
2. 根据请求元数据（用户位置、租户合规标志、数据分类标签）拼接对应的 base_url 前缀
3. 不需要按地区查凭证，只需要构造 URL

对路由网关来说，这把多地区路由从凭证路由问题变成了 URL 构造问题。凭证库缩小，轮换面缩小，每个租户的合规策略变成请求打标问题，而不是 Key 选择问题。

跨 provider 视角

Azure OpenAI Service 多年来一直用独立的 resource 部署来提供地区端点，每个 resource 有自己的 base URL 和 Key。Google Vertex AI 的地区端点同样需要按地区初始化独立 client。OpenAI 这次的按请求方式更接近 AWS Bedrock 的跨地区推理 Profile，用一个标识符，推理在选定地区运行。

从网关操作的角度，OpenAI 新模式是三者里最简单的。单个 client 实例可以在不同地区之间切换，不需要销毁和重建。代价是地区处理能力依赖 Global 项目资格，无法在单次请求里混用不同的数据留存配置。

运营者需要确认的资格限制

在把这个特性写进路由策略之前，有几个具体限制要核清楚。

• 只有 Global 地域项目才有资格。已经锁定到某个地区的项目，就没有按请求切换的灵活性，它们已经固定在那个地区了。
• 欧盟处理需要 MAM 或 ZDR。如果团队还在用默认的滥用监控配置，欧盟处理不可用。如果路线图里有欧盟地区推理，现在就要启动审批流程。
• 模型必须支持目标地区。不是每个模型快照都在每个地区可用。比如 UAE 端点的处理只支持 gpt-5.6-luna 和 gpt-5.5-2026-04-23，不支持 gpt-5.6-sol 或 gpt-5.6-terra。在把生产流量路由过去之前，先在 OpenAI 的数据控制文档 里确认模型与地区的组合。
• 按请求路由只对处理有效。把流量发到 gb.api.openai.com 并期待地区内处理，得到的只是地区存储。路由策略要区分支持处理的端点和仅存储的端点。

网关运营者现在可以做什么

三个具体动作对应这次发布实际改变的地方。

审计当前的地区 Key 配置。 如果你已经按地区建了多个 OpenAI 项目，检查一下能否合并到一个 Global 项目 Key。合并的代价是丢失了项目级的数据隔离（项目级 ZDR 不能用），对某些企业配置有影响。

路由到欧盟之前确认资格。 欧盟处理需要 MAM 或 ZDR。如果 GDPR 合规要求地区内推理，审批周期很重要，早点找 OpenAI 销售谈，而不是等到需要端点上线时。

把地区作为路由维度而非凭证维度来建模。 如果你在重新设计路由层，把地区前缀（us、eu、ae）理解为可从请求元数据推导出的属性，比如用户地理位置、租户合规等级、数据分类标签，而不是要选择的独立凭证。实现变成 base_url = f"https://{region_prefix}.api.openai.com/v1" if region_prefix else "https://api.openai.com/v1"。

对 TheRouter 用户来说，这意味着可以配置单个 OpenAI provider 凭证，把地区路由作为请求路径上的策略来表达，而不是配置多个带不同 Key 的 OpenAI provider。具体配置方式参考 provider 配置文档。