Перейти к содержанию
Публикация AiManual

OpenAI GPT-5.6, GPT-6 и GPT-6.1 в Amazon Bedrock: как канадским командам подключиться через cross-Region inference

Канадские команды получили доступ к OpenAI GPT-5.6, GPT-6 и GPT-6.1 Sol в Amazon Bedrock из ca-central-1 и ca-west-1 через cross-Region inference. Разбираем мех

Коротко

Что будет в материале

  1. 01

    Что именно открылось канадским организациям в Amazon Bedrock

  2. 02

    Как работает cross-Region inference: endpoint в Канаде, обработка в поддерживаемом регионе

  3. 03

    Настройка доступа: IAM-политики и SCP с условием bedrock:InferenceProfileArn

  4. 04

    Проверка доступных профилей через AWS CLI и консоль

Что именно открылось канадским организациям в Amazon Bedrock

Канадские организации могут вызывать модели OpenAI GPT-5.6 (Sol, Terra, Luna), GPT-6 (Astra, Sol, Luna) и GPT-6.1 Sol в Amazon Bedrock из регионов Canada (Central) и Canada West (Calgary). Механизм доступа называется cross-Region inference: приложение отправляет запрос на endpoint bedrock-runtime в своём регионе, Bedrock маршрутизирует его в поддерживаемый регион обработки и возвращает ответ обратно. Об этом говорится в анонсе AWS от 20 октября 2026 года.

Практический смысл в двух вещах. Маршрутизацию держит сервис, а не ваш код: не нужно прописывать несколько регионов в конфиге, писать обвязку на случай недоступной площадки и переучивать SDK. Пропускная способность распределяется по более широкому пулу мощностей, поэтому пики проходят мягче.

Модели принимают текст и изображения, возвращают текст, поддерживают контекстное окно в 1 млн токенов, режим рассуждения и вызов инструментов. У GPT-6.1 Sol набор входных и выходных модальностей шире, детали приведены в её model card. Вызов идёт через OpenAI Responses API, OpenAI Chat Completions API или Amazon Bedrock Converse API на том же endpoint bedrock-runtime.

Кому и зачем это нужно: сценарии канадских команд

  • Продакшен с требованием держать данные в Канаде. Данные at rest остаются в исходном регионе, обработка идёт в Северной Америке. Это ограничение обсуждают с комплаенсом до, а не после запуска.
  • Агентные пайплайны. GPT-6 Astra позиционируется под сложные end-to-end рассуждения и агентные задачи, GPT-6.1 Sol под рассуждения и кодинг там, где важны и производительность, и стоимость.
  • Массовые повторяющиеся операции. Извлечение полей, классификация, суммаризация: GPT-6 Luna даёт быстрый и недорогой инференс с настраиваемым reasoning effort на каждый запрос.
  • Кодинг-ассистенты. GPT-5.6 Sol закрывает высокие нагрузки рассуждения, кодинга и агентных задач, GPT-6.1 Sol подходит для регулярной работы с балансом цены и качества.

Ограничение стоит проговорить прямо: инференс обрабатывается в Северной Америке, а не внутри канадского региона. Если внутренняя политика требует, чтобы запросы физически не покидали страну, CRIS такой сценарий не закрывает. Тогда отдельно проверяйте, какие модели доступны в вашем регионе без кросс-региональной маршрутизации, и держите в уме локальный контур для чувствительных данных.

Как работает cross-Region inference: endpoint в Канаде, обработка в поддерживаемом регионе

Последовательность вызова выглядит так:

  1. Приложение обращается к bedrock-runtime в ca-central-1 или ca-west-1.
  2. В запросе указывается inference-профиль: именованный объект с ARN, который задаёт правила маршрутизации.
  3. Bedrock выбирает поддерживаемый регион обработки из пула профиля и передаёт запрос туда.
  4. Ответ возвращается в исходный регион в том же соединении.

Приложению не нужно знать, где именно обработан запрос. Отсюда следует и обратное: география обработки определяется выбранным профилем, а не кодом. Поэтому профиль становится единицей контроля и для комплаенса, и для IAM.

US geographic (us.) vs Global (global.) inference-профили

В анонсе упоминаются два типа профилей. US geographic (префикс us.) держит обработку в Канаде и США. Global (префикс global.) маршрутизирует запросы в поддерживаемые коммерческие регионы AWS, то есть география шире. Отдельный нюанс: глобальный профиль для GPT-5.6, по описанию обновления, доступен только из ca-central-1.

