[Amazon Bedrock] クロスリージョン推論が東京リージョンを含むアジアパシフィック地域で利用可能になりました
みなさん、こんにちは!
福岡オフィスの青柳です。
今年8月にリリースされたAmazon Bedrockの「クロスリージョン推論」機能が、東京リージョンを含むアジアパシフィック地域でも利用可能になりました。
クロスリージョン推論とは?
あるリージョンでAmazon BedrockのAPIを利用している時、リージョンに設定されたスループットのクォータを超えたAPIリクエストが発生した際、予め設定された近隣リージョンのBedrock APIエンドポイントへ自動的にルーティングすることによってスロットリングを回避してくれる機能です。
大規模アクセスを必要とする生成AIアプリケーション・生成AIサービスを導入する際に、特に有用な機能です。
クロスリージョン推論の詳細は下記ブログ記事を参照してください:
アジアパシフィック地域で利用可能に
これまでは、クロスリージョン推論は「アメリカ地域 (US)」「ヨーロッパ地域 (EU)」でのみ利用可能でした。
- アメリカ地域 (US) でサポートされるリージョン
- us-east-1 (北部バージニア)
- us-east-2 (オハイオ)
- us-west-2 (オレゴン)
- ヨーロッパ地域 (EU) でサポートされるリージョン
- eu-central-1 (フランクフルト)
- eu-west-1 (アイルランド)
- eu-west-3 (パリ)
今回、これらに加えて「アジアパシフィック地域 (APAC)」でクロスリージョン推論が利用可能になりました。
- アジアパシフィック地域 (APAC) でサポートされるリージョン
- ap-northeast-1 (東京)
- ap-northeast-2 (ソウル)
- ap-southeast-1 (シンガポール)
- ap-southeast-2 (シドニー)
- ap-south-1 (ムンバイ)
現時点で、アジアパシフィック地域のクロスリージョン推論でサポートされる基礎モデル (FM) は以下の通りです。
- Claude 3 Haiku
- Claude 3 Sonnet
- Claude 3.5 Sonnet
使ってみる
それでは、実際にクロスリージョン推論を東京リージョンで使ってみます。
前提として、API呼び出し元リージョン (=東京) の「モデルアクセス」で、対象の基礎モデルを有効化しておきます。
今回は「Claude 3.5 Sonnet」を使用することにします。(※先日オレゴンリージョンで「Claude 3.5 Sonnet v2」がリリースされましたが、こちらはv1の方です)
なお、ルーティング先となる可能性があるリージョン (=ソウル、シンガポール、シドニー、ムンバイ) については、モデルの有効化は不要です。
クロスリージョン推論を使わない場合
まずは、クロスリージョン推論を使わない通常のAPI呼び出しを行なってみます。
以下のようにコードを記述します。
(コードはこちらのブログを参考にしました)
import boto3
region_name = "ap-northeast-1"
bedrock_runtime = boto3.client("bedrock-runtime", region_name=region_name)
system_prompt = "あなたは AWS サービスの専門家であり、常に正確で簡潔な回答を提供します。"
input_message = "S3、EBS、EFS の違いを教えてください。日本語で回答してください。"
modelId = "anthropic.claude-3-5-sonnet-20240620-v1:0"
response = bedrock_runtime.converse(
modelId=modelId,
system=[{"text": system_prompt}],
messages=[{
"role": "user",
"content": [{"text": input_message}]
}]
)
print(response["output"]["message"]["content"][0]["text"])
以下の行で指定しているのは、使用する基礎モデルを表す「モデルID」です。
modelId = "anthropic.claude-3-5-sonnet-20240620-v1:0"
モデルIDは、Bedrockコンソールの「基礎モデル」から対象モデルを選択すると確認できます。
このコードを実行すると、実行結果として、生成されたテキストが以下のように返ってきました。
S3、EBS、EFSはAWSのストレージサービスですが、それぞれ異なる特徴と用途があります:
1. S3 (Simple Storage Service):
- オブジェクトストレージ
- 無制限のスケーラビリティ
- HTTPSを介してアクセス可能
- データの長期保存やバックアップに適している
- 静的ウェブサイトホスティングが可能
2. EBS (Elastic Block Store):
(以下略)
クロスリージョン推論を使った場合
クロスリージョン推論を使う場合は、「モデルID」の指定を、クロスリージョン推論に対応した「推論プロファイルID」に置き換える必要があります。
推論プロファイルIDは、Bedrockコンソールで「Cross-region inference」を選択すると確認できます。
各基礎モデルに対応する推論プロファイルIDが「Inference profile ID」欄に記載されています。
(なお、「Region」欄にはクロスリージョン推論でルーティング対象となるリージョンのリストが記載されています)
コードの「モデルID」を指定している行を、確認した推論プロファイルIDで置き換えます。
@@ -5,7 +5,7 @@
-modelId = "anthropic.claude-3-5-sonnet-20240620-v1:0"
+modelId = "apac.anthropic.claude-3-5-sonnet-20240620-v1:0"
コードを書き換えた後、実行すると、今度も正常に生成されたテキストが返ってきました。
S3、EBS、EFSはすべてAWSのストレージサービスですが、それぞれ異なる用途と特徴があります。
(以下略)
クロスリージョン推論を使うと「スループットのクォータを超えたAPIリクエストが発生した際、別のリージョンのBedrock APIエンドポイントへ自動的にルーティングされる」ということですが、実際にどのリージョンのAPIが呼び出されたのかを確認してみましょう。
これを確認するためには、予め、Bedrockの「モデル呼び出しのログ記録」を有効化しておく必要があります。
ログ記録を有効化した状態で、もう一度「クロスリージョン推論」を使ったAPI呼び出しを行いました。
ログを確認すると以下のようになっていました。
{
"schemaType": "ModelInvocationLog",
"schemaVersion": "1.0",
"timestamp": "2024-11-05T03:33:48Z",
"accountId": "123456789012",
"identity": {
"arn": "arn:aws:sts::123456789012:assumed-role/user_name/0000000000000000000"
},
"region": "ap-northeast-1",
"requestId": "4e33a8ad-a436-4da9-85c7-d9f90a78f7a9",
"operation": "Converse",
"modelId": "apac.anthropic.claude-3-5-sonnet-20240620-v1:0",
"input": {
...
},
"output": {
...
},
"inferenceRegion": "ap-northeast-1"
}
「inferenceRegion」の値を確認すると、東京リージョンのAPIが呼び出されたようですね。
今回は、呼び出し元と同じリージョンのAPIが呼び出されましたが、大量リクエストを行った際などは他のリージョンのAPIが呼び出される場合もあるかと思います。
東京リージョンでネイティブに対応していないモデルを呼び出す
クロスリージョン推論を使うと、あるリージョンでネイティブに対応していないモデルを、別のリージョンへのルーティングによって利用することができます。
東京リージョンの「モデルアクセス」を見ると、「Claude 3 Sonnet」の横に「Cross-region inference」の表記があることが分かります。
これは、「東京リージョンではClaude 3 Sonnetをローカルリージョン内で利用することはできないが、クロスリージョン推論を使うことで他のリージョンへのルーティングによって利用することはできる」ということを意味します。
まず、コードの「モデルID」を指定する部分を、以下のように記述します。
modelId = "anthropic.claude-3-sonnet-20240229-v1:0"
このコードを実行すると、以下のようにエラーとなります。
botocore.errorfactory.ValidationException: An error occurred (ValidationException) when calling the Converse operation: Invocation of model ID anthropic.claude-3-sonnet-20240229-v1:0 with on-demand throughput isn’t supported. Retry your request with the ID or ARN of an inference profile that contains this model.
「(現在のリージョンで) 指定されたモデルIDはサポートされていない」というエラーです。
次に、コードの「モデルID」の指定を、以下のように「推論プロファイルID」に書き換えます。
modelId = "apac.anthropic.claude-3-sonnet-20240229-v1:0"
今度は、正常に生成されたテキストが返ってきました。
S3、EBS、EFSは、AWSが提供するストレージサービスです。それぞれの違いは以下の通りです。
(以下略)
モデル呼び出しログを確認してみましょう。
{
"schemaType": "ModelInvocationLog",
"schemaVersion": "1.0",
"timestamp": "2024-11-05T05:28:00Z",
"accountId": "123456789012",
"identity": {
"arn": "arn:aws:sts::123456789012:assumed-role/user_name/0000000000000000000"
},
"region": "ap-northeast-1",
"requestId": "26b68f64-1972-43a6-9e62-0a2dba11eb4e",
"operation": "Converse",
"modelId": "apac.anthropic.claude-3-sonnet-20240229-v1:0",
"input": {
...
},
"output": {
...
},
"inferenceRegion": "ap-southeast-2"
}
「inferenceRegion」の値が「ap-southeast-2」となっていて、シドニーリージョンのAPIが呼び出されたことが分かります。
このように、東京リージョンでネイティブに対応していないモデルを、クロスリージョン推論を使って別リージョンのAPI呼び出しで利用できる訳です。
リージョン毎のモデルのサポート状況
アジアパシフィック地域の各リージョンで、クロスリージョン推論がサポートしている各モデルが「ネイティブ呼び出し」「クロスリージョン推論による呼び出し」をどのようにサポートしているのかをまとめました。
リージョン | Claude 3 Haiku | Claude 3 Sonnet | Claude 3.5 Sonnet |
---|---|---|---|
東京リージョン | ◎ | ◯ | ◎ |
ソウルリージョン | ◎ | ◯ | ◎ |
シンガポールリージョン | × | ◯ | × |
シドニーリージョン | ◎ | ◎ | ◯ |
ムンバイリージョン | ◎ | ◎ | ◯ |
◎ … ローカルリージョンでの呼び出し、クロスリージョン推論を使った呼び出し、共にサポート
◯ … クロスリージョン推論を使った呼び出しのみサポート
× … 未サポート
※ シンガポールリージョンは現在モデルアクセスが一部制限されているため、利用できないモデルがあるものと想定します。
FAQ
Q. 企業のセキュリティポリシーで、AWSのサービスは東京リージョン以外のリージョンを使ってはいけないことになっています。東京リージョンのBedrockが「クロスリージョン推論」に対応したことで、東京以外のリージョンで実行される可能性があるということなのでしょうか?
A. クロスリージョン推論が行われるのは、モデルの呼び出し時に「推論プロファイルID」を指定した場合のみです。これまで通り「モデルID」を指定している場合は呼び出し元のリージョン内でAPIが呼び出されます。
おわりに
クロスリージョン推論を使うことによって、以下のようなメリットがあるかと思います。
- スループットのクォータを超えるような大規模アクセスを必要とする生成AIアプリケーションを構築する際に、他のリージョンへの自動的なルーティングによってスロットリングを回避できる。
- アプリケーションを実行するリージョンで特定のモデルがネイティブで利用できない場合、クロスリージョン推論に対応していれば、呼び出し元のリージョンを切り替えることなくモデルの利用が行える。
本来の目的は前者であるのですが、副次的な効果として後者のメリットも享受できる場面があるかもしれません。
今後、対応するモデルが増えることで、より利用しやすくなることが期待されます。