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.
Résolution des problèmes
Les informations suivantes FAQs peuvent vous aider à résoudre les problèmes liés à vos points de terminaison Amazon SageMaker Asynchronous Inference.
Vous pouvez utiliser les méthodes suivantes pour déterminer le nombre d'instances derrière votre point de terminaison :
Vous pouvez utiliser l'DescribeEndpointAPI SageMaker AI pour décrire le nombre d'instances situées derrière le point de terminaison à un moment donné.
Vous pouvez obtenir le nombre d'instances en consultant vos CloudWatch statistiques Amazon. Consultez les métriques de vos instances de point de terminaison, telles que
CPUUtilization
ouMemoryUtilization
, et vérifiez les statistiques relatives au nombre d'échantillons sur une période d'une minute. Ce nombre doit être égal au nombre d'instances actives. La capture d'écran suivante montre laCPUUtilization
métrique représentée graphiquement dans la CloudWatch console, où la statistique est définie surSample count
, la période est définie sur et le nombre obtenu est 5.1 minute

Les tableaux suivants présentent les variables d'environnement réglables courantes pour les conteneurs SageMaker AI par type de framework.
TensorFlow
Variable d'environnement | Description |
---|---|
|
Pour les modèles TensorFlow basés, le |
|
Ce paramètre régit la fraction de la mémoire GPU disponible pour initialiser CUDA/cuDNN et les autres bibliothèques GPU. |
|
Elle est liée à la variable |
|
Elle est liée à la variable |
|
Cela régit le nombre de processus d'application de travail que Gunicorn est invité à générer pour traiter les demandes. Cette valeur est utilisée en combinaison avec d'autres paramètres pour dériver un ensemble qui maximise le débit d'inférence. En plus de cela, la variable |
|
Cela régit le nombre de processus d'application de travail que Gunicorn est invité à générer pour traiter les demandes. Cette valeur est utilisée en combinaison avec d'autres paramètres pour dériver un ensemble qui maximise le débit d'inférence. En plus de cela, la variable |
|
Python utilise OpenMP en interne pour implémenter le multithreading au sein des processus. Généralement, des threads équivalents au nombre de cœurs CPU sont générés. Mais lorsqu'il est implémenté en plus du multithread simultané (SMT), tel que celui d'Intel HypeThreading, un certain processus peut surabonner un cœur en particulier en générant deux fois plus de threads que le nombre de cœurs de processeur réels. Dans certains cas, un binaire Python peut générer jusqu'à quatre fois plus de threads que de cœurs de processeur disponibles. Par conséquent, le paramètre idéal pour ce paramètre, si vous avez sursouscrit des cœurs disponibles à l'aide de threads de travail, est |
|
Dans certains cas, la désactivation de MKL peut accélérer l'inférence si |
PyTorch
Variable d'environnement | Description |
---|---|
|
Il s'agit du délai d' TorchServe attente maximal du lot avant réception. |
|
S'il TorchServe ne reçoit pas le nombre de demandes spécifié dans |
|
Le nombre minimum de travailleurs TorchServe autorisé à être réduit. |
|
Le nombre maximum de travailleurs autorisé à augmenter. TorchServe |
|
Délai après lequel l'inférence expire en l'absence de réponse. |
|
La taille de charge utile maximale pour TorchServe. |
|
Taille de réponse maximale pour TorchServe. |
Serveur multimodèle (MMS)
Variable d'environnement | Description |
---|---|
|
Il est utile de régler ce paramètre dans un scénario où le type de la charge utile de demande d'inférence est important et si, en raison de cette taille, la consommation de mémoire de tas de la JVM dans laquelle cette file d'attente est maintenue peut être plus élevée. Dans l'idéal, vous pouvez réduire les besoins en mémoire de tas de la JVM et permettre aux applications de travail Python d'allouer plus de mémoire pour la prise en charge réelle du modèle. La JVM sert uniquement à recevoir les requêtes HTTP, à les mettre en file d'attente et à les distribuer aux applications de travail basées sur Python pour l'inférence. Si vous augmentez la variable |
|
Ce paramètre est destiné au service du modèle backend et peut être utile à régler, car il s'agit du composant essentiel du service de modèle global, sur la base duquel Python traite les threads de génération pour chaque modèle. Si ce composant est plus lent (ou s'il n'est pas réglé correctement), le réglage frontal risque de ne pas être efficace. |
Vous pouvez utiliser le même conteneur pour l'inférence asynchrone que pour l'inférence en temps réel ou la transformation par lots. Vous devez confirmer que les délais d'expiration et les limites de taille de charge utile sur votre conteneur sont définis pour gérer des charges utiles plus importantes et des délais d'expiration plus longs.
Reportez-vous aux limites suivantes pour l'inférence asynchrone :
Limite de taille de charge utile : 1 Go
Limite de délai d'expiration : une demande peut prendre jusqu'à 60 minutes.
Message de file d'attente TimeToLive (TTL) : 6 heures
Nombre de messages pouvant être placés dans Amazon SQS : illimité. Cependant, il existe un quota de 120 000 messages en vol pour une file d'attente standard et de 20 000 pour une file FIFO.
En général, avec l'inférence asynchrone, vous pouvez monter en puissance en fonction des invocations ou des instances. Pour les métriques d'invocation, il est judicieux de consulter votre métrique ApproximateBacklogSize
, qui correspond au nombre d'éléments de votre file d'attente qui doivent encore être traités. Vous pouvez utiliser cette métrique ou votre métrique InvocationsPerInstance
pour comprendre à quel TPS vous êtes peut-être limité. Au niveau de l'instance, vérifiez votre type d'instance et son utilisation du CPU/GPU pour définir à quel moment monter en puissance. Si la capacité d'une instance unique dépasse 60-70 %, cela est souvent bon signe et indique que vous saturez votre matériel.
Nous ne recommandons pas l'utilisation de plusieurs politiques de mise à l'échelle, car cela peut engendrer des conflits et créer de la confusion au niveau du matériel, ce qui peut entraîner des retards lors d'une montée en puissance.
Vérifiez si votre conteneur est capable de gérer le ping et d'invoquer des requêtes simultanément. SageMaker Les demandes d'invocation par l'IA prennent environ 3 minutes, et pendant cette durée, plusieurs demandes ping finissent généralement par échouer en raison du délai imparti à l' SageMaker IA pour détecter votre conteneur sous Unhealthy
le nom de.
Oui. MaxConcurrentInvocationsPerInstance
est une fonctionnalité des points de terminaison asynchrones. Cela ne dépend pas de l'implémentation du conteneur personnalisé. MaxConcurrentInvocationsPerInstance
contrôle la fréquence à laquelle les demandes d'invocation sont envoyées au conteneur client. Si cette valeur est définie sur 1
, une seule demande est envoyée au conteneur à la fois, quel que soit le nombre d'applications de travail présentes sur le conteneur client.
L'erreur signifie que le conteneur du client a renvoyé une erreur. SageMaker L'IA ne contrôle pas le comportement des conteneurs des clients. SageMaker L'IA renvoie simplement la réponse du ModelContainer
et ne réessaie pas. Si vous le souhaitez, vous pouvez configurer l'invocation pour réessayer en cas d'échec. Nous vous suggérons d'activer la journalisation des conteneurs et de consulter vos journaux de conteneurs pour trouver la cause première de l'erreur 500 dans votre modèle. Vérifiez également les métriques CPUUtilization
et MemoryUtilization
correspondantes au point de défaillance. Vous pouvez également configurer le S3 FailurePath en fonction du modèle de réponse dans Amazon SNS dans le cadre des notifications d'erreur asynchrones pour enquêter sur les défaillances.
Vous pouvez vérifier la métrique InvocationsProcesssed
, qui doit correspondre au nombre d'invocations que vous prévoyez de traiter en une minute sur la base d'une simultanéité unique.
La bonne pratique consiste à activer Amazon SNS, qui est un service de notification destiné aux applications orientées messagerie, avec plusieurs abonnés demandant et recevant des notifications « push » de messages à caractère urgent via divers protocoles de transport, dont notamment HTTP, Amazon SQS et la messagerie électronique. L'inférence asynchrone publie des notifications lorsque vous créez un point de terminaison avec CreateEndpointConfig
et spécifiez une rubrique Amazon SNS.
Pour utiliser Amazon SNS afin de vérifier les résultats de prédiction à partir de votre point de terminaison asynchrone, vous devez d'abord créer une rubrique, vous abonner à la rubrique, confirmer votre abonnement à la rubrique et noter l'Amazon Resource Name (ARN) de cette rubrique. Pour obtenir des informations détaillées sur la création, l'abonnement et la recherche de l'Amazon ARN d'une rubrique Amazon SNS, consultez Configuration d'Amazon SNS dans le Guide du développeur Amazon SNS. Pour plus d'informations sur l'utilisation d'Amazon SNS avec l'inférence asynchrone, consultez Vérification des résultats de prédiction.
Oui. L'inférence asynchrone fournit un mécanisme permettant de réduire à zéro le nombre d'instances en l'absence de demandes. Si votre point de terminaison a été réduit à zéro instance au cours de ces périodes, votre point de terminaison ne sera pas de nouveau augmenté tant que le nombre de demandes dans la file d'attente ne dépassera pas la cible spécifiée dans votre politique de mise à l'échelle. Cela peut entraîner de longs délais d'attente pour les demandes dans la file d'attente. Dans de tels cas, si vous souhaitez augmenter le nombre d'instances à partir de zéro pour les nouvelles demandes tout en restant sous la cible de file d'attente spécifiée, vous pouvez utiliser une politique de mise à l'échelle supplémentaire appelée HasBacklogWithoutCapacity
. Pour plus d'informations sur la façon de définir cette politique de mise à l'échelle, consultez Mise à l'échelle automatique d'un point de terminaison asynchrone.
Pour une liste exhaustive des instances prises en charge par Asynchronous Inference par région, consultez SageMaker la section Tarification de l'IA.