Amazon Web Services ブログ

Amazon Bedrock を使用した生成 AI のコストと使用状況の追跡、配分、管理

この記事は、Track, allocate, and manage your generative AI cost and usage with Amazon Bedrock | Amazon Web Services を翻訳したものです。

企業が 生成 AI を積極的に導入するにつれて、付随するコストの管理という課題に直面しています。プロジェクトや複数の事業部門にわたって生成 AI アプリケーションの需要が急増する中、コストの正確な配分と追跡はより複雑になっています。組織は、顧客やユーザーセグメント全体でコストの透明性を維持しながら、ビジネスへの影響度と重要性に基づいて生成 AI への支出に優先順位をつける必要があります。この可視性は、生成 AI サービスの正確な価格設定、費用の部門間精算の実装、使用量ベースの課金モデルの確立に不可欠です。

コストを管理するためのスケーラブルなアプローチがないと、組織は予算外の使用とコストの超過のリスクにさらされます。手動での支出監視と定期的な使用制限の調整は非効率で、人的ミスが発生しやすく、潜在的な過剰支出につながる可能性があります。プロビジョニングされたモデル、カスタムモデル、エージェントとエージェントエイリアス、モデル評価、プロンプト、プロンプトフロー、ナレッジベース、バッチ推論ジョブ、カスタムモデルジョブ、モデルコピージョブなど、さまざまな Amazon Bedrock リソースでタグ付けがサポートされているにもかかわらず、これまではオンデマンドの基盤モデルへのタグ付け機能がありませんでした。この制限により、生成 AI の取り組みのコスト管理がより複雑になっていました。

これらの課題に対処するため、Amazon Bedrock では、組織がオンデマンドモデルにタグを付け、付随コストを監視できる機能が公開されました。組織は、すべての Amazon Bedrock モデルに AWS コスト配分タグを付けることで、コストセンター、事業部門、アプリケーションなどの組織の分類に使用状況を関連付けることができるようになりました。生成 AI の支出を適切に管理するため、組織は AWS Budgets などのサービスを使用して、タグベースの予算とアラームを設定し、使用状況を監視し、異常や事前に定義したしきい値に関するアラートを受け取ることができます。この自動化されたスケーラブルなアプローチにより、非効率な手動プロセスを排除し、過剰支出のリスクを軽減し、重要なアプリケーションを優先的に扱うことができます。生成 AI 関連の支出に対する可視性とコントロールを強化することで、組織は生成 AI への投資を最大限に活用し、イノベーションを促進することができます。

Amazon Bedrock アプリケーション推論プロファイルの紹介

Amazon Bedrock では最近、クロスリージョン推論が導入され、AWS リージョン間で推論リクエストを自動的にルーティングできるようになりました。この機能は、Amazon Bedrock によって事前定義されているクロスリージョン推論プロファイルを使用し、さまざまなリージョンから異なるモデル ARN (Amazon Resource Name) を設定し、単一のモデル識別子 (モデル ID と ARN の両方) の下に統合します。この機能によってモデルの使用における柔軟性は向上しましたが、ワークロードやテナント間でのコストの追跡、管理、制御のためのカスタムタグを付与することはサポートされていません。

この課題を解決するため、Amazon Bedrock は新機能としてアプリケーション推論プロファイルを導入しました。これにより、組織はカスタムのコスト配分タグを適用して、Amazon Bedrock のオンデマンドモデルのコストと使用状況を追跡、管理、制御できるようになります。この機能により、組織は Bedrock の基盤モデルに対してカスタム推論プロファイルを作成し、テナント固有のメタデータを追加できるため、さまざまな AI アプリケーション全体でリソースの割り当てとコストの可視化を効率化できます。

アプリケーション推論プロファイルの作成

アプリケーション推論プロファイルを使用すると、ユーザーは推論リクエストとリソース管理のためのカスタマイズされた設定を定義できます。これらのプロファイルは、次の 2 つの方法で作成できます：

  1. 単一モデル ARN 設定: オンデマンドのベースモデル ARN を 1 つ使用して直接アプリケーション推論プロファイルを作成し、選択したモデルで迅速なセットアップを可能にします。
  2. システム定義の推論プロファイルからのコピー: 既存のシステム定義の推論プロファイルをコピーしてアプリケーション推論プロファイルを作成します。これにより、拡張性と耐障害性を向上させるためのリージョン間推論機能などの設定が継承されます。

アプリケーション推論プロファイルの ARN は以下の形式になります。推論プロファイル ID は、プロファイル作成時に Amazon Bedrock によって生成される一意の 12 桁の英数字文字列です。

