翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
リクエストごとのメタデータのタグ付け
リクエストメタデータを使用すると、bedrock-runtimeエンドポイントの個々の Amazon Bedrock 推論呼び出しにキーと値のタグをアタッチできます。タグは、モデル呼び出しログに リクエストとともに記録されます。その後、使用状況をチーム、アプリケーション、環境、実験、または呼び出しごとに異なるその他のディメンションに属性付けできます。事前に作成または設定するリソースはありません。各呼び出しには異なるタグセットを含めることができます。
リクエストメタデータは、次の bedrock-runtime APIs。
注記
リクエストメタデータはbedrock-mantleエンドポイントではサポートされていません。コスト配分タグとして AWS Cost Explorer「」、プロジェクト「」、またはアプリケーション推論プロファイル「」を参照してくださいWorkSpaces。 AWS
リクエストメタデータの仕組み
リクエストにメタデータをアタッチする方法は、呼び出す API によって異なります。
-
InvokeModel と InvokeModelWithResponseStream – リクエストに
X-Amzn-Bedrock-Request-MetadataHTTP ヘッダーを設定します。値は、キーと値が選択した文字列である JSON オブジェクトです。 -
Converse and ConverseStream – リクエスト本文の
requestMetadataフィールドを設定します。詳細については、「requestMetadata」を参照してください。
リクエストメタデータは、呼び出し AWS リージョン が行われた でログ記録が有効になっている場合にのみ、モデル呼び出しログに記録されます。セットアップ手順については、「」を参照してくださいCloudWatch Logs と Amazon S3 を使用してモデル呼び出しをモニタリングする。
次の例は、呼び出しにチーム名、環境、テストケース識別子をタグ付けする InvokeModel リクエストを示しています。
POST /model/anthropic.claude-3-haiku-20240307-v1:0/invoke HTTP/1.1 Content-Type: application/json X-Amzn-Bedrock-Request-Metadata: {"team": "orchestrator", "environment": "preview-test", "test_case": "invoke_model_sync"} { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 50, "messages": [{"role": "user", "content": "Say hello in one word."}] }
InvokeModelWithResponseStream でも同じヘッダーがサポートされています。
POST /model/anthropic.claude-3-haiku-20240307-v1:0/invoke-with-response-stream HTTP/1.1 Content-Type: application/json X-Amzn-Bedrock-Request-Metadata: {"team": "orchestrator", "environment": "preview-test", "test_case": "invoke_model_stream"} { "anthropic_version": "bedrock-2023-05-31", "max_tokens": 50, "messages": [{"role": "user", "content": "Say hello in one word."}] }
重要
AWS 署名バージョン 4 (SigV4) でリクエストに署名するときは、SignedHeadersリストX-Amzn-Bedrock-Request-Metadataに を含めます。署名付きリストから ヘッダーを省略するリクエストは、リクエストメタデータをパラメータとして公開する InvalidSignatureException. AWS SDKs によって自動的に拒否されます。
次の例では、Converse 呼び出しで AWS SDK for Python (Boto3) を使用してリクエストメタデータを設定します。SDK には、SigV4-signed付きヘッダーにメタデータが含まれています。
import boto3 client = boto3.client("bedrock-runtime") response = client.converse( modelId="us.anthropic.claude-opus-4-8", # or an inference profile ARN messages=[{"role": "user", "content": [{"text": "Summarize this ticket."}]}], requestMetadata={ "user": "alice@example.com", "team": "growth", "feature": "summarizer", "environment": "prod", }, )
制限
リクエストメタデータには以下の制限があり、X-Amzn-Bedrock-Request-Metadataヘッダー (InvokeModel、InvokeModelWithResponseStream) とrequestMetadata本文フィールド (Converse、ConverseStream) の両方に適用されます。
リクエストあたり最大 16 個のメタデータエントリ。
キー: 最大 256 文字。
値: 最大 256 文字。
使用できる文字: 英数字と句読点文字の制限されたセット。
これらの制限を超えるリクエストは、検証エラーで拒否されます。
リクエストメタデータが表示される場所
リクエストメタデータは、最上位requestMetadataフィールドの Amazon Bedrock モデル呼び出しログに表示されます。次の省略ログエントリは、InvokeModel 呼び出しの フィールドを示しています。
{ "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "2024-01-15T12:00:00Z", "accountId": "123456789012", "region": "us-east-1", "requestId": "abcd1234-5678-efgh-ijkl-mnopqrstuvwx", "operation": "InvokeModel", "modelId": "anthropic.claude-3-haiku-20240307-v1:0", "requestMetadata": { "team": "orchestrator", "environment": "preview-test", "test_case": "invoke_model_sync" }, "input": { "...": "..." }, "output": { "...": "..." } }
Amazon CloudWatch Logs Insights、Amazon Athena などの Amazon S3 クエリツール、または呼び出しログを読み取るその他のシステム内のメタデータフィールドでログをフィルタリングおよび集計できます。
ログからのコストの取得
リクエストメタデータとトークン数は、請求書ではなくモデル呼び出しログに書き込まれます。これらをコストに変換する方法は 2 つあります。
- トークン数からのコンピューティング
-
各ログレコードには、リクエストの入力トークン数、出力トークン数、キャッシュ読み取りトークン数、キャッシュ書き込みトークン数が含まれます。これらを Amazon Bedrock の料金
のトークンごとのレートで乗算し、任意のメタデータタグでグループ化します。このアプローチはプロンプトごとにほぼリアルタイムで行われますが、見積もりです。レートカードは維持します。モデル化しない限り、割引、コミットメント、バッチ料金、無料利用枠、プロビジョニングされたスループットは反映されません。 次の CloudWatch Logs Insights クエリは、呼び出しログが CloudWatch Logs に配信されたときに、ユーザーとモデルごとにトークンを合計します。
fields requestMetadata.user as user, modelId, input.inputTokenCount as inTokens, output.outputTokenCount as outTokens | stats sum(inTokens) as totalInput, sum(outTokens) as totalOutput, count() as calls by user, modelId | sort totalInput descAmazon S3 に配信されるログの場合、次の Amazon Athena クエリはチーム別のコストを見積もります。トークンごとの料金を Amazon Bedrock
の現在の料金に置き換え、テーブル定義に合わせて AWS Glue テーブルと列の参照を調整します。 SELECT requestMetadata.team AS team, modelId, SUM(input.inputTokenCount) AS input_tokens, SUM(output.outputTokenCount) AS output_tokens, SUM(input.inputTokenCount) * 0.000015 AS est_input_cost, SUM(output.outputTokenCount) * 0.000075 AS est_output_cost FROM bedrock_invocation_logs GROUP BY requestMetadata.team, modelId ORDER BY est_input_cost DESC; - CUR と照合する
-
請求書の正確な合計について、呼び出しログを AWS コストと使用状況レポートに結合します。クラシック CUR も CUR 2.0 も、その明細項目にリクエストごとの識別子を含めません。1 時間または 1 日の使用タイプ別の総コスト。このパスをモデルと使用状況タイプの調整として扱い、その下にリクエストごとの詳細がログに表示されます。
注記
リクエストメタデータと IAM セッションタグは、異なるメカニズムです。リクエストメタデータは呼び出しごとに設定され、リクエストによって異なります。呼び出しログに記録されます。IAM セッションタグはセッションごとにバインドされ、 AWS Cost Explorer と CUR の集計請求データとしてのみ表示されます。ユーザーごと、プロンプトごとの属性については、セッションタグではなく、ARN でリクエストメタデータまたはユーザーごとの ID を使用します。
考慮事項
-
リクエストメタデータ値は、呼び出しの でモデル呼び出しログ記録が有効になっている場合にのみ記録されます AWS リージョン。ログ記録が設定されていない場合、リクエストは成功しますが、メタデータは保持されません。
-
リクエストメタデータは AWS コスト配分タグとして配信されず、 AWS Cost Explorer または CUR に表示されません。メタデータディメンション別にコストを分析するには、呼び出しログを のコストと使用状況レポートに結合します
requestId。または、ログレコードから直接トークン数を集計し、Amazon Bedrock 料金のトークンごとのレートを掛けます。Cost Explorer と CUR にネイティブに流れる属性については、アプリケーション推論プロファイル、プロジェクト、または を使用しますWorkSpaces。 -
集計しやすい分析
experimentには、team、、environmentfeature、 などの安定した低カーディナリティキーを選択します。個々の呼び出しをトレースする必要がある場合にのみ、セッション識別子やトレース識別子などのより高いカーディナリティ値を使用します。 -
個人を特定できる情報 (PII)、認証情報、またはその他の機密データをリクエストメタデータに配置しないでください。値は、モデル呼び出しログと、それらのログを読み取るすべてのシステムに保存されます。
-
リクエストメタデータは呼び出しごとに提供され、Amazon Bedrock によって強制されません。省略したリクエストは引き続き成功し、要求するサービス側のポリシーはありません。組織全体のカバレッジを保証するには、共有クライアントまたは LLM ゲートウェイにリクエストメタデータを設定します。コールごとのコードなしで常に存在する属性の場合は、 を使用しますIAM プリンシパル属性。発信者 ID を自動的にキャプチャします。
-
リクエストメタデータは、他の Amazon Bedrock 使用状況追跡方法と連動します。ID ごとの属性IAM プリンシパル属性に を使用し、同じワークロードのリソースレベルのコスト配分タグアプリケーション推論プロファイルに を使用できます。