

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Solução de problemas
<a name="async-inference-troubleshooting"></a>

As perguntas frequentes a seguir podem ajudar a solucionar problemas com os endpoints de inferência assíncrona do Amazon SageMaker.

## P: Eu tenho o dimensionamento automático ativado. Como posso encontrar a contagem de instâncias atrás do endpoint em um determinado ponto?
<a name="async-troubleshooting-q1"></a>

É possível usar os métodos abaixo para encontrar a contagem de instâncias por trás do endpoint:
+ Use a API [DescribeEndpoint](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeEndpoint.html) do SageMaker AI para descrever o número de instâncias atrás do endpoint em um determinado momento.
+ Você pode obter a contagem de instâncias visualizando suas métricas do Amazon CloudWatch. Veja as [métricas de suas instâncias de endpoint](https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-jobs), como, por exemplo, `CPUUtilization` ou `MemoryUtilization`, e verifique a estatística de contagem de exemplos por um período de 1 minuto. A contagem deve ser igual ao número de instâncias ativas. A captura de tela a seguir mostra a métrica `CPUUtilization` representada graficamente no console do CloudWatch, em que a **estatística** é definida em `Sample count`, o **período** é definido em `1 minute` e a contagem resultante é 5.

![Console do CloudWatch mostrando o gráfico de contagem de instâncias ativas de um endpoint.](http://docs.aws.amazon.com/pt_br/sagemaker/latest/dg/images/cloudwatch-sample-count.png)


## P: Quais são as variáveis de ambiente ajustáveis comuns para contêineres do SageMaker AI?
<a name="async-troubleshooting-q2"></a>

As tabelas a seguir descrevem as variáveis de ambiente ajustáveis comuns para contêineres do SageMaker AI por tipo de framework.

**TensorFlow**


| Variável de ambiente | Descrição | 
| --- | --- | 
| `SAGEMAKER_TFS_INSTANCE_COUNT` | Para modelos baseados em TensorFlow, o binário `tensorflow_model_server` é a peça operacional responsável por carregar um modelo na memória, executar entradas em um gráfico de modelo e derivar saídas. Normalmente, uma instância única desse binário é executada para servir modelos em um endpoint. Esse binário é internamente multi-thread e gera vários threads para responder a uma solicitação de inferência. Em certas instâncias, se você observar que a CPU é utilizada de forma respeitável (mais de 30% de utilização), mas a memória está subutilizada (menor que 10% de utilização), aumentar esse parâmetro pode ajudar. Aumentar o número de unidades `tensorflow_model_servers` disponíveis para servir normalmente aumenta a taxa de throughput de um endpoint. | 
| `SAGEMAKER_TFS_FRACTIONAL_GPU_MEM_MARGIN` | Esse parâmetro controla a fração da memória da GPU disponível para inicializar CUDA/cuDNN e outras bibliotecas de GPU. `0.2` significa que 20% da memória da GPU disponível é reservada para inicializar CUDA/cuDNN e outras bibliotecas de GPU, e 80% da memória da GPU disponível é alocada igualmente entre os processos de TF. A memória da GPU é pré-alocada, a menos que a opção `allow_growth` esteja habilitada. | 
| `SAGEMAKER_TFS_INTER_OP_PARALLELISM` | Isso está relacionado à variável `inter_op_parallelism_threads`. Essa variável determina o número de threads usados por operações independentes sem bloqueio. `0` significa que o sistema escolhe um número apropriado. | 
| `SAGEMAKER_TFS_INTRA_OP_PARALLELISM` | Isso está relacionado à variável `intra_op_parallelism_threads`. Isso determina o número de threads que podem ser usados em determinadas operações, como multiplicação de matrizes e reduções para aumentos de velocidade. Um valor de `0` significa que o sistema escolhe um número apropriado. | 
| `SAGEMAKER_GUNICORN_WORKERS` | Isso rege o número de processos de trabalho que o Gunicorn deve gerar para lidar com solicitações. Esse valor é usado em combinação com outros parâmetros para derivar um conjunto que maximiza a throughput da inferência. Além disso, `SAGEMAKER_GUNICORN_WORKER_CLASS` rege o tipo de operadores gerados, normalmente `async` ou `gevent`. | 
| `SAGEMAKER_GUNICORN_WORKER_CLASS` | Isso rege o número de processos de trabalho que o Gunicorn deve gerar para lidar com solicitações. Esse valor é usado em combinação com outros parâmetros para derivar um conjunto que maximiza a throughput da inferência. Além disso, `SAGEMAKER_GUNICORN_WORKER_CLASS` rege o tipo de operadores gerados, normalmente `async` ou `gevent`. | 
| `OMP_NUM_THREADS` | O Python usa internamente o OpenMP para implementar multithreading em processos. Normalmente, são gerados threads equivalentes ao número de núcleos de CPU. Mas quando implementado em cima do Simultaneous Multi Threading (SMT), como o HypeThreading da Intel, um determinado processo pode substituir um núcleo em particular ao gerar duas vezes mais threads do que o número real de núcleos de CPU. Em certos casos, um binário Python pode acabar gerando até quatro vezes mais threads do que os núcleos de processador disponíveis. Portanto, uma configuração ideal para esse parâmetro, se você tiver excesso de assinaturas de núcleos disponíveis usando threads de trabalho, é `1` ou metade do número de núcleos de CPU em uma CPU com o SMT ativado. | 
| `TF_DISABLE_MKL`<br />`TF_DISABLE_POOL_ALLOCATOR` | Em alguns casos, desativar o MKL pode acelerar a inferência se `TF_DISABLE_MKL` e `TF_DISABLE_POOL_ALLOCATOR` estiverem definidos como `1`. | 

**PyTorch**


| Variável de ambiente | Descrição | 
| --- | --- | 
| `SAGEMAKER_TS_MAX_BATCH_DELAY` | Este é o tempo máximo de atraso do lote que o TorchServe espera para receber. | 
| `SAGEMAKER_TS_BATCH_SIZE` | Se o TorchServe não receber o número de solicitações especificado em `batch_size` antes que o cronômetro pare, ele envia as solicitações recebidas para o manipulador do modelo. | 
| `SAGEMAKER_TS_MIN_WORKERS` | O número mínimo de operadores para os quais o TorchServe pode reduzir a escala verticalmente. | 
| `SAGEMAKER_TS_MAX_WORKERS` | O número máximo de operadores para os quais o TorchServe pode aumentar a escala verticalmente. | 
| `SAGEMAKER_TS_RESPONSE_TIMEOUT` | O atraso de tempo, após o qual a inferência expira na ausência de uma resposta. | 
| `SAGEMAKER_TS_MAX_REQUEST_SIZE` | O tamanho máximo da carga útil do TorchServe. | 
| `SAGEMAKER_TS_MAX_RESPONSE_SIZE` | O tamanho máximo da resposta do TorchServe. | 

**Servidor multimodelo (MMS)**


| Variável de ambiente | Descrição | 
| --- | --- | 
| `job_queue_size` | Esse parâmetro é útil para ajustar quando você tem um cenário em que o tipo de carga útil da solicitação de inferência é grande e, devido ao tamanho da carga útil ser maior, você pode ter maior consumo de memória de pilha da JVM na qual essa fila está sendo mantida. Idealmente, talvez você queira manter os requisitos de memória de pilha da JVM mais baixos e permitir que os operadores do Python aloquem mais memória para o fornecimento real do modelo. A JVM serve apenas para receber as solicitações HTTP, enfileirá-las e expedi-las aos operadores baseados em Python para inferência. Se você aumentar o `job_queue_size`, poderá acabar aumentando o consumo de memória de pilha da JVM e, por fim, retirar memória do host que poderia ter sido usada por operadores do Python. Portanto, tenha precaução ao ajustar esse parâmetro também. | 
| `default_workers_per_model` | Esse parâmetro é para o fornecimento do modelo de backend e pode ser útil ajustá-lo, pois este é o componente crítico do fornecimento do modelo geral, baseado em quais processos do Python geram threads para cada modelo. Se esse componente for mais lento (ou não estiver ajustado adequadamente), o ajuste do front-end pode não ser efetivo. | 

## P: Como posso garantir que meu contêiner dê compatibilidade com a inferência assíncrona?
<a name="async-troubleshooting-q3"></a>

Você pode usar o mesmo contêiner para inferência assíncrona que usa para inferência em tempo real ou Batch Transform. Você deve confirmar se os tempos limite e os limites de tamanho da carga útil em seu contêiner estão definidos para lidar com cargas úteis maiores e tempos limite mais longos.

## P: Quais são os limites específicos da inferência assíncrona? Eles podem ser ajustados?
<a name="async-troubleshooting-q4"></a>

Consulte os seguintes limites para inferência assíncrona:
+ Limite de tamanho da carga útil: 1 GB
+ Tempo limite máximo: uma solicitação pode levar até 60 minutos.
+ TimeToLive da mensagem na fila (TTL): 6 horas
+ Número de mensagens que podem ser colocadas dentro do Amazon SQS: Ilimitado. No entanto, há uma cota de 120.000 para o número de mensagens em andamento para uma fila padrão e 20.000 para uma fila FIFO.

## P: Quais métricas são melhores para definir com dimensionamento automático na inferência assíncrona? Posso ter várias políticas de escalabilidade?
<a name="async-troubleshooting-q5"></a>

Em geral, com a inferência assíncrona, você pode aumentar a escala horizontalmente com base em invocações ou instâncias. Para métricas de invocação, é uma boa ideia analisar sua `ApproximateBacklogSize`, métrica que define o número de itens em sua fila que ainda não foram processados. Você pode utilizar essa métrica ou sua métrica `InvocationsPerInstance` para entender em qual TPS pode estar havendo controle de utilização. No nível da instância, verifique seu tipo de instância e a utilização da CPU/GPU para definir quando aumentar a escala horizontalmente. Se uma instância singular está acima de 60 a 70% da capacidade, geralmente é um bom sinal de que você está saturando seu hardware.

Não recomendamos ter várias políticas de escalabilidade, pois elas podem entrar em conflito e causar confusão no nível do hardware, gerando atrasos na quando aumentar a escala horizontalmente.

## P: Por que meu endpoint assíncrono está encerrando uma instância `Unhealthy` e as solicitações de atualização do dimensionamento automático estão falhando?
<a name="async-troubleshooting-q6"></a>

Verifique se seu contêiner é capaz de lidar com solicitações de ping e invocação simultaneamente. As solicitações de invocação do SageMaker AI levam aproximadamente 3 minutos e, nesse período, geralmente várias solicitações de ping acabam falhando devido ao tempo limite que faz com que o SageMaker AI detecte seu contêiner como `Unhealthy`.

## P: Pode `MaxConcurrentInvocationsPerInstance` funcionar para o meu contêiner modelo BYOC com as configurações ningx/gunicorn/flask?
<a name="async-troubleshooting-q7"></a>

Sim. `MaxConcurrentInvocationsPerInstance` é um atributo dos endpoints assíncronos. Isso não depende da implantação do contêiner personalizado. `MaxConcurrentInvocationsPerInstance` controla a taxa na qual as solicitações de invocação são enviadas para o contêiner do cliente. Se esse valor for definido como `1`, apenas 1 solicitação será enviada para o contêiner por vez, não importa quantos operadores estejam no contêiner do cliente.

## P: Como posso depurar erros do servidor de modelos (500) no meu endpoint assíncrono?
<a name="async-troubleshooting-q8"></a>

O erro significa que o contêiner do cliente retornou um erro. O SageMaker AI não controla o comportamento dos contêineres dos clientes. Ele simplesmente exibe a resposta de `ModelContainer` e não tenta novamente. Se quiser, você pode configurar a invocação para tentar novamente em caso de falha. Sugerimos que ative o log de contêineres e verifique seus logs de contêineres para encontrar a causa raiz do erro 500 em seu modelo. Verifique também as métricas `CPUUtilization` e `MemoryUtilization` no momento da falha. Você também pode configurar o [S3FailurePath](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AsyncInferenceOutputConfig.html#sagemaker-Type-AsyncInferenceOutputConfig-S3FailurePath) para a resposta do modelo no Amazon SNS como parte das notificações de erro assíncronas para investigar falhas.

## P: Como posso saber se `MaxConcurrentInvocationsPerInstance=1` tem efeito? Há alguma métrica que eu possa verificar?
<a name="async-troubleshooting-q9"></a>

Você pode verificar a métrica `InvocationsProcesssed`, que deve estar alinhada com o número de invocações que você espera que sejam processadas em um minuto baseado em uma única simultaneidade.

## P: Como posso monitorar o sucesso e as falhas das minhas solicitações de invocação? Quais são as práticas recomendadas?
<a name="async-troubleshooting-q10"></a>

A prática recomendada é habilitar o Amazon SNS, que é um serviço de notificação para aplicações orientados a mensagens, em que vários assinantes solicitam e recebem notificações “push” de mensagens urgentes de uma variedade de protocolos de transporte, incluindo HTTP, Amazon SQS e e-mail. A inferência assíncrona publica notificações quando você cria um endpoint com `CreateEndpointConfig` e especifica um tópico do Amazon SNS.

Para usar o Amazon SNS para verificar os resultados da predição do seu endpoint assíncrono, primeiro você precisa criar um tópico, assinar o tópico, confirmar sua assinatura no tópico e anotar o nome do recurso da Amazon (ARN) desse tópico. Para obter informações detalhadas sobre como criar, assinar e encontrar o Amazon ARN de um tópico do Amazon SNS, consulte [Configurando o Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html) no *Guia do desenvolvedor do Amazon SNS*. Para obter mais informações sobre como usar o Amazon SNS com inferência assíncrona, consulte [Verificar resultados da predição](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-check-predictions.html).

## P: Posso definir uma política de escalabilidade que aumente a escala verticalmente a partir de zero instâncias ao receber uma nova solicitação?
<a name="async-troubleshooting-q11"></a>

Sim. A inferência assíncrona fornece um mecanismo para reduzir a escala verticalmente até zero instâncias quando não há solicitações. Se a escala do seu endpoint tiver sido reduzida verticalmente para zero instâncias durante esses períodos, ele não aumentará a escala verticalmente outra vez até que o número de solicitações na fila exceda a meta especificada em sua política de escalabilidade. Isso pode resultar em longos tempos de espera para solicitações na fila. Nesses casos, se você quiser aumentar a escala verticalmente a partir de zero instâncias para novas solicitações menores do que o destino de fila especificado, você pode usar uma política de escalabilidade adicional chamada `HasBacklogWithoutCapacity`. Para obter mais informações sobre como definir essa política de escalabilidade, consulte [Escalabilidade automaticamente de um endpoint assíncrono](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference-autoscale.html#async-inference-autoscale-scale-up).

## P: Estou recebendo um erro informando que o tipo de instância não é compatível com inferência assíncrona. Quais são os tipos de instância compatíveis com a inferência assíncrona?
<a name="async-troubleshooting-q12"></a>

Para obter uma lista completa de instâncias compatíveis com inferência assíncrona por região, consulte [preços do SageMaker.](https://aws.amazon.com/sagemaker/pricing/) Verifique se a instância necessária está disponível na sua região antes de continuar.