AWS amplia l’accesso a GPT-6 su Amazon Bedrock a cinque regioni dell’Asia-Pacifico

Amazon Web Services ha reso disponibili GPT-6 Sol e GPT-6 Luna di OpenAI su Amazon Bedrock tramite l’inferenza globale tra regioni a partire da cinque regioni di origine dell’Asia-Pacifico. GPT-6 Astra è disponibile dall’Asia-Pacifico (Singapore), ha dichiarato l’azienda in un articolo sul blog AWS dedicato al machine learning pubblicato il 12 ottobre 2026.

L’articolo illustra la configurazione per i team in Thailandia, Malesia, Singapore, Indonesia e Taiwan, spiegando come effettuare la chiamata, impostare le autorizzazioni e monitorare l’inferenza dalla regione di origine. AWS presenta i profili come una soluzione all’inferenza in una singola regione, che, secondo l’azienda, può subire limitazioni quando la domanda supera la capacità locale.

Profili di inferenza globale tra regioni

Sono elencati tre ID di profilo sull’ bedrock-runtime endpoint. È possibile accedere a GPT-6 Sol e GPT-6 Luna tramite global.openai.gpt-6-sol e global.openai.gpt-6-luna dall’Asia-Pacifico (Singapore) ap-southeast-1, dall’Asia-Pacifico (Giacarta) ap-southeast-3, dall’Asia-Pacifico (Malesia) ap-southeast-5, dall’Asia-Pacifico (Thailandia) ap-southeast-7 e dall’Asia-Pacifico (Taipei) ap-east-2. GPT-6 Astra è accessibile tramite global.openai.gpt-6-astra solo da Singapore. Le regioni di destinazione sono le regioni AWS commerciali supportate in cui è distribuito ciascun modello; nella console di Amazon Bedrock, tutti e tre i profili sono elencati tra i profili di inferenza definiti dal sistema.

Con l’inferenza globale tra regioni, il chiamante passa un ID di profilo al posto di un ID modello. La regione di origine è quella da cui viene effettuata la chiamata API; Amazon Bedrock seleziona la regione di destinazione per l’elaborazione, mentre la fatturazione, il monitoraggio delle quote, AWS CloudTrail e Amazon CloudWatch restano nella regione di origine. AWS descrive questa soluzione come un modo per accedere ampiamente alla capacità di Amazon Bedrock nelle diverse regioni.

AWS descrive i tre modelli in base ai carichi di lavoro: GPT-6 Sol è destinato al ragionamento e alla programmazione su attività complesse, GPT-6 Luna ad attività mirate e ripetibili su larga scala e GPT-6 Astra al ragionamento complesso, alla programmazione e all’elaborazione di documenti lunghi. Secondo l’articolo, tutti e tre accettano input di testo e immagini, supportano l’uso di strumenti lato client e la memorizzazione nella cache dei prompt. Differiscono per il livello di ragionamento: Sol e Luna accettano impostazioni da none a max, mentre Astra accetta gli stessi livelli, tranne none.

Modalità di accesso e client di programmazione

Ciascun modello supporta tre modalità di accesso su bedrock-runtime: l’API Converse di Amazon Bedrock, l’API Responses di OpenAI e l’API Chat Completions di OpenAI. Le API compatibili con OpenAI vengono chiamate tramite percorsi /openai/v1 anziché tramite gli SDK AWS e accettano la firma Signature Version 4 oppure una chiave API di Amazon Bedrock; in ogni caso, l’ID di profilo va passato come parametro del modello.

Tra i prerequisiti figurano un’identità IAM autorizzata a richiamare il profilo, una regione di origine attivata (Singapore è abilitata per impostazione predefinita, mentre Giacarta, Malesia, Thailandia e Taipei sono regioni facoltative da attivare prima dell’uso) e una versione aggiornata di AWS SDK o CLI. Gli esempi compatibili con OpenAI richiedono anche OpenAI SDK e il generatore di token di Amazon Bedrock. Per i team che migrano un client OpenAI esistente, l’articolo consiglia di impostare il parametro del modello in ogni richiesta, usare i tipi di strumenti supportati (function, mcp, custom, namespace, e tool_search) e configurare direttamente l’ID del profilo di inferenza anziché interrogare l’endpoint dei modelli.

