1 つのエンドポイントの背後にある 1 つのコンテナで複数のモデルをホストする - Amazon SageMaker
サポートされるアルゴリズム、フレームワーク、インスタンスサンプルノートブックAmazon SageMaker マルチモデルエンドポイントの仕組み SageMaker マルチモデルエンドポイントモデルのキャッシュ動作の設定マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

1 つのエンドポイントの背後にある 1 つのコンテナで複数のモデルをホストする

マルチモデルエンドポイントは、多数のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションを提供します。同じリソース群と共有サービングコンテナを使用して、すべてのモデルをホストします。これにより、単一モデルエンドポイントを使用する場合と比較して、エンドポイントの使用率が向上し、ホスティングコストが削減されます。また、Amazon SageMaker はモデルをメモリにロードし、エンドポイントへのトラフィックパターンに基づいてスケーリングするため、デプロイのオーバーヘッドも削減されます。

次の図は、マルチモデルエンドポイントが単一モデルのエンドポイントと比較してどのように機能するかを示しています。

マルチモデルとシングルモデルエンドポイントがモデルをホストする方法を示す図。

マルチモデルエンドポイントは、共有サービングコンテナ上で同じ ML フレームワークを使用する多数のモデルをホストするのに理想的です。アクセス頻度の高いモデルとアクセス頻度の低いモデルが混在している場合、マルチモデルエンドポイントは、より少ないリソースと高いコスト削減でトラフィックを効率的に処理できます。使用頻度の低いモデルを呼び出すときに発生する、コールドスタート関連のレイテンシーのペナルティをアプリケーション側で許容する必要があります。

マルチモデルエンドポイントは、 CPUと GPU の両方のバックアップモデルをホストすることをサポートします。GPU バックアップモデルを使用すると、エンドポイントとその基盤となる高速コンピューティングインスタンスの使用が増えるため、モデルのデプロイコストを削減できます。

マルチモデルエンドポイントにより、モデル間でメモリリソースのタイムシェアリングが可能になります。これは、モデル間でサイズと呼び出しレイテンシーが酷似している場合に最適です。この場合、マルチモデルエンドポイントは、すべてのモデル間でインスタンスを効果的に使用できます。1 秒あたりのトランザクション数 (TPS) またはレイテンシー要件が大幅に高いモデルがある場合は、専用エンドポイントでホストすることをお勧めします。

以下の機能を備えたマルチモデルエンドポイントを使用できます。

Amazon Elastic Inference で multi-model-enabled コンテナを使用することはできません。

AWS SDK for Python (Boto) または SageMaker コンソールを使用して、マルチモデルエンドポイントを作成できます。CPU バックアップされたマルチモデルエンドポイントの場合、マルチモデルサーバーライブラリを統合することで、カスタムビルドのコンテナでエンドポイントを作成できます。

トピック

サポートされるアルゴリズム、フレームワーク、インスタンス

マルチモデルエンドポイントで使用できるアルゴリズム、フレームワーク、インスタンスタイプについては、以下のセクションを参照してください。

CPU バックアップされたインスタンスを使用するマルチモデルエンドポイントでサポートされているアルゴリズム、フレームワーク、インスタンス

次のアルゴリズムおよびフレームワークの推論コンテナは、マルチモデルエンドポイントをサポートしています。

他のフレームワークまたはアルゴリズムを使用するには、 SageMaker 推論ツールキットを使用して、マルチモデルエンドポイントをサポートするコンテナを構築します。詳細については、マルチモデルエンドポイント用の SageMaker独自のコンテナを構築する を参照してください。

マルチモデルエンドポイントは、すべてのCPUインスタンスタイプをサポートします。

GPU バックアップされたインスタンスを使用するマルチモデルエンドポイントでサポートされるアルゴリズム、フレームワーク、インスタンス

マルチモデルエンドポイントでの複数のGPUバックアップ済みモデルのホストは、SageMaker Triton Inference サーバー を通じてサポートされています。これにより、NVIDIA® TensorRT 、 PyTorch、、MXNetPython、、ONNX、scikit-learnXGBoost、Open、VINOカスタム C++ など RandomForest、すべての主要な推論フレームワークがサポートされます。

