AWS rozszerza dostęp do GPT-6 w Amazon Bedrock na pięć regionów Azji i Pacyfiku

Amazon Web Services udostępniło modele OpenAI GPT-6 Sol i GPT-6 Luna w Amazon Bedrock za pośrednictwem globalnego wnioskowania między regionami, z pięciu źródłowych regionów Azji i Pacyfiku. Model GPT-6 Astra jest dostępny z regionu Azja i Pacyfik (Singapur) — poinformowała firma we wpisie opublikowanym 12 października 2026 r. na blogu AWS Machine Learning Blog: wpisie na blogu AWS Machine Learning Blog.

Wpis zawiera instrukcję konfiguracji dla zespołów w Tajlandii, Malezji, Singapurze, Indonezji i na Tajwanie. Opisuje, jak kierować wywołania, ustawiać uprawnienia i monitorować wnioskowanie z regionu źródłowego. AWS przedstawia profile jako rozwiązanie problemu wnioskowania w jednym regionie, które — jak twierdzi — może podlegać ograniczeniom, gdy popyt przekracza lokalne możliwości.

Globalne profile wnioskowania między regionami

Trzy identyfikatory profili wymieniono w punkcie bedrock-runtime końcowym. Użytkownicy uzyskują dostęp do GPT-6 Sol i GPT-6 Luna za pośrednictwem global.openai.gpt-6-sol oraz global.openai.gpt-6-luna z regionów Azja i Pacyfik (Singapur) ap-southeast-1, Azja i Pacyfik (Dżakarta) ap-southeast-3, Azja i Pacyfik (Malezja) ap-southeast-5, Azja i Pacyfik (Tajlandia) ap-southeast-7 oraz Azja i Pacyfik (Tajpej) ap-east-2. Do modelu GPT-6 Astra można uzyskać dostęp za pośrednictwem global.openai.gpt-6-astra wyłącznie z Singapuru. Regiony docelowe to obsługiwane komercyjne regiony AWS, w których wdrożono dany model. Konsola Amazon Bedrock wymienia wszystkie trzy profile wśród zdefiniowanych przez system profili wnioskowania.

W przypadku globalnego wnioskowania między regionami wywołujący przekazuje identyfikator profilu zamiast identyfikatora modelu. Region źródłowy to miejsce, z którego wykonywane jest wywołanie API; Amazon Bedrock wybiera region docelowy, w którym przetwarzane jest żądanie, natomiast rozliczenia, śledzenie limitów, AWS CloudTrail i Amazon CloudWatch pozostają w regionie źródłowym. AWS opisuje to rozwiązanie jako zapewniające szeroki dostęp do zasobów Amazon Bedrock w różnych regionach.

AWS opisuje trzy modele w kontekście ich zastosowań: GPT-6 Sol służy do rozumowania i programowania przy złożonych zadaniach, GPT-6 Luna — do ukierunkowanych, powtarzalnych zadań realizowanych na dużą skalę, a GPT-6 Astra — do złożonego rozumowania, programowania i pracy z długimi dokumentami. Według wpisu wszystkie trzy modele przyjmują tekst i obrazy, obsługują korzystanie z narzędzi po stronie klienta oraz buforowanie promptów. Różnią się poziomami intensywności rozumowania: Sol i Luna obsługują ustawienia od „none” do „max”, natomiast Astra — te same poziomy z wyjątkiem „none”.

Ścieżki dostępu i klienci do programowania

Każdy model obsługuje trzy ścieżki dostępu w Amazon Bedrock bedrock-runtime: Amazon Bedrock Converse API, OpenAI Responses API i OpenAI Chat Completions API. Zgodne z OpenAI interfejsy API wywołuje się przy użyciu /openai/v1 ścieżek, a nie za pośrednictwem SDK AWS. Obsługują one podpisywanie Signature Version 4 lub klucz API Amazon Bedrock, a w każdym przypadku identyfikator profilu należy przekazać jako parametr modelu.

Wymagania wstępne obejmują tożsamość IAM z uprawnieniami do wywoływania profilu, aktywowany region źródłowy (Singapur jest włączony domyślnie, natomiast Dżakarta, Malezja, Tajlandia i Tajpej to regiony opcjonalne, które trzeba najpierw aktywować) oraz aktualną wersję AWS SDK lub CLI. Przykłady zgodne z OpenAI wymagają również OpenAI SDK i generatora tokenów Amazon Bedrock. Zespołom migrującym istniejącego klienta OpenAI wpis zaleca ustawianie parametru modelu przy każdym żądaniu, korzystanie z obsługiwanych typów narzędzi (function, mcp, custom, namespace, oraz tool_search) i bezpośrednie konfigurowanie identyfikatora profilu wnioskowania zamiast odpytywania punktu końcowego modeli.