L’app desktop ChatGPT e la CLI Codex condividono un unico file di configurazione, quindi una sola modifica vale per entrambe. Dei due provider integrati di Amazon Bedrock, solo amazon-bedrock-runtime accetta un profilo di inferenza; la firma SigV4 implica che non c’è alcuna chiave API da ruotare. Codex indica per questi profili una finestra di contesto di 272.000 token, che, secondo AWS, è un valore incluso da Codex e non un limite del servizio; è possibile aumentarla con l’impostazione model_context_window . È necessaria la versione 0.148 o successiva della CLI Codex.

Autorizzazioni, quote e monitoraggio

Per richiamare uno qualsiasi dei tre modelli tramite un profilo globale sono necessarie quattro istruzioni di policy IAM: accesso al profilo di inferenza e alla risorsa project/default nella regione di origine; accesso al modello di fondazione nella regione di origine, limitato al profilo; l’ARN del modello di fondazione indipendente dalla regione, con aws:RequestedRegion impostato su unspecified per consentire l’instradamento tra regioni; e bedrock:CallWithBearerToken per l’autenticazione tramite chiave API. Le chiamate in streaming aggiungono bedrock:InvokeModelWithResponseStream alle prime tre istruzioni.

Una richiesta globale tra regioni non contiene il nome di una regione, quindi Amazon Bedrock imposta aws:RequestedRegion su unspecified e una policy di controllo dei servizi con un elenco di regioni consentite nega la chiamata, restituendo un errore che indica solo il tipo di policy. L’articolo individua in questo comportamento un motivo comune per cui la prima chiamata non riesce in un account aziendale. Invece di ampliare l’elenco delle regioni consentite, AWS consiglia di circoscrivere l’eccezione con la bedrock:InferenceProfileArn chiave di condizione, che Amazon Bedrock valorizza durante l’autorizzazione; aggiungere unspecified all’elenco delle regioni consentite funziona, ma estende la stessa eccezione a tutti gli altri servizi.

Per il rilevamento automatico degli abusi offline, il traffico segnalato dal classificatore viene conservato da AWS per un massimo di 30 giorni ed elaborato automaticamente. Con l’inferenza tra Regioni, la conservazione avviene nella Regione di destinazione, che, per un profilo globale, è una qualsiasi Regione commerciale supportata in cui il modello è distribuito. I clienti idonei possono richiedere la conservazione zero completa dei dati tramite il proprio team account AWS; l’articolo consiglia alle organizzazioni soggette a requisiti di residenza dei dati di coinvolgere tempestivamente i team dedicati a rischio e conformità.

Quote di GPT-6 su bedrock-runtime sono misurate in token al minuto rispetto alla Regione di origine. I token di input e quelli usati per scrivere nella cache vengono conteggiati uno a uno, mentre ogni token di output consuma 10 token di quota; nell’esempio dell’articolo, una richiesta con 2.000 token di input e 1.000 token di output esaurisce 12.000 token. Amazon Bedrock riserva l’intero max_tokens valore in anticipo e una sola quota copre InvokeModel, Converse, Responses e Chat Completions. AWS consiglia di richiedere aumenti prima della messa in produzione e di impostare allarmi su EstimatedTPMQuotaUsage nello spazio dei nomi AWS/Bedrock, al 70–80 per cento dell’allocazione.

Le metriche di CloudWatch, gli eventi di CloudTrail, i log delle invocazioni dei modelli, il calcolo delle quote e la fatturazione restano tutti nella Regione di origine; i clienti pagano le tariffe di quest’ultima, non quelle della Regione di elaborazione. AWS indica che le destinazioni di un profilo globale sono le sue Regioni commerciali, senza elencarle, e l’ GetInferenceProfile API restituisce gli ARN del modello indipendenti dalla Regione e specifici della Regione di origine, anziché un elenco delle destinazioni. Il record di elaborazione per ogni richiesta è additionalEventData.inferenceRegion in CloudTrail nella Regione di origine.

L’inferenza su questo endpoint è un evento di gestione, registrato per impostazione predefinita senza costi aggiuntivi; la cronologia degli eventi di CloudTrail conserva i dati per 90 giorni, quindi per periodi più lunghi è necessario un trail o la registrazione delle invocazioni dei modelli. Quando gli sviluppatori accedono a GPT-6 tramite un agente di programmazione, CloudWatch Coding Agent Insights mette a disposizione dashboard già pronte in GenAI Observability, che ripartiscono l’utilizzo dei token per utente, team e centro di costo; gli agenti generano metriche OpenTelemetry in modo nativo.