他のフレームワークやアルゴリズムを使用するには、Python または C++ 用の Triton バックエンドを使用してモデルロジックを記述し、任意のカスタムモデルを提供できます。サーバーの準備が整ったら、1 つのエンドポイントに何百ものディープラーニングモデルのデプロイを開始できます。

マルチモデルエンドポイントは、次のGPUインスタンスタイプをサポートします。

インスタンスファミリー インスタンスタイプ vCPUs v あたりのメモリの GiB CPU GPUs GPU メモリ

p2

ml.p2.xlarge

4

15.25

1

12

p3

ml.p3.2xlarge

8

7.62

1

16

g5

ml.g5.xlarge

4

4

1

24

g5

ml.g5.2xlarge

8

4

1

24

g5

ml.g5.4xlarge

16

4

1

24

g5

ml.g5.8xlarge

32

4

1

24

g5

ml.g5.16xlarge

64

4

1

24

g4dn

ml.g4dn.xlarge

4

4

1

16

g4dn

ml.g4dn.2xlarge

8

4

1

16

g4dn

ml.g4dn.4xlarge

16

4

1

16

g4dn

ml.g4dn.8xlarge

32

4

1

16

g4dn

ml.g4dn.16xlarge

64

4

1

16

マルチモデルエンドポイントのサンプルノートブック

マルチモデルエンドポイントの使用方法の詳細については、以下のサンプルノートブックを試すことができます。

で前の例を実行するために使用できる Jupyter Notebook インスタンスを作成してアクセスする方法については SageMaker、「」を参照してくださいAmazon SageMaker Notebook インスタンス。ノートブックインスタンスを作成して開いたら、SageMaker 「例」タブを選択すると、すべての SageMaker サンプルのリストが表示されます。マルチモデルエンドポイントノートブックは、 ADVANCEDFUNCTIONALITYセクションにあります。ノートブックを開くには、その [Use (使用)] タブを選択し、[Create copy (コピーを作成)] を選択します。

マルチモデルエンドポイントのユースケースの詳細については、以下のブログとリソースを参照してください。

マルチモデルエンドポイントの仕組み

SageMaker は、コンテナのメモリ内のマルチモデルエンドポイントでホストされるモデルのライフサイクルを管理します。エンドポイントの作成時にすべてのモデルを Amazon S3 バケットからコンテナにダウンロードする代わりに、 はそれらを呼び出すときに SageMaker 動的にロードしてキャッシュします。が特定のモデルの呼び出しリクエスト SageMakerを受信すると、次の処理が行われます。

  1. エンドポイントの背後にあるインスタンスにリクエストをルーティングします。

  2. S3 バケットからインスタンスのストレージボリュームにモデルをダウンロードします。

  3. 高速コンピューティングインスタンスのコンテナのメモリ (CPU または GPU、またはCPUGPUバックアップされたインスタンスがあるかどうかに応じて) にモデルをロードします。モデルがコンテナのメモリにすでにロードされている場合、 はモデルをダウンロードしてロードする必要 SageMaker がないため、呼び出しが速くなります。

SageMaker は、モデルのリクエストを、モデルが既にロードされているインスタンスにルーティングし続けます。ただし、モデルが多数の呼び出しリクエストを受信し、マルチモデルエンドポイントに追加のインスタンスがある場合、 はトラフィックに対応するために一部のリクエストを別のインスタンスに SageMaker ルーティングします。モデルが 2 番目のインスタンスにまだロードされていない場合、モデルはそのインスタンスのストレージボリュームにダウンロードされ、コンテナのメモリにロードされます。

インスタンスのメモリ使用率が高く、別のモデルをメモリにロード SageMaker する必要がある場合、そのインスタンスのコンテナから未使用のモデルをアンロードして、モデルをロードするのに十分なメモリがあることを確認します。アンロードされたモデルはインスタンスのストレージボリュームに残り、S3 バケットから再度ダウンロードすることなく、後でコンテナのメモリにロードできます。インスタンスのストレージボリュームが容量に達すると、 SageMaker は未使用のモデルをストレージボリュームから削除します。

