AmazonSageMakerサーバーレス推論 は、機械学習 (ML) モデルのデプロイとスケーリングを容易にする専用の推論オプションです。 これは従量制モデルを提供します。これは、エンドポイントの呼び出しがまれで予測できないサービスに最適です。 長時間実行されるインスタンスによってサポートされるリアルタイム ホスティング エンドポイントとは異なり、サーバーレス エンドポイントのコンピューティング リソースはオンデマンドでプロビジョニングされるため、インスタンス タイプを選択したり、スケーリング ポリシーを管理したりする必要がなくなります。
次の高レベル アーキテクチャは、サーバーレス エンドポイントがどのように機能するかを示しています。 クライアントは、AWS マネージド インフラストラクチャによってサポートされるエンドポイントを呼び出します。
ただし、サーバーレス エンドポイントは数秒でコールド スタートする傾向があるため、断続的または予測不可能なワークロードに適しています。
コストとパフォーマンスの観点から、サーバーレス エンドポイントが適切な展開オプションであるかどうかを判断するのに役立つように、 SageMaker サーバーレス推論ベンチマーク ツールキット、さまざまなエンドポイント構成をテストし、最も最適な構成を同等のリアルタイム ホスティング インスタンスと比較します。
この投稿では、ツールキットを紹介し、その構成と出力の概要を示します。
ソリューションの概要
ツールキットをダウンロードしてインストールできます。 GitHubレポ. 始めるのは簡単です: ライブラリをインストールし、 SageMakerモデルを入力し、ペイロードの本文やコンテンツ タイプなどの呼び出しパラメータのサンプル セットを含む JSON 行形式のファイルとともに、モデルの名前を指定します。 サンプル呼び出し引数のリストを、画像、ビデオ、オーディオなどのバイナリ ペイロードの JSON 行ファイルまたは pickle ファイルに変換する便利な関数が提供されています。
ツールキットをインストールする
最初に、pip を使用してベンチマーク ライブラリを Python 環境にインストールします。
から次のコードを実行できます。 Amazon SageMakerスタジオ インスタンス、 SageMakerノートブックインスタンス、または任意のインスタンス プログラムによるアクセス AWS および適切な AWS IDおよびアクセス管理 (IAM) アクセス許可。 必要な IAM 権限は、 GitHubレポ. IAM の追加のガイダンスとポリシーの例については、次を参照してください。 AmazonSageMakerがIAMとどのように連携するか. このコードは、XNUMX つのサンプル レコードを含む CSV 入力を想定するモデルで、既定のパラメーター セットを使用してベンチマークを実行します。 エンドポイントがさまざまな入力ペイロードでどのように機能するかを分析するために、代表的な一連の例を提供することをお勧めします。
さらに、ベンチマークを SageMaker 処理ジョブとして実行することもできます。これは、多数の呼び出しを伴う長時間実行されるベンチマークのより信頼性の高いオプションになる可能性があります。 次のコードを参照してください。
これには、ベンチマークの期間中、ml.m5.large SageMaker Processing インスタンスを実行するための追加コストが発生することに注意してください。
どちらの方法も、ベンチマークするメモリ構成のリストや各構成が呼び出される回数など、構成する多数のパラメーターを受け入れます。 ほとんどの場合、最初はデフォルトのオプションで十分ですが、 GitHubレポ 各パラメーターの完全なリストと説明については、
ベンチマーク構成
ベンチマークの機能とそれが生成する出力について詳しく説明する前に、サーバーレス エンドポイントの構成に関するいくつかの重要な概念を理解することが重要です。
全 XNUMX つの主要な構成オプション: MemorySizeInMB & MaxConcurrency. MemorySizeInMB インスタンスに割り当てられるメモリの量を構成します。1024 MB、2048 MB、3072 MB、4096 MB、5120 MB、または 6144 MB のいずれかです。 vCPU の数も、割り当てられたメモリの量に比例してスケーリングされます。 の MaxConcurrency パラメータは、エンドポイントが処理できる同時要求の数を調整します。 とともに MaxConcurrency 1 の場合、サーバーレス エンドポイントは一度に XNUMX つのリクエストしか処理できません。
まとめると、 MemorySizeInMB パラメータは、垂直方向のスケーラビリティのメカニズムを提供し、メモリと計算リソースを調整してより大きなモデルを提供できるようにします。 MaxConcurrency 水平スケーラビリティのメカニズムを提供し、エンドポイントがより多くの同時リクエストを処理できるようにします。
エンドポイントの運用コストは主にメモリ サイズによって決まり、最大同時実行数の増加に関連するコストはありません。 ただし、すべてのエンドポイントにわたる最大同時実行数には、リージョンごとのアカウント制限があります。 参照する SageMaker エンドポイントとクォータ 最新の制限について。
ベンチマーク出力
このことから、サーバーレス エンドポイントのベンチマークの目標は、最も費用対効果が高く信頼できるメモリ サイズの設定と、予想されるトラフィック パターンを処理できる最小最大同時実行数を決定することです。
デフォルトでは、ツールは XNUMX つのベンチマークを実行します。 XNUMX つ目は安定性ベンチマークで、指定されたメモリ構成ごとにエンドポイントをデプロイし、提供されたサンプル ペイロードで各エンドポイントを呼び出します。 このベンチマークの目標は、最も効果的で安定した MemorySizeInMB 設定を決定することです。 ベンチマークは、呼び出しのレイテンシをキャプチャし、各エンドポイントの呼び出しごとに予想されるコストを計算します。 次に、コストを同様のリアルタイム ホスティング インスタンスと比較します。
ベンチマークが完了すると、ツールは指定された形式でいくつかの出力を生成します。 result_save_path 次のディレクトリ構造を持つディレクトリ:
benchmarking_report ディレクトリには、この投稿で概説するすべての要約出力を含む統合レポートが含まれています。 追加のディレクトリには、追加の分析に使用できる未加工の中間出力が含まれています。 を参照してください。 GitHubレポ 各出力アーティファクトの詳細な説明については、
コンピューター ビジョン MobileNetV2 TensorFlow モデルを提供するエンドポイントの実際のベンチマーク出力をいくつか調べてみましょう。 この例を再現したい場合は、 ノートブックの例 GitHub リポジトリのディレクトリ。
統合レポート内の最初の出力は、それぞれの最小、平均、中、および最大レイテンシ メトリックを提供する要約テーブルです。 MemorySizeInMB メモリ サイズの構成に成功しました。 次の表に示すように、平均呼び出しレイテンシ (invocation_latency_mean）は、メモリ構成が 3072 MB に増加するにつれて改善を続けましたが、その後改善が止まりました。
高レベルの記述統計に加えて、各メモリー構成についてクライアントから観測されたレイテンシーの分布を示すグラフが提供されます。 繰り返しになりますが、1024 MB の構成は他のオプションほどパフォーマンスが高くないことがわかりますが、2048 以上の構成ではパフォーマンスに大きな違いはありません.
アマゾンクラウドウォッチ 各エンドポイント構成に関連付けられたメトリックも提供されます。 ここでの重要な指標の XNUMX つは、 ModelSetupTimeエンドポイントがコールド状態で呼び出されたときに、モデルの読み込みにかかった時間を測定します。 エンドポイントがウォーム状態で起動されるため、指標がレポートに表示されない場合があります。 あ cold_start_delay パラメータを使用して、デプロイされたエンドポイントでベンチマークを開始する前にスリープする秒数を指定できます。 このパラメーターを 600 秒などのより大きな数値に設定すると、コールド状態が呼び出される可能性が高くなり、このメトリックを取得できる可能性が高くなります。 さらに、このメトリックは、このセクションで後述する同時呼び出しベンチマークで取得される可能性がはるかに高くなります。
次の表は、各メモリ構成について CloudWatch によってキャプチャされたメトリクスを示しています。
次のグラフは、さまざまなメモリ構成のパフォーマンスとコストのトレードオフを示しています。 1 つの線は、エンドポイントを 2048 万回呼び出した場合の推定コストを示し、もう 2048 つの線は、平均応答待ち時間を示しています。 これらのメトリックは、どのエンドポイント構成が最も費用対効果が高いかを決定する際に役立ちます。 この例では、平均レイテンシーが XNUMX MB を過ぎると横ばいになり、コストが増加し続けていることがわかります。これは、このモデルでは XNUMX のメモリ サイズ構成が最適であることを示しています。
コストと安定性のベンチマークの最終的な出力は、推奨されるメモリ構成と、サーバーレス エンドポイントを運用するコストを同等の SageMaker ホスティング インスタンスと比較した表です。 収集されたデータに基づいて、ツールは 2048 MB の構成がこのモデルに最適であると判断しました。 3072 構成ではレイテンシーが約 10 ミリ秒短縮されますが、30 万リクエストあたり 4.55 ドルから 5.95 ドルに 1% コストが増加します。 さらに、出力は、月間呼び出しリクエストが 88.72 万未満の場合、サーバーレス エンドポイントは、同等のリアルタイム ホスティング インスタンスに対して最大 1% の節約を提供し、8.5 万のリクエストの後、リアルタイム エンドポイントでさえ壊れることを示しています。
XNUMX 番目のタイプのベンチマークはオプションで、さまざまなテストを行います MaxConcurency さまざまなトラフィック パターンでの設定。 このベンチマークは通常、最適な MemorySizeInMB 安定性ベンチマークからの構成。 このベンチマークの XNUMX つの重要なパラメータは、次のリストです。 MaxConcurency エンドポイントがテストされるシミュレートされた同時クライアントの数を決定するクライアント乗数のリストとともにテストする設定。
たとえば、 concurrency_benchmark_max_conc parameter [4, 8] および concurrency_num_clients_multiplier [1, 1.5, 2] にすると、XNUMX つのエンドポイントが起動されます。 MaxConcurency 各エンドポイントは、(MaxConcurency x 乗数) シミュレートされた同時クライアントの数。同時実行数が 4 のエンドポイントの場合、4、6、および 8 の同時クライアントによるロード テスト ベンチマークに変換されます。
このベンチマークの最初の出力は、それぞれに関連付けられているレイテンシ メトリック、スロットル例外、および XNUMX 秒あたりのトランザクション メトリック (TPS) を示す表です。 MaxConcurrency 同時クライアントの数が異なる構成。 これらの指標は、適切な MaxConcurrency 予想されるトラフィック負荷を処理するための設定。 次の表では、最大同時実行数 8 で構成されたエンドポイントが最大 16 の同時クライアントを処理でき、2,500 秒あたり平均 24 トランザクションで行われた XNUMX 回の呼び出しのうち XNUMX 回のスロットリング例外のみで処理できたことがわかります。
次の一連の出力は、それぞれのグラフを提供します MaxConcurrency さまざまな負荷の下でのレイテンシの分布を示す設定。 この例では、エンドポイントが MaxConcurrency 4 に設定すると、呼び出しレイテンシーの増加を最小限に抑えながら、最大 8 つの同時クライアントですべての要求を正常に処理できました。
最終的な出力は、それぞれの CloudWatch メトリクスを含むテーブルを提供します MaxConcurrency 構成。 コールド スタートを常に表示するとは限らない、各メモリ構成のレイテンシの分布を示す前の表とは異なります。 ModelSetupTime このメトリックは、呼び出しリクエストの数が多く、 MaxConcurrency.
まとめ
この投稿では、SageMaker Serverless Inference Benchmarking Toolkit を紹介し、その構成と出力の概要を説明しました。 このツールは、現実的なトラフィック パターンでさまざまな構成を負荷テストすることにより、サーバーレス推論に関してより多くの情報に基づいた決定を下すのに役立ちます。 独自のモデルでベンチマーク ツールキットを試して、サーバーレス エンドポイントをデプロイすることで期待できるパフォーマンスとコスト削減をご確認ください。 を参照してください。 GitHubレポ 追加のドキュメントとノートブックの例については。
その他のリソース
著者について
サイモンザマリン はAI / MLソリューションアーキテクトであり、その主な焦点は、顧客がデータ資産から価値を引き出すのを支援することです。 余暇には、家族と過ごしたり、SFを読んだり、さまざまなDIYハウスプロジェクトに取り組んだりしています。
ダワル・パテル AWS のプリンシパル機械学習アーキテクトです。 大企業から中規模の新興企業まで、さまざまな組織と協力して、分散コンピューティングと人工知能に関連する問題に取り組んできました。 彼は、NLP やコンピューター ビジョン ドメインなどのディープ ラーニングに焦点を当てています。 彼は、顧客が SageMaker で高性能のモデル推論を実現するのを支援しています。
リシャブ・レイ・チョードリー Amazon SageMaker のシニア プロダクト マネージャーで、機械学習の推論に重点を置いています。 彼は、ワークロードのスケーリングを支援するために、AWS で機械学習の顧客向けの新しいエクスペリエンスを革新および構築することに情熱を注いでいます。 余暇には、旅行と料理を楽しんでいます。 あなたは彼を見つけることができます LinkedIn.
