We wpisie na blogu AWS Machine Learning opublikowanym 28 września 2026 r. ogłoszono, że model Grok 4.7 firmy xAI jest dostępny w Amazon Bedrock. AWS przedstawia w nim rodzaje danych wejściowych i wyjściowych, rozmiar okna kontekstowego oraz nazwane interfejsy i profile inferencji. Te informacje warto czytać łącznie: sama wiadomość o dostępności nie określa jeszcze, jakiego rodzaju żądanie zostanie wysłane, którą ścieżkę API wybierze użytkownik ani jaki profil wskaże. Poniższe szczegóły pochodzą z komunikatu AWS.

Dane wejściowe, odpowiedź i kontekst

Według AWS Grok 4.7 w Amazon Bedrock przyjmuje tekst i obrazy na wejściu oraz zwraca tekst. Kierunek tej wymiany ma znaczenie. Obraz jest opisany jako możliwy element danych wejściowych, natomiast wskazanym wynikiem jest tekst. Informacja o obsłudze obrazu na wejściu nie jest więc stwierdzeniem o tworzeniu obrazu na wyjściu. AWS podaje również okno kontekstowe o wielkości 500 tys. tokenów. Liczba ta określa deklarowany rozmiar kontekstu; sama w sobie nie mówi, jak długa będzie konkretna odpowiedź ani jaki rezultat przyniesie określone zadanie.

Wpis wymienia cztery poziomy nakładu rozumowania: low, medium, high i xhigh. Poziomem domyślnym jest high. Przy przygotowywaniu żądania warto więc rozpoznać, czy poziom ma być wybrany wprost, czy pozostawiony jako domyślny. Dzięki temu odczytujący konfigurację wie, do której z wymienionych wartości odnosi się żądanie. Nazwy poziomów i wartość domyślna nie stanowią jednak porównania jakości, czasu działania ani kosztu poszczególnych ustawień.

Interfejsy i profile inferencji

AWS podaje, że model jest udostępniany przez punkt końcowy bedrock-runtime z wykorzystaniem profili inferencji między regionami. Wpis wymienia obsługę Responses API, Chat Completions API, InvokeModel oraz Converse API. Są to nazwane w komunikacie ścieżki wywołania modelu. Czytając przykład integracji, należy ustalić, której ścieżki dotyczy, ponieważ AWS osobno opisuje uwierzytelnianie i zawartość odpowiedzi dla wybranych interfejsów. Umieszczenie ich na jednej liście obsługiwanych opcji nie oznacza, że każdy szczegół odpowiedzi jest w nich identyczny.

Dwa podane profile mają nazwy global.xai.grok-4.7 i us.xai.grok-4.7. AWS informuje, że w przypadku profilu geograficznego USA przetwarzanie pozostaje w geografii USA. To stwierdzenie odnosi się do tego konkretnego profilu, dlatego przy analizie miejsca przetwarzania istotna jest pełna nazwa profilu, a nie tylko nazwa modelu. Wpis opisuje również trzy poziomy usługi: Standard, Priority i Flex. Samo wymienienie tych nazw nie określa jeszcze zachowania pojedynczego żądania w danym poziomie.

Uwierzytelnianie i treść rozumowania

Według wpisu AWS wywołania zgodne z OpenAI mogą używać klucza Bedrock API jako tokenu bearer. Wywołania Converse za pomocą boto3 używają natomiast SigV4 z poświadczeniami AWS. Te informacje dotyczą różnych ścieżek wywołania. Przy konfigurowaniu klienta należy więc powiązać sposób uwierzytelniania z wybranym interfejsem, zamiast zakładać, że jeden opis obejmuje każdą z wymienionych możliwości.

AWS wskazuje też różnicę w treści odpowiedzi. Responses API może na żądanie zwrócić zaszyfrowaną treść rozumowania, podczas gdy Chat Completions API nie zwraca tokenów rozumowania. Możliwość poproszenia o zaszyfrowaną treść w Responses API nie jest zatem podstawą do oczekiwania takiego samego wyniku w Chat Completions API. Oba interfejsy są wymienione jako obsługiwane, ale wskazany szczegół wyjścia jest dla nich odmienny.

Przy wstępnej ocenie integracji pomocne są cztery pytania: czy żądanie ma zawierać tekst lub obraz, który z podanych interfejsów zostanie użyty, jaka będzie pełna nazwa profilu inferencji oraz czy poziom nakładu rozumowania trzeba wskazać jawnie. Wpis na blogu AWS Machine Learning dostarcza danych potrzebnych do takiego odczytania ogłoszenia. Potwierdza dostępność modelu w Bedrock i wymienia te ustawienia; z samych tych informacji nie wynika wynik konkretnego zastosowania.