Solucionar problemas de implantação de modelo remoto

Veja como solucionar problemas e resolver (ou contornar) erros que você pode encontrar ao implantar um modelo em ACI (Instâncias de Contêiner do Azure) e AKS (Serviço de Kubernetes do Azure) usando Azure Machine Learning.

Pré-requisitos

• Uma assinatura do Azure. Experimente a versão gratuita ou paga do Azure Machine Learning.

• O SDK do Azure Machine Learning.

• O CLI do Azure.

• A Extensão v1 da CLI do Azure Machine Learning.

  Importante

  Alguns comandos da CLI do Azure neste artigo usam a extensão azure-cli-ml ou v1 do Azure Machine Learning. O suporte à extensão v1 terminará em 30 de setembro de 2025. Você poderá instalar e usar a extensão v1 até essa data.

  Recomendamos que você faça a transição para a extensão ml ou v2, antes de 30 de setembro de 2025. Para obter mais informações sobre a extensão v2, confira Extensão da CLI do Azure ML e SDK do Python v2.

Etapas para a implantação do Docker de modelos de aprendizado de máquina

Quando você implanta um modelo em uma computação não local no Azure Machine Learning, ocorre o seguinte:

1. O Dockerfile especificado no seu objeto de ambiente em InferenceConfig é enviado para a nuvem, juntamente com o conteúdo do seu diretório de origem
2. Se uma imagem criada anteriormente não estiver disponível no registro de contêiner, uma nova imagem do Docker será criada na nuvem e armazenada no registro de contêiner padrão do seu workspace.
3. A imagem do Docker do registro de contêiner é baixada para seu destino de computação.
4. O armazenamento de blob padrão do seu workspace é montado no seu destino de computação, oferecendo acesso a modelos registrados
5. O servidor Web é inicializado com a execução da função do script de entrada init()
6. Quando o modelo implantado recebe uma solicitação, sua função run() manipula essa solicitação

A principal diferença ao usar uma implantação local é que a imagem de contêiner é criada no computador local. Por isso, você precisa ter o Docker instalado para uma implantação local.

Entender essas etapas de alto nível deve ajudar a entender onde estão ocorrendo erros.

Obter logs de implantação

A primeira etapa na depuração de erros é obter logs de implantação. Primeiro, siga as instruções aqui para se conectar ao seu workspace.

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

print(ws.webservices)

# Choose the webservice you are interested in

from azureml.core import Webservice

service = Webservice(ws, '<insert name of webservice>')
print(service.get_logs())

Depurar Localmente

Se tiver problema ao implantar um modelo ao ACI ou AKS, implante-o como serviço Web local. Usar um serviço Web local facilita a solução de problemas. Para solucionar problemas de uma implantação localmente, confira o artigo de solução de problemas local.

Servidor HTTP de inferência do Azure Machine Learning

O servidor de inferência local permite que você depure rapidamente o script de entrada (score.py). Caso o script de pontuação subjacente tenha um bug, ocorre uma falha de inicialização do servidor ou de fornecimento do modelo. Em vez disso, ele gera uma exceção e o local onde ocorreram os problemas. Saiba mais sobre o servidor HTTP de inferência do Azure Machine Learning

1. Instale o pacote azureml-inference-server-http do feed pypi:

   python -m pip install azureml-inference-server-http
   

2. Inicie o servidor e defina score.py como o script de entrada:

   azmlinfsrv --entry_script score.py
   

3. Envie uma solicitação de pontuação para o servidor usando curl:

   curl -p 127.0.0.1:5001/score
   

Não é possível agendar o contêiner

Ao implantar um serviço em um destino de computação do Serviço de Kubernetes do Azure, o Azure Machine Learning tentará agendar o serviço com a quantidade solicitada de recursos. Se não houver nós disponíveis no cluster com a quantidade apropriada de recursos após 5 minutos, a implantação falhará. A mensagem de falha é Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. É possível resolver esse erro adicionando mais nós, alterando a SKU dos nós ou alterando os requisitos de recursos do serviço.

A mensagem de erro normalmente indica qual recurso você precisa mais, por exemplo, se você vir uma mensagem de erro indicando 0/3 nodes are available: 3 Insufficient nvidia.com/gpu que significa que o serviço requer GPUs e existem três nós no cluster que não possuem GPUs disponíveis. Isso pode ser resolvido adicionando mais nós, se você estiver usando um SKU de GPU, alternando para um SKU habilitado para GPU, se não estiver, ou alterando o ambiente para não exigir GPUs.

Falhas na inicialização do serviço

Depois que a imagem é criada com êxito, o sistema tenta iniciar um contêiner usando a configuração de implantação. Como parte do processo de inicialização do contêiner, a função init() em seu script de pontuação é invocada pelo sistema. Se houver exceções não capturadas na função init(), você poderá ver o erro CrashLoopBackOff na mensagem de erro.

Use as informações no artigo Inspecionar o log do Docker.

Falha na inicialização do contêiner azureml-fe-aci

Durante a implantação de um serviço em um destino de computação da Instância de Contêiner do Azure, o Azure Machine Learning tenta criar um contêiner de front-end com o nome azureml-fe-aci para a solicitação de inferência. Se o azureml-fe-aci falhar, veja os logs executando az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. Siga a mensagem de erro nos logs para fazer a correção.

A falha mais comum de azureml-fe-aci o é que a chave ou o certificado SSL fornecido é inválido.

Falha de função: get_model_path()

