Inférence ML rentable avec des modèles multi-framework sur Amazon SageMaker 

L’apprentissage automatique (ML) s’est avéré être l’une des applications technologiques les plus réussies et les plus répandues, affectant un large éventail d’industries et touchant des milliards d’utilisateurs chaque jour. Avec cette adoption rapide du ML dans tous les secteurs, les entreprises sont confrontées à des défis pour prendre en charge des prévisions à faible latence et avec une haute disponibilité tout en maximisant l'utilisation des ressources et en réduisant les coûts associés. Étant donné que chaque framework ML a ses propres dépendances et que les étapes de déploiement pour chaque framework sont différentes, le déploiement de modèles construits dans différents frameworks en production et la gestion de chacun des points de terminaison deviennent de plus en plus complexes.

Amazon Sage Maker les points de terminaison multi-conteneurs (MCE) nous permettent de regrouper des modèles sur différents frameworks et de les déployer sur le même hôte, créant ainsi un seul point de terminaison. Vous pouvez fournir des conteneurs pour les différents frameworks que vous utilisez pour créer les modèles, et SageMaker prend tous ces conteneurs et les place derrière un seul point de terminaison. Par exemple, vous pouvez avoir un modèle PyTorch et TensorFlow chargés sur deux points de terminaison dédiés servant des cas d'utilisation identiques ou totalement différents, et ces deux modèles ont un trafic entrant intermittent n'utilisant pas les ressources à leur limite. Dans un tel scénario, vous pouvez les regrouper à l'aide de conteneurs dans un seul point de terminaison à l'aide d'un MCE, améliorant ainsi l'utilisation des ressources tout en réduisant les coûts liés à la diffusion des deux modèles à partir de différents points de terminaison.

Les points de terminaison multi-conteneurs fournissent une solution évolutive et rentable pour déployer jusqu'à 15 modèles construits sur différents frameworks ML, serveurs de modèles et algorithmes servant le même cas d'utilisation ou différents, ce qui signifie que vous pouvez avoir des modèles construits sur divers frameworks ML ou intermédiaires. étapes dans tous ces conteneurs et modèles. Tous ces modèles sont accessibles individuellement via une invocation directe ou intégrés dans un pipeline à l'aide d'une invocation en série, où la sortie d'un modèle est l'entrée du suivant.

Dans cet article, nous expliquons comment effectuer une inférence ML rentable avec des modèles multi-framework sur SageMaker.

Modèles d'appel MCE

L'invocation directe de SageMaker MCE est utile dans les cas où vous avez regroupé des modèles non liés dans un point de terminaison MCE ou si vous exécutez un test A/B entre les modèles derrière un point de terminaison MCE pour évaluer leurs performances. Vous pouvez appeler le conteneur spécifique directement dans l'appel d'API et obtenir la prédiction de ce modèle.

Avec l'invocation en série, vous pouvez assembler 2 à 15 conteneurs, et la sortie de l'un devient l'entrée du conteneur suivant dans la séquence. Il s'agit d'un cas d'utilisation idéal si, par exemple, vous disposez d'un pipeline de prédiction en plusieurs étapes dans lequel un modèle Scikit-learn est utilisé pour une prédiction intermédiaire et le résultat est transmis à un modèle TensorFlow pour l'inférence finale. Au lieu de les déployer en tant que points de terminaison différents et qu'une autre application ou tâche les orchestre et effectue plusieurs appels d'API, vous pouvez les déployer en tant que SageMaker MCE, en faisant abstraction de la logique et en les configurant pour un appel en série, où SageMaker gère le transfert de données entre un conteneur. à un autre automatiquement et émet la sortie du conteneur final au client effectuant la requête API.

L'invocation série SageMaker MCE est fondamentalement différente d'un pipeline d'inférence série SageMaker (plus de détails dans les sections ci-dessous). Un pipeline d'inférence série est davantage destiné à orchestrer des flux de travail de ML complexes tels que le prétraitement des données, la création d'un ensemble de modèles, la mise en œuvre de vérifications conditionnelles pour déterminer le modèle à invoquer ou le post-traitement de la prédiction, impliquant une logique métier avant que la prédiction ne soit envoyée aux applications en aval. . En revanche, l’invocation en série MCE est conçue pour assembler 2 à 14 modèles dans un pipeline à des fins d’inférence, chaque modèle prenant en entrée la prédiction du modèle précédent.

