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

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

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

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

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

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

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

• AWS PrivateLink および VPCs

• Auto scaling

• シリアル推論パイプライン (ただし、推論パイプラインに含めることができるマルチモデル対応コンテナは 1 つだけです)

• A/B テスト

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

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

トピック

• サポートされるアルゴリズム、フレームワーク、インスタンス
• マルチモデルエンドポイントのサンプルノートブック
• マルチモデルエンドポイントの仕組み
• SageMaker マルチモデルエンドポイントモデルのキャッシュ動作の設定
• マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項
• マルチモデルエンドポイントを作成する
• マルチモデルエンドポイントを呼び出す
• モデルの追加または削除
• SageMaker マルチモデルエンドポイント用の独自のコンテナを構築する
• マルチモデルエンドポイントのセキュリティ
• CloudWatch マルチモデルエンドポイントデプロイのメトリクス
• マルチモデルエンドポイントデプロイの自動スケーリングポリシーの設定

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

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

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

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

• XGBoost アルゴリズム

• K 最近傍 (k-NN) アルゴリズム

• 線形学習アルゴリズム

• ランダムカットフォレスト (RCF) アルゴリズム

• Amazon TensorFlow で使用 SageMaker

• Amazon で Scikit-Learn を使う SageMaker

• Amazon で Apache MXNet を使う SageMaker

• Amazon PyTorch で使用 SageMaker

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

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

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

マルチモデルエンドポイントでの複数の GPU ベースのモデルのホストは、SageMaker Triton Inference サーバー を介してサポートされています。これにより、NVIDIATAK TensorRT TAK、MXNet PyTorch、Python、ONNX、XGBoost、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

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

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

• CPU ベースのインスタンスを使用するマルチモデルエンドポイントの例。

  • マルチモデルエンドポイント XGBoost サンプルノートブック – このノートブックでは、複数の XGBoost モデルをエンドポイントにデプロイする方法を説明します。

  • マルチモデルエンドポイント BYOC サンプルノートブック – このノートブックでは、 でマルチモデルエンドポイントをサポートするカスタマーコンテナを設定およびデプロイする方法を示します SageMaker。

• GPU ベースのインスタンスを使用するマルチモデルエンドポイントの例。

  • Amazon SageMaker マルチモデルエンドポイント (MME) を使用して GPUs で複数の深層学習モデルを実行する – このノートブックでは、NVIDIA Triton Inference コンテナを使用して ResNet-50 モデルをマルチモデルエンドポイントにデプロイする方法を説明します。

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

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

• 動画: で何千ものモデルをホストする SageMaker

• 動画: SageMaker ML for SaaS

• ブログ: マルチテナント SaaS ユースケースの機械学習推論をスケーリングする方法

• ケーススタディ: Veeva Systems

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

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 が高いのは、 がinvoke_endpointリクエスト後に以下 SageMaker を行うためです。

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

• 推論コンテナでモデルをダウンロード、ロードする際に、同時実行数を増やす 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 ストレージが付属 SageMaker しているため、マルチモデルエンドポイントをホストするこれらの ML コンピューティングインスタンスには Amazon EBS ストレージボリュームをアタッチしません。Auto Scaling は、モデルのサイズが同じで均質な場合、つまり推定レイテンシーとリソース要件が類似している場合に最も効果的です。

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

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

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

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

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

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