Résolution des problèmes - Amazon SageMaker AI

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 ou MemoryUtilization, 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 la CPUUtilization 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

CloudWatch console affichant le graphique du nombre d'instances actives pour un point de terminaison.

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

SAGEMAKER_TFS_INSTANCE_COUNT

Pour les modèles TensorFlow basés, le tensorflow_model_server binaire est l'élément opérationnel responsable du chargement d'un modèle en mémoire, de l'exécution des entrées par rapport à un graphe du modèle et de la dérivation des sorties. Généralement, une seule instance de ce binaire est lancée pour servir les modèles dans un point de terminaison. Ce binaire est multithread en interne et génère plusieurs threads pour répondre à une demande d'inférence. Dans certains cas, si vous constatez que le processeur est convenablement utilisé (plus de 30 % d'utilisation) mais que la mémoire est sous-utilisée (moins de 10 % d'utilisation), il peut être utile d'augmenter ce paramètre. L'augmentation du nombre tensorflow_model_servers de serveurs disponibles augmente généralement le débit d'un point de terminaison.

SAGEMAKER_TFS_FRACTIONAL_GPU_MEM_MARGIN

Ce paramètre régit la fraction de la mémoire GPU disponible pour initialiser CUDA/cuDNN et les autres bibliothèques GPU. 0.2 signifie que 20 % de la mémoire GPU disponible est réservée à l'initialisation de CUDA/cuDNN et des autres bibliothèques GPU, et que 80 % de la mémoire GPU disponible est allouée de manière égale entre les processus TF. La mémoire GPU est préallouée sauf si l'option allow_growth est activée.

SAGEMAKER_TFS_INTER_OP_PARALLELISM

Elle est liée à la variable inter_op_parallelism_threads. Cette variable détermine le nombre de threads utilisés par les opérations indépendantes sans blocage. 0 signifie que le système choisit un nombre approprié.

SAGEMAKER_TFS_INTRA_OP_PARALLELISM

Elle est liée à la variable intra_op_parallelism_threads. Cela détermine le nombre de threads qui peuvent être utilisés pour certaines opérations telles que la multiplication matricielle et les réductions pour les accélérations. Une valeur de 0 signifie que le système choisit un nombre approprié.

SAGEMAKER_GUNICORN_WORKERS

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 SAGEMAKER_GUNICORN_WORKER_CLASS régit le type des applications de travail engendrées, généralement async ou gevent.

SAGEMAKER_GUNICORN_WORKER_CLASS

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 SAGEMAKER_GUNICORN_WORKER_CLASS régit le type des applications de travail engendrées, généralement async ou gevent.

OMP_NUM_THREADS

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 1, ou la moitié du nombre de cœurs de processeur d'un processeur avec le SMT activé.

TF_DISABLE_MKL

TF_DISABLE_POOL_ALLOCATOR

Dans certains cas, la désactivation de MKL peut accélérer l'inférence si TF_DISABLE_MKL et TF_DISABLE_POOL_ALLOCATOR sont définies sur 1.

PyTorch

Variable d'environnement Description

SAGEMAKER_TS_MAX_BATCH_DELAY

Il s'agit du délai d' TorchServe attente maximal du lot avant réception.

SAGEMAKER_TS_BATCH_SIZE

S'il TorchServe ne reçoit pas le nombre de demandes spécifié dans batch_size avant la fin du délai imparti, il envoie les demandes reçues au gestionnaire de modèles.

SAGEMAKER_TS_MIN_WORKERS

Le nombre minimum de travailleurs TorchServe autorisé à être réduit.

SAGEMAKER_TS_MAX_WORKERS

Le nombre maximum de travailleurs autorisé à augmenter. TorchServe

SAGEMAKER_TS_RESPONSE_TIMEOUT

Délai après lequel l'inférence expire en l'absence de réponse.

SAGEMAKER_TS_MAX_REQUEST_SIZE

La taille de charge utile maximale pour TorchServe.

SAGEMAKER_TS_MAX_RESPONSE_SIZE

Taille de réponse maximale pour TorchServe.

Serveur multimodèle (MMS)

Variable d'environnement Description

job_queue_size

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 job_queue_size, vous risquez d'augmenter la consommation de mémoire de tas de la JVM et, finalement, de priver l'hôte de la mémoire qui aurait pu être utilisée par les applications de travail Python. Par conséquent, soyez également prudent lorsque vous réglez ce paramètre.

default_workers_per_model

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. Vérifiez si l'instance requise est disponible dans votre région avant de continuer.