モデルを削除するには、リクエストの送信を停止し、S3 bucket から削除します。 SageMaker は、サービングコンテナにマルチモデルエンドポイント機能を提供します。マルチモデルエンドポイントに対するモデルの追加と削除では、エンドポイント自体を更新する必要はありません。モデルを追加するには、そのモデルを S3 バケットにアップロードして、その呼び出しを開始します。この機能を使用するためにコードを変更する必要はありません。

注記

マルチモデルエンドポイントを更新すると、マルチモデルエンドポイントのスマートルーティングがトラフィックパターンに適応するため、エンドポイントでの初回呼び出しリクエストの待ち時間が長くなる可能性があります。ただし、トラフィックパターンを学習すると、最も頻繁に使用されるモデルのレイテンシーは短くなります。使用頻度の低いモデルでは、モデルがインスタンスに動的に読み込まれるため、コールドスタートのレイテンシーが発生する可能性があります。

SageMaker マルチモデルエンドポイントモデルのキャッシュ動作の設定

デフォルトでは、マルチモデルエンドポイントは頻繁に使用されるモデルをメモリ (CPU または GPUで、インスタンスのCPUGPUバックアップの有無に応じて) とディスクにキャッシュして、低レイテンシーの推論を実現します。キャッシュされたモデルがディスクからアンロードまたは削除されるのは、新しいターゲットモデルに対応してコンテナのメモリまたはディスク領域が不足した場合のみです。

create_model を呼び出したときにパラメータ ModelCacheSetting を設定することで、マルチモデルエンドポイントのキャッシュ動作を変更し、モデルキャッシュを明示的に有効または無効にできます。

モデルのキャッシュによる利点がないユースケースの場合は、ModelCacheSetting パラメータの値を Disabled に設定することをお勧めします。例えば、エンドポイントから多数のモデルを提供する必要があるものの、各モデルが 1 回のみ (または非常にまれに) 呼び出される場合などです。このようなユースケースでは、 ModelCacheSettingパラメータの値を に設定すると、デフォルトのキャッシュモードと比較してinvoke_endpoint、リクエストの 1 秒あたりのトランザクション数 (TPS) がDisabled高くなります。これらのユースケースTPSでは、invoke_endpointリクエスト後に が以下 SageMaker を行うため、 が高いです。

  • モデルをメモリから非同期的にアンロードし、呼び出された直後にディスクから削除する。

  • 推論コンテナでモデルをダウンロード、ロードする際に、同時実行数を増やす CPU とGPUバックアップされたエンドポイントの両方で、同時実行数はコンテナインスタンス vCPUs の の数の係数です。

マルチモデルエンドポイントの SageMaker ML インスタンスタイプの選択に関するガイドラインについては、「」を参照してくださいマルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項。

マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項

