Utilisation de votre propre code d'inférence avec les services d'hébergement - Amazon SageMaker

Utilisation de votre propre code d'inférence avec les services d'hébergement

Cette section explique comment Amazon SageMaker interagit avec un conteneur Docker qui exécute votre propre code d'inférence pour les services d'hébergement. 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 Remarques :

  • Pour l'inférence de modèle, SageMaker exécute le conteneur de la façon suivante :

    docker run image serve

    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"]

    Le formulaire exec de l'instruction ENTRYPOINT lance l'exécutable directement, et non en tant qu'enfant de /bin/sh. Cela lui permet de recevoir des signaux tels que SIGTERM et SIGKILL à partir des opérations d'API SageMaker, ce qui est une condition requise.

     

    Par exemple, lorsque vous utilisez l'API CreateEndpoint pour créer un point de terminaison, SageMaker alloue le nombre d'instances de calcul ML requis par la configuration du point de terminaison, que vous spécifiez dans la requête. SageMaker exécute le conteneur Docker sur ces instances.

     

    Si vous réduisez le nombre d'instances soutenant le point de terminaison (en appelant l'API UpdateEndpointWeightsAndCapacities), SageMaker exécute une commande pour arrêter le conteneur Docker sur les instances en cours de résiliation. La commande envoie le signal SIGTERM, puis envoie le signal SIGKILL 30 secondes plus tard.

     

    Si vous mettez à jour le point de terminaison (en appelant l'API UpdateEndpoint), SageMaker lance un autre ensemble d'instances de calcul ML et exécute les conteneurs Docker contenant le code d'inférence sur ces dernières. Ensuite, il exécute une commande pour arrêter les conteneurs Docker précédents. Pour arrêter un conteneur Docker, la commande envoie le signal SIGTERM, puis le signal SIGKILL 30 secondes plus tard.

     

  • SageMaker utilise la définition du conteneur que vous avez fournie dans votre requête CreateModel pour définir les variables d'environnement et le nom d'hôte DNS pour le conteneur de la façon suivante :

     

    • Il définit les variables d'environnement à l'aide du mappage chaîne-à-chaîne ContainerDefinition.Environment.

    • Il définit le nom d'hôte DNS à l'aide de ContainerDefinition.ContainerHostname.

       

  • Si vous prévoyez d'utiliser des périphériques GPU pour les inférences de modèle (en spécifiant les instances de calcul ML basées sur des GPU dans votre requête CreateEndpointConfig), 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 tini en tant que 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 votre requête CreateModel, la définition du conteneur comprend le paramètre ModelDataUrl qui identifie l'emplacement S3 où les artefacts de modèle sont stockés. SageMaker utilise ces informations pour déterminer à partir de quel emplacement copier les artefacts de modèle. Il copie les artefacts dans le répertoire /opt/ml/model afin qu'ils soient utilisés par votre code d'inférence.

L'élément ModelDataUrl doit pointer vers un fichier tar.gz. Sinon, SageMaker ne téléchargera pas le fichier.

Si vous avez entraîné votre modèle dans SageMaker, les artefacts de modèle sont enregistrés sous la forme d'un fichier .tar compressé unique dans Amazon S3. Si vous avez entraîné votre modèle en dehors de SageMaker, vous devez créer ce fichier .tar compressé unique et l'enregistrer dans un emplacement S3. SageMaker décompresse ce fichier .tar dans le répertoire /opt/ml/model avant que votre conteneur ne démarre.

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

Les conteneurs ont besoin d'implémenter un serveur web qui répond à /invocations et /ping sur le port 8080.

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

Pour obtenir des inférences, l'application client envoie une requête POST au point de terminaison SageMaker. Pour de plus amples informations, veuillez consulter l'API InvokeEndpoint. SageMaker transmet la requête au conteneur et renvoie l'inférence du conteneur ainsi obtenue au client. Remarques :

  • SageMaker supprime tous les en-têtes POST, à l'exception de ceux pris en charge par InvokeEndpoint. SageMaker peut ajouter des en-têtes supplémentaires. Les conteneurs d'inférence doivent être en mesure d'ignorer sans risque ces en-têtes supplémentaires.

  • Pour recevoir des requêtes d'inférence, le conteneur doit avoir un serveur web à l'écoute sur le port 8080 et doit accepter les requêtes POST envoyées au point de terminaison /invocations.

  • Les conteneurs de modèles d'un client doivent accepter les requêtes de connexion au socket dans un délai de 250 millisecondes.

  • Les conteneurs de modèles d'un client doivent répondre aux requêtes dans un délai de 60 secondes. Le traitement du modèle lui-même peut durer 60 secondes au maximum, avant de répondre aux /invocations. Si le traitement de votre modèle dure entre 50 et 60 secondes, définissez le délai d'expiration du socket du kit SDK sur 70 secondes.

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

Les appels d'API CreateEndpoint et UpdateEndpoint provoquent le démarrage de nouveaux conteneurs d'inférence par SageMaker. Peu de temps après le démarrage des conteneurs, SageMaker commence à envoyer des requêtes GET périodiques au point de terminaison /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.

Si le conteneur ne commence pas à transmettre les surveillances de l'état, en répondant systématiquement par 200s, pendant les 4 minutes suivant le démarrage, CreateEndPoint échoue, laissant le point de terminaison en état d'échec, et la mise à jour demandée par UpdateEndpoint n'est pas exécutée.

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 /ping est de 2 secondes.