arn:aws:bedrock:<region>:<account_id>:application-inference-profile/<inference_profile_id>

クロスリージョン推論プロファイルとアプリケーションの推論プロファイルの比較

クロスリージョン推論プロファイルとアプリケーション推論プロファイルの主な違いは、type 属性と ARN 名前空間内のリソース仕様にあります。

  • クロスリージョン推論プロファイル: これらは SYSTEM_DEFINED の type 属性を持ち、inference-profile リソースタイプを使用します。クロスリージョンおよびマルチモデル機能をサポートするように設計されていますが、AWS によって一元管理されています。 
    {
 …
"inferenceProfileArn": "arn:aws:bedrock:us-east-1:<Account ID>:inference-profile/us-1.anthropic.claude-3-sonnet-20240229-v1:0",
"inferenceProfileId": "us-1.anthropic.claude-3-sonnet-20240229-v1:0",
"inferenceProfileName": "US-1 Anthropic Claude 3 Sonnet",
"status": "ACTIVE",
"type": "SYSTEM_DEFINED",
…
}
  • アプリケーション推論プロファイル: これらのプロファイルは type 属性が APPLICATION で、application-inference-profile リソースタイプを使用します。ユーザー定義のプロファイルで、モデル構成に対する詳細な制御と柔軟性を提供し、AWS Identity and Access Management (IAM) を使用した属性ベースのアクセス制御 (ABAC) によってポリシーをカスタマイズできます。これにより、より正確な IAM ポリシーの作成が可能になり、Amazon Bedrock へのアクセスをより安全かつ効率的に管理できます。 
    {
…
"inferenceProfileArn": "arn:aws:bedrock:us-east-1:<Account ID>:application-inference-profile/<Auto generated ID>",
"inferenceProfileId": <Auto generated ID>,
"inferenceProfileName": <User defined name>,
"status": "ACTIVE",
"type": "APPLICATION"
…
}

これらの違いは、Amazon API Gateway や他の API クライアントと統合する際に重要であり、正確なモデルの呼び出し、リソースの割り当て、ワークロードの優先順位付けを適切に行うために役立ちます。組織はプロファイルの type に基づいてカスタマイズされたポリシーを適用でき、分散 AI ワークロードの制御とセキュリティを強化できます。両方のモデルを次の図に示します。

コスト管理のためのアプリケーションの推論設定の確立

架空のシナリオとして、保険会社が生成 AI を通じて顧客体験を向上させる取り組みを始めたとイメージしてください。この会社は、保険金請求処理の自動化、個人向けの保険商品の推奨、さまざまな地域の顧客に対するリスク評価の改善といった機会を特定しました。しかし、このビジョンを実現するためには、組織は生成 AI ワークロードを効果的に管理するための堅牢なフレームワークを採用する必要があります。

保険会社が、各事業部門に合わせたアプリケーション推論プロファイルを作成することから始まります。AWS コスト配分タグを割り当てることで、組織は Bedrock の支出パターンを効果的に監視・追跡できます。例えば、保険金請求処理チームは、dept: claims、team: automation、app: claims_chatbot などのタグを持つアプリケーション推論プロファイルを作成しました。このタグ付け構造により、コストを分類し、予算に対する使用状況を評価することができます。

ユーザーは Bedrock API または boto3 SDK を使用してアプリケーション推論プロファイルを管理および使用できます。

  • CreateInferenceProfile: 新しい推論プロファイルを開始し、プロファイルのパラメータを設定できるようにします。
  • GetInferenceProfile: 特定の推論プロファイルの詳細を取得し、その設定と現在のステータスを確認できます。
  • ListInferenceProfiles: ユーザーのアカウント内で利用可能なすべての推論プロファイルを一覧表示し、作成されたプロファイルの概要を提供します。
  • TagResource: ユーザーがアプリケーション推論プロファイルを含む特定の Bedrock リソースにタグを付けることができ、リソースの整理やコスト追跡を容易にします。
  • ListTagsForResource: 特定の Bedrock リソースに関連付けられたタグを取得し、リソースがどのように分類されているかを理解するのに役立ちます。
  • UntagResource: リソースから指定されたタグを削除し、リソースの分類管理ができます。
  • Invoke models with application inference profiles:
    • Converse API: 会話型のやり取りのために、指定された推論設定を使用してモデルを呼び出します。
    • ConverseStream API: Converse API と同様ですが、リアルタイムのやり取りのためにストリーミングレスポンスをサポートします。
    • InvokeModel API: 一般的なユースケースのために、指定された推論設定でモデルを呼び出します。
    • InvokeModelWithResponseStream API: モデルを呼び出してレスポンスをストリーミングします。大規模なデータ出力や長時間実行される処理の処理に有用です。

