Utilisation de votre propre code d'inférence avec une transformation par lots

Cette section explique comment Amazon SageMaker interagit avec un conteneur Docker qui exécute votre propre code d'inférence pour la transformation par lots. Utilisez ces informations pour écrire du code d'inférence et créer une image Docker.

Exécution de votre image d'inférence par SageMaker

Pour configurer un conteneur et utiliser celui-ci en tant qu'exécutable, utilisez une instruction dans un Dockerfile.ENTRYPOINT Notez ce qui suit :

• Pour les transformations par lots, SageMaker invoque le modèle en votre nom. SageMaker exécute le conteneur comme suit :

  docker run image serve

  L'entrée des transformations par lots doit être d'un format qui peut être divisé en fichiers plus petits à traiter en parallèle. Ces formats incluent CSV, JSON, JSON Lines, TFRecord et RecordIO.

  SageMaker remplace les instructions CMD par défaut dans un conteneur en spécifiant l'argument serve après le nom de l'image. L'argument serve remplace les arguments fournis avec la commande CMD dans le Dockerfile.

   

• Nous vous recommandons d'utiliser le formulaire exec de l'instruction ENTRYPOINT :

  ENTRYPOINT ["executable", "param1", "param2"]

  Par exemple :

  ENTRYPOINT ["python", "k_means_inference.py"]

   

• SageMaker définit les variables d'environnement spécifiées dans CreateModel et CreateTransformJob sur votre conteneur. En outre, les variables d'environnement suivantes sont renseignées :

  • SAGEMAKER_BATCH est défini sur true quand le conteneur exécute des transformations par lots.

  • SAGEMAKER_MAX_PAYLOAD_IN_MB est défini sur la charge utile la plus volumineuse envoyée au conteneur via HTTP.

  • SAGEMAKER_BATCH_STRATEGY est défini sur SINGLE_RECORD lorsque le conteneur reçoit un seul enregistrement par appel à des invocations et sur MULTI_RECORD lorsque le conteneur reçoit autant d'enregistrements que possible tenant dans la charge utile.

  • SAGEMAKER_MAX_CONCURRENT_TRANSFORMS est défini sur le nombre maximal de demandes /invocations pouvant être ouvertes simultanément.

  Note

  Les trois dernières variables d'environnement proviennent de l'appel de l'API effectué par l'utilisateur. Si l'utilisateur ne définit pas de valeurs pour ces variables, elles ne sont pas transmises. Dans ce cas, les valeurs par défaut ou les valeurs demandées par l'algorithme (en réponse à /execution-parameters) sont utilisées.

• Si vous prévoyez d'utiliser des appareils GPU pour les inférences de modèle (en spécifiant des instances de calcul ML basées sur des GPU dans votre demande CreateTransformJob), assurez-vous que vos conteneurs sont compatibles avec nvidia-docker. Ne regroupez pas des pilotes NVIDIA avec l'image. Pour plus d'informations sur nvidia-docker, consultez NVIDIA/nvidia-docker.

   

• Vous ne pouvez pas utiliser l'initialiseur init comme point d'entrée dans des conteneurs SageMaker, car les arguments train et serve le perturbent.

Chargement de vos artefacts de modèle par SageMaker

Dans une requête CreateModel, les définitions de conteneur comprennent le paramètre ModelDataUrl qui identifie l'emplacement où les artefacts de modèle sont stockés dans Amazon S3. Lorsque vous utilisez SageMaker pour exécuter des inférences, il utilise ces informations pour déterminer où copier les artéfacts de modèle. Il copie les artefacts dans le répertoire /opt/ml/model du conteneur Docker afin qu'ils soient utilisés par votre code d'inférence.

Le paramètre ModelDataUrl doit pointer vers un fichier tar.gz. Sinon, SageMaker ne télécharge pas le fichier. Si vous entraînez un modèle dans SageMaker, il enregistre les artefacts sous la forme d'un fichier .tar compressé unique dans Amazon S3. Si vous entraînez un modèle dans un autre cadre, vous devez stocker les artefacts de modèle dans Amazon S3 sous la forme d'un fichier .tar compressé. SageMaker décompresse ce fichier .tar et l'enregistre dans le répertoire /opt/ml/model du conteneur avant que la tâche de transformation par lots ne démarre.

