組織が本番環境で生成 AI ワークロードを拡大するにつれて、信頼性の高い GPU コンピューティングを確保することが最も永続的な運用上の課題の 1 つになっています。大規模言語モデル (LLM) とマルチモーダルアーキテクチャは特定のインスタンスタイプを必要とし、その容量が利用できない場合、エンドポイントは 1 つのリクエストも処理する前に失敗します。
Amazon SageMaker AI でリアルタイム推論エンドポイントを構築するということは、作成時に単一のインスタンスタイプにコミットすることを意味していました。そのタイプの容量が不十分な場合、エンドポイントは実行状態に到達できませんでした。設定を更新し、別のインスタンスタイプを選択して再試行し、プロビジョニングの試行が成功するまでサイクルを繰り返していました。
本日、Amazon SageMaker AI は、新規および既存の推論エンドポイント向けに容量認識インスタンスプールを導入します。優先順位付きのインスタンスタイプのリストを定義すると、作成時、スケールアウト時、スケールイン時に容量が制限されている場合、SageMaker AI が自動的にリストを処理します。エンドポイントは手動操作なしで利用可能な AI インフラストラクチャ上にプロビジョニングされます。この機能は、シングルモデルエンドポイント、推論コンポーネントベースのエンドポイント、および非同期推論エンドポイントで利用できます。
この投稿では、インスタンスプールの仕組みと、新しいエンドポイントを作成する場合でも既存のエンドポイントを移行する場合でも、開始する方法について説明します。
問題
モデルを SageMaker AI 推論エンドポイント（リアルタイムまたは非同期）にデプロイする場合、単一のインスタンスタイプを指定します。そのタイプに利用可能な容量がない場合、エンドポイントの作成は失敗します。この制限は、エンドポイントのライフサイクルのすべての段階で発生します。
- エンドポイントの作成は容量不足で失敗します。優先するインスタンスタイプが利用できない場合、SageMaker AI は容量不足エラーを返します。実行中のエンドポイントに到達するには、代替案を手動で繰り返し試行する必要があり、各試行には結果がわかるまでにかなりの時間がかかります。
- 自動スケーリングはフリートを拡張できません。スケールアウトイベントがトリガーされ、インスタンスタイプの容量が不足している場合、オートスケーラーは同じタイプを無制限に再試行します。トラフィックは増加し続けますが、エンドポイントは現在のサイズのままです。
- スケールインには優先順位の認識がありません。単一のインスタンスタイプでは、優先ハードウェアとフォールバックハードウェアの概念はありません。すべてのインスタンスが区別なく削除対象となります。
- 可観測性は集約され、実用的ではありません。Amazon CloudWatch メトリクスはエンドポイントレベルで集約されます。レイテンシーや容量の問題を調査する場合、メトリクスは何かが間違っていることを示しますが、どのインスタンスタイプが原因であるかは示しません。
仕組み：優先順位ベースのインスタンスプール
エンドポイント設定で、インスタンスプールと呼ばれるランク付けされたインスタンスタイプのリストを定義します。容量が制限されるたびに、SageMaker AI はそのリストを自動的に処理します。
- エンドポイントが起動します。SageMaker AI は最初に優先するインスタンスタイプを試します。容量が利用できない場合は、すぐに 2 番目の選択肢、次に 3 番目の選択肢を試します。手動での再試行は必要ありません。エンドポイントは数分以内に最初に利用可能な AI インフラストラクチャ上で InService 状態に達します。
- エンドポイントは稼働し続けます。自動スケーリングがトリガーされ、優先するインスタンスタイプが制限されている場合、SageMaker AI は優先順位リストの次に利用可能なタイプでスケールアウトするため、トラフィックは流れ続けます。
- フリートは優先ハードウェアに向かう傾向があります。スケールイン中、SageMaker AI は最初に最低優先度（フォールバック）インスタンスを削除します。その後のスケールアウトイベントでは、再び最高優先度のタイプを最初に試します。優先ハードウェアが利用可能になると、フリートは時間の経過とともに自然にそれに向かってシフトし、手動介入は必要ありません。
- すべてが表示されます。既存のすべての CloudWatch メトリクスに InstanceType ディメンションが含まれるようになったため、単一のエンドポイント内でインスタンスタイプごとのレイテンシー、スループット、GPU 使用率、インスタンス数を追跡できます。
詳細については、Amazon SageMaker AI ドキュメントを参照し、GitHub のサンプルノートブックを確認してください。
各インスタンスタイプに適したモデル
フォールバックインスタンスタイプは、GPU メモリ、コンピューティング能力、アーキテクチャが異なることがよくあります。高メモリのマルチ GPU インスタンス向けに最適化されたモデルは、より小規模なシングル GPU フォールバックでは必ずしも実行できるとは限りません。プールリストの各インスタンスタイプを正しく設定されたモデルに一致させる方法は 2 つあります。
オプション 1：独自の最適化モデルを持ち込む
インスタンスタイプのターゲットがすでにわかっている場合は、それぞれにモデルアーティファクトを準備します。プライマリのハイエンドインスタンスでは、複数の GPU にわたってテンソル並列処理を使用する場合があります。ミッドレンジのフォールバックでは、投機的デコードを適用して推論を高速化する場合があります。最低優先度のフォールバックでは、INT4 量子化を使用して、より小さいメモリバジェットに収める場合があります。
各構成に対して個別の SageMaker AI モデルを作成し、ModelNameOverride を使用して各 InstancePools エントリ（シングルモデルエンドポイントの場合）またはインスタンスタイプごとの Specifications（推論コンポーネントベースのエンドポイントの場合）で参照します。SageMaker AI が優先度の低いプールにフォールバックすると、そのハードウェア用に準備したモデルをデプロイします。
オプション 2：SageMaker AI 推論レコメンデーションを使用する
各ハードウェアターゲットを手動で最適化したくない場合は、SageMaker AI 推論レコメンデーションがハードウェア固有の構成を生成します。ベースモデルを提供すると、SageMaker AI は投機的デコードや量子化などの手法を使用して、ターゲットのインスタンスタイプ全体で最適化された構成を生成します。
レコメンデーションジョブは、ターゲットインスタンスタイプごとに 1 つの結果を返します。各結果には、AIRecommendationModelDetails 応答に ModelPackageArn と InferenceSpecificationName が含まれ、特定のハードウェアの構成を識別します。両方のフィールドを使用して結果ごとに 1 つの SageMaker AI モデルを作成し、対応するプールエントリで ModelNameOverride を使用して参照します。これはオプション 1 と同じパターンで、サービスが最適化作業を処理します。
混合フリートの自動スケーリング
自動スケーリングは、作成時に定義したのと同じ優先順位ロジックに従います。スケールアウトは最初に最高優先度のプールを試し、容量が利用できない場合は次のプールにフォールバックします。スケールインは最初に最低優先度のインスタンスを削除し、フリートが縮小するときに優先ハードウェアを保持します。
加重スケーリングメトリクスの構築
フリートにはスループット容量が異なるインスタンスタイプが含まれているため、デフォルトの集計メトリクスは実際の使用状況を誤って表す可能性があります。18 の同時リクエストを処理する p5 インスタンスと 7 を処理する g6 を考えてみると、これらの生の数値を 12.5 に平均化しても、どちらのタイプの負荷も正確に反映されません。
タイプごとの利用率比率に基づいて加重メトリクスを構築するために、CloudWatch メトリクス数学を利用できるようになりました。各項は、タイプの観測された同時実行数をその最大容量で割り、0.0～1.0 の値を生成します。これらの比率を平均すると、TargetValue と同じ 0.0～1.0 スケールのフリートレベルの使用率シグナルが得られます。TargetValue を 0.7 に設定すると、加重平均がフリート内のすべてのインスタンスタイプの容量の 70% を超えた場合にスケールアウトすることを意味します。
フリートの監視
既存のすべての CloudWatch メトリクスに、新しい InstanceType ディメンション（ModelLatency、ConcurrentRequestsPerModel、GPUUtilization、InstanceCount、InvocationsPerInstance）が含まれるようになり、単一のエンドポイント内でハードウェアタイプ別に分類されます。各インスタンスタイプを個別に追跡するダッシュボードとアラームを構築できます。
DescribeEndpoint はプールごとの現在のインスタンス数を返すため、フリートの構成を常に把握できます。
トラフィックルーティング
インスタンスプールを持つエンドポイントでは、ProductionVariant で RoutingConfig を設定して、最小未処理リクエスト (LOR) ルーティングを有効にすることをお勧めします。LOR は、各着信リクエストを、モデルコピーあたりの処理中リクエストが最も少ないインスタンスにルーティングします。容量の大きいインスタンスはリクエストをより迅速に処理するため、キューをより早く空にし、定常状態でより低い処理中カウントを維持します。つまり、手動で重みを設定しなくても、比例的に多くのトラフィックを自然に受信します。
更新とロールバック
ブルー/グリーンデプロイとローリングデプロイの両方がサポートされています。
ブルー/グリーンデプロイは、トラフィックを切り替える前に、同じ優先順位ベースのフォールバックロジックを使用して完全な新しい（グリーン）フリートをプロビジョニングします。ヘルスチェックに合格すると、トラフィックが切り替わります。失敗した場合、自動ロールバックによりブルーフリートが保持され、エンドポイントは全体を通じて InService のままです。
ローリングデプロイは、設定可能なバッチ（一度にインスタンスの 5～50%）でフリートを更新するため、完全なブルー/グリーンフリートよりも少ない追加容量で済みます。これは、大規模モデルや需要の高い GPU インスタンスタイプに特に有効です。SageMaker AI は、新しい各バッチをプロビジョニングするときに優先順位ベースのフォールバックロジックを適用します。ベーキング期間中に CloudWatch アラームがトリガーされると、トラフィックは自動的にロールバックされます。
前提条件
開始する前に、以下があることを確認してください。
- sagemaker:CreateEndpointConfig、sagemaker:CreateEndpoint、sagemaker:UpdateEndpoint IAM 権限を持つ AWS アカウント
- Amazon S3 にアーティファクトを持つ少なくとも 1 つの SageMaker モデル
- Boto3 バージョン 1.43.1 以降（Python SDK での InstancePools サポート用）
- （オプション）ターゲットインスタンスタイプごとに個別に最適化されたモデルアーティファクト、または SageMaker AI 推論レコメンデーションからの ModelPackage
インスタンスプールのサポートは、すべての商用 AWS リージョンで利用できます。AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、または AWS SDK を使用して開始できます。
エンドポイントを構成するワークフロー
インスタンスプールを構成する方法は 2 つあります。新しい Amazon SageMaker AI エンドポイント用、または既存の Amazon SageMaker AI エンドポイント用です。
新しいエンドポイントを作成する場合、以下の図がワークフローを説明しています。
- インスタンスタイプを選択し、優先順位を割り当てます（1 が最高）。
- 各インスタンスタイプに最適化されたモデルを準備するか、SageMaker AI 推論レコメンデーションを実行して生成します。
- 優先順位をリストした InstancePools を使用してエンドポイント設定を作成します。
- エンドポイントを作成します。SageMaker AI が容量解決を自動的に処理します。
- 新しい InstanceType ディメンションを使用して、タイプごとの CloudWatch 監視を設定します。
既存のエンドポイントを移行する場合、以下の図がワークフローを説明しています。
- 新しいエンドポイント設定を作成します。InstanceType を InstancePools に置き換え、現在のインスタンスタイプを Priority: 1 に維持します。
- UpdateEndpoint を呼び出すと、エンドポイントはブルー/グリーン移行中も InService のままです。
- フォールバックインスタンスタイプのスループット容量が大幅に異なる場合は、オプションで加重利用率スケーリングメトリクスを追加します。
セットアップ
インスタンスプールを採用するには、エンドポイント設定を 1 か所変更する必要があります。ProductionVariant の単一の InstanceType フィールドを InstancePools リストに置き換えます。モデル、スケーリングポリシー、および監視ダッシュボードは、変更なしで引き続き機能します。
既存のエンドポイントの移行
変更前：単一のインスタンスタイプ：
import boto3 sm = boto3.client("sagemaker")
sm.create_endpoint_config( EndpointConfigName="my-config", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "InstanceType": "ml.g6e.48xlarge", # 単一タイプ — 容量フォールバックなし }], )
変更後：優先順位付きインスタンスプール：
sm.create_endpoint_config( EndpointConfigName="my-config-v2", ProductionVariants=[{ "VariantName": "primary", "ModelName": "my-llm", "InitialInstanceCount": 2, "VariantInstanceProvisionTimeoutInSeconds": 1200, # 以下の注を参照 "InstancePools": [ {"InstanceType": "ml.g6e.48xlarge", "Priority": 1}, # 現在のタイプ {"InstanceType": "ml.g6.48xlarge", "Priority": 2}, # 同じファミリー、最初のフォールバック {"InstanceType": "ml.p4d.24xlarge", "Priority": 3}, # より広いフォールバック ], }], )
エンドポイントはブルー/グリーン移行中も InService のままです。
sm.update_endpoint( EndpointName="my-endpoint", EndpointConfigName="my-config-v2", )
注：VariantInstanceProvisionTimeoutInSeconds は、インスタンスプールサポートで導入された新しいフィールドです。プールからインスタンスを調達するための合計ウィンドウを設定します。SageMaker AI はこのウィンドウ内で容量不足エラーが発生した場合に再試行を続け、タイムアウトが経過すると次のプールに移動します。有効な範囲は 300～3600 秒です。1200 秒は、大規模な GPU インスタンスタイプの合理的な開始値です。このタイマーはインスタンスの調達のみを対象とし、モデルのダウンロードとコンテナの起動時間は、既存の ModelDataDownloadTimeoutInSeconds および ContainerStartupHealthCheckTimeoutInSeconds フィールドで個別に管理されます。インスタンスタイプごとに異なる最適化モデルをデプロイするには、任意のプールエントリに ModelNameOverride を追加します。モデル構成オプションについては、前のセクションを参照してください。
推論コンポーネントベースのエンドポイント
sm.create_inference_component( InferenceComponentName="my-ic", EndpointName="my-heterogeneous-endpoint", VariantName="primary", Specifications=[ { "InstanceType": "ml.p5.48xlarge", "ModelName": "my-model-p5-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 65536, }, }, { "InstanceType": "ml.g6.48xlarge", "ModelName": "my-model-g6-optimized", "ComputeResourceRequirements": { "NumberOfAcceleratorDevicesRequired": 8, "MinMemoryRequiredInMb": 32768, }, }, ], RuntimeConfig={"CopyCount": 4}, )
非同期推論エンドポイント
インスタンスプールは、非同期推論エンドポイントでも同様に機能します。CreateEndpointConfig 呼び出しに AsyncInferenceConfig ブロックを InstancePools 定義とともに追加します。優先順位ベースのプロビジョニングとフォールバックロジックは同じように適用されます。これは、インスタンスをゼロにスケールダウンする非同期ワークロードに特に役立ちます。エンドポイントがキューに入れられたリクエストを処理するために再スケールアップするとき、SageMaker AI は最初に利用可能な最高優先度のプールを使用してプロビジョニングし、手動操作なしで復元力のあるコールドスタート動作を実現します。
結論
Amazon SageMaker AI インスタンスプールを使用すると、推論エンドポイントに優先順位付きのインスタンスタイプのリストを定義でき、SageMaker AI がその順序に基づいて容量を自動的に管理します。
エンドポイントの作成、スケールアウト、スケールイン中に、SageMaker AI は優先するインスタンスタイプを処理するため、最初に選択したハードウェアが利用できない場合に手動でデプロイを再試行する必要はありません。開始するのは簡単です。エンドポイント設定の InstanceType を InstancePools に置き換え、UpdateEndpoint を呼び出すだけです。既存のモデル、自動スケーリングポリシー、および監視ダッシュボードは、大幅な変更なしで引き続き機能します。
インスタンスタイプごとの CloudWatch メトリクスと DescribeEndpoint からの詳細なプールカウントにより、どのインスタンスタイプがフリートを稼働しているかを明確かつリアルタイムに把握できます。コストの最適化、GPU 容量の制約の処理、またはゼロからのコールドスタートが可能な復元力のある非同期パイプラインの構築のいずれにおいても、インスタンスプールは、運用オーバーヘッドを減らして ML 推論をスムーズに実行し続けるための柔軟性と自動化を提供します。
この機能は、追加費用なしで本日から利用できます。実際にプロビジョニングされたインスタンスタイプに対して、標準のシングルタイプエンドポイントと同じレートで課金されます。詳細については、Amazon SageMaker AI ドキュメントを参照し、GitHub のサンプルノートブックを確認してください。