KI-Modelle und Plattformen
AWS eröffnet Zugriff auf GPT‑5.6 über Amazon Bedrock aus australischen Regionen
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Amazon Web Services teilte am 2. September 2026 mit, dass Teams in Australien nun auf die GPT‑5.6‑Modelle von OpenAI über Amazon Bedrock zugreifen können, indem sie die Varianten Sol, Terra und Luna aus den Regionen Asien‑Pazifik (Sydney) und Asien‑Pazifik (Melbourne) über globale regionenübergreifende Inferenz aufrufen.
Im Rahmen dieser Regelung ruft eine Anwendung den Amazon Bedrock Runtime-Endpunkt in Sydney oder Melbourne auf, und Bedrock leitet die Anfrage zur Verarbeitung an eine unterstützte kommerzielle AWS‑Region weiter. AWS erklärte, dass dies australischen Kunden Zugang zu einem größeren Kapazitätspool verschafft, ohne dass Anwendungen das Routing zur Zielregion verwalten müssen. Drei globale Inferenzprofile decken die Modelle ab: global.openai.gpt-5.6-sol, global.openai.gpt-5.6-terra und global.openai.gpt-5.6-luna. Sydney verwendet den Regionscode ap-southeast-2 und Melbourne ap-southeast-4.
Die drei GPT‑5.6‑Varianten
AWS beschrieb die drei Varianten als für unterschiedliche Arbeitslastprofile ausgelegt. Laut dem AWS Machine Learning Blog‑Beitrag ist GPT‑5.6 Sol für anspruchsvolle Reasoning‑, Coding‑ und agentenbasierte Workloads geeignet; Terra bietet ein ausgewogenes Verhältnis von Leistung und Kosten für den täglichen Produktionseinsatz; und Luna liefert schnelle, kostengünstige Inferenz für Anwendungen mit hohem Volumen und latenzsensiblen Anforderungen. Alle drei akzeptieren Text‑ und Bild‑Eingaben, erzeugen Text und unterstützen Kontextfenster von bis zu 1 Million Token.
Aus den beiden australischen Regionen können Entwickler die Modelle über drei Zugriffswege auf dem Bedrock Runtime‑Endpunkt aufrufen: die OpenAI Responses‑API, die OpenAI Chat Completions‑API und die Amazon Bedrock Converse‑API. Die OpenAI‑kompatiblen APIs werden über die Pfade /openai/v1 des Endpunkts aufgerufen, nicht über AWS‑SDKs, und der Endpunkt akzeptiert entweder eine AWS‑Signature‑Version‑4‑Signatur oder einen Amazon Bedrock‑Modell‑Inferenz‑API‑Schlüssel.
Prompt‑Caching ist für GPT‑5.6 über die unterstützten APIs in zwei Modi verfügbar. Implizites Caching ist standardmäßig aktiviert und erfordert keine Code‑Änderungen, während explizites Caching Entwicklern erlaubt, das wiederverwendbare Präfix, die Cache‑Grenze und den Cache‑Schlüssel zu definieren. AWS wies darauf hin, dass die Zugehörigkeit zu Profilen und die Verfügbarkeit von Modellen sich ändern können, und verwies Kunden auf die Dokumentation zur regionenübergreifenden Inferenz, um die Konfigurationen vor der Bereitstellung zu prüfen.
Codex‑Integration und OIDC‑Authentifizierung
Der Codex‑Coding‑Agent von OpenAI kann dieselben globalen Inferenzprofile über den im neuesten Codex‑CLI integrierten Bedrock Runtime‑Modellanbieter nutzen. AWS teilte mit, dass die Konfiguration mit codex‑cli 0.149.1, das GPT‑5.6 Sol aus Sydney ausführt, validiert wurde.
Für Organisationen, die Identitäten über Okta, Auth0, Microsoft Entra ID, Amazon Cognito oder AWS IAM Identity Center föderieren, stellt AWS einen Beispiel‑Credential‑Helper bereit, der ein OpenID‑Connect‑Token gegen temporäre AWS‑Anmeldeinformationen austauscht. Codex liest diese Anmeldeinformationen anschließend über die standardmäßige AWS‑Credential‑Kette aus, und die Anfragen werden mit SigV4 signiert, sodass kein API‑Schlüssel im Inferenzpfad verwendet wird. Wenn das Profil vom IAM Identity Center unterstützt wird, sind die Anmeldeinformationen bereits kurzfristig und rotieren mit der Single‑Sign‑On‑Sitzung.
Voraussetzungen für australische Deployments umfassen ein AWS‑Konto mit Sydney oder Melbourne als Quellregion, eine IAM‑Rolle oder einen Nutzer mit Berechtigungen zum Aufrufen der GPT‑5.6‑Inferenzprofile sowie Python 3.9 oder höher mit den installierten Paketen openai, boto3 und aws‑bedrock‑token‑generator. Organisationen, die Service‑Control‑Policies verwenden, müssen prüfen, dass ihre Richtlinie die GPT‑5.6‑globalen Inferenzprofile in der gewählten Quellregion zulässt. Administratoren können aktive Profile über die AWS‑CLI oder die Inferenzprofil‑Ansicht in der Amazon Bedrock‑Konsole bestätigen.
Kontingente, Überwachung und Protokollierung
Die On‑Demand‑Kontingente für GPT‑5.6 werden in Anfragen pro Minute und Token pro Minute gemessen, wobei der Token‑Verbrauch pro Anfrage das Kontingent bestimmt. Für GPT‑5.6 werden Eingabe‑Token und Cache‑Write‑Eingabe‑Token im Verhältnis 1:1 gezählt, während jedes Ausgabe‑Token 10 Token des Kontingents verbraucht, so AWS. Kontingente werden über die Service‑Quotas‑Konsole in der Quellregion, die die Anwendung nutzt, überprüft und erhöht, und AWS riet Kunden, frühzeitig Erhöhungen zu beantragen, die Auslastung zu überwachen und repräsentative Prompts, Streaming‑Verhalten, Parallelität und Spitzenverkehr vor dem Produktions‑Rollout zu testen.
Da GPT‑5.6‑Anfragen die Bedrock Runtime‑API nutzen, erscheinen Aufrufe über die globalen Inferenzprofile im Modell‑Aufruf‑Logging wie andere On‑Demand‑Anfragen, wobei die Datensätze die Inferenz‑Profil‑ID und Aufruf‑Metadaten enthalten. Codex exportiert Metriken über das OpenTelemetry‑Protokoll, und CloudWatch Coding Agent Insights stellt ein Dashboard für diese Telemetrie bereit, das Token‑Verbrauch, API‑Anfragen, aktive Nutzer, Konversations‑Aktivität und Cache‑Treffer‑Rate abdeckt.
AWS bietet zwei Konfigurationspfade für das Dashboard an: einen Bearer‑Token‑Ansatz mit einem CloudWatch‑Metrics‑API‑Schlüssel und einen Enterprise‑Rollout, bei dem ein lokaler Collector den Export mit SigV4 unter Verwendung der föderierten Anmeldeinformationen des Entwicklers signiert. AWS klassifiziert den Metrics‑API‑Schlüssel als langfristige Anmeldeinformation und empfiehlt ihn nur dort, wo kurzfristige Anmeldeinformationen nicht realisierbar sind. Der Enterprise‑Pfad sei die empfohlene Option für Organisationen, die die Entwickleridentität über ein corporate Single‑Sign‑On föderieren, sagte AWS.