Практическая разница сводится к двум пунктам. Первый — data residency: us. оставляет обработку в Северной Америке, global расширяет список площадок. Второй — набор ARN, которые попадут в IAM-условие. Если политика разрешает только us.-профили, вызов global. упадёт с отказом доступа, и это нормальное поведение guardrail, а не баг.

Критерий выбора короткий. Комплаенс требует Северной Америки: берите us. Политика допускает более широкую географию, а вам нужен максимум мощностей в пик: берите global. Промежуточных вариантов нет. Точный список регионов обработки по каждому профилю смотрите в консоли Bedrock и документации: публичный фрагмент анонса обрывается ровно на разделе о профилях, поэтому префиксы и ограничения проверяйте по актуальному Bedrock User Guide перед планированием.

Настройка доступа: IAM-политики и SCP с условием bedrock:InferenceProfileArn

Права настраиваются в исходном регионе, откуда приложение вызывает bedrock-runtime. Минимальный набор действий: bedrock:InvokeModel и bedrock:InvokeModelWithResponseStream. Ключевая деталь — условие bedrock:InferenceProfileArn: оно привязывает разрешение к конкретному профилю и не даёт обойти маршрутизацию, обратившись к модели напрямую в другом регионе.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeViaApprovedInferenceProfiles",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_ID"
      ],
      "Condition": {
        "StringEquals": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_ID"
        }
      }
    }
  ]
}

Что важно в этом фрагменте. Resource и Condition ссылаются на один и тот же ARN профиля: одного Resource мало, потому что вызовы через CRIS проверяются ещё и по условию на профиль. Плейсхолдеры ACCOUNT_ID и PROFILE_ID замените значениями из вывода get-inference-profile. Формат ARN и номер аккаунта зависят от типа профиля, поэтому копируйте строку целиком, а не собирайте по памяти.

Тот же condition переносится в SCP на уровне AWS Organizations, где он ограничивает набор разрешённых профилей сразу для всех аккаунтов подразделения:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInvokeOutsideApprovedProfiles",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:InferenceProfileArn": [
            "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_US_ID",
            "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_GLOBAL_ID"
          ]
        }
      }
    }
  ]
}

У Deny есть побочный эффект. Условие срабатывает и тогда, когда ключ bedrock:InferenceProfileArn в запросе отсутствует, поэтому политика заблокирует любые вызовы bedrock:InvokeModel без профиля, включая чужие модели в том же аккаунте. Если такие вызовы нужны, сузьте Resource до ARN конкретных моделей или вынесите Deny на отдельный OU. SCP не заменяет IAM: он задаёт верхнюю границу, а разрешение всё равно выдаётся ролью или пользователем в исходном регионе.

Проверка доступных профилей через AWS CLI и консоль

Перед написанием кода убедитесь, что профиль виден в регионе, из которого вы собираетесь вызывать модель.

aws bedrock list-inference-profiles --region ca-central-1
aws bedrock list-inference-profiles --region ca-west-1
aws bedrock get-inference-profile --region ca-central-1 --inference-profile-identifier PROFILE_ARN

В консоли Bedrock тот же список открывается в разделе inference profiles. Проверяйте три вещи: регион в правом верхнем углу совпадает с исходным, префикс профиля (us. или global.) соответствует вашей политике data residency, ARN скопирован целиком. ARN понадобится дважды: в запросе и в IAM-условии.

Отдельно проверьте, что нужная модель есть в списке поддерживаемых для выбранного профиля. Набор моделей по регионам меняется, и расхождение между статьёй и консолью чаще всего означает именно это.

Вызов моделей: Responses API, Chat Completions API и Converse API

Все три пути работают на endpoint bedrock-runtime. В поле model (в Converse это modelId) передаётся ARN или идентификатор inference-профиля, а не имя модели: именно профиль включает маршрутизацию. Если подставить имя модели напрямую, вызов либо не найдёт провайдера, либо уйдёт мимо нужного пула мощностей.

  • OpenAI Responses API. Агентные сценарии, вызов инструментов, стриминг. В анонсе для него приведены примеры и стриминга, и tool use.
  • OpenAI Chat Completions API. Когда в проекте уже есть OpenAI-совместимый код и хочется поменять только адрес и идентификатор модели.
  • Amazon Bedrock Converse API. Нативный Bedrock-стек, единый формат сообщений и инструментов для разных моделей, удобно при мультипровайдерной архитектуре.

Пример на Converse API из ca-central-1:

import boto3

