翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
1 つのエンドポイントの背後にある 1 つのコンテナで複数のモデルをホストする
複数のモデルをホストできるエンドポイントを作成するには、マルチモデルエンドポイントを使用します。マルチモデルエンドポイントは、多数のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションを提供します。複数のモデルをホストできるようになっている共有サービングコンテナを使用します。これにより、単一モデルエンドポイントを使用する場合と比較して、エンドポイントの使用率が向上し、ホスティングコストが削減されます。また、Amazon SageMaker によってメモリへのモデルのロードが管理され、トラフィックパターンに基づいてモデルがスケーリングされるため、デプロイのオーバーヘッドも削減されます。
マルチモデルエンドポイントにより、モデル間でメモリリソースのタイムシェアリングが可能になります。これは、モデル間でサイズと呼び出しレイテンシーが酷似している場合に最適です。この場合、マルチモデルエンドポイントは、すべてのモデル間でインスタンスを効果的に使用できます。1 秒あたりのトランザクション (TPS) やレイテンシーの要件が非常に高いモデルがある場合は、専用のエンドポイントでそれらのモデルをホストすることをお勧めします。マルチモデルエンドポイントは、使用頻度の低いモデルの呼び出し時に発生するコールドスタート関連のレイテンシーペナルティを許容できる場合にも適しています。
マルチモデルエンドポイントは A/B テストをサポートしており、Auto Scaling と AWS PrivateLink と連携します。シリアル推論パイプラインではマルチモデル対応コンテナを使用できますが、推論パイプラインに含めることができるマルチモデル対応コンテナは 1 つだけです。Amazon Elastic Inference では、マルチモデル対応コンテナを使うことはできません。
AWS SDK for Python (Boto) または SageMaker コンソールを使って、マルチモデルエンドポイントを作成します。Multi Model Server
トピック
サポートされるアルゴリズムとフレームワーク
次のアルゴリズムおよびフレームワークの推論コンテナは、マルチモデルエンドポイントをサポートしています。
他のフレームワークまたはアルゴリズムを使うには、SageMaker 推論ツールキットを使って、マルチモデルエンドポイントをサポートするコンテナを構築します。詳細については、マルチモデルサーバーで独自のコンテナを構築する を参照してください。
マルチモデルエンドポイントのサンプルノートブック
SageMaker を使って複数の XGBoost モデルをエンドポイントにデプロイするサンプルノートブックについては、マルチモデルエンドポイント (XGBoost) のサンプルノートブック
マルチモデルエンドポイントの仕組み
SageMaker は、コンテナのメモリ内にある、マルチモデルエンドポイントでホストされるモデルのライフサイクルを管理します。SageMaker では、エンドポイントの作成時に Amazon S3 バケットからコンテナにすべてのモデルをダウンロードするのではなく、モデルを呼び出したときに動的にモデルをロードします。SageMaker が特定のモデルの呼び出しリクエストを受信すると、次の処理が行われます。
-
エンドポイントの背後にあるインスタンスにリクエストをルーティングします。
-
S3 バケットからインスタンスのストレージボリュームにモデルをダウンロードします。
-
モデルをそのインスタンスのコンテナのメモリにロードします。モデルがコンテナのメモリにすでにロードされている場合、SageMaker はモデルをダウンロードしてロードする必要がないため、呼び出しが速くなります。
SageMaker は、モデルがすでにロードされているインスタンスに、モデルへのリクエストを引き続きルーティングします。ただし、モデルが多数の呼び出しリクエストを受信し、マルチモデルエンドポイントに追加のインスタンスがある場合、SageMaker はトラフィックに対応するために一部のリクエストを別のインスタンスにルーティングします。モデルが 2 番目のインスタンスにまだロードされていない場合、モデルはそのインスタンスのストレージボリュームにダウンロードされ、コンテナのメモリにロードされます。
インスタンスのメモリ使用率が高く、SageMaker がメモリに別のモデルをロードする必要がある場合、そのインスタンスのコンテナから未使用のモデルをアンロードして、モデルをロードするのに十分なメモリを確保します。アンロードされたモデルはインスタンスのストレージボリュームに残り、S3 バケットから再度ダウンロードすることなく、後でコンテナのメモリにロードできます。インスタンスのストレージボリュームが最大容量に達すると、SageMaker はストレージボリュームから未使用のモデルを削除します。
モデルを削除するには、リクエストの送信を停止し、そのモデルを S3 バケットから削除します。SageMaker は、サービングコンテナでマルチモデルエンドポイントの機能を提供します。マルチモデルエンドポイントに対するモデルの追加と削除では、エンドポイント自体を更新する必要はありません。モデルを追加するには、そのモデルを S3 バケットにアップロードして、その呼び出しを開始します。この機能を使用するためにコードを変更する必要はありません。
マルチモデルエンドポイントを更新すると、更新されたエンドポイント内のインスタンスにトラフィックが送られるため、エンドポイントでの呼び出しリクエストのレイテンシーが高くなることがあります。
SageMaker マルチモデルエンドポイントモデルのキャッシュ動作を設定する
デフォルトでは、マルチモデルエンドポイントは、メモリとディスクに頻繁に使われるモデルをキャッシュして、低レイテンシーの推論を提供します。キャッシュされたモデルがディスクからアンロードまたは削除されるのは、新しいターゲットモデルに対応してコンテナのメモリまたはディスク領域が不足した場合のみです。
create_modelModelCacheSetting を設定することで、マルチモデルエンドポイントのキャッシュ動作を変更し、モデルキャッシュを明示的に有効または無効にできます。
モデルのキャッシュによる利点がないユースケースの場合は、ModelCacheSetting パラメータの値を Disabled に設定することをお勧めします。例えば、エンドポイントから多数のモデルを提供する必要があるものの、各モデルが 1 回のみ (または非常にまれに) 呼び出される場合などです。このようなユースケースでは、ModelCacheSetting パラメータの値を Disabled に設定にすると、デフォルトのキャッシュモードと比較して、invoke_endpoint リクエストに対する 1 秒あたりのトランザクション処理件数 (TPS) が多くなります。これらのユースケースで TPS が多くなるのは、SageMaker が invoke_endpoint リクエスト受信後に以下を実行するためです。
-
モデルをメモリから非同期的にアンロードし、呼び出された直後にディスクから削除する。
-
推論コンテナでモデルをダウンロード、ロードする際に、同時実行数を増やす (同時実行数は、コンテナインスタンスの vCPU 数の因数)。
マルチモデルエンドポイントの SageMaker 機械学習インスタンスタイプを選択する際のガイドラインについては、「マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項 」を参照してください。
マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項
マルチモデルエンドポイントの SageMaker ML インスタンスタイプを選択する際に考慮すべきいくつかの項目があります。提供する必要があるすべてのモデルに十分な Amazon Elastic Block Store (Amazon EBS) 容量をプロビジョニングします。パフォーマンスとコストのバランスをとります (コールドスタートを最小限に抑える。インスタンスの容量を過剰にプロビジョニングしない)。エンドポイントおよびマルチモデルエンドポイントの各インスタンスタイプに SageMaker がアタッチするストレージボリュームのサイズについては、「ホストインスタンスストレージボリューム」を参照してください。MultiModel モードで動作するように設定されたコンテナの場合、そのインスタンス用にプロビジョニングされたストレージボリュームにはより多くのメモリがあります。そのため、より多くのモデルをインスタンスストレージボリュームにキャッシュできます。
SageMaker 機械学習インスタンスタイプを選択する際は、以下の点を考慮してください。
-
マルチモデルエンドポイントは GPU インスタンスタイプではサポートされません。
-
マルチモデルエンドポイントの背後でホストするモデルへのトラフィック分散 (アクセスパターン)、およびモデルのサイズ (インスタンスのメモリにロードできるモデルの数)。
-
インスタンスのメモリ量は、ロードするモデルのキャッシュ領域と考えます。vCPU の数は、ロードされたモデルに対する推論の同時実行数の制限と考えます (モデルの呼び出しが CPU に縛られると想定)。
-
インスタンスメモリの量が多いほど、より多くのモデルを読み込んで推論リクエストを処理できます。モデルのロードに時間を浪費する必要はありません。
-
vCPU の量が多いほど、より多くの一意なモデルを同時に呼び出すことができます (ここでも推論が CPU に縛られると想定)。
-
特に複数のインスタンスで設定されたマルチモデルエンドポイントの場合は、未使用のモデルをアンロードできるように「スラック」メモリをいくらか確保します。インスタンスまたはアベイラビリティーゾーンに障害が発生した場合、それらのインスタンスのモデルはエンドポイントの背後にある他のインスタンスに再ルーティングされます。
-
-
ロード/ダウンロード時間の許容範囲:
-
d インスタンスタイプファミリー (m5d、c5d、r5d など) には NVMe (不揮発性メモリエクスプレス) SSD が付属しています。これにより、I/O パフォーマンスが高まり、モデルをストレージボリュームにダウンロードする時間、モデルをストレージボリュームからコンテナにロードする時間が短くなります。
-
d インスタンスタイプには NVMe SSD ストレージが付属しているため、SageMaker は、マルチモデルエンドポイントをホストするこれらの機械学習コンピューティングインスタンスには Amazon EBS ストレージボリュームをアタッチしません。Auto Scaling は、モデルのサイズが同じで均質な場合、つまり推定レイテンシーとリソース要件が類似している場合に最も効果的です。
-
場合によっては、ターゲットモデルのすべてを一度にメモリに保持できないインスタンスタイプを選択することにより、コストを削減することを選択できます。SageMaker は、メモリが不足するとモデルを動的にアンロードして、新たにターゲットになったモデルのために空き領域を確保します。頻繁にリクエストされないモデルの場合は、動的なロードのレイテンシーに関連して料金が発生することになります。レイテンシーの要件がより厳しい場合は、より大きなインスタンスタイプまたはより多くのインスタンスを選択できます。適切なパフォーマンステストと分析に事前に時間をかけることは、本番稼働用環境へのデプロイの成功に大いに役立ちます。
ModelCacheHit メトリクスの Average 統計を使用して、モデルがすでにロードされていたリクエストの比率をモニタリングできます。ModelUnloadingTime メトリクスの SampleCount 統計を使用して、一定期間にコンテナに送信されたアンロードリクエストの数をモニタリングできます。モデルがあまりにも頻繁にアンロードされる場合 (これはスラッシングの兆候であり、作業モデルのセットに十分なキャッシュ領域がないためモデルのアンロードと再ロードが繰り返される状況)、より多くのメモリを備えたより大きなインスタンスタイプの使用を検討するか、マルチモデルエンドポイントの背後にあるインスタンスの数の増加を検討します。複数のインスタンスで設定されたマルチモデルエンドポイントの場合は、モデルが複数のインスタンスにロードされる可能性があります。
SageMaker マルチモデルエンドポイントでは Auto Scaling が完全にサポートされており、モデルのレプリカは管理され、モデルはトラフィックパターンに基づいてスケーリングされます。上記のすべてを考慮してマルチモデルエンドポイントとインスタンスのサイズを設定し、さらに、エンドポイントの自動スケーリングも設定することをお勧めします。自動スケーリングイベントのトリガーに使用される呼び出し率は、エンドポイントが提供するすべてのモデルのセットのすべての予測のセットに基づいています。