Tous les conteneurs d'un MCE sont toujours en service et en mémoire, il n'y a donc pas de démarrage à froid lors de l'appel du point de terminaison. Les MCE améliorent également l'utilisation des points de terminaison et réduisent les coûts, car les modèles sont déployés derrière un point de terminaison et partagent l'instance de calcul sous-jacente, au lieu que chaque modèle n'occupe des ressources de calcul individuelles.

Examinons quelques cas d'utilisation et voyons comment vous pouvez utiliser les MCE SageMaker pour optimiser l'inférence ML.

Cas d'utilisation des MCE SageMaker

Supposons que vous disposiez de deux modèles de classification des sentiments, un pour la langue anglaise et un autre pour la langue allemande, et que ces modèles desservent différentes zones géographiques avec un trafic arrivant à différents moments de la journée. Au lieu d'avoir deux points de terminaison fonctionnant 24h/7 et XNUMXj/XNUMX, vous pouvez les déployer tous les deux sur un seul point de terminaison à l'aide d'un MCE et y accéder via un appel direct, optimisant ainsi l'utilisation de vos ressources et vos coûts. Voir le code suivant :

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

Dans cet exemple, nous avons deux modèles (englishModel ainsi que le germanModel), et nous définissons les conteneurs dans le SageMaker create_model construire et définir le InferenceExecutionConfig comme « Direct ». Nous pouvons maintenant appeler le point final pour l'inférence et définir le TargetContainerHostname soit englishModel or germanModel en fonction du client effectuant l'appel API :

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

Vous pouvez également utiliser l'invocation directe au sein du MCE pour exécuter des tests A/B afin de comparer les performances entre les modèles.

Le diagramme suivant illustre notre architecture.

De même, dans d'autres cas d'utilisation du ML, lorsque le modèle entraîné est utilisé pour traiter une requête, le modèle reçoit des données dans un format qui doit être prétraité (par exemple, présenté) avant de pouvoir être transmis à l'algorithme pour inférence. Lorsque les algorithmes ML sont enchaînés, la sortie d’un modèle sert d’entrée au suivant avant d’atteindre le résultat final. Dans ce cas, vous pouvez créer un pipeline série SageMaker MCE, dans lequel les conteneurs communiquent entre eux dans l'ordre défini dans le create_model construisez au lieu de déployer chacun des modèles dans différents points de terminaison et d'écrire une logique indépendante pour faciliter le flux de données entre tous ces modèles et appels d'API. Le diagramme suivant illustre cette architecture.

Pour ce cas d'utilisation, nous utilisons le code suivant :

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

Dans cet exemple, nous avons deux conteneurs de traitement (Processing-1 ainsi que le Processing-2) pour le traitement des fonctionnalités et les transformations de données, et deux conteneurs d'inférence (Inference-1 ainsi que le Inference-2) pour exécuter des prédictions de modèle ML sur les données prétraitées. Le PipelineModel L'instance vous permet de définir le pipeline d'inférence composé d'une séquence linéaire de quatre conteneurs qui traitent les demandes d'inférence sur les données. Les conteneurs sont colocalisés sur la même instance, ce qui vous permet d'exécuter des inférences avec une faible latence.

Mettre à l'échelle des points de terminaison multimodèles pour un grand nombre de modèles

Les avantages des points de terminaison multimodèles SageMaker augmentent en fonction de l'échelle de consolidation des modèles. Vous pouvez constater des économies en hébergeant deux modèles avec un seul point de terminaison, et pour les cas d’utilisation comportant des centaines ou des milliers de modèles, les économies sont bien plus importantes.

