Solução de problemas de implantação de modelo remoto

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

Pré-requisitos

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

• O SDK do Azure Machine Learning.

• CLI do Azure.

• A extensão da CLI v1 para o Azure Machine Learning.

  Importante

  Alguns dos comandos da CLI do Azure neste artigo usam a extensão , ou v1, para o azure-cli-mlAzure Machine Learning. O suporte para a 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 mlextensão , ou v2, antes de 30 de setembro de 2025. Para obter mais informações sobre a extensão v2, consulte Extensão CLI do Azure ML e Python SDK v2.

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

Quando você implanta um modelo para computação não local no Aprendizado de Máquina do Azure, as seguintes coisas acontecem:

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

A principal diferença ao usar uma implantação local é que a imagem do contêiner é criada em sua máquina local, e é por isso que você precisa ter o Docker instalado para uma implantação local.

Compreender essas etapas de alto nível deve ajudá-lo a entender onde os erros estão acontecendo.

Obter logs de implantação

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

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 você tiver problemas ao implantar um modelo no ACI ou AKS, implante-o como um serviço Web local. A utilização de um serviço Web local facilita a resolução de problemas. Para solucionar problemas de uma implantação localmente, consulte 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 seu script de entrada (score.py). Caso o script de pontuação subjacente tenha um bug, o servidor não consegue inicializar ou servir o modelo. Em vez disso, ele lança uma exceção e o local onde os problemas ocorreram. Saiba mais sobre o Servidor HTTP de inferência do Azure Machine Learning

1. Instale o azureml-inference-server-http pacote a partir 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
   

O contêiner não pode ser agendado

Ao implantar um serviço em um destino de computação do Serviço Kubernetes do Azure, o Aprendizado de Máquina do Azure tenta agendar o serviço com a quantidade de recursos solicitada. 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. Você pode 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 indicará 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 isso significa que o serviço requer GPUs e há três nós no cluster que não têm GPUs disponíveis. Isso pode ser resolvido adicionando mais nós se você estiver usando um SKU de GPU, mudando para um SKU habilitado para GPU se não estiver ou alterando seu ambiente para não exigir GPUs.

Falha ao iniciar o serviço

Depois que a imagem é criada com êxito, o sistema tenta iniciar um contêiner usando sua configuração de implantação. A função init() no script de classificação é invocada pelo sistema como parte do processo de inicialização do contentor. Se houver exceções não detetadas na init() função, você pode ver o erro CrashLoopBackOff na mensagem de erro.

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

Falha ao iniciar o contentor azureml-fe-aci

Ao implantar um serviço em um destino de computação da Instância de Contêiner do Azure, o Aprendizado de Máquina do Azure tenta criar um contêiner front-end com o nome azureml-fe-aci da solicitação de inferência. Se azureml-fe-aci falhar, você pode ver os logs executando az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci. Você pode seguir a mensagem de erro nos logs para fazer a correção.

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

A função falha: get_model_path()

Muitas vezes, na init() função 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 pasta do modelo não puder ser encontrado, a função falhará. A maneira mais fácil de depurar esse erro é executar o código Python abaixo no shell do contêiner:

APLICA-SE A: Python SDK 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'))

Este exemplo imprime o caminho local (relativo a /var/azureml-app) no contêiner onde o script de pontuação espera localizar o arquivo ou pasta modelo. Em seguida, você pode verificar se o arquivo ou pasta está realmente onde se espera que esteja.

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

A função falha: run(input_data)

Se o serviço for implantado com êxito, mas falhar quando você postar dados no ponto de extremidade de pontuação, você poderá adicionar uma instrução de captura de erro em sua run(input_data) função para que ela retorne uma mensagem de erro detalhada. 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})

Nota: O retorno de mensagens de erro da run(input_data) chamada deve ser feito 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 estado de HTTP 502

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

Código de estado de HTTP 503

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

As decisões de aumentar/reduzir a escala baseiam-se na utilização das réplicas de contêiner atuais. O número de réplicas ocupadas (processando uma solicitação) dividido pelo número total de réplicas atuais é a utilização atual. Se esse número exceder autoscale_target_utilizationo , mais réplicas serão criadas. Se for menor, as réplicas serão reduzidas. As decisões para adicionar réplicas são rápidas 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 do destino de dimensionamento automático é definida como 70%, o que significa que o serviço pode lidar com picos de solicitações por segundo (RPS) de até 30%.

Há duas coisas que podem ajudar a 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 a meta de utilização definindo o autoscale_target_utilization para um valor mais baixo.

  Importante

  Essa alteração não faz com que as réplicas sejam criadas mais rapidamente. Em vez disso, eles são criados em um limite de utilização mais baixo. Em vez de esperar até que o serviço seja 70% utilizado, alterar o valor para 30% faz com que réplicas sejam criadas quando ocorre uma utilização de 30%.

  Se o serviço Web já estiver usando as réplicas máximas atuais e você ainda estiver vendo 503 códigos de status, aumente o autoscale_max_replicas valor 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 mais alto. Você pode calcular as réplicas necessárias usando o código a seguir, substituindo valores por valores específicos para seu 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)
  

  Nota

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

Para obter mais informações sobre a configuração autoscale_target_utilization, autoscale_max_replicase autoscale_min_replicas para, consulte a referência do módulo AksWebservice .

Código de estado de HTTP 504

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

Você pode aumentar o tempo limite ou tentar acelerar o serviço modificando o score.py para remover 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 em um loop infinito.

Outras mensagens de erro

Execute estas ações para os seguintes erros:

Depuração avançada

É possível que tenha de depurar interativamente o código Python contido na implementação de modelo. Por exemplo, se o script de entrada estiver falhando e o motivo não puder ser determinado com registro extra. Usando o Visual Studio Code e a depuração, você pode anexar ao código em execução dentro do contêiner do Docker.

Para obter mais informações, veja a depuração interativa no guia do VS Code.

Fórum de usuários de implantação de modelo

Próximos passos

Saiba mais sobre a implementação:

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