2021年に、 AWS サポート プロアクティブ サービス の一部として AWSエンタープライズサポート プラン。 導入以来、当社は何百ものお客様のワークロードの最適化、ガードレールの設定、機械学習 (ML) ワークロードのコストと使用状況の可視性の向上を支援してきました。
この一連の投稿では、コストの最適化について学んだ教訓を共有します。 アマゾンセージメーカー。 に 第1部の使用を開始する方法を説明しました。 AWSコストエクスプローラー SageMaker でのコスト最適化の機会を特定します。 この投稿では、SageMaker 推論環境 (リアルタイム推論、バッチ変換、非同期推論、サーバーレス推論) に焦点を当てます。
セージメーカー 複数の推論オプションを提供します ワークロード要件に基づいて選択できます。
- リアルタイム推論 オンライン、低遅延、または高スループット要件向け
- バッチ変換 オフライン、スケジュールされた処理、および永続的なエンドポイントが必要ない場合
- 非同期推論 処理時間が長いペイロードが大きく、リクエストをキューに入れたい場合用
- サーバーレス推論 断続的または予測不可能なトラフィック パターンがあり、コールド スタートを許容できる場合に使用します。
次のセクションでは、各推論オプションについて詳しく説明します。
SageMakerリアルタイム推論
エンドポイントを作成すると、SageMaker は Amazon Elastic Blockストア (Amazon EBS) ストレージボリュームを アマゾン エラスティック コンピューティング クラウド エンドポイントをホストする (Amazon EC2) インスタンス。 これは、SSD ストレージが付属していないすべてのインスタンス タイプに当てはまります。 d* インスタンス タイプには NVMe SSD ストレージが付属しているため、SageMaker はこれらの ML コンピューティング インスタンスに EBS ストレージ ボリュームを接続しません。 参照する ホストインスタンスのストレージボリューム 単一エンドポイントおよびマルチモデルエンドポイントのインスタンスタイプごとに SageMaker が接続するストレージボリュームのサイズ。
SageMaker リアルタイム エンドポイントのコストは、エンドポイントの実行中に各インスタンスで消費されるインスタンスごとの時間、プロビジョニングされたストレージ (EBS ボリューム) の GB 月のコスト、および送受信される GB データに基づいています。で説明したように、エンドポイント インスタンスの Amazon SageMakerの価格。 Cost Explorer では、使用量タイプにフィルターを適用することで、リアルタイムのエンドポイント コストを表示できます。 これらの使用タイプの名前は次のように構成されています。
REGION-Host:instanceType
(例えば、USE1-Host:ml.c5.9xlarge
)REGION-Host:VolumeUsage.gp2
(例えば、USE1-Host:VolumeUsage.gp2
)REGION-Hst:Data-Bytes-Out
(例えば、USE2-Hst:Data-Bytes-In
)REGION-Hst:Data-Bytes-Out
(例えば、USW2-Hst:Data-Bytes-Out)
次のスクリーンショットに示すように、使用タイプによるフィルタリング Host:
アカウント内のリアルタイム ホスティング使用タイプのリストが表示されます。
特定の使用タイプを選択するか、 すべてを選択します。 選択して 申し込む SageMaker リアルタイム ホスティングの使用量のコスト内訳を表示します。 インスタンス時間ごとのコストと使用量の内訳を確認するには、すべての選択を解除する必要があります。 REGION-Host:VolumeUsage.gp2
使用量タイプ フィルタを適用する前に、使用量タイプを確認してください。 アカウント番号、EC2 インスタンス タイプ、コスト割り当てタグ、リージョン、などの追加のフィルターを適用することもできます。 他には?。 次のスクリーンショットは、選択したホスティング使用量タイプのコストと使用量のグラフを示しています。
さらに、 インスタンスタイプ フィルター。 次のスクリーンショットは、ホスティング インスタンス ml.p2.xlarge のコストと使用量の内訳を示しています。
同様に、次のスクリーンショットに示すように、処理された GB データと処理された GB データのコストは、適用されたフィルターとして関連する使用タイプを選択することによって表示できます。
フィルターとグループ化で目的の結果が得られたら、次のいずれかを選択して結果をダウンロードできます。 CSVとしてダウンロード または、選択してレポートを保存します。 レポート ライブラリに保存。 Cost Explorer の使用に関する一般的なガイダンスについては、以下を参照してください。 AWS Cost Explorer の新しい外観と一般的な使用例.
オプションで、有効にすることができます AWS のコストと使用状況レポート (AWS CUR) を使用して、アカウントのコストと使用状況データを把握します。 AWS CUR には、時間ごとの AWS 消費量の詳細が含まれています。 に保存されています Amazon シンプル ストレージ サービス (Amazon S3) 支払者アカウントに保存され、リンクされているすべてのアカウントのデータが統合されます。 クエリを実行して使用量の傾向を分析し、コストを最適化するために適切なアクションを実行できます。 アマゾンアテナ は、標準 SQL を使用して Amazon S3 の AWS CUR からのデータを分析するために使用できるサーバーレス クエリ サービスです。 詳細とクエリの例については、 AWS CUR クエリ ライブラリ.
AWS CUR データをフィードすることもできます。 アマゾンクイックサイト, レポートや視覚化の目的で、任意の方法でスライスしたり、細かくしたりできます。 手順については、を参照してください。 AWS のコストと使用状況レポート (CUR) を Amazon QuickSight に取り込んで視覚化する方法.
AWS CUR から、エンドポイント ARN、エンドポイント インスタンス タイプ、時間当たりのインスタンス料金、毎日の使用時間などのリソースレベルの情報を取得できます。 クエリにコスト割り当てタグを含めて、粒度をさらに高めることもできます。 次のクエリ例は、指定された支払者アカウントの過去 3 か月のリアルタイムのホスティング リソース使用量を返します。
次のスクリーンショットは、Athena を使用してクエリを実行して得られた結果を示しています。 詳細については、以下を参照してください。 Amazon Athena を使用したコストと使用状況レポートのクエリ.
クエリの結果は、そのエンドポイントを示します mme-xgboost-housing
ml.x4.xlarge インスタンスでは、連続した数日間で 24 時間の実行時間が報告されています。 インスタンス料金は 0.24 ドル/時間で、24 時間実行した場合の 5.76 日あたりのコストは XNUMX ドルです。
AWS CUR の結果は、リンクされた各アカウントで連続して実行されるエンドポイントのパターンや、月間コストが最も高いエンドポイントを特定するのに役立ちます。 これは、コストを節約するために非運用アカウントのエンドポイントを削除できるかどうかを判断するのにも役立ちます。
リアルタイムエンドポイントのコストを最適化する
コスト管理の観点からは、使用率が低い (またはサイズが大きすぎる) インスタンスを特定し、必要に応じてインスタンスのサイズと数をワークロード要件に合わせることが重要です。 CPU/GPU 使用率やメモリ使用率などの一般的なシステム メトリックが書き込まれます。 アマゾンクラウドウォッチ すべてのホスティング インスタンスに対して。 リアルタイムエンドポイントの場合、SageMaker は CloudWatch でいくつかの追加メトリクスを利用できるようにします。 一般的に監視されるメトリクスには、呼び出し数や呼び出し 4xx/5xx エラーなどがあります。 メトリクスの完全なリストについては、以下を参照してください。 Amazon CloudWatchでAmazon SageMakerを監視する.
メトリック CPUUtilization
個々の CPU コアの使用率の合計を示します。 各コアの CPU 使用率の範囲は 0 ~ 100 です。 たとえば、CPU が XNUMX つある場合、 CPUUtilization
範囲は 0 ~ 400% です。 メトリクス MemoryUtilization
インスタンス上のコンテナによって使用されるメモリの割合です。 この値の範囲は 0 ~ 100% です。 次のスクリーンショットは、CloudWatch メトリクスの例を示しています CPUUtilization
および MemoryUtilization
4.10 個の vCPU と 40 GiB メモリを備えたエンドポイント インスタンス ml.m160xlarge の場合。
これらのメトリクス グラフは、最大 CPU 使用率が約 3,000% であることを示しています。これは 30 vCPU に相当します。 これは、このエンドポイントが 30 個の vCPU の合計容量のうち 40 個を超える vCPU を使用していないことを意味します。 同様に、メモリ使用率も 6% 未満です。 この情報を使用すると、このリソースのニーズを満たす小規模なインスタンスを実験できる可能性があります。 さらに、 CPUUtilization
メトリクスは、周期的な CPU 需要の高低の古典的なパターンを示しているため、このエンドポイントは自動スケーリングの適切な候補になります。 より小さいインスタンスから開始し、コンピューティング需要の変化に応じて最初にスケールアウトできます。 詳細については、を参照してください。 Amazon SageMakerモデルを自動的にスケーリングする.
SageMaker は、次を使用して新しいモデルを A/B テスト環境に簡単にデプロイできるため、新しいモデルのテストに最適です。 生産バリアント、使用した分だけお支払いいただきます。 各実稼働バリアントは独自のコンピューティング インスタンス上で実行され、バリアントの実行中に各インスタンスで消費されたインスタンス時間ごとに料金が請求されます。
SageMaker もサポート 影の亜種、実稼働バリアントと同じコンポーネントがあり、独自のコンピューティング インスタンスで実行されます。 シャドウ バリアントを使用すると、SageMaker はモデルをテスト環境に自動的にデプロイし、運用モデルが受信した推論リクエストのコピーをリアルタイムでテスト モデルにルーティングし、レイテンシやスループットなどのパフォーマンス メトリクスを収集します。 これにより、モデル サービング スタックの新しい候補コンポーネントを実稼働環境にプロモートする前に検証できます。
テストが完了し、エンドポイントまたはバリアントを広範囲に使用しなくなったら、コストを節約するためにエンドポイントを削除する必要があります。 モデルは Amazon S3 に保存されているため、必要に応じて再作成できます。 これらのエンドポイントを自動的に検出し、次のコマンドを使用して修正アクション (削除など) を実行できます。 Amazon CloudWatchイベント および AWSラムダ 機能。 たとえば、次のように使用できます。 Invocations
メトリクスを使用して、モデル エンドポイントに送信されたリクエストの合計数を取得し、エンドポイントが過去の時間 (24 時間などの特定の期間にわたって呼び出しがなかった) アイドル状態であったかどうかを検出します。
十分に活用されていないエンドポイント インスタンスが複数ある場合は、次のようなホスティング オプションを検討してください。 マルチモデル エンドポイント (MME)、 マルチコンテナ エンドポイント (MCE)、および シリアル推論パイプライン 使用をより少ないエンドポイント インスタンスに統合します。
リアルタイムおよび非同期推論モデルのデプロイメントの場合、次を使用して SageMaker にモデルをデプロイすることでコストとパフォーマンスを最適化できます。 AWS グラビトン。 AWS Graviton は、AWS によって設計されたプロセッサ ファミリであり、最高の価格パフォーマンスを提供し、x86 プロセッサよりもエネルギー効率が優れています。 ML モデルを AWS Graviton ベースのインスタンスにデプロイするためのガイダンスと、価格パフォーマンスの利点の詳細については、以下を参照してください。 Amazon SageMaker を使用して AWS Graviton ベースのインスタンスで機械学習推論ワークロードを実行する。 SageMaker もサポートしています AWSインフェレンティア 加速器を通して ml.inf2 リアルタイムおよび非同期推論用の ML モデルをデプロイするためのインスタンスのファミリー。 SageMaker でこれらのインスタンスを使用すると、大規模言語モデル (LLM) やビジョン トランスフォーマーなどの生成人工知能 (AI) モデルの高性能を低コストで実現できます。
また、 AmazonSageMaker推論レコメンダー 負荷テストを実行し、これらのインスタンスにモデルをデプロイすることによる価格パフォーマンスの利点を評価します。 アイドル状態の SageMaker エンドポイントの自動検出、および SageMaker エンドポイントのインスタンスの適切なサイジングと自動スケーリングに関する追加のガイダンスについては、以下を参照してください。 Amazon SageMaker で効率的なコンピューティング リソースを確保する.
SageMakerバッチ変換
バッチ推論、または オフライン推論、観測のバッチに対して予測を生成するプロセスです。 オフライン予測は、大規模なデータセットや、応答までに数分または数時間待つ余裕がある場合に適しています。
SageMaker バッチ変換のコストは、以下で説明するように、バッチ変換ジョブの実行中に各インスタンスで消費されるインスタンス時間に基づいています。 Amazon SageMakerの価格。 Cost Explorer では、使用量タイプにフィルターを適用することで、バッチ変換コストを調査できます。 この使用タイプの名前は次のように構成されています。 REGION-Tsform:instanceType
(例えば、 USE1-Tsform:ml.c5.9xlarge
).
次のスクリーンショットに示すように、使用タイプによるフィルタリング Tsform:
アカウント内の SageMaker バッチ変換の使用タイプのリストが表示されます。
特定の使用タイプを選択するか、 すべてを選択します。 選択して 申し込む 選択したタイプのバッチ変換インスタンス使用量のコスト内訳を表示します。 前述したように、追加のフィルターを適用することもできます。 次のスクリーンショットは、選択したバッチ変換の使用タイプのコストと使用量のグラフを示しています。
バッチ変換のコストを最適化する
SageMaker バッチ変換では、ジョブの実行中に使用されたインスタンスに対してのみ料金が発生します。 データがすでに Amazon S3 にある場合は、Amazon S3 から入力データを読み取り、Amazon S3 に出力データを書き込むためのコストはかかりません。 すべての出力オブジェクトは Amazon S3 へのアップロードが試行されます。 すべてが成功した場合、バッチ変換ジョブは完了としてマークされます。 XNUMX つ以上のオブジェクトが失敗した場合、バッチ変換ジョブは失敗としてマークされます。
バッチ変換ジョブの料金は、次のシナリオに適用されます。
- 仕事は成功しました
- 原因による失敗
ClientError
モデルコンテナは SageMaker または SageMaker 管理フレームワーク - 原因による失敗
AlgorithmError
orClientError
モデル コンテナは独自のカスタム コンテナです (BYOC)
以下は、SageMaker バッチ変換ジョブを最適化するためのベスト プラクティスの一部です。 これらの推奨事項により、バッチ変換ジョブの合計実行時間が短縮され、コストが削減されます。
- 作成セッションプロセスで バッチ戦略 〜へ
MultiRecord
およびSplitType
〜へLine
入力ファイルからミニバッチを作成するためにバッチ変換ジョブが必要な場合。 データセットをミニ バッチに自動的に分割できない場合は、データ ソース S3 バケットに配置された個別の入力ファイルに各バッチを配置することで、ミニ バッチに分割できます。 - バッチ サイズがメモリに収まるようにしてください。 通常、SageMaker はこれを自動的に処理します。 ただし、バッチを手動で分割する場合は、メモリに基づいて調整する必要があります。
- バッチ変換は、入力内の S3 オブジェクトをキーによって分割し、それらのオブジェクトをインスタンスにマップします。 複数のファイルがある場合、XNUMX つのインスタンスが処理する可能性があります
input1.csv
、別のインスタンスが処理する可能性がありますinput2.csv
。 入力ファイルが XNUMX つあり、複数のコンピューティング インスタンスを初期化する場合、XNUMX つのインスタンスだけが入力ファイルを処理し、残りのインスタンスはアイドル状態になります。 ファイルの数がインスタンスの数以上であることを確認してください。 - 小さなファイルが多数ある場合は、Amazon S3 の対話時間を短縮するために、複数のファイルを少数の大きなファイルに結合すると有益な場合があります。
- あなたが使用している場合 変換ジョブの作成 API では、次のようなパラメーターに最適な値を使用することで、バッチ変換ジョブの完了にかかる時間を短縮できます。 最大ペイロードMB, MaxConcurrentTransformsまたは バッチ戦略:
MaxConcurrentTransforms
変換ジョブ内の各インスタンスに送信できる並列リクエストの最大数を示します。 の理想的な値MaxConcurrentTransforms
インスタンス内の vCPU コアの数と同じです。MaxPayloadInMB
ペイロードの最大許容サイズ (MB 単位) です。 の値MaxPayloadInMB
単一レコードのサイズ以上である必要があります。 レコードのサイズを MB 単位で見積もるには、データセットのサイズをレコード数で割ります。 レコードが最大ペイロード サイズ内に確実に収まるように、わずかに大きい値を使用することをお勧めします。 デフォルト値は 6 MB です。MaxPayloadInMB
100 MB を超えてはなりません。 オプションを指定した場合MaxConcurrentTransforms
パラメータ、次に (MaxConcurrentTransforms
*MaxPayloadInMB
) も 100 MB を超えてはなりません。- ペイロードが任意に大きく、HTTP チャンク エンコーディングを使用して送信される場合は、MaxPayloadInMB 値を 0 に設定します。この機能は、サポートされているアルゴリズムでのみ機能します。 現在、SageMaker 組み込みアルゴリズムは HTTP チャンクエンコーディングをサポートしていません。
- 通常、バッチ推論タスクは水平スケーリングの適切な候補です。 クラスター内の各ワーカーは、他のワーカーと情報を交換することなく、データの異なるサブセットを操作できます。 AWS は、水平スケーリングを可能にする複数のストレージとコンピューティングのオプションを提供します。 単一のインスタンスではパフォーマンス要件を満たすのに十分でない場合は、複数のインスタンスを並行して使用してワークロードを分散することを検討してください。 バッチ変換ジョブを設計する際の主な考慮事項については、以下を参照してください。 Amazon SageMaker による大規模なバッチ推論.
- CloudWatch を使用して、SageMaker バッチ変換ジョブのパフォーマンスメトリクスを継続的に監視します。 CPU や GPU の高い使用率、メモリ使用量、ネットワーク スループットなどのボトルネックを探して、インスタンスのサイズや構成を調整する必要があるかどうかを判断します。
- SageMaker は Amazon S3 を使用します マルチパートアップロードAPI バッチ変換ジョブの結果を Amazon S3 にアップロードします。 エラーが発生した場合、アップロードされた結果は Amazon S3 から削除されます。 ネットワーク障害が発生した場合など、場合によっては、不完全なマルチパート アップロードが Amazon S3 に残ることがあります。 ストレージ料金の発生を避けるために、 S3 バケット ポリシー S3 バケットのライフサイクル ルールに準拠します。 このポリシーは、S3 バケットに保存されている可能性のある不完全なマルチパート アップロードを削除します。 詳細については、を参照してください。 ストレージ ライフサイクルの管理.
SageMaker 非同期推論
非同期推論は、大きなペイロードとバースト トラフィックを伴うコスト重視のワークロードに最適です。 リクエストの処理には最大 1 時間かかり、ペイロード サイズは最大 1 GB であるため、レイテンシ要件が緩和されたワークロードにより適しています。
非同期エンドポイントの呼び出しは、リアルタイム エンドポイントとは異なります。 リクエストペイロードをリクエストと同期的に渡すのではなく、ペイロードを Amazon S3 にアップロードし、リクエストの一部として S3 URI を渡します。 SageMaker は内部的に、これらのリクエストを含むキューを維持し、処理します。 エンドポイントの作成中に、オプションで Amazon シンプル通知サービス (Amazon SNS) トピックで成功またはエラーの通知を受け取ります。 推論リクエストが正常に処理されたという通知を受け取ると、出力 Amazon S3 の場所にある結果にアクセスできます。
非同期推論のコストは、エンドポイントの実行中に各インスタンスで消費されるインスタンスごとの時間、プロビジョニングされたストレージの GB/月のコスト、およびエンドポイント インスタンスの内外で処理される GB データに基づきます。 Amazon SageMakerの価格。 Cost Explorer では、使用量タイプにフィルターを適用することで、非同期推論コストをフィルターできます。 この使用タイプの名前は次のように構成されています。 REGION-AsyncInf:instanceType
(例えば、 USE1-AsyncInf:ml.c5.9xlarge
)。 この投稿で前述したように、GB ボリュームと GB データ処理された使用量タイプはリアルタイム エンドポイントと同じであることに注意してください。
次のスクリーンショットに示すように、使用タイプによるフィルタリング AsyncInf:
Cost Explorer では、非同期エンドポイントの使用タイプごとにコストの内訳が表示されます。
インスタンス時間ごとのコストと使用量の内訳を確認するには、すべての選択を解除する必要があります。 REGION-Host:VolumeUsage.gp2
使用量タイプ フィルタを適用する前に、使用量タイプを確認してください。 追加のフィルターを適用することもできます。 エンドポイント ARN、エンドポイント インスタンス タイプ、時間ごとのインスタンス料金、毎日の使用時間などのリソースレベルの情報は、AWS CUR から取得できます。 以下は、過去 3 か月の非同期ホスティング リソースの使用状況を取得する AWS CUR クエリの例です。
次のスクリーンショットは、Athena を使用して AWS CUR クエリを実行して得られた結果を示しています。
クエリの結果は、そのエンドポイントを示します sagemaker-abc-model-5
ml.m5.xlarge インスタンスを使用すると、連続した数日間で 24 時間の実行時間が報告されます。 インスタンス料金は 0.23 ドル/時間で、24 時間実行した場合の 5.52 日あたりのコストは XNUMX ドルです。
前述したように、AWS CUR の結果は、連続して数日間実行されるエンドポイントのパターンや、月間コストが最も高いエンドポイントを特定するのに役立ちます。 これは、コストを節約するために非運用アカウントのエンドポイントを削除できるかどうかを判断するのにも役立ちます。
非同期推論のコストを最適化する
リアルタイム エンドポイントと同様に、非同期エンドポイントのコストはインスタンス タイプの使用量に基づきます。 したがって、十分に活用されていないインスタンスを特定し、ワークロード要件に基づいてサイズを変更することが重要です。 非同期エンドポイントを監視するために、SageMaker は いくつかの指標 など ApproximateBacklogSize
, HasBacklogWithoutCapacity
など、CloudWatch で利用できるものもあります。 これらのメトリクスは、インスタンスのキュー内のリクエストを示し、エンドポイントの自動スケーリングに使用できます。 SageMaker の非同期推論には、ホストレベルのメトリクスも含まれています。 ホストレベルのメトリクスについては、を参照してください。 SageMaker ジョブとエンドポイントメトリクス。 これらのメトリクスは、インスタンスの適切なサイズ設定に役立つリソース使用率を示すことができます。
SageMaker のサポート 自動スケーリング 非同期エンドポイントの場合。 リアルタイムのホスト型エンドポイントとは異なり、非同期推論エンドポイントは、最小容量をゼロに設定することで、インスタンスをゼロにスケールダウンすることをサポートします。 非同期エンドポイントの場合、SageMaker は、デプロイされたモデル (バリアント) のターゲット追跡スケーリング用のポリシー設定を作成することを強くお勧めします。 スケーリングポリシーを定義する必要があります。 ApproximateBacklogPerInstance
カスタムメトリクスを設定し、 MinCapacity
値をゼロにします。
非同期推論を使用すると、処理するリクエストがないときにインスタンス数をゼロに自動スケールすることでコストを節約できるため、エンドポイントがリクエストを処理している場合にのみ料金が発生します。 インスタンスがゼロのときに受信したリクエストは、エンドポイントがスケールアップした後に処理するためにキューに入れられます。 したがって、数分間のコールド スタート ペナルティを許容できるユースケースの場合、オプションで、未処理のリクエストがないときにエンドポイント インスタンス数をゼロにスケールダウンし、新しいリクエストが到着するたびにスケールアップすることができます。 コールド スタート時間は、新しいエンドポイントを最初から起動するのに必要な時間によって異なります。 また、モデル自体が大きい場合は時間がかかる場合があります。 ジョブの処理時間が 1 時間よりも長くかかることが予想される場合は、SageMaker バッチ変換を検討することをお勧めします。
さらに、リクエストのキューに入れられた時間と処理時間を組み合わせてインスタンス タイプを選択することもできます。 たとえば、ユースケースが何時間もの待機時間を許容できる場合は、より小さいインスタンスを選択してコストを節約できます。
SageMaker エンドポイントのインスタンスの適切なサイズ設定と自動スケーリングに関する追加のガイダンスについては、以下を参照してください。 Amazon SageMaker で効率的なコンピューティング リソースを確保する.
サーバーレス推論
サーバーレス推論を使用すると、基盤となるインフラストラクチャを構成または管理することなく、推論用の ML モデルをデプロイできます。 モデルが受信する推論リクエストの量に基づいて、SageMaker サーバーレス推論は、コンピューティング容量を自動的にプロビジョニング、スケールし、オフにします。 その結果、アイドル時間ではなく、推論コードを実行するための計算時間と処理されたデータ量に対してのみ料金が発生します。 サーバーレス エンドポイントの場合、インスタンスのプロビジョニングは必要ありません。 提供する必要があります メモリサイズと最大同時実行性。 サーバーレス エンドポイントはオンデマンドでコンピューティング リソースをプロビジョニングするため、エンドポイントではアイドル期間後の最初の呼び出しで数秒の余分な待ち時間 (コールド スタート) が発生する可能性があります。 料金は、推論リクエストの処理に使用されるコンピューティング容量に対して、ミリ秒単位、プロビジョニングされたストレージの GB 月単位、および処理されたデータ量に応じて課金されます。 コンピューティング料金は、選択したメモリ構成によって異なります。
Cost Explorer では、使用量の種類にフィルターを適用することで、サーバーレス エンドポイントのコストをフィルターできます。 この使用タイプの名前は次のように構成されています。 REGION-ServerlessInf:Mem-MemorySize
(例えば、 USE2-ServerlessInf:Mem-4GB
)。 GB ボリュームと GB データ処理された使用量タイプは、リアルタイム エンドポイントと同じであることに注意してください。
アカウント番号、インスタンス タイプ、リージョンなどの追加フィルターを適用すると、コストの内訳を確認できます。 次のスクリーンショットは、サーバーレス推論の使用タイプにフィルターを適用した場合のコストの内訳を示しています。
サーバーレス推論のコストを最適化する
サーバーレス エンドポイントを構成するときに、メモリ サイズと同時呼び出しの最大数を指定できます。 SageMaker サーバーレス推論は、選択したメモリに比例してコンピューティング リソースを自動的に割り当てます。 より大きなメモリ サイズを選択すると、コンテナがより多くの vCPU にアクセスできるようになります。 サーバーレス推論では、ミリ秒単位で請求される推論リクエストの処理に使用されたコンピューティング容量と、処理されたデータ量に対してのみ料金を支払います。 コンピューティング料金は、選択したメモリ構成によって異なります。 選択できるメモリ サイズは、1024 MB、2048 MB、3072 MB、4096 MB、5120 MB、および 6144 MB です。 で説明されているように、メモリ サイズが増えると価格も上がります。 Amazon SageMakerの価格したがって、正しいメモリ サイズを選択することが重要です。 一般に、メモリ サイズは少なくともモデル サイズと同じ大きさである必要があります。 ただし、エンドポイントのメモリ サイズを決定する際には、モデル サイズそのものに加えて、メモリ使用率も参照することをお勧めします。
SageMaker 推論コストを最適化するための一般的なベスト プラクティス
ホスティング コストの最適化は、XNUMX 回限りの作業ではありません。 これは、デプロイされたインフラストラクチャ、使用パターン、パフォーマンスを監視する継続的なプロセスであり、AWS がリリースする、コストに影響を与える可能性のある新しい革新的なソリューションにも注意深く監視します。 次のベスト プラクティスを考慮してください。
- 適切なインスタンス タイプを選択する – SageMaker は、CPU、GPU、メモリ、ストレージ容量のさまざまな組み合わせを持つ複数のインスタンス タイプをサポートします。 モデルのリソース要件に基づいて、過剰プロビジョニングなしで必要なリソースを提供するインスタンス タイプを選択します。 利用可能な SageMaker インスタンス タイプ、その仕様、および適切なインスタンスを選択するためのガイダンスについては、以下を参照してください。 Amazon SageMaker で効率的なコンピューティング リソースを確保する.
- ローカルモードを使用してテストする – 障害を検出してデバッグを迅速に行うために、コードとコンテナー (BYOC の場合) をテストすることをお勧めします。 ローカルモード リモート SageMaker インスタンスで推論ワークロードを実行する前に。 ローカル モードは、SageMaker 管理のホスティング環境でスクリプトを実行する前にスクリプトをテストする優れた方法です。
- モデルを最適化してパフォーマンスを向上させる – 最適化されていないモデルは、実行時間が長くなり、より多くのリソースを使用する可能性があります。 パフォーマンスを向上させるために、より多くのインスタンスまたはより大きなインスタンスを使用することを選択できます。 ただし、これによりコストが高くなります。 モデルのパフォーマンスが向上するように最適化すると、同じまたはより優れたパフォーマンス特性を維持しながら、使用するインスタンスの数を減らすか、より小さくすることでコストを削減できる場合があります。 使用できます Amazon SageMaker ネオ SageMaker 推論を使用してモデルを自動的に最適化します。 詳細とサンプルについては、を参照してください。 Neo を使用してモデルのパフォーマンスを最適化する.
- タグとコスト管理ツールを使用する – 推論ワークロードの可視性を維持するには、タグだけでなく、次のような AWS コスト管理ツールを使用することをお勧めします。 AWS 予算 AWS 請求コンソール、Cost Explorer の予測機能。 柔軟な価格設定モデルとして SageMaker Savings Plans を検討することもできます。 これらのオプションの詳細については、次を参照してください。 第1部 このシリーズの。
まとめ
この投稿では、SageMaker 推論オプションを使用する際のコスト分析とベスト プラクティスに関するガイダンスを提供しました。 機械学習が業界全体で強力なツールとしての地位を確立するにつれて、ML モデルのトレーニングと実行はコスト効率を維持する必要があります。 SageMaker は、ML パイプラインの各ステップを促進するための幅広く奥深い機能セットを提供し、パフォーマンスや俊敏性に影響を与えることなくコストを最適化する機会を提供します。 SageMaker ワークロードのコストに関するガイダンスについては、AWS チームにお問い合わせください。
著者について
ディーパリ・ラジャレ AWS のシニア AI/ML スペシャリストです。 彼女は企業顧客と協力して、AWS エコシステムで AI/ML ソリューションをデプロイおよび維持するためのベストプラクティスに関する技術ガイダンスを提供しています。 彼女は、NLP とコンピューター ビジョンを含むさまざまな深層学習のユースケースについて、幅広い組織と協力してきました。 彼女は、組織が生成 AI を活用して使用エクスペリエンスを向上できるようにすることに情熱を注いでいます。 余暇には、映画、音楽、文学を楽しんでいます。
ユリ・ローゼンバーグ は、ヨーロッパ、中東、アフリカの AI および ML スペシャリスト テクニカル マネージャーです。 Uri はイスラエルに拠点を置き、ML に関するあらゆる分野で企業顧客が大規模に設計、構築、運用できるよう支援することに取り組んでいます。 余暇には、サイクリング、ハイキング、ロックンロール クライミングを楽しんでいます。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- プラトアイストリーム。 Web3 データ インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- 未来を鋳造する w エイドリエン・アシュリー。 こちらからアクセスしてください。
- PREIPO® を使用して PRE-IPO 企業の株式を売買します。 こちらからアクセスしてください。
- 情報源: https://aws.amazon.com/blogs/machine-learning/part-5-analyze-amazon-sagemaker-spend-and-determine-cost-optimization-opportunities-based-on-usage-part-5-hosting/
- :持っている
- :は
- :not
- :どこ
- $UP
- 000
- 1
- 100
- 2021
- 24
- 30
- 40
- 500
- 7
- 8
- a
- できる
- 私たちについて
- 加速器
- アクセス
- アカウント
- 達成する
- 達成
- 越えて
- Action
- 行動
- 加えます
- 添加
- NEW
- アフリカ
- 後
- AI
- AI / ML
- アルゴリズム
- すべて
- 配分
- ことができます
- 既に
- また
- Amazon
- Amazon EC2
- アマゾンセージメーカー
- Amazon Webサービス
- 量
- an
- 分析
- 分析します
- および
- 別の
- どれか
- もはや
- API
- 適用された
- 申し込む
- 適用
- 適切な
- 約
- です
- 人工の
- 人工知能
- 人工知能(AI)
- AS
- 関連する
- At
- アタッチ
- 試みた
- オート
- 自動的に
- 利用できます
- 避ける
- AWS
- バック
- ベース
- BE
- なぜなら
- き
- 以下
- 有益な
- 恩恵
- 利点
- BEST
- ベストプラクティス
- より良いです
- ビッグ
- より大きい
- 請求
- ブロック
- 内訳
- 持って来る
- ビルド
- 内蔵
- 焙煎が極度に未発達や過発達のコーヒーにて、クロロゲン酸の味わいへの影響は強くなり、金属を思わせる味わいと乾いたマウスフィールを感じさせます。
- by
- 缶
- 候補者
- 候補
- 容量
- 容量
- 場合
- 例
- 一定
- 変更
- 特性
- チャージ
- 荷担した
- 課金
- 選択
- 選択する
- 選択する
- クラシック
- クライミング
- クラスタ
- コード
- 冷たい
- 組み合わせ
- 組み合わせる
- 組み合わせた
- 来ます
- comes
- コマンドと
- 一般に
- コンプリート
- コンポーネント
- コンポーネント
- 計算
- コンピュータ
- Computer Vision
- 同時
- 連続した
- 検討
- 検討事項
- 統合します
- 連結する
- 消費
- 消費
- コンテナ
- コンテナ
- 含まれています
- 連続的な
- 基本
- 正しい
- 費用
- Financials
- コスト効率の良い
- コスト
- 可能性
- 作ります
- 創造
- 現在
- カスタム
- Customers
- daily
- データ
- データセット
- 日
- 決めます
- 決定する
- 深いです
- 深い学習
- デフォルト
- 需要
- 依存
- 展開します
- 展開
- 展開する
- 展開
- 配備する
- 設計
- 設計
- 希望
- 詳細
- 細部
- 決定する
- 異なります
- 話し合います
- ディスプレイ
- ディスプレイ
- 分配します
- do
- そうではありません
- 行われ
- ドント
- ダウン
- ダウンロード
- 原因
- 間に
- 各
- 前
- 簡単に
- 東
- エコシステム
- 効率的な
- どちら
- エンパワー
- エンパワーメント
- enable
- 可能
- エンドポイント
- エネルギー
- 高めます
- 確保
- Enterprise
- 環境
- 環境
- 等しい
- 同等の
- エラー
- エラー
- 確立する
- 推定
- ヨーロッパ
- 評価する
- イベント
- 例
- 超えます
- 交換
- 予想される
- 体験
- 実験
- 説明
- 探る
- エクスプローラ
- 広く
- 余分な
- 目
- 容易化する
- フェイル
- Failed:
- 家族
- 速いです
- 特徴
- 少数の
- より少ない
- File
- filter
- フィルタリング
- フィルター
- 名
- フィット
- フレキシブル
- フォーカス
- フォロー中
- 次
- 発見
- 4
- から
- フル
- 機能
- さらに
- 利得
- 生成
- 生々しい
- 生成AI
- 取得する
- 与えられた
- 良い
- GPU
- グラフ
- 素晴らしい
- 大きい
- グループ
- ガイダンス
- ハンドル
- 持ってる
- 持って
- he
- 助けます
- 助けました
- 彼女の
- ハイ
- より高い
- 最高
- 彼の
- 水平な
- 主催
- ホスティング
- ホスティング費用
- ホスト
- 時間
- HOURS
- 認定条件
- How To
- しかしながら
- HTML
- HTTP
- HTTPS
- 何百
- i
- 理想
- 識別する
- アイドル
- if
- 影響
- 影響を与える
- 重要
- 改善します
- in
- include
- 含ま
- 含めて
- 増加
- を示し
- 個人
- 産業
- 情報
- インフラ関連事業
- 革新的な
- 洞察
- 説明書
- インテリジェンス
- 相互作用
- 内部で
- に
- 概要
- 関与
- イスラエル
- IT
- ITS
- 自体
- ジョブ
- Jobs > Create New Job
- JPG
- キーン
- 保管
- キー
- 言語
- 大
- より大きい
- 姓
- レイテンシ
- 起動する
- 打ち上げ
- つながる
- リード
- 学んだ
- 学習
- 最低
- レッスン
- 教訓
- レベル
- 活用します
- wifecycwe
- ような
- LINE
- リンク
- リスト
- レポート
- 負荷
- ローカル
- 場所
- 長い
- より長いです
- 見て
- ロー
- 下側
- 導入トータルコストの
- 機械
- 機械学習
- 維持する
- 保守
- 維持
- make
- 作る
- 管理します
- マネージド
- 管理
- 管理ツール
- マネージャー
- 手動で
- ゲレンデマップ
- マークされた
- 一致
- 五月..
- 手段
- 大会
- メモリ
- 言及した
- メトリック
- メトリック
- 真ん中
- 中東
- かもしれない
- 最小
- 分
- ML
- モード
- モデル
- モニター
- 監視対象
- モニタリング
- 月
- monthly
- ヶ月
- 他には?
- 動画
- マルチモデル エンドポイント
- の試合に
- 音楽を聴く際のスピーカーとして
- しなければなりません
- 名
- 名
- 必要
- 必要
- 必要とされる
- ニーズ
- ネットワーク
- ネットワークの停止
- 新作
- NLP
- いいえ
- 通知
- 通知
- 数
- オブジェクト
- 入手する
- 得
- of
- オフ
- オファー
- オンライン
- on
- ONE
- オンライン
- の
- 操作する
- 機会
- 最適な
- 最適化
- 最適化
- 最適化
- オプション
- オプション
- or
- 注文
- 組織
- その他
- でる
- 機能停止
- 概説
- 出力
- 傑出した
- が
- 自分の
- 並列シミュレーションの設定
- パラメーター
- パラメータ
- 部
- パス
- 通過
- 情熱的な
- 過去
- パターン
- パターン
- 支払う
- 割合
- パフォーマンス
- 期間
- periodic
- 視点
- 選ぶ
- パイプライン
- 計画
- プラン
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- 方針
- おそらく
- ポスト
- 投稿
- 強力な
- 練習
- プラクティス
- 予測
- ブランド
- 価格設定
- 価格モデル
- 先を見越した
- プロセス
- 処理済み
- ラボレーション
- 処理
- プロセッサ
- 生産
- 推進
- 提供します
- 提供
- は、大阪で
- 提供
- 準備
- 目的
- パッティング
- クエリ
- 範囲
- レート
- むしろ
- リーチ
- リーディング
- リアル
- への
- 受け取ります
- 受け
- 受け取り
- 推奨する
- 提言
- 推奨される
- お勧めする
- 記録
- 記録
- 減らします
- 地域
- リリース
- 残る
- リモート
- 削除済み
- レポート
- 各種レポート作成
- レポート
- 要求
- リクエスト
- の提出が必要です
- 要件
- リソースを追加する。
- リソース
- 応答
- REST
- 結果
- 結果
- 収益
- 右
- 岩
- ロール
- ルート
- ルール
- ルール
- ラン
- ランニング
- セージメーカー
- SageMaker の推論
- 同じ
- Save
- 貯蓄
- 規模
- 秤
- スケーリング
- シナリオ
- 予定の
- スクラッチ
- スクリプト
- 秒
- セクション
- 選択
- 選択
- シニア
- 送信
- 別
- シリーズ
- サーバレス
- サービス
- サービス
- サービング
- セッションに
- 設定
- いくつかの
- Shadow
- シェアする
- 彼女
- すべき
- 表示する
- 示されました
- 示す
- 作品
- 同様に
- 簡単な拡張で
- から
- サイズ
- サイズ
- スライス
- 小さい
- より小さい
- So
- ソリューション
- 一部
- ソース
- 専門家
- 特定の
- 仕様
- 過ごす
- split
- スタック
- 標準
- start
- 開始
- 手順
- ストレージ利用料
- 保存され
- 強く
- 構造化された
- 成功
- 成功した
- 首尾よく
- そのような
- 十分な
- 適当
- サポート
- プロアクティブをサポート
- サポート
- サポート
- TAG
- 取る
- 取り
- タスク
- チーム
- 技術的
- test
- テスト
- テスト
- より
- それ
- アプリ環境に合わせて
- それら
- その後
- そこ。
- それによって
- したがって、
- ボーマン
- 物事
- この
- それらの
- 介して
- スループット
- 時間
- <font style="vertical-align: inherit;">回数</font>
- 〜へ
- ツール
- 豊富なツール群
- トピック
- トータル
- トラフィック
- トレーニング
- 最適化の適用
- トランスフォーマー
- トレンド
- true
- ターン
- type
- 根本的な
- 異なり、
- 予測できない
- アップロード
- 使用法
- つかいます
- 使用事例
- 中古
- 使用されます
- 通常
- 活用
- 検証
- 値
- 価値観
- バリアント
- さまざまな
- 詳しく見る
- 視認性
- ビジョン
- 可視化
- ボリューム
- ボリューム
- wait
- 欲しいです
- 仕方..
- we
- ウェブ
- Webサービス
- WELL
- この試験は
- いつ
- かどうか
- which
- while
- ワイド
- 広い範囲
- 意志
- 以内
- 無し
- 働いていました
- ワーカー
- 労働者
- 作品
- 書き込み
- 書かれた
- You
- あなたの
- ゼファーネット
- ゼロ