La mise à l'échelle des points de terminaison MCE est également simple à l'aide de l'outil SageMakerVariantInvocationsPerInstance métrique prédéfinie, qui donne le nombre moyen de fois par minute où chaque instance d'un point de terminaison de modèle est invoquée pour définir un TargetScaling politique. SageMaker ajuste dynamiquement le nombre d'instances provisionnées pour un modèle en réponse aux changements de votre charge de travail. Lorsque la charge de travail augmente, la mise à l'échelle automatique met davantage d'instances en ligne et se charge avec les modèles et conteneurs cibles pour continuer à répondre aux demandes. Lorsque la charge de travail diminue, la mise à l'échelle automatique supprime les instances inutiles et décharge les conteneurs de modèles afin que ceux-ci ne consomment pas de ressources et que vous ne payiez pas pour les instances que vous n'utilisez pas. Le temps nécessaire pour terminer la première requête sur un modèle donné subit une latence supplémentaire (appelée démarrage à froid) pour télécharger le modèle à partir de Service de stockage simple Amazon (Amazon S3) et chargez-le en mémoire. Les appels suivants se terminent sans surcharge supplémentaire car le modèle est déjà chargé. Voir le code suivant :

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Suite à l'exemple de configuration de stratégie précédent, nous utilisons le SageMakerVariantInvocationsPerInstance métrique prédéfinie pour ajuster le nombre d'instances de variantes afin que chaque instance ait une InvocationsPerInstance métrique de 70.

Nous pouvons également faire évoluer les MCE SageMaker en fonction de nos propres métriques personnalisées, telles que CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationou DiskUtilization, pour augmenter ou réduire le nombre d'instances en fonction de l'utilisation d'une ressource spécifique. Pour plus d'informations, reportez-vous à Mise à l'échelle automatique des modèles Amazon SageMaker.

Il est recommandé que le modèle de chaque conteneur présente des exigences de calcul et de latence similaires pour chaque demande d'inférence, car si le trafic vers le MCE passe d'un modèle à utilisation élevée du processeur à un modèle à faible utilisation du processeur, mais que le volume global d'appels reste le même, le point de terminaison n'évolue pas et il se peut qu'il n'y ait pas suffisamment d'instances pour gérer toutes les requêtes adressées au modèle à utilisation élevée du processeur.

MCE sécurisés

Pour les MCE avec appel direct, plusieurs conteneurs sont hébergés dans une seule instance en partageant la mémoire et un volume de stockage. Il est important de sécuriser les conteneurs, de maintenir le mappage correct des requêtes vers les conteneurs cibles et de fournir aux utilisateurs un accès correct aux conteneurs cibles. Vous pouvez restreindre invoke_endpoint accès à un ensemble limité de conteneurs à l’intérieur d’un MCE en utilisant le sagemaker:TargetContainerHostname Gestion des identités et des accès AWS (IAM) clé de condition. SageMaker utilise Rôles IAM pour fournir des stratégies basées sur l'identité IAM que vous utilisez pour spécifier les actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Les stratégies suivantes montrent comment limiter les appels à des conteneurs spécifiques au sein d'un point de terminaison :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Surveillez les points de terminaison multimodèles à l'aide des métriques Amazon CloudWatch

Pour faire des compromis en termes de prix et de performances, vous souhaiterez tester des points de terminaison multimodèles avec des modèles et un trafic représentatif de votre propre application. SageMaker fournit des métriques supplémentaires dans Amazon Cloud Watch pour les points de terminaison multimodèles afin que vous puissiez déterminer l'utilisation du point de terminaison et le taux de réussite du cache et optimiser votre point de terminaison. Les métriques sont les suivantes :

• ModèleLoadingWaitTime – L'intervalle de temps pendant lequel une demande d'appel attend que le modèle cible soit téléchargé ou chargé pour effectuer l'inférence.
• ModèleUnloadingTime – L'intervalle de temps nécessaire pour décharger le modèle via le conteneur UnloadModel Appel API.
• ModèleDownloadingTime – L'intervalle de temps nécessaire pour télécharger le modèle depuis Amazon S3.
• Temps de chargement du modèle – L'intervalle de temps nécessaire pour charger le modèle via le conteneur LoadModel Appel API.
• ModèleCacheHit - Le nombre de InvokeEndpoint requêtes envoyées au point de terminaison où le modèle était déjà chargé. Prenant le Average la statistique montre le ratio de requêtes dans lesquelles le modèle a déjà été chargé.
• LoadedModelCountLoadedModelCount – Le nombre de modèles chargés dans les conteneurs du point final. Cette métrique est émise par instance. Le Average statistique d'une période de 1 minute vous indique le nombre moyen de modèles chargés par instance, et le Sum La statistique vous indique le nombre total de modèles chargés sur toutes les instances du point de terminaison. Les modèles suivis par cette métrique ne sont pas nécessairement uniques, car vous pouvez charger un modèle dans plusieurs conteneurs dans le point de terminaison.

