Exécuter des modèles ML d'ensemble sur Amazon SageMaker

Le déploiement de modèles en machine learning (ML) devient de plus en plus complexe. Vous souhaitez déployer non pas un seul modèle ML, mais de grands groupes de modèles ML représentés sous forme de workflows d'ensemble. Ces flux de travail sont composés de plusieurs modèles ML. La production de ces modèles ML est un défi car vous devez respecter diverses exigences de performances et de latence.

Amazon Sage Maker prend en charge les ensembles à instance unique avec Serveur d'inférence Triton. Cette fonctionnalité vous permet d'exécuter des ensembles de modèles qui tiennent sur une seule instance. En coulisses, SageMaker exploite Triton Inference Server pour gérer l'ensemble sur chaque instance derrière le point de terminaison afin de maximiser le débit et l'utilisation du matériel avec une latence d'inférence ultra faible (à un chiffre en millisecondes). Avec Triton, vous pouvez également choisir parmi une large gamme de frameworks ML pris en charge (notamment TensorFlow, PyTorch, ONNX, XGBoost et NVIDIA TensorRT) et de backends d'infrastructure, notamment des GPU, des CPU et Inférence AWS.

Grâce à cette fonctionnalité sur SageMaker, vous pouvez optimiser vos charges de travail en évitant une latence réseau coûteuse et en profitant des avantages du calcul et de la localisation des données pour les pipelines d'inférence d'ensemble. Dans cet article, nous discutons des avantages de l'utilisation de Triton Inference Server ainsi que des considérations pour savoir s'il s'agit de la bonne option pour votre charge de travail.

Vue d'ensemble de la solution

Triton Inference Server est conçu pour permettre aux équipes de déployer, d'exécuter et de faire évoluer des modèles d'IA formés à partir de n'importe quel framework sur n'importe quelle infrastructure basée sur GPU ou CPU. De plus, il a été optimisé pour offrir une inférence hautes performances à grande échelle avec des fonctionnalités telles que le traitement par lots dynamique, les exécutions simultanées, la configuration optimale du modèle, les capacités d'ensemble de modèles et la prise en charge des entrées de streaming.

Les charges de travail doivent prendre en compte les capacités fournies par Triton pour garantir que leurs modèles peuvent être servis. Triton prend en charge un certain nombre de frameworks populaires prêts à l'emploi, notamment TensorFlow, PyTorch, ONNX, XGBoost et NVIDIA TensorRT. Triton prend également en charge divers backends qui sont nécessaires au bon fonctionnement des algorithmes. Vous devez vous assurer que vos modèles sont pris en charge par ces backends et dans le cas où ce n'est pas le cas d'un backend, Triton vous permet d'implémenter le vôtre et de l'intégrer. Vous devez également vérifier que la version de votre algorithme est prise en charge et vous assurer que les artefacts du modèle sont acceptables par le backend correspondant. Pour vérifier si votre algorithme particulier est pris en charge, reportez-vous à Backend du serveur d'inférence Triton pour une liste des backends pris en charge de manière native et gérés par NVIDIA.

Il peut y avoir certains scénarios dans lesquels vos modèles ou ensembles de modèles ne fonctionneront pas sur Triton sans nécessiter plus d'efforts, par exemple s'il n'existe pas de backend pris en charge de manière native pour votre algorithme. Il y a d'autres considérations à prendre en compte, telles que le format de charge utile peut ne pas être idéal, en particulier lorsque la taille de votre charge utile peut être importante pour votre demande. Comme toujours, vous devez valider vos performances après avoir déployé ces charges de travail pour vous assurer que vos attentes sont satisfaites.

Prenons un modèle de réseau neuronal de classification d'images et voyons comment nous pouvons accélérer nos charges de travail. Dans cet exemple, nous utilisons le backend NVIDIA DALI pour accélérer notre prétraitement dans le contexte de notre ensemble.

Créer des ensembles de modèles Triton

Triton Inference Server simplifie le déploiement de modèles d'IA à grande échelle. Triton Inference Server est livré avec une solution pratique qui simplifie la création de pipelines de prétraitement et de post-traitement. La plateforme Triton Inference Server fournit le planificateur d'ensemble, que vous pouvez utiliser pour créer des modèles d'ensemble de pipeline participant au processus d'inférence tout en garantissant l'efficacité et en optimisant le débit.

