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

インスタンスプールを使用して複数のインスタンスタイプにデプロイする

モデルを SageMaker AI エンドポイントにデプロイする場合、通常、本番稼働用バリアントに単一のインスタンスタイプを指定します。そのインスタンスタイプがターゲットアベイラビリティーゾーンで使用できない場合、デプロイは容量不足エラー (ICE) で失敗し、別のインスタンスタイプで手動で再試行する必要があります。

インスタンスプールでは、本番稼働用バリアントに最大 5 つのインスタンスタイプの順序付きリストを指定できます。SageMaker AI は、優先度の高いタイプ (優先度 1) から開始してインスタンスのプロビジョニングを試み、容量が利用できない場合、優先度の低いタイプに自動的にフォールバックします。これにより、手動で再試行する必要がなくなり、エンドポイントの可用性が向上します。

インスタンスプールは、リアルタイム推論エンドポイントと非同期推論エンドポイントの両方をサポートします。単一モデルエンドポイントと推論コンポーネントで使用できます。

次の手順では、インスタンスプールのプロビジョニングの仕組みについて説明します。

インスタンスプールを使用してエンドポイントを設定する

インスタンスプールを使用するには、本番稼働用バリアントの InstanceTypeパラメータを InstancePoolsリストに置き換えます。各エントリは、インスタンスタイプと優先度 (1 ～ 5、1 が最上位) を指定します。オプションで VariantInstanceProvisionTimeoutInSeconds (300～3600 秒) を設定して、オペレーションが失敗する前に SageMaker AI がすべてのプールにインスタンスをプロビジョニングしようとした合計時間を制御できます。

単一モデルによるリアルタイムエンドポイント

次の例では、2 つのインスタンスプールを持つエンドポイント設定を作成します。ml.g6.2xlarge インスタンスが使用できない場合、SageMaker AI は にフォールバックしますml.g6e.2xlarge。

import boto3

sagemaker_client = boto3.client("sagemaker")

endpoint_config_name = "my-heterog-endpoint-config"

sagemaker_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "AllTraffic",
            "ModelName": "my-model",
            "InitialInstanceCount": 2,
            "InstancePools": [
                {
                    "InstanceType": "ml.g6.2xlarge",
                    "Priority": 1,
                },
                {
                    "InstanceType": "ml.g6e.2xlarge",
                    "Priority": 2,
                },
            ],
            "VariantInstanceProvisionTimeoutInSeconds": 600,
        }
    ],
)

sagemaker_client.create_endpoint(
    EndpointName="my-heterog-endpoint",
    EndpointConfigName=endpoint_config_name,
)
            

各プールで ModelNameOverrideパラメータを使用して、そのインスタンスタイプに最適化された別のモデルを指定することもできます。たとえば、GPU 用にコンパイルされたモデルを 1 つのインスタンスタイプにデプロイし、コンパイルされていないバージョンを別のインスタンスタイプにデプロイできます。

推論コンポーネントを使用したリアルタイムエンドポイント

インスタンスプールで推論コンポーネントを使用する場合、仕様を定義するための 2 つのオプションがあります。

次の例では、per-instance-type仕様を持つ推論コンポーネントを作成します。

sagemaker_client.create_inference_component(
    InferenceComponentName="my-ic",
    EndpointName="my-heterog-endpoint",
    VariantName="AllTraffic",
    Specifications=[
        {
            "InstanceType": "ml.g6.2xlarge",
            "ModelName": "my-model-g6",
            "Container": {
                "Image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/my-image:latest",
            },
            "ComputeResourceRequirements": {
                "NumberOfAcceleratorDevicesRequired": 1,
                "MinMemoryRequiredInMb": 4096,
            },
        },
        {
            "InstanceType": "ml.g6e.2xlarge",
            "ModelName": "my-model-g6e",
            "Container": {
                "Image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/my-image:latest",
            },
            "ComputeResourceRequirements": {
                "NumberOfAcceleratorDevicesRequired": 1,
                "MinMemoryRequiredInMb": 8192,
            },
        },
    ],
    RuntimeConfig={
        "CopyCount": 2,
    },
)
            

インスタンスプールのモニタリング

Invocations、、 など、バリアント内のすべてのインスタンスに集約された既存の CloudWatch メトリクスはModelLatency、インスタンスプールを使用する場合も引き続き同じようにCPUUtilization動作します。さらに、CloudWatch はこれらのメトリクスを InstanceTypeディメンションで公開するため、インスタンスタイプごとにパフォーマンスを個別にモニタリングできます。

インスタンスタイプごとのメトリックス

本番稼働用バリアントがインスタンスプールを使用する場合、CloudWatch ではper-instance-typeモニタリングに次のディメンションの組み合わせを使用できます。

これらのディメンションは、標準の CloudWatch メトリクスと拡張メトリクスの両方で使用できます。使用可能なメトリクスの完全なリストについては、Amazon CloudWatch における Amazon SageMaker AI メトリクス「」および「」を参照してください推論エンドポイントの Amazon SageMaker AI 拡張メトリクス。

フリートディストリビューションを確認する

