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

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

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

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

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

マルチモデルエンドポイントがモデルをホストする方法と、単一モデルのエンドポイントがモデルをホストする方法を示す図。

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

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

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

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

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

AWS SDK for Python (Boto) SageMaker またはコンソールを使用してマルチモデルエンドポイントを作成できます。CPU ベースのマルチモデルエンドポイントでは、Multi Model Server ライブラリを統合することで、カスタム構築コンテナでエンドポイントを作成できます。

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

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

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

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

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

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

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

マルチモデルエンドポイントでの複数の GPU ベースのモデルのホスティングは、Triton Inference サーバーを通じてサポートされています。SageMaker これにより、NVIDIA® TensorRT™、MXNet、Python、ONNX、XGBoost PyTorch、scikit-learn、OpenVino、カスタム C++ など、すべての主要な推論フレームワークがサポートされます。 RandomForest

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

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

インスタンスファミリー インスタンスタイプ vCPUs vCPU あたりのメモリ (GiB) GPU 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 ノートブックインスタンスを作成してアクセスする方法については、を参照してください。 SageMaker Amazon SageMaker Notebook インスタンスノートブックインスタンスを作成して開いたら、「SageMaker Examples」タブを選択すると、すべてのサンプルのリストが表示されます。 SageMakerマルチモデルエンドポイントノートブックは [高度な機能] セクションにあります。ノートブックを開くには、その [Use (使用)] タブを選択し、[Create copy (コピーを作成)] を選択します。

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

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

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

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

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

  3. その高速コンピューティングインスタンス上のコンテナのメモリ (CPU と GPU ベースのインスタンスのどちらを使用しているかによって CPU または GPU) にモデルをロードします。モデルが既にコンテナのメモリに読み込まれている場合は、 SageMaker ダウンロードして読み込む必要がないため、呼び出しが速くなります。

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

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

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

注記

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

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

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

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

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

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

  • 推論コンテナでモデルをダウンロード、ロードする際に、同時実行数を増やす CPU と GPU ベースのエンドポイントの両方で、同時実行数は、コンテナインスタンスの vCPU 数の因数です。

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

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

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

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

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

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

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

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

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

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

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

    • GPU ベースのインスタンスの場合、インスタンスと GPU のメモリの量が多いほど、より多くのモデルを読み込んで推論リクエストを処理できます。

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

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

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

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

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

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

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

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

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

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