Pourquoi la création ou la mise à jour de mon point de terminaison Amazon SageMaker échoue-t-elle ?

Solution

Lorsque la création ou la mise à jour de votre point de terminaison SageMaker échoue, SageMaker fournit la raison de l'échec. Utilisez l'une des options suivantes pour vérifier cette raison :

• Vérifiez le point de terminaison dans la console SageMaker. La raison de l'échec est indiquée dans la console.
• Exécutez la commande describe-endpoint de l'Interface de la ligne de commande AWS (AWS CLI). Cochez le champ FailureReason pour connaître la raison de l'échec.

Remarque : si vous recevez des erreurs lors de l'exécution de commandes de l'AWS CLI, vérifiez que vous utilisez la dernière version de l'AWS CLI.

Vous trouverez ci-dessous certaines raisons d'échec et leurs méthodes de résolution.

Impossible d'allouer la capacité de calcul de ML demandée en raison d'une erreur InsufficientInstanceCapacity

Le message d'erreur suivant peut s'afficher lorsque vous essayez de créer un point de terminaison :

Unable to provision requested ML compute capacity due to InsufficientInstanceCapacity error

Cette erreur se produit lorsqu'AWS ne dispose pas de la capacité suffisante pour fournir les instances demandées pour votre point de terminaison.

Vous pouvez résoudre cette erreur en essayant l'une ou plusieurs des approches suivantes :

• Attendez quelques minutes et réessayez, car la capacité peut changer fréquemment.
• Si vous utilisez plusieurs instances pour votre point de terminaison, essayez de créer le point de terminaison avec un plus petit nombre d'instances. Si la scalabilité automatique est configurée, SageMaker peut augmenter ou diminuer selon les besoins et les capacités.
• Essayez un autre type d'instance qui prend en charge votre charge de travail. Après avoir créé un point de terminaison, mettez-le à jour avec le type d'instance souhaité. Étant donné que SageMaker utilise une méthode de déploiement bleu/vert pour optimiser la disponibilité, vous pouvez passer à un nouveau type d'instance sans affecter vos charges de travail de production actuelles.

Le conteneur de la variante de production <variant>n'a pas réussi la surveillance de l'état ping. Consultez les journaux CloudWatch de ce point de terminaison.

Les conteneurs utilisés pour les points de terminaison SageMaker doivent implémenter un serveur web qui répond aux points de terminaison /invocations et /ping. Lorsque vous créez un point de terminaison, SageMaker commence à envoyer des demandes GET régulières au point de terminaison /ping après le démarrage du conteneur.

Au minimum, un conteneur doit répondre avec un code d'état HTTP 200 OK et un corps vide pour indiquer qu'il est prêt à accepter les demandes d'inférence. Cette erreur se produit lorsque SageMaker n'obtient pas de réponses cohérentes de la part du conteneur dans les quatre minutes suivant le démarrage du conteneur. SageMaker ne considère pas que le point de terminaison est sain, car il ne répond pas à la surveillance de l'état. Par conséquent, le point de terminaison est marqué comme Failed (Échoué).

La surveillance de l'état peut également échouer lorsque vous utilisez l'une des images de conteneurs AWS Deep Learning Containers. Celles-ci utilisent TorchServe ou Multi Model Server pour servir les modèles qui implémentent les points de terminaison HTTP à des fins d'inférence et de surveillance de l'état. Ces cadres vérifient que le modèle est chargé avant de répondre à SageMaker par 200 OK. Si le serveur ne parvient pas à voir si le modèle est chargé, la surveillance de l'état échoue. Un modèle peut ne pas se charger pour de nombreuses raisons, notamment l'utilisation de la mémoire. Les messages d'erreur correspondants sont enregistrés dans les journaux Amazon CloudWatch Logs du point de terminaison. Si le code chargé dans le point de terminaison est à l'origine de l'échec (par exemple, model_fn pour PyTorch), les erreurs sont journalisées dans AWS CloudTrail. Pour augmenter la verbosité de ces journaux, mettez à jour la variable d'environnement SAGEMAKER_CONTAINER_LOG_LEVEL du modèle avec les niveaux de journaux pour la journalisation Python.

Une surveillance de l'état doit recevoir une réponse dans les deux secondes pour être acceptée. Assurez-vous de tester la réponse en démarrant votre modèle de conteneur localement et en envoyant une demande GET au conteneur afin de vérifier la réponse.

Impossible d'extraire l'archive de données de modèle pour le conteneur

SageMaker attend un fichier TAR contenant les données du modèle à utiliser sur votre point de terminaison. Une fois que SageMaker a téléchargé le fichier TAR, l'archive de données est extraite. Cette erreur peut se produire si SageMaker ne parvient pas à extraire cette archive de données. Par exemple, SageMaker ne peut pas extraire l'archive de données si l'artefact du modèle contient des liens symboliques vers des fichiers situés dans le fichier TAR.

Lorsque vous créez un point de terminaison, assurez-vous que les artefacts du modèle n'incluent pas de liens symboliques dans le fichier TAR. Pour vérifier si le fichier TAR contient des liens symboliques, extrayez les données du modèle, puis exécutez la commande suivante dans les artefacts :

find . -type l -ls

Cette commande renvoie tous les liens symboliques trouvés après une recherche dans le répertoire actuel et ses sous-répertoires. Remplacez tout lien renvoyé par les copies du fichier elles-mêmes.

CannotStartContainerError

Cette erreur se produit lorsque SageMaker ne parvient pas à démarrer le conteneur pour le préparer à l'inférence.

Lorsque SageMaker démarre le point de terminaison, votre conteneur démarre à l'aide de la commande suivante :

docker run <image-id> serve

Lorsque cette commande est exécutée, votre conteneur doit démarrer le processus de diffusion.

Pour résoudre cette erreur, utilisez le mode local pour le kit SDK SageMaker Python. Vous pouvez également essayer d'exécuter votre image d'inférence avec la commande docker run. Le kit SDK SageMaker Python charge votre modèle de la même manière qu'un point de terminaison SageMaker. Cependant, Docker ne charge pas le modèle, sauf si vous configurez la commande ou le conteneur pour le faire. Vous pouvez utiliser une commande similaire à ce qui suit pour charger votre modèle localement :

docker run -v $(pwd)/test_dir:/opt/ml -p 8080:8080 --rm ${image} serve

---