アプリケーション推論プロファイル API は、AWS Management Console からアクセスできないことにご注意ください。

アプリケーション推論プロファイルを使用した Converse API によるモデルの呼び出し

以下の例では、アプリケーション推論プロファイルを作成し、そのプロファイルを使用して Converse API を呼び出し、会話を行う方法を示します。

def create_inference_profile(profile_name, model_arn, tags):
    """Create Inference Profile using base model ARN"""
    response = bedrock.create_inference_profile(
        inferenceProfileName=profile_name,
        description="test",
        modelSource={'copyFrom': model_arn},
        tags=tags 
    )
    print("CreateInferenceProfile Response:", response['ResponseMetadata']['HTTPStatusCode']),
    print(f"{response}\n")
    return response 

# Create Inference Profile 
 print("Testing CreateInferenceProfile...")
 tags = [{'key': 'dept', 'value': 'claims'}] 
 base_model_arn = "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"
 claims_dept_claude_3_sonnet_profile = create_inference_profile("claims_dept_claude_3_sonnet_profile", base_model_arn, tags)

# Extracting the ARN and retrieving Application Inference Profile ID 
 claims_dept_claude_3_sonnet_profile_arn = claims_dept_claude_3_sonnet_profile['inferenceProfileArn'] 

 def converse(model_id, messages):
    """Use the Converse API to engage in a conversation with the specified model"""
    response = bedrock_runtime.converse(
        modelId=model_id,
        messages=messages,
        inferenceConfig={
            'maxTokens': 300,  # Specify max tokens if needed 
        }
    )
    
    status_code = response.get('ResponseMetadata', {}).get('HTTPStatusCode')
    print("Converse Response:", status_code)
    parsed_response = parse_converse_response(response)
    print(parsed_response)
    return response 

# Example of Converse API with Application Inference Profile 
 print("\nTesting Converse...")
 prompt = "\n\nHuman: Tell me about Amazon Bedrock.\n\nAssistant:"
 messages = [{"role": "user", "content": [{"text": prompt}]}] 
 response = converse(claims_dept_claude_3_sonnet_profile_arn, messages)

アプリケーション推論プロファイルを使用したタグ付け、リソース管理、コスト管理

アプリケーション推論プロファイル内のタグ付けにより、組織は特定の生成 AI 関連の取り組みにコストを割り当てることができ、正確な費用の追跡が可能になります。アプリケーション推論プロファイルでは、作成時にコスト配分タグを適用でき、さまざまな AWS リソースへのメタデータの関連付けを可能にする既存の TagResource および UnTagResource API を通じて、追加のタグ付けをサポートしています。project_id、cost_center、model_version、environment などのカスタムタグは、リソースの分類に役立ち、費用の可視性を向上させ、チームが予算に対する支出と利用状況を把握できるようにします。

アプリケーション推論プロファイルとコスト配分タグによるコストと使用状況の可視化

AWS Budgets、AWS Cost Anomaly Detection、AWS Cost Explorer、AWS Cost and Usage Reports (CUR)、Amazon CloudWatch などのツールでコスト配分タグを活用することで、組織は支出傾向を把握し、予算内に収めるために早期にコストの急増を検出して対処することができます。

AWS Budgets を使用すると、組織はタグベースのしきい値を設定し、支出が予算の上限に近づくとアラートを受け取ることができ、AI リソースのコストを管理し、予期せぬ急増に迅速に対応するためのプロアクティブなアプローチを提供します。例えば、営業部門のサポートチームのチャットボットアプリケーションに、dept: sales、team: support、app: chat_app というタグをアプリケーションの推論プロファイルに適用することで、それぞれの予算を設定できます。また、AWS コスト異常検出 はタグ付けされたリソースの異常な支出パターンを監視し、異常なコストを自動的に特定して検知することで、コスト配分タグの運用を容易にします。

以下の AWS Budgets コンソールのスクリーンショットは、予算のしきい値を超過した状態を示しています。

より詳細な分析のために、AWS Cost Explorer と CUR を使用することで、組織はタグ付けされたリソースを日次、週次、月次で分析し、リソースの割り当てとコスト最適化に関する十分な情報に基づいた意思決定を行うことができます。タグのキー/バリューや ARN などのメタデータ属性に基づいてコストと使用状況を可視化することで、組織は支出状況の詳細な内訳を把握することができます。

以下の AWS Cost Explorer コンソールのスクリーンショットは、タグのキーと値でフィルタリングされたコストと使用量のグラフを示しています。

