Code d’inférence personnalisé avec les services d’hébergement
Cette section explique comment Amazon SageMaker AI 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.
Rubriques
Exécution de votre image d’inférence par SageMaker AI
Pour configurer un conteneur et utiliser celui-ci en tant qu’exécutable, utilisez une instruction ENTRYPOINT dans un Dockerfile. Remarques :
-
Pour l’inférence de modèle, SageMaker AI exécute le conteneur de la façon suivante :
docker runimageserveSageMaker AI remplace les instructions
CMDpar défaut dans un conteneur en spécifiant l’argumentserveaprès le nom de l’image. L’argumentserveremplace les arguments fournis avec la commandeCMDdans le Dockerfile. -
SageMaker AI s’attend à ce que tous les conteneurs s’exécutent avec des utilisateurs racine. Créez votre conteneur de manière à ce qu’il n’utilise que des utilisateurs root. Lorsque SageMaker AI exécute votre conteneur, les utilisateurs qui ne disposent pas d’un accès au niveau root peuvent provoquer des problèmes d’autorisations.
-
Nous vous recommandons d’utiliser le formulaire
execde l’instructionENTRYPOINT:ENTRYPOINT ["executable", "param1", "param2"]Par exemple :
ENTRYPOINT ["python", "k_means_inference.py"]Le formulaire
execde l’instructionENTRYPOINTlance l’exécutable directement, et non en tant qu’enfant de/bin/sh. Cela lui permet de recevoir des signaux tels queSIGTERMetSIGKILLà partir des opérations d’API SageMaker, ce qui est une condition requise.Par exemple, lorsque vous utilisez l’API
CreateEndpointpour créer un point de terminaison, SageMaker AI 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 AI 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 AI exécute une commande pour arrêter le conteneur Docker sur les instances en cours de résiliation. La commande envoie le signalSIGTERM, puis envoie le signalSIGKILL30 secondes plus tard.Si vous mettez à jour le point de terminaison (en appelant l’API
UpdateEndpoint), SageMaker AI 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 signalSIGTERM, puis le signalSIGKILL30 secondes plus tard. -
SageMaker AI utilise la définition du conteneur que vous avez fournie dans votre requête
CreateModelpour 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 dispositifs GPU pour les inférences de modèle (en spécifiant les instances de calcul ML basées sur des GPU dans votre demande
CreateEndpointConfig), assurez-vous que vos conteneurs sont compatibles avecnvidia-docker. Ne regroupez pas des pilotes NVIDIA avec l’image. Pour plus d’informations surnvidia-docker, consultez NVIDIA/nvidia-docker. -
Vous ne pouvez pas utiliser l’initialiseur
tinien tant que point d’entrée dans des conteneurs SageMaker AI, car les argumentstrainetservele perturbent.
Chargement de vos artefacts de modèle par SageMaker AI
Dans votre demande d’API CreateModel, vous pouvez utiliser le paramètre ModelDataUrl ou S3DataSource pour identifier l’emplacement S3 où les artefacts du modèle sont stockés. SageMaker AI copie vos artefacts de modèle à partir de l’emplacement S3 vers le répertoire /opt/ml/model pour permettre à votre code d’inférence de les utiliser. Votre conteneur dispose d’un accès en lecture seule à /opt/ml/model. N’écrivez pas dans ce répertoire.
L’élément ModelDataUrl doit pointer vers un fichier tar.gz. Sinon, SageMaker AI ne téléchargera pas le fichier.
Si vous avez entraîné votre modèle dans SageMaker AI, les artefacts du 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 AI, vous devez créer ce fichier tar compressé unique et l’enregistrer dans un emplacement S3. SageMaker AI décompresse ce fichier tar dans le répertoire /opt/ml/model avant que votre conteneur ne démarre.
Pour le déploiement de modèles de grande taille, nous vous recommandons de suivre Déploiement de modèles non compressés.
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 AI. SageMaker AI transmet la requête au conteneur et renvoie l’inférence du conteneur ainsi obtenue au client.
Pour plus d’informations sur les demandes d’inférence que votre conteneur recevra, consultez les actions suivantes dans la Référence des API Amazon SageMaker AI :
Exigences relatives aux conteneurs d’inférence
Pour répondre aux demandes d’inférence, votre conteneur doit répondre aux exigences suivantes :
-
SageMaker AI supprime tous les en-têtes
POST, à l’exception de ceux pris en charge parInvokeEndpoint. SageMaker AI 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 demandes d’inférence, le conteneur doit avoir un serveur web à l’écoute sur le port 8080 et doit accepter les demandes
POSTenvoyées aux points de terminaison/invocationset/ping. -
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.
Exemple fonctions d’invocation
Les exemples suivants montrent comment le code de votre conteneur peut traiter les demandes d’inférence. Ces exemples traitent les demandes envoyées par les applications clientes à l’aide de l’action InvokeEndpoint.
Exemple fonctions d’invocation pour le streaming des demandes
Les exemples suivants montrent comment le code figurant dans votre conteneur d’inférence peut traiter les demandes d’inférence en streaming. Ces exemples traitent les demandes envoyées par les applications clientes à l’aide de l’action InvokeEndpointWithResponseStream.
Lorsqu’un conteneur traite une demande d’inférence en streaming, il renvoie l’inférence du modèle sous la forme d’une série de parties au fur et à mesure que le modèle les génère. Les applications clientes commencent à recevoir des réponses dès qu’elles sont disponibles. Elles n’ont pas besoin d’attendre que le modèle génère la réponse complète. Vous pouvez mettre en œuvre le streaming pour prendre en charge des expériences interactives rapides, telles que les chatbots, les assistants virtuels et les générateurs de musique.
Comment votre conteneur doit-il répondre aux requêtes de surveillance de l’état (Ping) ?
SageMaker AI lance de nouveaux conteneurs d’inférence dans les situations suivantes :
-
Réponse aux appels d’API
CreateEndpoint,UpdateEndpointetUpdateEndpointWeightsAndCapacities -
Application de correctifs de sécurité
-
Remplacement des instances défectueuses
Peu de temps après le démarrage des conteneurs, SageMaker AI 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 AI 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 avec 200, pendant les huit minutes suivant le démarrage, le lancement d’une nouvelle instance échoue. Cela provoque l’échec de CreateEndpoint, laissant le point de terminaison dans un état d’échec. La mise à jour demandée par UpdateEndpoint n’est pas terminée, les correctifs de sécurité ne sont pas appliqués et les instances défectueuses ne sont pas remplacées.
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 demandes /ping est de 2 secondes.