1つのエンドポイントの背後にある1つのコンテナで複数のモデルをホスト - アマゾン 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 ベースのマルチモデルエンドポイントの場合、Multi Model Server ライブラリを統合することで、カスタムビルドのコンテナを使用してエンドポイントを作成できます。

トピック

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

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

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

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

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

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

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

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

他のフレームワークやアルゴリズムを使用するには、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

ミリリットル 5.2X ラージ

8

4

1

24

g5

ミリリットル 5.4X ラージ

16

4

1

24

g5

5.8xLarge

32

4

1

24

g5

ミリゲージ 5.16X ラージ

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 ノートブックインスタンスを使用する。ノートブックインスタンスを作成して開いた後、[Examples] (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 でバックアップされたインスタンスがあるかどうかに応じて) とディスクにキャッシュします。キャッシュされたモデルがディスクからアンロードまたは削除されるのは、新しいターゲットモデルに対応してコンテナのメモリまたはディスク領域が不足した場合のみです。

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

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

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

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

マルチモデルエンドポイントの SageMaker 機械学習インスタンスタイプを選択する際のガイドラインについては、「」を参照してくださいマルチモデルエンドポイントのデプロイにおけるインスタンスの推奨事項。

マルチモデルエンドポイントのデプロイにおけるインスタンスの推奨事項

マルチモデルエンドポイントの SageMaker 機械学習インスタンスタイプを選択する際に考慮すべき点がいくつかあります。

  • サービスを提供する必要があるすべてのモデルに十分な Amazon Elastic Block Store (Amazon EBS) のキャパシティをプロビジョニングします。

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

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

SageMaker 機械学習インスタンスタイプを選択する際は、次の点を考慮してください。

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

  • マルチモデルエンドポイントの背後でホストするモデルへのトラフィック分散（アクセスパターン）とモデルサイズ（インスタンスのメモリにロードできるモデルの数）については、次の情報に留意してください。

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

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

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

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

  • ロード/ダウンロード時間の許容範囲を判断してください。

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

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

また、次のガイダンスを参考にして、マルチモデルエンドポイントでのモデル読み込みを最適化することもできます。

ターゲットモデルのすべてをメモリに保持できないインスタンスタイプを選択する

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

モデルキャッシュヒットの評価

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

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