Comment les conteneurs répondent-ils aux requêtes ?

Les conteneurs doivent mettre en œuvre un serveur web qui répond aux appels et aux requêtes ping sur le port 8080. Pour les transformations par lots, vous avez la possibilité de définir des algorithmes pour mettre en œuvre les requêtes de paramètres d'exécution afin de fournir une configuration d'exécution dynamique pour SageMaker. SageMaker utilise les points de terminaison suivants :

• ping : permet de vérifier périodiquement l'état du conteneur. SageMaker attend un code d'état 200 HTTP et un corps vide pour qu'une requête ping réussisse avant d'envoyer une requête d'invocations. Vous pouvez utiliser une requête ping pour charger un modèle dans la mémoire pour générer l'inférence lorsque les requêtes d'appels sont envoyées.

• (Facultatif) execution-parameters : autorise l'algorithme à fournir les paramètres de réglage optimaux pour une tâche lors de l'exécution. En fonction de la mémoire et des processeurs disponibles pour un conteneur, l'algorithme choisit les valeurs MaxConcurrentTransforms, BatchStrategy et MaxPayloadInMBpour la tâche.

Avant d'appeler la requête d'invocations, SageMaker tente d'appeler la requête de paramètres d'exécution. Lorsque vous créez une tâche de transformation par lots, vous pouvez fournir des valeurs pour les paramètres MaxConcurrentTransforms, BatchStrategy et MaxPayloadInMB. SageMaker détermine les valeurs de ces paramètres selon l'ordre de priorité suivant :

1. Les valeurs des paramètres que vous fournissez lorsque vous créez la requête CreateTransformJob.

2. Les valeurs que le conteneur de modèle renvoie lorsque SageMaker appelle le point de terminaison des paramètres d'exécution>

3. Les valeurs des paramètres par défaut répertoriées dans le tableau suivant.

   Paramètre	Valeurs par défaut
   MaxConcurrentTransforms	1
   BatchStrategy	MULTI_RECORD
   MaxPayloadInMB	6

La réponse pour une requête de paramètres d'exécution GET est un objet JSON avec des clés pour les paramètres MaxConcurrentTransforms, BatchStrategy et MaxPayloadInMB. Voici un exemple de réponse valide :

{
“MaxConcurrentTransforms”: 8,
“BatchStrategy": "MULTI_RECORD",
"MaxPayloadInMB": 6
}

Comment votre conteneur doit-il répondre aux requêtes d'inférence ?

Pour obtenir des inférences, Amazon SageMaker envoie une requête POST au conteneur d'inférences. Le corps de la requête POST contient des données provenant d'Amazon S3. Amazon SageMaker transmet la requête au conteneur et renvoie le résultat de l'inférence à partir du conteneur, en enregistrant les données de la réponse dans Amazon S3.

Pour recevoir des demandes d'inférence, le conteneur doit avoir un serveur web à l'écoute sur le port 8080 et doit accepter les demandes POST envoyées au point de terminaison /invocations. Le délai d'expiration des demandes d'inférence et le nombre maximal de nouvelles tentatives peuvent être configurés via ModelClientConfig.

Comment votre conteneur doit-il répondre aux requêtes de surveillance de l'état (Ping) ?

L'exigence la plus simple concernant le conteneur consiste à répondre avec un code d'état HTTP 200 et un corps vide. Cela indique à SageMaker que le conteneur est prêt à accepter des requêtes d'inférence au niveau du point de terminaison /invocations.

Bien que l'exigence minimale pour le conteneur soit de renvoyer un statique 200, un développeur de conteneur peut utiliser cette fonctionnalité pour effectuer des vérifications plus approfondies. Le délai d'attente des requêtes est de 2 secondes./ping