client = boto3.client("bedrock-runtime", region_name="ca-central-1")
arn = "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_ID"

resp = client.converse(
    modelId=arn,
    messages=[
        {"role": "user", "content": [{"text": "Суммаризируй тикет и выдели главный риск"}]}
    ],
    inferenceConfig={"maxTokens": 800, "temperature": 0.2},
)
print(resp["output"]["message"]["content"][0]["text"])

Контекст до 1 млн токенов и режим рассуждения доступны через все три API, но параметры рассуждения и формата ответа у OpenAI-совместимых вызовов и у Converse различаются. Точные поля и пути запросов смотрите в документации Bedrock Runtime: набор параметров у моделей OpenAI на Bedrock шире, чем в типовом примере выше.

Стриминг ответов

Стриминг сокращает время до первого токена и нужен там, где ответ читает человек или агент принимает решение по ходу генерации. Требуется отдельное разрешение bedrock:InvokeModelWithResponseStream. При CRIS поток идёт через исходный регион, приложению не нужно знать destination.

stream = client.converse_stream(
    modelId=arn,
    messages=[{"role": "user", "content": [{"text": "Разбери инцидент по шагам"}]}],
    inferenceConfig={"maxTokens": 1500},
)["stream"]

for event in stream:
    if "contentBlockDelta" in event:
        print(event["contentBlockDelta"]["delta"].get("text", ""), end="")

Практический нюанс: обрыв клиентского соединения не отменяет списание токенов, которые модель уже сгенерировала. Ставьте таймауты и лимит maxTokens осознанно.

Tool use и агентные сценарии

Схема одинаковая во всех трёх API: вы объявляете инструменты (имя, назначение, JSON-схема аргументов), модель возвращает вызов с аргументами, приложение выполняет функцию и отправляет результат обратно в диалог, после чего получает финальный ответ. В Converse инструменты передаются в toolConfig, в Responses API используется собственный формат объявления и собственные события для вызовов.

Под агентные сценарии в линейке есть два разных профиля. GPT-6 Astra рассчитана на сложные end-to-end рассуждения и многошаговые агентные цепочки, GPT-6.1 Sol даёт сильные рассуждения и кодинг с балансом производительности и стоимости. Логика выбора и ограничения подробно разобраны в материале про GPT-6 Astra и корпоративных агентов.

Какую модель выбрать: GPT-5.6, GPT-6 или GPT-6.1 Sol

Позиционирование по данным анонса:

МодельПозиционированиеКогда подходит
GPT-5.6 SolВысокие нагрузки рассуждения, кодинга и агентных задачСложные шаги, где качество важнее задержки
GPT-5.6 TerraБаланс производительности и стоимости для повседневного продакшенаОсновной рабочий профиль для регулярных запросов
GPT-5.6 LunaБыстро и доступно для высоконагруженных приложений, чувствительных к задержкеМассовые операции с жёстким SLA по времени ответа
GPT-6 AstraСложные end-to-end рассуждения и агентные задачиМногошаговые агенты, где цепочка должна дойти до результата
GPT-6 SolРассуждения и кодинг для повторяющихся задач с подходящей экономикойРегулярная разработка, отладка, анализ данных
GPT-6 LunaБыстрый и недорогой инференс для высоконагруженных повторяющихся задач, reasoning effort настраивается на запросИзвлечение, классификация, суммаризация большими объёмами
GPT-6.1 SolСильные рассуждения и кодинг при балансе производительности и стоимостиКодинг-ассистенты и анализ, где важны и качество, и бюджет

Цены и результаты бенчмарков здесь не приводятся: в исходном анонсе их нет, а цифры из сторонних обзоров плохо переносятся на чужой профиль нагрузки. Сравнение GPT-6 Sol и Luna по экономике запроса разобрано отдельно в материале про выбор между GPT-6 Sol и GPT-6 Luna.

Рабочая эвристика для пайплайна: Luna на маршрутизацию и извлечение, Terra или GPT-6 Sol на типовые производственные задачи, Astra на шаги, где ошибка дороже токенов, GPT-6.1 Sol на кодинг. Проверять гипотезу стоит на своём наборе запросов, а не на общем лидерборде.

Квоты, prompt caching и стоимость владения