Il existe également plusieurs autres métriques utilisées par chaque conteneur exécuté sur une instance, telles que Invocations indiquant le nombre de InvokeEndpoint requêtes envoyées à un conteneur à l’intérieur d’un point de terminaison, ContainerLatency donner le temps qu'un point de terminaison a mis pour que le conteneur cible ou tous les conteneurs d'un appel en série répondent tel qu'il est vu depuis SageMaker, et CPUUtilization ainsi que le MemoryUtilizaton indiquant les unités CPU et le pourcentage de mémoire.

Conclusion

Dans cet article, nous avons expliqué comment les points de terminaison multi-conteneurs SageMaker peuvent être utiles pour optimiser les coûts et l'utilisation des ressources. Les exemples d'utilisation des MCE incluent, sans s'y limiter, les éléments suivants :

• Modèles d'hébergement sur différents frameworks (tels que TensorFlow, PyTorch et Scikit-learn) qui n'ont pas suffisamment de trafic pour saturer la pleine capacité d'une instance
• Hébergement de modèles à partir du même cadre avec différents algorithmes ML (tels que des recommandations, des prévisions ou une classification) et des fonctions de gestionnaire
• Comparaisons d'architectures similaires exécutées sur différentes versions de framework (telles que TensorFlow 1.x et TensorFlow 2.x) pour des scénarios tels que les tests A/B

Les MCE SageMaker prennent en charge le déploiement de jusqu'à 15 conteneurs sur des points de terminaison en temps réel et leur appel indépendant pour une inférence à faible latence et des économies de coûts. Les modèles peuvent être complètement hétérogènes, avec leur propre pile de portions indépendante. Vous pouvez appeler ces conteneurs de manière séquentielle ou indépendante pour chaque requête. L'hébergement sécurisé de plusieurs modèles, à partir de différents frameworks, sur une seule instance peut vous faire économiser jusqu'à 90 % par rapport à l'hébergement de modèles dans des points de terminaison dédiés à instance unique.

À propos des auteurs

Dhawal Patel est architecte principal en apprentissage machine chez AWS. Il a travaillé avec des organisations allant des grandes entreprises aux startups de taille moyenne sur des problèmes liés à l'informatique distribuée et à l'intelligence artificielle. Il se concentre sur l'apprentissage en profondeur, y compris les domaines de la PNL et de la vision par ordinateur. Il aide les clients à obtenir une inférence de modèle hautes performances sur Amazon SageMaker.

Vikram Elango est un architecte senior de solutions spécialisé en IA/ML chez Amazon Web Services, basé en Virginie, aux États-Unis. Vikram aide les clients mondiaux du secteur de la finance et de l'assurance en matière de conception et de leadership éclairé pour créer et déployer des applications d'apprentissage automatique à grande échelle. Il se concentre actuellement sur le traitement du langage naturel, l'IA responsable, l'optimisation des inférences et la mise à l'échelle du ML dans l'ensemble de l'entreprise. Dans ses temps libres, il aime voyager, faire de la randonnée, cuisiner et camper avec sa famille.

Saurabh Trikandé est chef de produit senior pour Amazon SageMaker Inference. Il est passionné par le travail avec les clients et est motivé par l'objectif de démocratiser l'apprentissage automatique. Il se concentre sur les principaux défis liés au déploiement d'applications ML complexes, de modèles ML multi-locataires, d'optimisations de coûts et de rendre le déploiement de modèles d'apprentissage en profondeur plus accessible. Dans ses temps libres, Saurabh aime faire de la randonnée, découvrir des technologies innovantes, suivre TechCrunch et passer du temps avec sa famille.