Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Déployez sur plusieurs types d'instances avec des pools d'instances

Lorsque vous déployez un modèle sur un point de terminaison d' SageMaker IA, vous spécifiez généralement un type d'instance unique pour la variante de production. Si ce type d'instance n'est pas disponible dans la zone de disponibilité cible, le déploiement échoue avec une erreur de capacité insuffisante (ICE) et vous devez réessayer manuellement avec un autre type d'instance.

Avec les pools d'instances, vous pouvez spécifier une liste ordonnée de cinq types d'instances maximum pour une variante de production. SageMaker L'IA tente de provisionner les instances en commençant par le type de priorité le plus élevé (priorité 1) et revient automatiquement aux types de priorité inférieure lorsque la capacité n'est pas disponible. Cela élimine le besoin de réessayer manuellement et améliore la disponibilité des terminaux.

Les pools d'instances prennent en charge les points de terminaison d'inférence asynchrones et en temps réel. Vous pouvez les utiliser avec des points de terminaison à modèle unique et avec des composants d'inférence.

Les étapes suivantes décrivent le fonctionnement du provisionnement du pool d'instances :

Configuration d'un point de terminaison avec des pools d'instances

Pour utiliser des pools d'instances, vous remplacez le InstanceType paramètre de votre variante de production par une InstancePools liste. Chaque entrée spécifie un type d'instance et une priorité (1 à 5, 1 étant la plus élevée). Vous pouvez éventuellement définir VariantInstanceProvisionTimeoutInSeconds (300 à 3 600 secondes) pour contrôler le temps total que l' SageMaker IA passe à essayer de provisionner des instances dans tous les pools avant l'échec de l'opération.

Real-time point de terminaison avec un modèle unique

L'exemple suivant crée une configuration de point de terminaison avec deux pools d'instances. Si ml.g6.2xlarge les instances ne sont pas disponibles, l' SageMaker IA revient à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,
)
            

Vous pouvez également utiliser le ModelNameOverride paramètre de chaque pool pour spécifier un modèle différent optimisé pour ce type d'instance. Par exemple, vous pouvez déployer un modèle compilé pour le GPU sur un type d'instance et une version non compilée sur un autre.

Real-time point de terminaison avec composants d'inférence

Lorsque vous utilisez des composants d'inférence avec des pools d'instances, deux options s'offrent à vous pour définir les spécifications :

L'exemple suivant crée un composant d'inférence avec des spécifications de type par instance :

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,
    },
)
            

Surveiller les pools d'instances

Les CloudWatch métriques existantes qui sont agrégées sur toutes les instances dans une varianteInvocations, telles queModelLatency, etCPUUtilization, continuent de fonctionner de la même manière lorsque vous utilisez des pools d'instances. En outre, CloudWatch publie ces métriques avec une InstanceType dimension afin que vous puissiez surveiller les performances de chaque type d'instance séparément.

Per-instance-type métriques

Lorsqu'une variante de production utilise des pools d'instances, les combinaisons de dimensions suivantes sont disponibles CloudWatch pour la surveillance par type d'instance :

Ces dimensions sont disponibles à la fois pour les CloudWatch métriques standard et les métriques améliorées. Pour la liste complète des mesures disponibles, consultez Métriques Amazon SageMaker AI sur Amazon CloudWatch etMesures améliorées d'Amazon SageMaker AI pour les points de terminaison d'inférence.

Vérifiez la répartition de la flotte

Pour connaître le nombre actuel d'instances pour chaque pool, appelez l'DescribeEndpointAPI. La ProductionVariants réponse inclut une InstancePools liste avec le nombre actuel pour chaque type d'instance. Cela montre la composition de votre flotte après le provisionnement, y compris les instances de secours provenant de pools de priorité inférieure.

Si vous utilisez des composants d'inférence, la DescribeInferenceComponentréponse inclut un PlacementStatus champ dans le résumé de la configuration d'exécution qui indique le nombre de copies par type d'instance. Utilisez-le pour comprendre comment les copies des composants d'inférence sont distribuées entre les types d'instances de votre parc.

Auto-scaling avec des pools d'instances

Auto-scaling avec des pools d'instances suit le même processus que l'auto-scaling standard des points de terminaison. Vous enregistrez des cibles évolutives, vous définissez des politiques de dimensionnement et vous les appliquez à votre point de terminaison. Pour la configuration générale de l'auto-scaling, voir. Mise à l'échelle automatique des modèles Amazon SageMaker AI

La principale différence réside dans la manière dont SageMaker l'IA approvisionne et libère les instances lorsqu'un événement de dimensionnement se déclenche :

Utiliser des métriques de dimensionnement prédéfinies

Des mesures de dimensionnement prédéfinies, telles que le SageMakerVariantInvocationsPerInstance fait de continuer à fonctionner avec des pools d'instances. Ces métriques sont agrégées pour tous les types d'instances de la variante, de sorte que le comportement de dimensionnement est le même que celui d'un point de terminaison standard. Il s'agit de l'approche la plus simple lorsque tous les types d'instances de vos pools ont une capacité similaire.

Pour le suivi des cibles et la configuration de la politique de dimensionnement par étapes, voirMise à l'échelle automatique des modèles Amazon SageMaker AI.

Utiliser des mesures personnalisées pondérées pour les flottes mixtes

Lorsque vos pools d'instances contiennent des types d'instances dotés de capacités de calcul différentes, vous pouvez utiliser les mathématiques CloudWatch métriques pour créer un signal de mise à l'échelle pondéré. Cela vous permet de contrôler dans quelle mesure la charge de chaque type d'instance contribue à la décision globale de dimensionnement.

L'exemple suivant crée une politique de suivi des cibles qui utilise une moyenne pondérée ConcurrentRequestsPerModel entre deux types d'instances. Les pondérations déterminent le degré de sensibilité de la politique de dimensionnement à la charge de chaque type :

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,
                },
            ],
        },
    },
)
            

Dans cet exemple, cr_g6 cr_g6e récupérez la métrique par type d'instanceConcurrentRequestsPerModel. L'weighted_avgexpression les combine avec des poids égaux (0,5/0,5). Ajustez les pondérations pour modifier la façon dont la politique répond à la charge sur chaque type d'instance.

Comment les pondérations affectent le comportement de mise à l'échelle : une pondération plus élevée sur un type d'instance signifie que la politique de dimensionnement est plus sensible à la charge de ce type, et non pas moins. Le signal du type le moins pondéré est atténué, de sorte qu'il peut fonctionner à une utilisation plus élevée avant de déclencher un événement de mise à l'échelle.

Pour plus d'informations sur les métriques personnalisées avec auto-scaling, consultez. Définissez une métrique personnalisée (CloudWatch métrique : CPUUtilization)