マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項 - Amazon SageMaker AI

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マルチモデルエンドポイントのデプロイのためのインスタンスの推奨事項

マルチモデルエンドポイントの SageMaker AI ML インスタンスタイプを選択するときに考慮すべき項目がいくつかあります。

  • 提供する必要があるすべてのモデルに十分な Amazon Elastic Block Store (Amazon EBS) 容量をプロビジョニングします。

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

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

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

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

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

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

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

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

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