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 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.
Rubriques
- Comment SageMaker fonctionne votre image d'inférence
- Comment se SageMaker charge les artefacts de votre modèle
- Comment votre conteneur doit-il répondre aux requêtes d'inférence ?
- Comment votre conteneur doit-il répondre aux requêtes de surveillance de l'état (Ping) ?
- Utilisation d'un registre Docker privé pour les conteneurs d'inférence en temps réel
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 l'inférence du modèle, SageMaker exécute le conteneur comme suit :
docker run
image
serveSageMaker remplace les
CMD
instructions par défaut dans un conteneur en spécifiant l'serve
argument après le nom de l'image. L'argumentserve
remplace les arguments fournis avec la commandeCMD
dans le Dockerfile. -
SageMaker s'attend à ce que tous les conteneurs s'exécutent avec des utilisateurs root. Créez votre conteneur de manière à ce qu'il n'utilise que des utilisateurs root. Lors de l' SageMaker exécution de votre conteneur, les utilisateurs qui ne disposent pas d'un accès au niveau root peuvent entraîner des problèmes d'autorisation.
-
Nous vous recommandons d'utiliser le formulaire
exec
de l'instructionENTRYPOINT
:ENTRYPOINT ["executable", "param1", "param2"]
Par exemple :
ENTRYPOINT ["python", "k_means_inference.py"]
Le formulaire
exec
de l'instructionENTRYPOINT
lance l'exécutable directement, et non en tant qu'enfant de/bin/sh
. Cela lui permet de recevoir des signaux tels queSIGTERM
etSIGKILL
provenant des SageMaker API opérations, ce qui est une exigence.Par exemple, lorsque vous utilisez le
CreateEndpoint
APIpour créer un point de terminaison, fournit SageMaker le nombre d'instances de calcul ML requises par la configuration du point de terminaison, que vous spécifiez dans la demande. SageMaker exécute le conteneur Docker sur ces instances.Si vous réduisez le nombre d'instances soutenant le point de terminaison (en appelant le
UpdateEndpointWeightsAndCapacities
API) SageMaker , exécutez une commande pour arrêter le conteneur Docker sur les instances en cours de résiliation. La commande envoie le signalSIGTERM
, puis envoie le signalSIGKILL
30 secondes plus tard.Si vous mettez à jour le point de terminaison (en appelant le
UpdateEndpoint
API), SageMaker lancez un autre ensemble d'instances de calcul ML et exécutez les conteneurs Docker contenant votre code d'inférence. 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 signalSIGKILL
30 secondes plus tard. -
SageMaker utilise la définition de conteneur que vous avez fournie dans votre
CreateModel
demande pour définir les variables d'environnement et le DNS nom d'hôte du conteneur comme suit :-
Il définit les variables d'environnement à l'aide de la
ContainerDefinition.Environment
string-to-string carte. -
Il définit le DNS nom d'hôte à l'aide du
ContainerDefinition.ContainerHostname
.
-
-
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
CreateEndpointConfig
demande), assurez-vous que vos conteneurs sontnvidia-docker
compatibles. N'associez pas NVIDIA les pilotes à l'image. Pour plus d'informationsnvidia-docker
, consultez NVIDIA/nvidia-docker. -
Vous ne pouvez pas utiliser l'
tini
initialiseur comme point d'entrée dans les SageMaker conteneurs car les argumentstrain
etserve
le confondent.
Comment se SageMaker charge les artefacts de votre modèle
Dans votre CreateModel
APIdemande, vous pouvez utiliser le S3DataSource
paramètre ModelDataUrl
ou pour identifier l'emplacement S3 où les artefacts du modèle sont stockés. SageMaker copie les artefacts de votre modèle de l'emplacement S3 vers le /opt/ml/model
répertoire pour les utiliser par votre code d'inférence. 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, je SageMaker ne téléchargerai pas le fichier.
Si vous avez entraîné votre modèle SageMaker, les artefacts du modèle sont enregistrés dans un seul fichier tar compressé dans Amazon S3. Si vous avez entraîné votre modèle à l'extérieur 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 le démarrage de votre conteneur.
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 cliente envoie une POST demande au SageMaker point de terminaison. SageMaker transmet la demande au conteneur et renvoie le résultat de l'inférence du conteneur au client.
Pour plus d'informations sur les demandes d'inférence que votre conteneur recevra, consultez les actions suivantes dans la SageMaker APIréférence Amazon :
Exigences relatives aux conteneurs d'inférence
Pour répondre aux demandes d'inférence, votre conteneur doit répondre aux exigences suivantes :
-
SageMaker supprime tous les
POST
en-têtes sauf ceux pris en charge parInvokeEndpoint
. 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 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 aux points de terminaison/invocations
et/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 votre modèle doit prendre 50 à 60 secondes de temps de traitement, le délai d'expiration du SDK socket doit être réglé 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 que les applications clientes envoient à l'aide de l' InvokeEndpoint action.
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 que les applications clientes envoient à l'aide de l' InvokeEndpointWithResponseStream action.
Lorsqu'un conteneur gère une demande d'inférence en streaming, il renvoie l'inférence du modèle sous la forme d'une série de pièces 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 lance de nouveaux conteneurs d'inférence dans les situations suivantes :
-
Répondre aux
CreateEndpoint
UpdateEndpointWeightsAndCapacities
API appelsUpdateEndpoint
et aux appels -
Application de correctifs de sécurité
-
Remplacement des instances défectueuses
Peu après le démarrage du conteneur, SageMaker commence à envoyer des GET demandes périodiques au /ping
point de terminaison.
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.
Si le conteneur ne commence pas à passer les tests de santé en répondant régulièrement par 200 secondes pendant les 8 minutes qui suivent le démarrage, le lancement de la nouvelle instance échoue. Cela CreateEndpoint
entraîne une défaillance, laissant le terminal dans un état défaillant. 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 requêtes est de 2 secondes./ping