次の AWS Cost Explorer コンソールのスクリーンショットは、Bedrock アプリケーションの推論プロファイル ARN でフィルタリングされたコストと使用量のグラフを示しています。

組織は Amazon CloudWatch を使用して Bedrock アプリケーションのランタイムメトリクスを監視し、パフォーマンスとコスト管理に関する追加のインサイトを得ることもできます。メトリクスはアプリケーションの推論プロファイルごとにグラフ化でき、チームはタグ付けされたリソースのしきい値に基づいてアラームを設定できます。これらのアラームによってトリガーされる通知と自動応答により、コストとリソース使用量をリアルタイムで管理し、予算超過を防ぎ、生成 AI ワークロードのコストを適切に管理することができます。

次の Amazon CloudWatch コンソールのスクリーンショットは、Bedrock アプリケーション推論プロファイル ARN でフィルタリングされた Bedrock ランタイムメトリクスをハイライトしています。

以下の Amazon CloudWatch コンソールのスクリーンショットは、Bedrock アプリケーションの推論プロファイル ARN でフィルタリングされた呼び出し上限のアラームを示しています。

タグ付け、予算設定、異常検出、詳細なコスト分析を組み合わせることで、組織は AI への投資を効果的に管理できます。これらの AWS ツールを活用することで、チームは支出パターンを明確に把握でき、重要なアプリケーションを予算内に収めながら、より適切な意思決定を行い、生成 AI イニシアチブの価値を最大化することができます。

タグに基づくモデル呼び出しのためのアプリケーション推測プロファイル ARN の取得

組織は、Amazon Bedrock API を呼び出す際、モデル推論の呼び出しを含め、生成 AI ゲートウェイや大規模言語モデルのプロキシを使用することがよくあります。アプリケーション推論プロファイルの導入により、組織はオンデマンドの基盤モデルのモデル推論を実行するために、推論プロファイル ARN を取得する必要があります。
適切な推論プロファイル ARN を取得するには、主に 2 つのアプローチがあります。

  • 静的な設定アプローチ： この方法では、AWS Systems Manager Parameter Store または AWS Secrets Manager に、テナント/ワークロードキーと対応するアプリケーション推論プロファイル ARN をマッピングする静的な設定ファイルを保持します。このアプローチは実装が簡単ですが、重大な制限があります。推論プロファイルの数が数十から数百、あるいは数千に拡大するにつれて、この設定ファイルの管理と更新が非常に困難になります。この方法は静的な性質上、変更が発生するたびに手動での更新が必要となり、特に組織がタグに基づいて正しい推論プロファイルを動的に取得する必要がある大規模なデプロイメントでは、不整合や保守作業の増加につながる可能性があります。
  • Resource Groups API を使用した動的な取得： 2 番目のよりロバストなアプローチは、AWS Resource Groups の GetResources API を活用して、リソースとタグフィルターに基づいてアプリケーション推論プロファイル ARN を動的に取得します。この方法では、テナント ID、プロジェクト ID、部門 ID、ワークロード ID、モデル ID、リージョンなど、さまざまなタグキーを使用して柔軟なクエリが可能です。このアプローチの主な利点は、スケーラビリティと動的な性質にあり、現在のタグ設定に基づいてアプリケーション推論プロファイル ARN をリアルタイムで取得できることです。

ただし、考慮すべき点がいくつかあります。GetResources API にはスロットリング制限があるため、キャッシュメカニズムの実装が必要です。組織は、パフォーマンスを最適化し API コールを削減するために、API の出力に基づいて TTL (Time-To-Live) を設定したキャッシュを維持する必要があります。さらに、TTL に基づいてキャッシュが更新される際に、常に最新の推論プロファイル ARN を読み取れるよう、スレッドセーフの実装が重要です。

次の図に示すように、この動的なアプローチでは、クライアントが特定のリソースタイプとタグフィルターを使用して Resource Groups サービスにリクエストを送信します。サービスは対応するアプリケーション推定プロファイル ARN を返し、これは一定期間キャッシュされます。その後、クライアントはこの ARN を使用して、InvokeModel または Converse API を通じて Bedrock モデルを呼び出すことができます。

この動的な取得方法を採用することで、組織はアプリケーション推論プロファイルを管理するためのより柔軟でスケーラブルなシステムを構築できます。これにより、要件の変更やプロファイル数の増加に対してより簡単に対応できるようになります。