Aplikacja ChatGPT na komputery i interfejs CLI Codex korzystają z jednego pliku konfiguracyjnego, więc jedna zmiana obejmuje oba narzędzia. Spośród dwóch wbudowanych dostawców Amazon Bedrock tylko amazon-bedrock-runtime obsługuje profil wnioskowania, a podpisywanie SigV4 oznacza, że nie ma klucza API, który trzeba byłoby rotować. Codex podaje dla tych profili okno kontekstowe o wielkości 272 000 tokenów. Według AWS jest to wartość dostarczana przez samego Codex, a nie limit usługi; można ją zwiększyć za pomocą ustawienia model_context_window . Wymagana jest wersja Codex CLI 0.148 lub nowsza.

Uprawnienia, limity i monitorowanie

Wywoływanie dowolnego z trzech modeli za pośrednictwem profilu globalnego wymaga czterech instrukcji zasad IAM: dostępu do profilu wnioskowania oraz zasobu projektu lub domyślnego zasobu w regionie źródłowym; dostępu do modelu podstawowego w regionie źródłowym, ograniczonego do profilu; ARN modelu podstawowego niezależnego od regionu, z aws:RequestedRegion ustawionym na unspecified w celu umożliwienia routingu między regionami; oraz bedrock:CallWithBearerToken na potrzeby uwierzytelniania za pomocą klucza API. Wywołania strumieniowe wymagają dodania bedrock:InvokeModelWithResponseStream do trzech pierwszych instrukcji.

Globalne żądanie kierowane między regionami nie zawiera nazwy regionu, dlatego Amazon Bedrock ustawia aws:RequestedRegion na unspecified i odrzuca wywołanie, jeśli zasada kontroli usług zawierająca listę dozwolonych regionów nie zezwala na tę operację; komunikat o błędzie wskazuje jedynie typ zasady. Wpis wymienia tę sytuację jako częstą przyczynę niepowodzenia pierwszego wywołania na koncie firmowym. Zamiast rozszerzać listę dozwolonych regionów, AWS zaleca ograniczenie wyjątku za pomocą warunku bedrock:InferenceProfileArn który Amazon Bedrock uzupełnia podczas autoryzacji; dodanie unspecified do listy dozwolonych regionów działa, ale rozszerza ten sam wyjątek na wszystkie pozostałe usługi.

Na potrzeby automatycznego wykrywania nadużyć w trybie offline AWS przechowuje ruch oznaczony przez klasyfikator przez maksymalnie 30 dni i przetwarza go programowo. W przypadku wnioskowania między regionami dane są przechowywane w regionie docelowym, którym dla profilu globalnego jest dowolny obsługiwany region komercyjny, w którym wdrożono model. Kwalifikujący się klienci mogą za pośrednictwem zespołu obsługi kont AWS wnioskować o całkowitym braku przechowywania danych, a we wpisie zaleca się organizacjom, które muszą spełniać wymogi dotyczące lokalizacji danych, aby na wczesnym etapie zaangażowały zespoły ds. ryzyka i zgodności.

Limity GPT-6 w bedrock-runtime są określane w tokenach na minutę względem regionu źródłowego. Tokeny wejściowe i tokeny zapisywane w pamięci podręcznej są liczone w stosunku jeden do jednego, natomiast każdy token wyjściowy zużywa 10 tokenów limitu; przykład we wpisie pokazuje, że żądanie zawierające 2 000 tokenów wejściowych i 1 000 tokenów wyjściowych zużywa 12 000 tokenów. Amazon Bedrock rezerwuje z góry pełną max_tokens wartość, a jeden limit obejmuje InvokeModel, Converse, Responses i Chat Completions. AWS zaleca składanie wniosków o zwiększenie limitów przed uruchomieniem produkcyjnym oraz konfigurowanie alarmów dla EstimatedTPMQuotaUsage w przestrzeni nazw AWS/Bedrock po osiągnięciu 70–80 procent przydziału.

Metryki CloudWatch, zdarzenia CloudTrail, dzienniki wywołań modeli, rozliczanie limitów i opłaty pozostają w regionie źródłowym, a klienci płacą stawki obowiązujące w regionie źródłowym, a nie w regionie przetwarzania. AWS opisuje regiony docelowe profilu globalnego jako jego regiony komercyjne, nie wymieniając ich z osobna, a GetInferenceProfile interfejs API zwraca identyfikatory ARN modeli niezależne od regionu oraz przypisane do regionu źródłowego, zamiast listy regionów docelowych. Zapis przetwarzania dla każdego żądania jest dostępny additionalEventData.inferenceRegion w CloudTrail w regionie źródłowym.

Wnioskowanie w tym punkcie końcowym jest zdarzeniem związanym z zarządzaniem, domyślnie rejestrowanym bez dodatkowych kosztów. Historia zdarzeń CloudTrail jest przechowywana przez 90 dni, więc dłuższy okres wymaga utworzenia ścieżki audytu lub włączenia rejestrowania wywołań modeli. Jeśli programiści korzystają z GPT-6 za pośrednictwem agenta kodującego, CloudWatch Coding Agent Insights udostępnia gotowe pulpity nawigacyjne w ramach GenAI Observability, które pokazują zużycie tokenów w podziale na użytkownika, zespół i centrum kosztów, a agenty natywnie emitują metryki OpenTelemetry.