Geralmente, na função init() no script de pontuação, a função Model.get_model_path() é chamada para localizar um arquivo de modelo ou uma pasta de arquivos de modelo no contêiner. Se o arquivo ou a pasta do modelo não puder ser encontrado, a função falhará. A maneira mais fácil para depurar esse erro é executar o código do Python no shell do contêiner abaixo:

APLICA-SE A: SDK do Python do AzureML v1

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

Esse exemplo imprime o caminho local (relativo ao /var/azureml-app) no contêiner em que o seu script de pontuação está esperando encontrar o arquivo ou a pasta de modelo. Em seguida, você pode verificar se o arquivo ou a pasta realmente está no local que deveria.

Definir o nível de log como DEBUG poderá fazer com que as informações adicionais sobre a causa sejam registradas, o que podem ser útil para identificar a falha.

Falha de função: run(input_data)

Se o serviço for implantado com êxito, mas falhar quando você publicar dados no ponto de extremidade de pontuação, você poderá adicionar o erro capturando instrução na função run(input_data) de modo que ele retorne a mensagem de erro detalhada em vez disso. Por exemplo:

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

Observação: O retorno de mensagens de erro da chamada run(input_data) deve ser feito para apenas para fins de depuração. Por motivos de segurança, você não deve retornar mensagens de erro dessa maneira em um ambiente de produção.

Código de status HTTP 502

Um código de status 502 indica que o serviço gerou uma exceção ou falhou no método run() do arquivo score.py. Use as informações neste artigo para depurar o arquivo.

Código de status HTTP 503

As implantações do Serviço de Kubernetes do Azure dão suporte ao dimensionamento automático, que permite que as réplicas sejam adicionadas para dar suporte à carga extra. O dimensionador automático foi criado para lidar com mudanças gradativas na carga. Se você receber grandes picos em solicitações por segundo, os clientes podem receber um código de status HTTP 503. Embora o dimensionamento automático reaja rapidamente, o AKS leva um tempo significativo para criar mais contêineres.

As decisões para dimensionar verticalmente/horizontalmente baseiam-se na utilização das réplicas de contêiner. O número de réplicas ocupadas (com o processamento de uma solicitação) dividido pelo número total de réplicas é a utilização atual. Se esse número exceder autoscale_target_utilization, mais réplicas serão criadas. Se for menor, as réplicas serão reduzidas. As decisões para adicionar réplicas são adiantadas e rápidas (cerca de 1 segundo). As decisões para remover réplicas são conservadoras (cerca de 1 minuto). Por padrão, a utilização de destino do dimensionamento automático é definida como 70% , o que significa que o serviço pode lidar com picos em solicitações por segundo (RPS) de até 30% .

As duas ações a seguir podem evitar códigos de status 503:

• Altere o nível de utilização no qual o dimensionamento automático cria novas réplicas. Você pode ajustar o destino de utilização, definindo o autoscale_target_utilization como um valor mais baixo.

  Importante

  Essa alteração não faz com que as réplicas sejam criadas mais rapidamente. Em vez disso, elas são criadas no limite inferior de utilização. Em vez de aguardar até que o serviço seja 70% utilizado, alterar o valor para 30% faz com que as réplicas sejam criadas quando ocorrer uma utilização de 30%.

  Se o serviço Web já estiver usando as réplicas máximas atuais e você ainda estiver vendo os códigos de status 503, aumente o valor autoscale_max_replicas para aumentar o número máximo de réplicas.

• Altere o número mínimo de réplicas. Aumentar as réplicas mínimas fornece um pool maior para lidar com os picos de entrada.

  Para aumentar o número mínimo de réplicas, defina autoscale_min_replicas como um valor maior. Você pode calcular as réplicas necessárias usando o código a seguir, substituindo os valores por valores específicos para o projeto:

  from math import ceil
  # target requests per second
  targetRps = 20
  # time to process the request (in seconds)
  reqTime = 10
  # Maximum requests per container
  maxReqPerContainer = 1
  # target_utilization. 70% in this example
  targetUtilization = .7
  
  concurrentRequests = targetRps * reqTime / targetUtilization
  
  # Number of container replicas
  replicas = ceil(concurrentRequests / maxReqPerContainer)
  

  Observação

  Se você receber picos de solicitação maiores do que as novas réplicas mínimas podem suportar, você poderá receber códigos 503 novamente. Por exemplo, à medida que o tráfego para o serviço aumenta, talvez seja necessário aumentar as réplicas mínimas.

Para obter mais informações sobre como definir autoscale_target_utilization, autoscale_max_replicas e autoscale_min_replicas, confira a referência do módulo AksWebservice.

Código de status HTTP 504

Um código de status 504 indica que a solicitação atingiu o tempo limite. O tempo limite padrão é 1 minuto.

Você pode aumentar o tempo limite ou tentar acelerar o serviço, modificando o score.py para remover as chamadas desnecessárias. Se essas ações não corrigirem o problema, use as informações neste artigo para depurar o arquivo score.py. O código pode estar em um estado não responsivo ou loop infinito.

Outras mensagens de erro

Efetue estas ações para os seguintes erros:

Depuração avançada

Talvez seja necessário depurar interativamente o código Python contido na implantação de modelo. Por exemplo, se o script de entrada estiver falhando e o motivo não puder ser determinado por registro em log adicional. Usando o Visual Studio Code e o debugpy, você pode anexar ao código em execução dentro do contêiner do Docker.

Para obter mais informações, acesse a Depuração interativa no guia VS Code.

Fórum do usuário de implantação de modelo

Próximas etapas

Saiba mais sobre a implantação:

• Como e onde implantar
• Como executar e depurar experimentos localmente