Региональная маршрутизация OpenAI по запросу: один ключ, любой регион, без новых проектов

Многорегиональные API-развёртывания раньше требовали отдельного проекта OpenAI — и отдельного API-ключа — для каждого целевого региона. С 21 августа это изменилось. Единый ключ от проекта с Global geography теперь позволяет выбрать регион обработки для каждого запроса, просто переключив base_url в момент вызова.

Механизм прямолинейный: добавить префикс к домену. us.api.openai.com/v1 направляет инференс и хранение в США. eu.api.openai.com/v1 — в Европу (EEA и Швейцарию). Оба вызова используют один и тот же API-ключ без смены проекта и ротации учётных данных.

Как выглядит запрос на практике

from openai import OpenAI

client = OpenAI()  # Global project 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 работает в любой версии OpenAI SDK, поддерживающей переопределение base URL на уровне вызова. Создаётся короткоживущий вариант клиента без мутации родительского объекта — безопасно для конкурентного использования.

Какие регионы поддерживают обработку и что требуется

Не все региональные endpoint-ы равнозначны. Разница между хранением и обработкой принципиальна с точки зрения compliance:

Обработка в США доступна немедленно без каких-либо согласований. Обработка в ЕС требует предварительного получения Modified Abuse Monitoring (MAM) или Zero Data Retention (ZDR) — это существующие enterprise-контроли, но оба требуют диалога с отделом продаж.

Регионы без обработки (Австралия, Канада, Япония, Индия, Сингапур, Южная Корея, Великобритания) обеспечивают только региональное хранение: данные в состоянии покоя остаются в регионе, но инференс может выходить за его пределы. Не стоит рассчитывать на региональную обработку в этих endpoint-ах. Routing-политика должна явно разграничивать endpoint-ы с поддержкой обработки и endpoint-ы только с хранением.

Как это меняет принятие решений при маршрутизации

Раньше многорегиональная схема выглядела так:

1. Создать отдельный проект OpenAI для каждого целевого региона
2. Выпустить и ротировать отдельный API-ключ для каждого региона
3. Настроить gateway с N учётными данными, сопоставленными с N регионами
4. Направлять запросы к нужным учётным данным на основе тегов соответствия

С единым ключом Global-проекта:

1. В хранилище учётных данных gateway — один API-ключ
2. Нужный base_url строится на основе метаданных запроса (геолокация пользователя, тег compliance уровня tenant, классификация данных)
3. Никакого lookup учётных данных по региону — только конструирование URL

Для routing gateway это превращает многорегиональную маршрутизацию из задачи управления учётными данными в задачу конструирования URL. Хранилище учётных данных сокращается, поверхность ротации уменьшается, compliance-политики для каждого tenant становятся функцией тегирования запросов, а не выбора ключа.

Взгляд с позиции роутера

Azure OpenAI Service предлагает региональные endpoint-ы через отдельные resource-развёртывания — у каждого resource собственный base URL и ключ. Google Vertex AI требует инициализации отдельного клиента на регион. Подход OpenAI per-request ближе к тому, как AWS Bedrock работает с cross-region inference profiles: один идентификатор, инференс выполняется в выбранном регионе.

Новая модель OpenAI наиболее удобна для gateway-операторов. Один экземпляр клиента может переключаться между регионами без пересоздания объекта. Компромисс: региональные возможности обработки зависят от наличия допуска Global-проекта, поэтому невозможно комбинировать разные конфигурации data residency в рамках одного запроса.

Ограничения допуска, которые нужно проверить операторам

Несколько конкретных ограничений перед тем, как встраивать это в routing-политику:

• Подходят только проекты с Global geography. Проекты, уже привязанные к конкретному региону, не получают гибкости per-request: они изначально зафиксированы.
• EU требует MAM или ZDR. При стандартной конфигурации мониторинга злоупотреблений EU-обработка недоступна. Если в роадмапе предусмотрен EU-инференс, процесс согласования нужно начинать заранее.
• Модель должна поддерживаться в целевом регионе. Не каждый снэпшот модели доступен в каждом регионе. Например, UAE-endpoint поддерживает обработку для gpt-5.6-luna и gpt-5.5-2026-04-23, но не для gpt-5.6-sol или gpt-5.6-terra. Перед направлением production-трафика нужно сверить совместимость модели и региона в документации по data controls.
• Per-request routing действует только для обработки. Запросы к gb.api.openai.com в ожидании региональной обработки дадут только региональное хранение. В routing-политике нужно разграничивать endpoint-ы с обработкой и endpoint-ы только с хранением.

Конкретные шаги для gateway-операторов

Три действия, соответствующие реальным изменениям в этом релизе:

Аудит текущей настройки региональных ключей. Если у вас несколько проектов OpenAI, созданных для каждого региона, оцените, можно ли консолидировать их в один Global-проект с единым ключом. Компромисс — потеря изоляции данных на уровне проекта (проектный ZDR перестаёт работать), что критично для некоторых enterprise-конфигураций.

Проверить допуск для EU до настройки маршрутизации. EU-обработка требует MAM или ZDR. Если требования GDPR предполагают региональный инференс, временны́е рамки согласования важны — взаимодействие с отделом продаж OpenAI лучше начать сейчас, а не когда endpoint уже должен быть в production.

Моделировать регион как измерение маршрутизации, а не как измерение учётных данных. При переработке routing-слоя региональный префикс (us, eu, ae) следует рассматривать как атрибут, выводимый из метаданных запроса — геолокация пользователя, compliance-уровень tenant, классификация данных — а не как отдельные учётные данные для выбора. Реализация сводится к: base_url = f"https://{region_prefix}.api.openai.com/v1" if region_prefix else "https://api.openai.com/v1".

Для пользователей TheRouter это означает возможность настроить единые учётные данные OpenAI-провайдера и выражать региональную маршрутизацию как политику на уровне пути запроса, не создавая несколько OpenAI-провайдеров с разными ключами. Подробности настройки — в документации по конфигурации провайдеров.