マルチモデルエンドポイントの SageMaker ML インスタンスタイプを選択するときに考慮すべき項目がいくつかあります。

  • 提供する必要があるすべてのモデルに十分な Amazon Elastic Block Store (Amazon EBS） 容量をプロビジョニングします。

  • パフォーマンスとコストのバランスをとります (コールドスタートを最小限に抑える。インスタンスの容量を過剰にプロビジョニングしない)。エンドポイントとマルチモデルエンドポイントの各インスタンスタイプにア SageMaker タッチするストレージボリュームのサイズについては、「」を参照してくださいホストインスタンスストレージボリューム。

  • MultiModel モードで動作するように設定されたコンテナの場合、そのインスタンス用にプロビジョニングされたストレージボリュームは、デフォルトの SingleModel モードよりも大きくなります。そのため、SingleModel モードより多くのモデルをインスタンスストレージボリュームにキャッシュできます。

SageMaker ML インスタンスタイプを選択するときは、次の点を考慮してください。

  • マルチモデルエンドポイントは現在、すべてのCPUインスタンスタイプと単一GPUインスタンスタイプでサポートされています。

  • マルチモデルエンドポイントの背後でホストするモデルへのトラフィック分散 (アクセスパターン)、およびモデルのサイズ (インスタンスのメモリにロードできるモデルの数) に関する次の情報にご注意ください。

    • インスタンスのメモリ量をロードするモデルのキャッシュスペースとして考え、 の数をロードしたモデルで推論を実行する同時実行数の制限 vCPUs として考えます (モデルを呼び出すのは にバインドされていると仮定）CPU。

    • CPU バックアップされたインスタンスの場合、 の数はインスタンスあたりの最大同時呼び出し数 vCPUs に影響します (モデルの呼び出しが にバインドされていると仮定）CPU。の量が多いほど、より一意のモデルを同時に呼び出す vCPUs ことができます。

    • GPU バックアップされたインスタンスの場合、インスタンスとGPUメモリの量が多いほど、より多くのモデルをロードし、推論リクエストを処理する準備が整います。

    • CPU とGPUバックアップされたインスタンスの両方で、未使用のモデルをアンロードできるように、いくつかの「スラック」メモリを使用できます。特に、複数のインスタンスを持つマルチモデルエンドポイントの場合。インスタンスまたはアベイラビリティーゾーンに障害が発生した場合、それらのインスタンスのモデルはエンドポイントの背後にある他のインスタンスに再ルーティングされます。

  • ロード/ダウンロード時間の許容範囲を確認する。

    • d インスタンスタイプファミリー (m5d、c5d、r5d など) と g5s には NVMe (不揮発性メモリエクスプレス) が付属しています。これによりSSD、I/O パフォーマンスが高くなり、モデルをストレージボリュームにダウンロードし、コンテナがストレージボリュームからモデルをロードする時間を短縮できる可能性があります。

    • d および g5 インスタンスタイプには NVMeSSDストレージが付属 SageMaker しているため、 は、マルチモデルエンドポイントをホストするこれらの ML コンピューティングインスタンスに Amazon EBSストレージボリュームをアタッチしません。Auto Scaling は、モデルのサイズが同じで均質な場合、つまり推定レイテンシーとリソース要件が類似している場合に最も効果的です。

また、以下のガイダンスを使用して、マルチモデルエンドポイントへのモデル読み込みを最適化することもできます。

対象となるモデルのすべてをメモリの範囲内に保持できないインスタンスタイプを選択する

場合によっては、すべてのターゲットモデルを一度にメモリに保持できないインスタンスタイプを選択することでコストを削減することを選択できます。 は、メモリが不足するとモデルを SageMaker 動的にアンロードして、新しくターゲットを絞ったモデルのためのスペースを確保します。リクエストの頻度が低いモデルでは、動的ロードレイテンシーが犠牲になります。レイテンシーの要件がより厳しい場合は、より大きなインスタンスタイプまたはより多くのインスタンスを選択できます。パフォーマンステストと分析に事前に時間をかけることは、本番環境へのデプロイを成功させるのに役立ちます。

モデルキャッシュのヒット数を評価する

Amazon CloudWatch メトリクスは、モデルの評価に役立ちます。マルチモデルエンドポイントで使用できるメトリクスの詳細については、「CloudWatch マルチモデルエンドポイントデプロイのメトリクス 」を参照してください。

ModelCacheHit メトリクスの Average 統計を使用して、モデルがすでにロードされていたリクエストの比率をモニタリングできます。ModelUnloadingTime メトリクスの SampleCount 統計を使用して、一定期間にコンテナに送信されたアンロードリクエストの数をモニタリングできます。モデルがあまりにも頻繁にアンロードされる場合 (これは「スラッシング」の兆候であり、作業モデルのセットに十分なキャッシュ領域がないためモデルのアンロードと再ロードが繰り返される状況)、より多くのメモリを備えたより大きなインスタンスタイプの使用を検討するか、マルチモデルエンドポイントの背後にあるインスタンスの数の増加を検討します。複数のインスタンスで設定されたマルチモデルエンドポイントの場合は、モデルが複数のインスタンスにロードされる可能性があります。