Triton Inference Server sert des modèles à partir de référentiels de modèles. Examinons la disposition du référentiel de modèles pour le modèle d'ensemble contenant le modèle de prétraitement DALI, le modèle TensorFlow Inception V3 et la configuration de l'ensemble de modèles. Chaque sous-répertoire contient les informations de référentiel pour les modèles correspondants. Le config.pbtxt Le fichier décrit la configuration du modèle pour les modèles. Chaque répertoire doit avoir un sous-dossier numérique pour chaque version du modèle et il est géré par un backend spécifique pris en charge par Triton.

NVIDIA DALI

Pour cet article, nous utilisons la bibliothèque de chargement de données NVIDIA (DALI) comme modèle de prétraitement dans notre ensemble de modèles. NVIDIA DALI est une bibliothèque de chargement et de prétraitement de données pour accélérer les applications d'apprentissage en profondeur. Il fournit une collection de blocs de construction optimisés pour le chargement et le traitement des données d'image, vidéo et audio. Vous pouvez l'utiliser comme remplacement portable pour les chargeurs de données et les itérateurs de données intégrés dans les frameworks d'apprentissage en profondeur populaires.

Le code suivant montre la configuration du modèle pour un backend DALI :

name: "dali"
backend: "dali"
max_batch_size: 256
input [
  {
    name: "DALI_INPUT_0"
    data_type: TYPE_UINT8
    dims: [ -1 ]
  }
]
output [
  {
    name: "DALI_OUTPUT_0"
    data_type: TYPE_FP32
    dims: [ 299, 299, 3 ]
  }
]
parameters: [
  {
    key: "num_threads"
    value: { string_value: "12" }
  }
]

Modèle de création V3

Pour cet article, nous montrons comment DALI est utilisé dans un ensemble de modèles avec Inception V3. Le modèle pré-entraîné Inception V3 TensorFlow est enregistré au format GraphDef en tant que fichier unique nommé model.graphdefL’ config.pbtxt Le fichier contient des informations sur le nom du modèle, la plate-forme, max_batch_sizeet les contrats d'entrée et de sortie. Nous vous recommandons de définir le max_batch_size configuration à une taille inférieure à la taille du lot du modèle Inception V3. Le fichier d'étiquettes contient des étiquettes de classe pour 1,000 XNUMX classes différentes. Nous copions les étiquettes du modèle de classification initiale dans le inception_graphdef répertoire dans le référentiel de modèles. Le fichier d'étiquettes contient 1,000 XNUMX étiquettes de classe du ImageNet ensemble de données de classification.

name: "inception_graphdef"
platform: "tensorflow_graphdef"
max_batch_size: 256
input [
  {
    name: "input"
    data_type: TYPE_FP32
    format: FORMAT_NHWC
    dims: [ 299, 299, 3 ]
  }
]
output [
  {
    name: "InceptionV3/Predictions/Softmax"
    data_type: TYPE_FP32
    dims: [ 1001 ]
    label_filename: "inception_labels.txt"
  }
]

Ensemble Triton

Le code suivant montre une configuration de modèle d'un modèle d'ensemble pour le prétraitement DALI et la classification d'images :

name: "ensemble_dali_inception"
platform: "ensemble"
max_batch_size: 256
input [
  {
    name: "INPUT"
    data_type: TYPE_UINT8
    dims: [ -1 ]
  }
]
output [
  {
    name: "OUTPUT"
    data_type: TYPE_FP32
    dims: [ 1001 ]
  }
]
ensemble_scheduling {
  step [
    {
      model_name: "dali"
      model_version: -1
      input_map {
        key: "DALI_INPUT_0"
        value: "INPUT"
      }
      output_map {
        key: "DALI_OUTPUT_0"
        value: "preprocessed_image"
      }
    },
    {
      model_name: "inception_graphdef"
      model_version: -1
      input_map {
        key: "input"
        value: "preprocessed_image"
      }
      output_map {
        key: "InceptionV3/Predictions/Softmax"
        value: "OUTPUT"
      }
    }
  ]
}

Créer un point de terminaison SageMaker

Points de terminaison SageMaker permettre un hébergement en temps réel où un temps de réponse d'une milliseconde est requis. SageMaker assume le gros du travail indifférencié de la gestion de l'hébergement de modèles et a la capacité d'évoluer automatiquement. De plus, un certain nombre de fonctionnalités sont également fournies, notamment l'hébergement de plusieurs variantes de votre modèle, les tests A/B de vos modèles, l'intégration avec Amazon Cloud Watch pour obtenir l'observabilité des performances du modèle et la surveillance de la dérive du modèle.

Créons un modèle SageMaker à partir des artefacts de modèle que nous avons téléchargés Service de stockage simple Amazon (Amazon S3).