各プールの現在のインスタンス数を確認するには、 DescribeEndpoint API を呼び出します。レスポンスProductionVariantsの には、各インスタンスタイプの現在の数を含むInstancePoolsリストが含まれます。これは、優先度の低いプールからのフォールバックインスタンスを含む、プロビジョニング後のフリート構成を示します。

推論コンポーネントを使用する場合、DescribeInferenceComponentレスポンスには、インスタンスタイプごとのコピー数を示すランタイム設定概要の PlacementStatus フィールドが含まれます。これを使用して、推論コンポーネントのコピーがフリートのインスタンスタイプ全体にどのように分散されるかを理解します。

インスタンスプールによる自動スケーリング

インスタンスプールによる自動スケーリングは、標準エンドポイントの自動スケーリングと同じプロセスに従います。スケーラブルターゲットを登録し、スケーリングポリシーを定義して、エンドポイントに適用します。一般的な自動スケーリングの設定については、「」を参照してくださいAmazon SageMaker AI モデルの自動スケーリング。

主な違いは、スケーリングイベントがトリガーされたときに SageMaker AI がインスタンスをプロビジョニングおよび解放する方法です。

事前定義されたスケーリングメトリクスを使用する

などの事前定義されたスケーリングメトリクスは、SageMakerVariantInvocationsPerInstance引き続きインスタンスプールで機能します。これらのメトリクスはバリアント内のすべてのインスタンスタイプに集約されるため、スケーリング動作は標準エンドポイントと同じです。これは、プール内のすべてのインスタンスタイプに同様の容量がある場合に最も簡単なアプローチです。

ターゲット追跡とステップスケーリングポリシーの設定については、「」を参照してくださいAmazon SageMaker AI モデルの自動スケーリング。

混合フリートに加重カスタムメトリクスを使用する

インスタンスプールに異なるコンピューティング容量を持つインスタンスタイプが含まれている場合、CloudWatch メトリクス数式を使用して加重スケーリングシグナルを作成できます。これにより、各インスタンスタイプの負荷が全体的なスケーリング決定にどの程度寄与するかを制御できます。

次の例では、2 つのインスタンスタイプConcurrentRequestsPerModelにわたって の加重平均を使用するターゲット追跡ポリシーを作成します。重みは、スケーリングポリシーが各タイプの負荷に対してどの程度敏感かを決定します。

import boto3

aas_client = boto3.client("application-autoscaling")

# Register the scalable target
aas_client.register_scalable_target(
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/my-heterog-endpoint/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    MinCapacity=1,
    MaxCapacity=10,
)

# Define target tracking policy with weighted metric math
aas_client.put_scaling_policy(
    PolicyName="weighted-concurrent-requests",
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/my-heterog-endpoint/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    PolicyType="TargetTrackingScaling",
    TargetTrackingScalingPolicyConfiguration={
        "TargetValue": 10.0,
        "CustomizedMetricSpecification": {
            "Metrics": [
                {
                    "Id": "cr_g6",
                    "Label": "ConcurrentRequests-g6-2xlarge",
                    "MetricStat": {
                        "Metric": {
                            "Namespace": "AWS/SageMaker",
                            "MetricName": "ConcurrentRequestsPerModel",
                            "Dimensions": [
                                {"Name": "EndpointName", "Value": "my-heterog-endpoint"},
                                {"Name": "VariantName", "Value": "AllTraffic"},
                                {"Name": "InstanceType", "Value": "ml.g6.2xlarge"},
                            ],
                        },
                        "Stat": "Average",
                    },
                    "ReturnData": False,
                },
                {
                    "Id": "cr_g6e",
                    "Label": "ConcurrentRequests-g6e-2xlarge",
                    "MetricStat": {
                        "Metric": {
                            "Namespace": "AWS/SageMaker",
                            "MetricName": "ConcurrentRequestsPerModel",
                            "Dimensions": [
                                {"Name": "EndpointName", "Value": "my-heterog-endpoint"},
                                {"Name": "VariantName", "Value": "AllTraffic"},
                                {"Name": "InstanceType", "Value": "ml.g6e.2xlarge"},
                            ],
                        },
                        "Stat": "Average",
                    },
                    "ReturnData": False,
                },
                {
                    "Id": "weighted_avg",
                    "Label": "WeightedConcurrentRequests",
                    "Expression": "0.5 * cr_g6 + 0.5 * cr_g6e",
                    "ReturnData": True,
                },
            ],
        },
    },
)
            

この例では、 cr_g6と cr_g6e はper-instance-typeConcurrentRequestsPerModelメトリクスを取得します。weighted_avg 式は、それらを等しい重み (0.5 / 0.5) で結合します。重みを調整して、各インスタンスタイプのロードに対するポリシーの応答方法を変更します。

重みがスケーリング動作に与える影響: インスタンスタイプの重みが大きいほど、スケーリングポリシーはそのタイプの負荷に対してより敏感になります。低加重型の信号は減衰されるため、スケーリングイベントをトリガーする前により高い使用率で実行できます。

自動スケーリングを使用したカスタムメトリクスの詳細については、「」を参照してくださいカスタムメトリクスを定義する (CloudWatch メトリクス: CPUUtilization)。