新規にPyTorchベースの自然言語処理モデルをSageMakerにデプロイする予定です。想定リクエスト量は1時間あたり500〜800件で、p95レイテンシーを300ms以内に収めつつコストを最小化したいです。どのインス

Question

新規にPyTorchベースの自然言語処理モデルをSageMakerにデプロイする予定です。想定リクエスト量は1時間あたり500〜800件で、p95レイテンシーを300ms以内に収めつつコストを最小化したいです。どのインスタンスタイプが最適かの知見がなく、本番デプロイ前に客観的な根拠でインスタンスタイプを選定する必要があります。最も効率的に要件を満たす方法はどれですか。

Accepted Answer

正解: SageMaker Inference Recommender のジョブを実行して複数インスタンスタイプで自動ベンチマークを実施し、レイテンシー・コストの比較レポートから最適なインスタンスタイプを選定する。SageMaker Inference Recommender はモデルを複数インスタンスタイプで自動ベンチマークし、レイテンシー・スループット・コストの比較レポートを本番デプロイ前に生成する専用サービス。

Answer

SageMaker Experimentsで複数のml.m5・ml.c5・ml.g4dnインスタンスに手動でエンドポイントをデプロイしてAWS X-Rayで推論レイテンシーを計測し、コストとレイテンシーのトレードオフを比較する — SageMaker Experimentsでの手動デプロイ・計測は設定工数が高く、本番稼働前の最適化という目的に対してInference Recommenderより非効率。

Answer

AWS Compute Optimizer を活用して類似ワークロードのEC2使用実績から機械学習推論インスタンスのサイジング推奨を取得し、SageMakerエンドポイントに適用する — AWS Compute Optimizer はEC2・Lambda・EBS・ECSを対象とし、SageMaker推論エンドポイントのインスタンス選定には対応していない。

Answer

本番エンドポイントをml.g4dn.xlargeで先行デプロイし、CloudWatch メトリクスで実際のレイテンシーを計測してからインスタンスタイプを段階的に変更する — ml.g4dn.xlargeでの本番先行デプロイは最適でないインスタンスで本番コストが発生するリスクがあり、デプロイ前の客観的選定という要件を満たさない。

解説