前述の図のアーキテクチャは、タグに基づいて推論プロファイルの ARN を動的に取得する 2 つの方法を示しています。それぞれのアプローチの長所と短所を説明します：

  1. TTL 付きキャッシュを維持する Bedrock クライアント: この方法では、クライアントがリソースタイプとタグフィルターに基づいて AWS ResourceGroups サービスの GetResources API を直接クエリします。クライアントは、取得したキーを TTL 付きのクライアント管理キャッシュに保存します。クライアントは、スレッドセーフな方法で GetResources API を呼び出してキャッシュを更新する責任を持ちます。
  2. Lambda ベースの方法: このアプローチでは、呼び出し元のクライアントと ResourceGroups API の間の仲介役として AWS Lambda を使用します。この方法では、インメモリキャッシュを備えた Lambda Extensions コアを使用し、ResourceGroups への API 呼び出し回数を削減する可能性があります。また、設定管理やキャッシュデータの永続的な保存に使用できる Parameter Store とも連携します。

両方のメソッドは、ResourceGroup API のクエリに同様のフィルタリング条件 (リソースタイプフィルターとタグフィルター) を使用し、テナント、モデル、リージョンなどの属性に基づいて推論プロファイルの ARN を正確に取得できます。これらのメソッドの選択は、想定されるリクエスト量、目標とするレイテンシー、コストの考慮事項、追加の処理やセキュリティ対策の必要性などの要因によって決まります。Lambda ベースのアプローチはより柔軟で最適化の可能性が高い一方、直接 API を使用する方法は実装とメンテナンスがより簡単です。

Amazon Bedrock のリソースタグ付け機能の概要

Amazon Bedrock のタグ付け機能は大きく進化し、マルチアカウントの AWS Control Tower 環境全体でリソース管理を行うための包括的なフレームワークを提供するようになりました。この進化により、組織は開発、ステージング、本番環境全体でリソースを管理できるようになり、AI/ML ワークロードのコストの追跡、管理、配分が容易になります。

Amazon Bedrock のリソースタグ付けシステムは、その中核において複数の運用コンポーネントにまたがっています。
組織は、バッチ推論ジョブ、エージェント、カスタムモデルジョブ、ナレッジベース、プロンプト、プロンプトフローに効果的にタグを付けることができます。この基本的なタグ付けの仕組みにより、運用リソースの詳細な制御が可能になり、さまざまなワークロードコンポーネントを正確に追跡・管理できます。Amazon Bedrock のモデル管理の側面では、カスタムモデルとベースモデルの両方を包含する新たな機能層が導入され、プロビジョンドモデルとオンデマンドモデルを区別し、それぞれに固有のタグ付け要件と機能を持たせています。

アプリケーション推論プロファイルの導入により、組織は Bedrock のベースとなる基盤モデルをオンデマンドで管理およびモニタリングできるようになりました。チームはシステム定義の推論プロファイルから派生したアプリケーション推論プロファイルを作成できるため、アプリケーションレベルでより正確なリソーストラッキングとコスト配分を設定できます。この機能は、複数の AI アプリケーションを異なる環境で実行している組織にとって特に価値があります。リソースの使用状況とコストを詳細なレベルで明確に可視化できるからです。

次の図は、マルチアカウント構造を視覚化し、これらのタグ付け機能が異なる AWS アカウント間でどのように実装できるかを示しています。

まとめ

この投稿では、Amazon Bedrock の最新機能であるアプリケーション推論プロファイルを紹介しました。その動作方法を探り、重要な考慮事項について説明しました。この機能のコードサンプルは、この GitHub リポジトリ で入手できます。この新機能により、組織はオンデマンドのモデル推論ワークロードと支出を、業務全体にわたってタグ付け、割り当て、追跡できるようになります。組織は、テナント、ワークロード、コストセンター、事業部門、チーム、アプリケーションなど、特定の組織分類に従って、すべての Amazon Bedrock モデルにタグを付け、使用状況を監視できます。この機能は、Amazon Bedrock が提供されているすべての AWS リージョンで一般提供されています。

翻訳はソリューションアーキテクトの福本が担当しました。

著者について

Kyle T. BlocksomKyle T. Blocksom は、南カリフォルニアを拠点とする AWS のシニアソリューションアーキテクトです。
Kyle の情熱は、人々を結びつけ、テクノロジーを活用してお客様に喜ばれるソリューションを提供することです。
仕事以外では、サーフィン、食事、愛犬とじゃれあう、甥や姪を甘やかすことを楽しんでいます。

Dhawal PatelDhawal Patel は AWS のプリンシパル機械学習アーキテクトです。
大企業から中規模のスタートアップまで、分散コンピューティングや人工知能に関連する問題に取り組んできました。
自然言語処理やコンピュータビジョンなどのディープラーニング分野に注力しており、SageMaker での高性能なモデル推論の実現をお客様を支援しています。