Ensuite, nous fournissons également une variable d'environnement supplémentaire : SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, qui spécifie le nom du modèle à charger par Triton. La valeur de cette clé doit correspondre au nom du dossier dans le package de modèle téléchargé sur Amazon S3. Cette variable est facultative dans les cas où vous utilisez un seul modèle. Dans le cas de modèles d'ensemble, cette clé doit être spécifiée pour que Triton démarre dans SageMaker.

De plus, vous pouvez définir SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT ainsi que SAGEMAKER_TRITON_THREAD_COUNT pour optimiser le nombre de threads.

container = {
    "Image": triton_image_uri,
    "ModelDataUrl": model_uri,
    "Environment": {"SAGEMAKER_TRITON_DEFAULT_MODEL_NAME": "ensemble_dali_inception"},
}
create_model_response = sm_client.create_model(
    ModelName=sm_model_name, ExecutionRoleArn=role, PrimaryContainer=container
)

Avec le modèle précédent, nous créons une configuration de point de terminaison dans laquelle nous pouvons spécifier le type et le nombre d'instances que nous voulons dans le point de terminaison :

create_endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "InstanceType": instance_type,
            "InitialVariantWeight": 1,
            "InitialInstanceCount": 1,
            "ModelName": sm_model_name,
            "VariantName": "AllTraffic",
        }
    ],
)
endpoint_config_arn = create_endpoint_config_response["EndpointConfigArn"]

Nous utilisons cette configuration de point de terminaison pour créer un nouveau point de terminaison SageMaker et attendons la fin du déploiement. Le statut passe à InService lorsque le déploiement réussit.

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name
)
endpoint_arn = create_endpoint_response["EndpointArn"]

Charge utile d'inférence

L'image de charge utile d'entrée passe par le pipeline de prétraitement DALI et est utilisée dans le planificateur d'ensemble fourni par Triton Inference Server. Nous construisons la charge utile à transmettre au point de terminaison d'inférence :

payload = {
    "inputs": [
        {
            "name": "INPUT",
            "shape": rv2.shape,
            "datatype": "UINT8",
            "data": rv2.tolist(),
        }
    ]
}

Inférence d'ensemble

Lorsque le point de terminaison est en cours d'exécution, nous pouvons utiliser l'exemple d'image pour effectuer une demande d'inférence en utilisant JSON comme format de charge utile. Pour le format de demande d'inférence, Triton utilise les protocoles d'inférence standard de la communauté KFServing.

response = runtime_sm_client.invoke_endpoint(
    EndpointName=endpoint_name, ContentType="application/octet-stream", Body=json.dumps(payload)
)
print(json.loads(response["Body"].read().decode("utf8")))

Avec la binary+json format, nous devons spécifier la longueur des métadonnées de la requête dans l'en-tête pour permettre à Triton d'analyser correctement la charge utile binaire. Cela se fait à l'aide d'un en-tête Content-Type personnalisé application/vnd.sagemaker-triton.binary+json;json-header-size={}.

Ceci est différent de l'utilisation d'un Inference-Header-Content-Length en-tête sur un serveur Triton autonome, car les en-têtes personnalisés ne sont pas autorisés dans SageMaker.

Le package tritonclient fournit des méthodes utilitaires pour générer la charge utile sans avoir à connaître les détails de la spécification. Nous utilisons les méthodes suivantes pour convertir notre demande d'inférence au format binaire, ce qui offre des latences d'inférence plus faibles. Référez-vous au GitHub cahier pour les détails de mise en œuvre.

response = runtime_sm_client.invoke_endpoint(
    EndpointName=endpoint_name,
    ContentType="application/vnd.sagemaker-triton.binary+json;json-header-size={}".format(
        header_length
    ),
    Body=request_body,
)

Conclusion

Dans cet article, nous avons montré comment produire des ensembles de modèles qui s'exécutent sur une seule instance sur SageMaker. Ce modèle de conception peut être utile pour combiner toute logique de prétraitement et de post-traitement avec des prédictions d'inférence. SageMaker utilise Triton pour exécuter l'inférence d'ensemble sur un seul conteneur sur une instance prenant en charge tous les principaux frameworks.

Pour plus d'échantillons sur les ensembles Triton sur SageMaker, reportez-vous au GitHub repo. Essaye le!

À propos des auteurs

James Park est architecte de solutions chez Amazon Web Services. Il travaille avec Amazon.com pour concevoir, créer et déployer des solutions technologiques sur AWS, et s'intéresse particulièrement à l'IA et à l'apprentissage automatique. Dans ses temps libres, il aime découvrir de nouvelles cultures, de nouvelles expériences et se tenir au courant des dernières tendances technologiques.

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 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.