Квоты на Bedrock считаются в токенах в минуту. Выходные токены расходуют лимит быстрее входных: это и есть burndown rate, из-за которого длинная генерация упирается в потолок раньше, чем позволяет прикидка по размеру промпта. Планируйте лимит по худшему сценарию (maxTokens в запросе), а не по среднему размеру ответа. Стартовые значения по каждой модели и региону смотрите в Service Quotas AWS, там же оформляется запрос на увеличение. Конкретные коэффициенты в доступном фрагменте анонса не приведены, поэтому сверяйтесь с консолью перед тем, как обещать заказчику пропускную способность.

Prompt caching поддерживается у GPT-5.6, GPT-6 и GPT-6.1 в Amazon Bedrock. Кэш окупается там, где между запросами повторяется большой статический префикс: системная инструкция, описание инструментов, справочник, схема данных. При уникальном промпте на каждый вызов он не даёт ничего. Как это устроено на практике и какие есть подводные камни, разобрано в гайде по GPT-5.6 на Bedrock.

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

Data residency: что остаётся в Канаде, а что уходит

Разделяйте две сущности. Данные at rest остаются в исходном регионе, то есть в вашем ca-central-1 или ca-west-1: сюда относятся запросы, сохранённые в сервисах вокруг Bedrock, и ваши собственные хранилища. Сам инференс обрабатывается в Северной Америке (профиль us.) или в поддерживаемых коммерческих регионах AWS (профиль global.).

Отдельный пункт, который чаще всего всплывает в юридических обсуждениях: контент, помеченный классификаторами злоупотреблений, может храниться до 30 дней в регионе обработки. Публичный фрагмент анонса обрывается до раздела о data residency, поэтому сроки и точную географию хранения подтверждайте в документации Bedrock и у своего аккаунт-менеджера AWS, прежде чем ссылаться на них в политике.

Вывод для комплаенса. Если внутренние правила запрещают хранение даже помеченного контента за пределами Канады, это нужно согласовать с юристами явно, а global-профиль использовать с осторожностью: он расширяет географию обработки. Гарантий здесь никто дать не может, решение принимает ваша служба комплаенса на основе документации и договора.

Observability: CloudTrail и CloudWatch в исходном регионе

Сигналы наблюдаемости доступны в исходном регионе, и это заметное удобство: не нужно собирать логи из нескольких destination-регионов и склеивать их по request-id. CloudTrail фиксирует вызовы API, включая отказы по IAM и SCP, CloudWatch отдаёт метрики по запросам и ошибкам.

Настройте алерты на throttling и на долю ошибок доступа. При CRIS лимиты и burndown rate проявляются на стороне профиля, поэтому всплеск throttling часто означает не аварию, а упор в квоту в пиковый момент. Полезно держать отдельную метрику по каждому профилю и модели: агрегированный график скрывает, что один сценарий съедает весь запас токенов в минуту.

После экспериментов уберите за собой: временные роли, тестовые политики, неиспользуемые профили в приложении. Забытая широкая политика переживёт эксперимент на месяцы.

Чек-лист внедрения и типичные ошибки

  1. Выберите исходный регион: ca-central-1 или ca-west-1.
  2. Проверьте доступные профили через list-inference-profiles и get-inference-profile, скопируйте ARN.
  3. Определитесь с префиксом us. или global. по политике data residency. Помните, что глобальный профиль GPT-5.6 доступен только из ca-central-1.
  4. Настройте IAM-политику и SCP с условием bedrock:InferenceProfileArn, проверьте, что Deny не блокирует другие модели в аккаунте.
  5. Выберите API: Responses для агентных сценариев, Chat Completions для совместимости с существующим кодом, Converse для нативного Bedrock-стека.
  6. Включите prompt caching для статических промптов и описаний инструментов.
  7. Запросите увеличение квот с учётом burndown rate по выходным токенам.
  8. Настройте CloudTrail и алерты CloudWatch в исходном регионе.

Типичные ошибки, которые ломают запуск:

  • Политика без условия на профиль: доступ есть, контроля над географией обработки нет.
  • Попытка вызвать модель напрямую в другом регионе в обход профиля: отказ доступа либо обход guardrail.
  • Ожидание, что данные вообще не покидают Канаду: инференс идёт в Северной Америке, а помеченный контент может храниться в регионе обработки.
  • Планирование квот по среднему размеру ответа без учёта burndown rate.
  • Расчёт бюджета только по цене за токен без ретраев и повторной отправки длинного контекста.

Следующий шаг простой: поднимите тестовую роль в ca-central-1, вызовите нужную модель через Converse с ARN профиля и снимите метрики за сутки. Так вы получите свои цифры по задержке и расходу токенов до того, как решение уйдёт в продакшен.

Подписаться на канал