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 questions fréquentes (FAQ) suivantes peuvent vous aider à résoudre les problèmes liés à vos points de terminaison d'inférence asynchrone Amazon SageMaker.
## Q : La mise à l'échelle automatique est activée. Comment puis-je trouver le nombre d'instances derrière le point de terminaison à un moment donné ?
Vous pouvez utiliser les méthodes suivantes pour déterminer le nombre d'instances derrière votre point de terminaison :
+ Vous pouvez utiliser l’API [DescribeEndpoint](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html) SageMaker AI pour décrire le nombre d’instances situées derrière le point de terminaison à tout instant.
+ Vous pouvez obtenir le nombre d'instances en consultant vos métriques Amazon CloudWatch. Consultez les [métriques de vos instances de point de terminaison](https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-jobs), 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 métrique `CPUUtilization` représentée graphiquement dans la console CloudWatch, où la valeur **Statistique** est définie sur `Sample count`, la valeur **Période** est définie sur `1 minute` et le nombre obtenu est 5.
## Q : Quelles sont les variables d’environnement réglables courantes pour les conteneurs SageMaker AI ?
Les tableaux suivants présentent les variables d’environnement réglables courantes pour les conteneurs SageMaker AI par type de cadre.
**TensorFlow**
| Variable d'environnement | Description |
| --- | --- |
| `SAGEMAKER_TFS_INSTANCE_COUNT` | Pour les modèles basés sur Tensorflow, le binaire `tensorflow_model_server` est l'élément opérationnel responsable du chargement d'un modèle en mémoire, de l'exécution d'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 multithreading simultané (SMT), tel que la technologie Hyper-Threading d'Intel, un certain processus peut sursouscrire un cœur en particulier en générant deux fois plus de threads que le nombre réel de cœurs de processeur. 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 de traitement par lots maximal que TorchServe attend de recevoir. |
| `SAGEMAKER_TS_BATCH_SIZE` | Si 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` | Nombre minimal d'applications de travail auquel TorchServe est autorisé à réduire la capacité. |
| `SAGEMAKER_TS_MAX_WORKERS` | Nombre maximal d'applications de travail auquel TorchServe est autorisé à augmenter la capacité. |
| `SAGEMAKER_TS_RESPONSE_TIMEOUT` | Délai après lequel l'inférence expire en l'absence de réponse. |
| `SAGEMAKER_TS_MAX_REQUEST_SIZE` | 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. |
## Q : Comment puis-je m'assurer que mon conteneur prend en charge l'inférence asynchrone ?
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.
## Q : Quelles sont les limites spécifiques à l'inférence asynchrone et peuvent-elles être ajustées ?
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.
+ Durée de vie (TTL) des messages en file d'attente : 6 heures
+ Nombre de messages pouvant être placés dans Amazon SQS : illimité. Toutefois, il existe un quota de 120 000 messages en cours pour une file d’attente standard et de 20 000 pour une file d’attente FIFO.
## Q : Quelles métriques sont les meilleures à définir pour la mise à l'échelle automatique dans le cadre d'une inférence asynchrone ? Puis-je avoir plusieurs politiques de mise à l'échelle ?
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.
## Q : Pourquoi mon point de terminaison asynchrone résilie une instance en tant que `Unhealthy` et les demandes de mise à jour provenant de la mise à l'échelle automatique échouent ?
Vérifiez si votre conteneur est capable de gérer simultanément des demandes ping et d'invocation. Les demandes d’invocation SageMaker AI prennent environ 3 minutes, et pendant ce temps, plusieurs demandes ping finissent généralement par échouer en raison de l’expiration du délai imparti à SageMaker AI pour détecter votre conteneur comme `Unhealthy`.
## Q : `MaxConcurrentInvocationsPerInstance` peut-il fonctionner pour mon modèle de conteneur BYOC avec les paramètres ningx/gunicorn/flask ?
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.
## Q : Comment puis-je corriger les erreurs de serveur de modèle (500) sur mon point de terminaison asynchrone ?
L'erreur signifie que le conteneur client a renvoyé une erreur. SageMaker AI ne contrôle pas le comportement des conteneurs client. SageMaker AI 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 [S3FailurePath](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AsyncInferenceOutputConfig.html#sagemaker-Type-AsyncInferenceOutputConfig-S3FailurePath) sur la réponse du modèle dans Amazon SNS dans le cadre des notifications d'erreur asynchrone pour enquêter sur les défaillances.
## Q : Comment puis-je savoir si `MaxConcurrentInvocationsPerInstance=1` prend effet ? Y a-t-il des métriques que je peux vérifier ?
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.
## Q : Comment puis-je suivre la réussite et l'échec de mes demandes d'invocation ? Quelles sont les bonnes pratiques ?
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](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html) 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](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-check-predictions.html).
## Q : Puis-je définir une politique de mise à l'échelle pour augmenter le nombre d'instances à partir de zéro après réception d'une nouvelle demande ?
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](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-autoscale.html#async-inference-autoscale-scale-up).
## Q : Je reçois une erreur indiquant que le type d'instance n'est pas pris en charge pour l'inférence asynchrone. Quels sont les types d'instances pris en charge par l'inférence asynchrone ?
Pour obtenir la liste exhaustive des instances prises en charge par l'inférence asynchrone par région, consultez [Tarification d'Amazon SageMaker](https://aws.amazon.com/sagemaker/pricing/). Vérifiez si l'instance requise est disponible dans votre région avant de continuer.