OpenAI GPT-6 Sol, Luna et Astra sont disponibles dans Bedrock depuis cinq régions d'Asie

Amazon Web Services explique comment exécuter trois modèles de la famille OpenAI GPT-6 (Sol, Luna et Astra) dans Amazon Bedrock depuis cinq localisations asiatiques : Singapour, Jakarta, la Thaïlande, la Malaisie et Taipei. Le mécanisme s'appelle global cross-Region inference. L'application interroge Bedrock dans sa propre région, mais l'inférence s'exécute là où AWS dispose de capacité libre. Pour les entreprises qui manquent de capacités locales pour ces modèles, c'est le chemin le plus court vers GPT-6 sans déplacer leur infrastructure.

Comment ça fonctionne

Le développeur n'appelle pas un modèle précis dans une région précise, mais un profil d'inférence global. Bedrock répartit lui-même la requête entre les régions AWS disponibles. Pour le client, le point d'entrée reste la région d'origine, par exemple Singapour. Les logs, les métriques et les quotas y restent aussi. Ce schéma aide à absorber les pics de charge : on butte moins souvent sur le plafond d'une seule région.

AWS décrit deux modes d'accès :

• l'API Converse, l'interface unifiée de Bedrock pour différents modèles. Elle convient si la pile technique comprend déjà d'autres modèles sur cette plateforme ;
• l'API compatible OpenAI. Elle permet de reprendre presque sans modification le code écrit pour le SDK OpenAI : seuls l'endpoint et le mode d'authentification changent.

La seconde option est plus intéressante pour les équipes qui travaillent depuis longtemps directement avec OpenAI et veulent basculer la facturation, l'audit et le contrôle d'accès vers AWS.

Droits, quotas et supervision

Les principaux pièges se trouvent ici non pas dans le code, mais dans les politiques d'accès. Le guide examine séparément les autorisations IAM et SCP, c'est-à-dire les politiques au niveau de l'organisation. Le profil global envoie du trafic en dehors de la région d'origine. Si les SCP de l'organisation limitent strictement la liste des régions autorisées, l'appel peut échouer avec une erreur d'accès, alors que le rôle est correctement attribué. Ces restrictions doivent être vérifiées avant le lancement. Pour les secteurs régulés, c'est aussi une question de conformité : pendant le traitement, les données peuvent se retrouver dans une autre juridiction.

Les quotas obéissent à la même logique. Les limites sont calculées à partir de la région d'origine ; il faut donc dimensionner le quota à l'avance, d'après le profil réel du trafic :

• nombre maximal de requêtes par minute ;
• longueur moyenne du prompt et de la réponse, en tokens ;
• marge pour les nouvelles tentatives après erreur et pour le throttling ;
• rythme de consommation du quota différent pour Sol, Luna et Astra.

Les limites exactes de chaque modèle mentionnées dans la publication sont à recouper avec la documentation Bedrock à jour : elles évoluent.

La supervision est elle aussi rattachée à la région d'origine. Les métriques d'appels, de latence et d'erreurs sont collectées là d'où vient la requête. Il n'est pas nécessaire de chercher séparément les traces d'exécution dans d'autres régions, ce qui simplifie l'exploitation.

Par où commencer en pratique

Mieux vaut commencer par un audit des politiques plutôt que par le code. Vérifiez les SCP et les rôles IAM : l'appel du profil d'inférence global est-il autorisé, et les règles de l'organisation bloquent-elles le trafic hors de la région ? Évaluez ensuite la charge et demandez des quotas avec de la marge. Pour cela, faites passer de vrais prompts par un compte de test et relevez la distribution des tokens.

Il est ensuite raisonnable de répartir les modèles par tâche. Les noms Sol, Luna et Astra laissent supposer des profils différents, mais la publication ne contient aucune donnée permettant de les comparer. Mieux vaut choisir sur la base de ses propres benchmarks : prix par token, latence et qualité sur vos données. Si l'application est déjà écrite pour le SDK OpenAI, le plus simple est de commencer par l'API compatible OpenAI ; pour les plateformes multimodèles, Converse est plus adaptée.

Enfin, décidez à l'avance si le traitement hors de la juridiction d'origine est acceptable pour vos données. Si ce n'est pas le cas, le profil global ne vous convient pas et il faudra étudier les variantes régionales.