翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
1つのエンドポイントの背後にある1つのコンテナで複数のモデルをホスト
複数のモデルをホストできるエンドポイントを作成するには、マルチモデルエンドポイントを使用します。マルチモデルエンドポイントは、多数のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションを提供します。複数のモデルをホストできるようになっている共有サービングコンテナを使用します。これにより、単一モデルエンドポイントを使用する場合と比較して、エンドポイントの使用率が向上し、ホスティングコストが削減されます。Amazon のため、デプロイのオーバーヘッドも削減されます。 SageMaker メモリへのモデルのロードを管理し、トラフィックパターンに基づいてモデルをスケーリングします。
マルチモデルエンドポイントにより、モデル間でメモリリソースのタイムシェアリングが可能になります。これは、モデル間でサイズと呼び出しレイテンシーが酷似している場合に最適です。この場合、マルチモデルエンドポイントは、すべてのモデル間でインスタンスを効果的に使用できます。1 秒あたりのトランザクション (TPS) やレイテンシーの要件が非常に高いモデルがある場合は、専用のエンドポイントでそれらのモデルをホストすることをお勧めします。マルチモデルエンドポイントは、時折発生しても耐えられるシナリオにも適しています cold-start-related 使用頻度の低いモデルを呼び出すときに発生するレイテンシーペナルティ。
マルチモデルエンドポイントは A/B テストをサポートしており、Auto Scaling と AWS PrivateLink と連携します。以下。 multi-model-enabled シリアル推論パイプラインを含むコンテナ、ただし1つだけ multi-model-enabled コンテナは推論パイプラインに含めることができます。ではを使用できません。 multi-model-enabled Amazon Elastic Inference
以下。AWS SDK for Python (Boto)または SageMaker コンソールを使って、マルチモデルエンドポイントを作成します。Multi Model Server
トピック
サポートされるアルゴリズムとフレームワーク
次のアルゴリズムおよびフレームワークの推論コンテナは、マルチモデルエンドポイントをサポートしています。
他のフレームワークまたはアルゴリズムを使用するには、 SageMaker マルチモデルエンドポイントをサポートするコンテナを構築するための推論ツールキット。詳細については、「マルチモデルサーバーで独自のコンテナを構築する」を参照してください。
マルチモデルエンドポイントのサンプルノートブック
を使用するサンプルノートブックの場合 SageMaker 複数のXGBoostモデルをエンドポイントにデプロイするには、マルチモデルエンドポイント XGBoost サンプルノートブック
マルチモデルエンドポイントの仕組み
SageMaker コンテナのメモリ内にある、マルチモデルエンドポイントでホストされるモデルのライフサイクルを管理します。エンドポイントの作成時に Amazon S3 バケットのすべてのモデルをコンテナにダウンロードする代わりに、 SageMaker呼び出すと動的にロードされます。メトリック 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 マルチモデルエンドポイントの機械学習インスタンスタイプ 提供する必要があるすべてのモデルに十分な 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 が完全にサポートされており、モデルのレプリカは管理され、モデルはトラフィックパターンに基づいてスケーリングされます。上記のすべてを考慮してマルチモデルエンドポイントとインスタンスのサイズを設定し、さらに、エンドポイントの自動スケーリングも設定することをお勧めします。自動スケーリングイベントのトリガーに使用される呼び出し率は、エンドポイントが提供するすべてのモデルのセットのすべての予測のセットに基づいています。
