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