翻訳待ち：Introducing OpenAI models on Amazon Bedrock for in-country inferencing in India

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Amazon Bedrock now supports the OpenAI GPT-5.6 models, Terra and Luna, in India, with India geographic cross-Region inference. If you have local data processing requirements in India, including in financial services, healthcare, and the public sector, you can now use these OpenAI models at scale. Amazon Bedrock processes inference requests and data within India. Both models offer a 1-million-token context window, accept text and image input, and produce text output. Your applications can process long documents, large code bases, and mixed text-and-image workloads in a single request. The processing never leaves the country. In this post, we walk through how India geographic cross-Region inference works from the Mumbai and Hyderabad Regions. We also show how to get started from the Amazon Bedrock console and with code, using the OpenAI Responses API, OpenAI Chat Completions API, and the Amazon Bedrock Converse API. India geographic cross-Region inference Cross-Region inference automatically routes inference requests across multiple AWS Regions to help improve throughput, without you having to manage capacity in each Region yourself. It’s primarily a capacity mechanism. Instead of being bound to one Region’s capacity, your requests draw on a broader pool of compute. That helps you maintain throughput and consistent performance under load, which matters most during traffic peaks. With India geographic cross-Region inference, Amazon Bedrock routes requests only within the India geography across Regions such as Asia Pacific (Mumbai) Region (ap-south-1) and Asia Pacific (Hyderabad) Region (ap-south-2). You can scale to meet demand while keeping data processed within India to meet data residency requirements. You call the profile from either India Region as the source, and Amazon Bedrock routes the request to the destination India Region based on capacity. For the most current information about model availability in each Region, see Regional availability by models in the Amazon Bedrock User Guide. Cross-Region inference works through inference profiles. You call a profile ID as the model, and it defines the model and the AWS Regions Amazon Bedrock can route your request to. The India geographic inference profiles keep that routing within India. There are two profiles: in.openai.gpt-5.6-terra for GPT-5.6 Terra. in.openai.gpt-5.6-luna for GPT-5.6 Luna. With inference profiles, billing and quota consumption are tracked against your account in the source Region, regardless of which backend Region handled the request. Amazon CloudWatch and AWS CloudTrail record log entries in the source Region only, so your monitoring stays in one place. Choosing between Amazon Bedrock Mantle and Runtime endpoints For new applications, we recommend the bedrock-runtime endpoint. It supports the Bedrock-native InvokeModel and Converse APIs, the OpenAI-compatible Responses and Chat Completions APIs, and the Anthropic Messages API, and it is where Amazon Bedrock features such as Guardrails, intelligent prompt routing, and cross-Region inference are available. Data residency The India geographic profile keeps inference within India. Requests route only between ap-south-1 and ap-south-2. Your input prompts and output results might move between those two Regions. Data is encrypted in transit across the Amazon network. Amazon Bedrock uses a zero data retention (ZDR) data security model. This means that by default, Amazon Bedrock does not store model inputs or outputs. However, for certain models, including GPT-5.6, content flagged by the Amazon Bedrock automated abuse-detection classifiers is retained for offline abuse detection. Please see Abuse detection in the Amazon Bedrock User Guide for more details. Global cross-Region inference Amazon Bedrock also offers global cross-Region inference and global inference profiles (prefixed global.) in India that route to supported commercial AWS Regions worldwide for maximum capacity. You send your request to the India Region endpoint, either Asia Pacific (Mumbai) ap-south-1 or Asia Pacific (Hyderabad) ap-south-2, using the global profile ID as the model ID. Amazon Bedrock then decides which destination Region serves the request. Global cross-Region inference supports OpenAI GPT-5.6 models, including Sol, Terra, and Luna. However, if your workload has local data processing requirements, use the India (prefixed in.) profiles instead, because they keep inference within the country. To read more about global cross-Region inference, see Introduce cross-Region inference for OpenAI GPT-5.6 models on Amazon Bedrock. Access GPT-5.6 models from the Amazon Bedrock console You can try GPT-5.6 in the text playground in the Amazon Bedrock console, which requires no coding or SDK setup. You can send prompts, adjust inference parameters, and switch between variants to get a feel for each model before you integrate the API. Open the Amazon Bedrock console in a Region where the models are available, such as Asia Pacific (Mumbai) ap-south-1. In the navigation pane, under Test, choose Playground. Choose Select model in the middle of the page. Search for OpenAI GPT-5.6 Terra, select IN OpenAI GPT-5.6 Terra, and choose Apply. Enter a prompt and choose Run to generate a response. Figure 1: The OpenAI GPT-5.6 Terra model selected in the Amazon Bedrock console playground Call GPT-5.6 models with the OpenAI Responses API GPT-5.6 models on Amazon Bedrock natively support the OpenAI Responses API format. If your application already calls OpenAI models, you can point your existing OpenAI SDK client at the Amazon Bedrock endpoint in either India Region, Mumbai or Hyderabad, and pass an India geographic inference profile ID as the model parameter. For authentication, Amazon Bedrock accepts either standard AWS credentials or an Amazon Bedrock API key. The API key path is the straightforward fit for the OpenAI SDK, which passes it as the bearer token. For production, generate short-term API keys programmatically with the aws-bedrock-token-generator package. It derives a bearer token from your existing AWS credentials, so no static key needs to be stored. The following example uses Asia Pacific (Mumbai) ap-south-1 endpoint and India geographic inference profile ID to call OpenAI GPT-5.6 Terra on Amazon Bedrock. from aws_bedrock_token_generator import provide_token from openai import OpenAI # Point the OpenAI SDK at the Amazon Bedrock OpenAI-compatible # endpoint in the Asia Pacific (Mumbai) Region. client = OpenAI( base_url="https://bedrock-runtime.ap-south-1.amazonaws.com/openai/v1", api_key=provide_token(region="ap-south-1"), # short-term Amazon Bedrock API key, valid up to 12 hours ) # Geographic (India) inference profile ID for GPT-5.6 Terra. model_id = "in.openai.gpt-5.6-terra" # "in.openai.gpt-5.6-luna" for luna response = client.responses.create( model=model_id, input="Extract the payment due date and total amount from the invoice text that follows, and return them as JSON. ", max_output_tokens=512, ) print(response.output_text) The Responses API uses a single input field and returns the generated text in output_text, with the output limit set through max_output_tokens. The same client also works with the Chat Completions API, useful if your application already uses this format. Controlling reasoning depth To control reasoning depth, set the optional reasoning parameter, for example reasoning={"effort": "low"}. GPT-5.6 models on Amazon Bedrock support the following reasoning effort levels: none, low, medium, high, xhigh, and max. For more information, see the related post Get started with OpenAI GPT-5.6 Sol, Terra, and Luna on Amazon Bedrock. Omitting the parameter uses the model default. response = client.responses.create( model="in.openai.gpt-5.6-terra", input="Extract the payment due date and total amount from the invoice text that follows, and return them as JSON. ", reasoning={"effort": "high"}, # none | low | medium | high | xhigh | max max_output_tokens=512, ) For the full list of supported parameters, see the OpenAI model documentation in the Amazon Bedrock User Guide. Multi-turn conversations with server-side state Set store=True to have Amazon Bedrock retain the response server-side, then reference it on the next turn with previous_response_id. You send only the new turn. You don’t resend the prior conversation history. first = client.responses.create( model="in.openai.gpt-5.6-terra", input="Remember this: my favorite number is 42. Reply with just 'stored'..", max_output_tokens=50, store=True, ) second = client.responses.create( model="in.openai.gpt-5.6-terra", previous_response_id=first.id, # the model recalls the earlier turn input="what is my favourite number?", max_output_tokens=50, store=True, ) print(second.output_text) If you chain with previous_response_id, the response you chain from must have been created with store=True. Chaining from an unstored response returns an error. Streaming responses For streaming, set stream=True and iterate over the events: stream = client.responses.create( model="in.openai.gpt-5.6-terra", input="Draft a short status update for a delayed shipment, in a polite and direct tone.", max_output_tokens=512, stream=True, ) for event in stream: if event.type == "response.output_text.delta": print(event.delta, end="") Call GPT-5.6 models with the Converse API If you prefer the AWS SDK and SigV4 authentication over an API key, the Amazon Bedrock Converse API supports GPT-5.6 models with the same unified interface it provides for other models on Amazon Bedrock. ConverseStream covers the streaming case. import boto3 # Standard AWS credentials (SigV4), no API key needed. client = boto3.client("bedrock-runtime", region_name="ap-south-1") model_id = "in.openai.gpt-5.6-terra" # India Geo inference profile response = client.converse( modelId=model_id, messages=[ { "role": "user", "content": [{"text": "Classify this support ticket as billing, technical, or account: "}], } ], inferenceConfig={"maxTokens": 512}, ) print(response["output"]["message"]["content"] Prompt caching Your prompts might share a long, stable prefix, such as a system instruction, a knowledge base excerpt, or a set of few-shot examples. When they do, GPT-5.6 models on Amazon Bedrock support prompt caching. Cached reads are billed at a 90 percent discount compared to uncached input tokens. This adds up quickly for Retrieval Augmented Generation (RAG) and agent workloads that repeat the same context across many turns. You can find details on Amazon Bedrock prompt caching documentation. Prompt caching works with the India geographic inference profiles, so you keep the savings under the India data-residency boundary. Prompt caching runs in two modes, explicit and implicit. With implicit caching, Amazon Bedrock places the cache breakpoints for you automatically. Note that the minimum prefix length is 1,024 tokens. With explicit caching, you mark the cache boundary yourself for precise control, and the cached prefix stays warm for at least 30 minutes. response = client.responses.create( model="in.openai.gpt-5.6-terra", prompt_cache_key="ticket-agent-ver123", # same key across all requests input=[ { "type": "message", "role": "developer", "content": [{ "type": "input_text", "text": SYSTEM_INSTRUCTIONS, # long, static: guidelines, KB excerpts (>= 1,024 tokens) "prompt_cache_breakpoint": {"mode": "explicit"}, }], }, { "type": "message", "role": "user", "content": [{ "type": "input_text", "text": user_question, # changes on every request }], }, ], extra_body={"prompt_cache_options": {"mode": "explicit"}}, ) Every response tells you what the cache did, in usage.input_tokens_details: details = response.usage.input_tokens_details print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}") On the first call, you will see cache_write_tokens populated as the prefix is stored. On subsequent calls, the [truncated for AI cost control]