Code d'inférence personnalisé avec Batch Transform - Amazon SageMaker

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.

Code d'inférence personnalisé avec Batch Transform

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.

Comment SageMaker fonctionne votre image d'inférence

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, JSONLines TFRecordet RecorDio.

    SageMaker remplace les CMD instructions par défaut dans un conteneur en spécifiant l'serveargument 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 CreateModelet CreateTransformJobsur 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_MBest défini sur la plus grande charge utile envoyée au conteneur viaHTTP.

    • 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'APIappel 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 GPU appareils pour les inférences de modèles (en spécifiant des instances de calcul ML GPU basées sur le langage machine dans votre CreateTransformJob demande), assurez-vous que vos conteneurs sont compatibles avec nvidia-docker. N'associez pas NVIDIA les pilotes à l'image. Pour plus d'informations sur nvidia-docker, consultez /nvidia-docker. NVIDIA

     

  • Vous ne pouvez pas utiliser l'initinitialiseur comme point d'entrée dans les SageMaker conteneurs car les arguments train et serve le confondent.

Comment se SageMaker charge les artefacts de votre modèle

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 exécutez SageMaker des inférences, il utilise ces informations pour déterminer d'où copier les artefacts du 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 SageMaker, il enregistre les artefacts dans un seul fichier tar compressé dans Amazon S3. Si vous entraînez un modèle dans un autre framework, vous devez stocker les artefacts du modèle dans Amazon S3 sous forme de fichier tar compressé. SageMaker décompresse ce fichier tar et l'enregistre dans le /opt/ml/model répertoire du conteneur avant le début de la tâche de transformation par lots.

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 implémenter des requêtes de paramètres d'exécution afin de fournir une configuration d'exécution dynamique à. SageMaker SageMakerutilise les points de terminaison suivants :

  • ping—Utilisé pour vérifier périodiquement l'état du contenant. SageMaker attend un code d'HTTP200état et un corps vide pour une demande ping réussie avant d'envoyer une demande d'invocation. 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. Sur la base de la mémoire et de la CPUs disponibilité pour un conteneur MaxConcurrentTransformsBatchStrategy, l'algorithme choisit les MaxPayloadInMB valeurs appropriées pour la tâche.

Avant d'appeler la demande d'invocation, SageMaker tente d'invoquer la demande de paramètres d'exécution. Lorsque vous créez une tâche de transformation par lots, vous pouvez fournir des valeurs pour les MaxPayloadInMB paramètres MaxConcurrentTransformsBatchStrategy, et. SageMaker détermine les valeurs de ces paramètres en utilisant cet ordre de priorité :

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

  2. Les valeurs que le conteneur du modèle renvoie lorsqu'il SageMaker invoque 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 à une demande de GET paramètres d'exécution est un JSON objet avec des clés pour MaxConcurrentTransformsBatchStrategy, et MaxPayloadInMB des paramètres. 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 déductions, Amazon SageMaker envoie une POST demande au conteneur d'inférence. Le corps de la POST demande contient des données provenant d'Amazon S3. Amazon SageMaker transmet la demande au conteneur et renvoie le résultat de l'inférence depuis le conteneur, en enregistrant les données de la réponse à Amazon S3.

Pour recevoir des demandes d'inférence, le conteneur doit disposer d'un serveur Web écoutant sur le port 8080 et doit accepter les POST demandes adressées au /invocations point de terminaison. 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 est de répondre avec un code d'état HTTP 200 et un corps vide. Cela indique SageMaker que le conteneur est prêt à accepter les demandes d'inférence au /invocations point de terminaison.

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