Partilhar via

Solucionar problemas de implantação e pontuação de endpoints online

  • Artigo

APLICA-SE A:Azure CLI ml extension v2 (current)Python SDK azure-ai-ml v2 (current)

Este artigo descreve como solucionar e resolver problemas comuns de implantação e pontuação de ponto de extremidade online do Azure Machine Learning.

A estrutura do documento reflete a maneira como você deve abordar a solução de problemas:

  1. Utilize a implementação local para testar e depurar os modelos localmente antes de os implementar na cloud.
  2. Utilize registos dos contentores para ajudar a depurar os problemas.
  3. Compreenda os erros de implementação comuns que podem surgir e como corrigi-los.

A seção Códigos de status HTTP explica como os erros de invocação e previsão são mapeados para códigos de status HTTP quando você pontua pontos de extremidade com solicitações REST.

Pré-requisitos

  • Uma subscrição ativa do Azure com a versão gratuita ou paga do Azure Machine Learning. Obtenha uma subscrição de avaliação gratuita do Azure.

Rastreamento de solicitações

Há dois cabeçalhos de rastreamento suportados:

  • x-request-id está reservado para rastreamento de servidores. O Azure Machine Learning substitui esse cabeçalho para garantir que seja um GUID válido. Ao criar um tíquete de suporte para uma solicitação com falha, anexe a ID da solicitação com falha para agilizar a investigação. Como alternativa, forneça o nome da região e o nome do ponto de extremidade.

  • x-ms-client-request-id está disponível para cenários de rastreamento de cliente. Este cabeçalho aceita apenas caracteres alfanuméricos, hífenes e sublinhados, e é truncado até um máximo de 40 caracteres.

Implementar localmente

Implantação local significa implantar um modelo em um ambiente Docker local. A implantação local oferece suporte à criação, atualização e exclusão de um ponto de extremidade local e permite que você invoque e obtenha logs do ponto de extremidade. A implantação local é útil para testar e depurar antes da implantação na nuvem.

Gorjeta

Você também pode usar o pacote Python do servidor HTTP de inferência do Azure Machine Learning para depurar seu script de pontuação localmente. A depuração com o servidor de inferência ajuda você a depurar o script de pontuação antes de implantar em pontos de extremidade locais para que você possa depurar sem ser afetado pelas configurações do contêiner de implantação.

Você pode implantar localmente com a CLI do Azure ou o SDK do Python. O estúdio de Aprendizado de Máquina do Azure não oferece suporte à implantação local ou a pontos de extremidade locais.

Para usar a implantação local, adicione --local ao comando apropriado.

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

As seguintes etapas ocorrem durante a implantação local:

  1. O Docker cria uma nova imagem de contêiner ou extrai uma imagem existente do cache local do Docker. O Docker usa uma imagem existente se uma corresponder à parte do ambiente do arquivo de especificação.
  2. O Docker inicia o novo contêiner com artefatos locais montados, como arquivos de modelo e código.

Para obter mais informações, consulte Implantar e depurar localmente usando um ponto de extremidade local.

Gorjeta

Você pode usar o Visual Studio Code para testar e depurar seus pontos de extremidade localmente. Para obter mais informações, consulte Depurar pontos de extremidade online localmente no Visual Studio Code.

Obter registos dos contentores

Você não pode obter acesso direto a uma máquina virtual (VM) onde um modelo é implantado, mas pode obter logs de alguns dos contêineres que estão sendo executados na VM. A quantidade de informações que você obtém depende do status de provisionamento da implantação. Se o contêiner especificado estiver instalado e em execução, você verá a saída do console. Caso contrário, você receberá uma mensagem para tentar novamente mais tarde.

Você pode obter logs dos seguintes tipos de contêineres:

  • O log do console do servidor de inferência contém a saída das funções de impressão e registro do seu script de pontuação score.py código.
  • Os logs do inicializador de armazenamento contêm informações sobre se os dados de código e modelo baixados com êxito para o contêiner. O contêiner é executado antes que o contêiner do servidor de inferência comece a ser executado.

Para pontos de extremidade online do Kubernetes, os administradores podem acessar diretamente o cluster onde você implanta o modelo e verificar os logs no Kubernetes. Por exemplo:

kubectl -n <compute-namespace> logs <container-name>

Nota

Se você usar o log em Python, certifique-se de usar o nível de log correto, como INFO, para que as mensagens sejam publicadas nos logs.

Ver saída de log de contêineres

Para ver a saída de log de um contêiner, use o seguinte comando:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

Ou

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

Por padrão, os logs são extraídos do servidor de inferência. Você pode obter logs do contêiner do inicializador de armazenamento passando –-container storage-initializer.

Adicione --resource-group e --workspace-name aos comandos se ainda não tiver definido esses parâmetros via az configure. Para ver informações sobre como definir esses parâmetros, ou se você tiver valores definidos no momento, execute o seguinte comando:

az ml online-deployment get-logs -h

Para ver mais informações, adicione --help ou --debug aos comandos.

Erros de implementação comuns

O status da operação de implantação pode relatar os seguintes erros comuns de implantação:

Se você estiver criando ou atualizando uma implantação online do Kubernetes, consulte também Erros comuns específicos para implantações do Kubernetes.

ERRO: ImageBuildFailure

Este erro é retornado quando o ambiente de imagem do Docker está sendo criado. Você pode verificar o log de compilação para obter mais informações sobre a falha. O log de compilação está localizado no armazenamento padrão para seu espaço de trabalho do Azure Machine Learning.

O local exato pode ser retornado como parte do erro, por exemplo "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

As seções a seguir descrevem cenários comuns de falha de compilação de imagem:

Falha de autorização do Registro de Contêiner do Azure

Uma mensagem de erro menciona "container registry authorization failure" quando você não pode acessar o registro de contêiner com as credenciais atuais. A dessincronização de chaves de recursos do espaço de trabalho pode causar esse erro e leva algum tempo para sincronizar automaticamente. No entanto, você pode chamar manualmente a sincronização de chaves com as chaves de sincronização do espaço de trabalho az ml, o que pode resolver a falha de autorização.

Os registros de contêiner que estão atrás de uma rede virtual também podem encontrar esse erro se estiverem configurados incorretamente. Verifique se a rede virtual está configurada corretamente.

Computação de construção de imagem não definida em um espaço de trabalho privado com rede virtual

Se a mensagem de "failed to communicate with the workspace's container registry"erro mencionar , e você estiver usando uma rede virtual, e o registro de contêiner do espaço de trabalho for privado e configurado com um ponto de extremidade privado, será necessário permitir que o Registro de Contêiner crie imagens na rede virtual.

Tempo limite de construção de imagem

Os tempos limite de construção da imagem geralmente são devidos ao fato de uma imagem ser muito grande para poder concluir a construção dentro do período de criação da implantação. Verifique os logs de construção da imagem no local especificado pelo erro. Os logs são cortados no ponto em que a compilação da imagem expirou.

Para resolver esse problema, crie sua imagem separadamente para que a imagem só precise ser puxada durante a criação da implantação. Revise também as configurações de teste padrão se você tiver tempos limite do ImageBuild.

Falha na compilação de imagem genérica

Verifique o log de compilação para obter mais informações sobre a falha. Se nenhum erro óbvio for encontrado no log de compilação e a última linha for Installing pip dependencies: ...working..., uma dependência pode estar causando o erro. Fixar dependências de versão em seu arquivo conda pode corrigir esse problema.

Tente implantar localmente para testar e depurar seus modelos antes de implantar na nuvem.

ERRO: OutOfQuota

Os seguintes recursos podem ficar sem cota ao usar os serviços do Azure:

Apenas para endpoints online do Kubernetes, o recurso do Kubernetes também pode ficar sem cota.

Quota de CPU

Você precisa ter cota de computação suficiente para implantar um modelo. A cota de CPU define quantos núcleos virtuais estão disponíveis por assinatura, por espaço de trabalho, por SKU e por região. Cada implantação subtrai da cota disponível e a adiciona de volta após a exclusão, com base no tipo de SKU.

Você pode verificar se há implantações não utilizadas que você pode excluir ou pode enviar uma solicitação para um aumento de cota.

Cota de cluster

O OutOfQuota erro ocorre quando você não tem cota suficiente de cluster de computação do Azure Machine Learning. A cota define o número total de clusters por assinatura que você pode usar ao mesmo tempo para implantar nós de CPU ou GPU na nuvem do Azure.

Quota de disco

O OutOfQuota erro ocorre quando o tamanho do modelo é maior do que o espaço em disco disponível e o modelo não pode ser baixado. Tente usar uma SKU com mais espaço em disco ou reduzir o tamanho da imagem e do modelo.

Quota de memória

O OutOfQuota erro ocorre quando o espaço ocupado pela memória do modelo é maior do que a memória disponível. Experimente um SKU com mais memória.

Quota de atribuição de funções

Quando você cria um ponto de extremidade online gerenciado, a atribuição de função é necessária para que a identidade gerenciada acesse os recursos do espaço de trabalho. Se você atingir o limite de atribuição de função, tente excluir algumas atribuições de função não utilizadas nesta assinatura. Você pode verificar todas as atribuições de função selecionando Controle de acesso para sua assinatura do Azure no portal do Azure.

Cota de ponto final

Tente eliminar alguns pontos finais não utilizados nesta subscrição. Se todos os seus endpoints estiverem ativamente em uso, tente solicitar um aumento do limite de endpoints. Para saber mais sobre o limite de pontos de extremidade, consulte Quota de pontos de extremidade com pontos de extremidade online e pontos de extremidade em lote do Azure Machine Learning.

Cota do Kubernetes

O OutOfQuota erro ocorre quando a CPU ou a memória solicitada não podem ser fornecidas devido aos nós não serem escalonáveis para esta implantação. Por exemplo, os nós podem estar isolados ou indisponíveis.

A mensagem de erro normalmente indica a insuficiência de recursos no cluster, por exemplo OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods.... Essa mensagem significa que há muitos pods no cluster e não há recursos suficientes para implantar o novo modelo com base em sua solicitação.

Tente as seguintes atenuações para resolver esse problema:

  • Os operadores de TI que mantêm o cluster Kubernetes podem tentar adicionar mais nós ou limpar alguns pods não utilizados no cluster para liberar alguns recursos.

  • Os engenheiros de aprendizado de máquina que implantam modelos podem tentar reduzir a solicitação de recursos da implantação.

    • Se você definir diretamente a solicitação de recurso na configuração de implantação por meio da seção de recursos, tente reduzir a solicitação de recurso.
    • Se você usar instance_type para definir recurso para implantação de modelo, entre em contato com o operador de TI para ajustar a configuração de recurso do tipo de instância. Para obter mais informações, consulte Criar e gerenciar tipos de instância.

Capacidade de VM em toda a região

Devido à falta de capacidade do Azure Machine Learning na região, o serviço não conseguiu provisionar o tamanho de VM especificado. Tente novamente mais tarde ou tente implantar em uma região diferente.

Outras quotas

Para executar o arquivo de score.py fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos de que o score.py precisa. Em seguida, o Azure Machine Learning executa o script de pontuação nesse contêiner. Se o contêiner não puder ser iniciado, a pontuação não poderá acontecer. O contêiner pode estar solicitando mais recursos do que o instance_type pode suportar. Considere atualizar a instance_type implantação on-line.

Para obter o motivo exato do erro, execute a seguinte ação.

Execute o seguinte comando:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

ERRO: BadArgument

Você pode receber esse erro ao usar endpoints online gerenciados ou pontos de extremidade online do Kubernetes, pelos seguintes motivos:

Você também pode obter esse erro ao usar apenas endpoints online do Kubernetes, pelos seguintes motivos:

A subscrição não existe

A assinatura do Azure referenciada deve ser existente e ativa. Este erro ocorre quando o Azure não consegue encontrar o ID de subscrição que introduziu. O erro pode ser devido a um erro de digitação na ID da assinatura. Verifique se o ID da assinatura foi inserido corretamente e está ativo no momento.

Erro de autorização

Depois de provisionar o recurso de computação quando você cria uma implantação, o Azure extrai a imagem do contêiner do usuário do registro do contêiner do espaço de trabalho e monta o modelo do usuário e os artefatos de código no contêiner do usuário a partir da conta de armazenamento do espaço de trabalho. O Azure usa identidades gerenciadas para acessar a conta de armazenamento e o registro de contêiner.

Se você criar o ponto de extremidade associado com identidade atribuída pelo usuário, a identidade gerenciada do usuário deverá ter permissão de leitor de dados de blob de armazenamento na conta de armazenamento do espaço de trabalho e permissão AcrPull no registro do contêiner do espaço de trabalho. Verifique se a identidade atribuída pelo usuário tem as permissões corretas.

Se você criar o ponto de extremidade associado com identidade atribuída ao sistema, a permissão RBAC (controle de acesso baseado em função) do Azure será concedida automaticamente e não serão necessárias mais permissões. Para obter mais informações, consulte Erro de autorização do registro de contêiner.

Especificação de função de modelo inválida

Este erro ocorre quando uma função de modelo foi especificada incorretamente. Corrija a política ou remova a atribuição de política a ser desbloqueada. A mensagem de erro pode incluir o nome da atribuição de política e a definição de política para ajudá-lo a depurar esse erro. Consulte Estrutura de definição de política do Azure para obter dicas para evitar falhas de modelo.

Não é possível transferir a imagem de contentor do utilizador

O contêiner do usuário pode não ser encontrado. Verifique os logs do contêiner para obter mais detalhes.

Verifique se a imagem do contêiner está disponível no registro do contêiner do espaço de trabalho. Por exemplo, se a imagem for testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, você pode usar o seguinte comando para verificar o repositório:

az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table`

Não é possível transferir o modelo de utilizador

O modelo de usuário pode não ser encontrado. Verifique os logs do contêiner para obter mais detalhes. Certifique-se de registrar o modelo no mesmo espaço de trabalho da implantação.

Para mostrar detalhes de um modelo em um espaço de trabalho, execute a seguinte ação. Você deve especificar a versão ou o rótulo para obter as informações do modelo.

Execute o seguinte comando:

az ml model show --name <model-name> --version <version>

Verifique também se os blobs estão presentes na conta de armazenamento do espaço de trabalho. Por exemplo, se o blob for https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, você pode usar o seguinte comando para verificar se o blob existe:

az storage blob exists --account-name <storage-account-name> --container-name <container-name> --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>

Se o blob estiver presente, você pode usar o seguinte comando para obter os logs do inicializador de armazenamento:

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

O formato de modelo MLflow com rede privada não é suportado

Você não pode usar o recurso de rede privada com um formato de modelo MLflow se estiver usando o método de isolamento de rede herdado para pontos de extremidade online gerenciados. Se você precisar implantar um modelo MLflow com a abordagem de implantação sem código, tente usar uma rede virtual gerenciada por espaço de trabalho.

Solicitações de recursos maiores que os limites

Os pedidos de recursos devem ser inferiores ou iguais a limites. Se você não definir limites, o Aprendizado de Máquina do Azure definirá valores padrão quando você anexar sua computação a um espaço de trabalho. Você pode verificar os limites no portal do Azure ou usando o az ml compute show comando.

Azureml-fe não está pronto

O componente front-end azureml-fe que roteia solicitações de inferência de entrada para serviços implantados é instalado durante a instalação da extensão k8s e dimensionado automaticamente conforme necessário. Esse componente deve ter pelo menos uma réplica íntegra no cluster.

Você receberá esse erro se o componente não estiver disponível quando você acionar um ponto de extremidade online do Kubernetes ou uma solicitação de criação ou atualização de implantação. Verifique o status e os logs do pod para corrigir esse problema. Você também pode tentar atualizar a extensão k8s instalada no cluster.

ERRO: ResourceNotReady

Para executar o arquivo de score.py fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos de que o score.py precisa e executa o script de pontuação nesse contêiner. O erro nesse cenário é que esse contêiner falha durante a execução, portanto, a pontuação não pode acontecer. Este erro pode ocorrer numa das seguintes condições:

  • Há um erro no score.py. Use get-logs para diagnosticar problemas comuns, tais como:

    • Um pacote que score.py tenta importar que não está incluído no ambiente conda
    • Um erro de sintaxe
    • Uma falha no init() método

    Se get-logs não produzir logs, isso geralmente significa que o contêiner falhou ao iniciar. Para depurar esse problema, tente implantar localmente.

  • As sondas de prontidão ou vivacidade não estão configuradas corretamente.

  • A inicialização do contêiner leva muito tempo, portanto, a sonda de prontidão ou vivacidade falha além do limite de falha. Nesse caso, ajuste as configurações da sonda para permitir um tempo maior para inicializar o contêiner. Ou tente uma SKU de VM suportada maior, que acelera a inicialização.

  • Há um erro na configuração do ambiente de contêiner, como uma dependência ausente.

    Se você receber o TypeError: register() takes 3 positional arguments but 4 were given erro, verifique a dependência entre o frasco v2 e azureml-inference-server-http. Para obter mais informações, consulte Solucionar problemas do servidor HTTP.

ERRO: ResourceNotFound

Você pode obter esse erro ao usar o endpoint online gerenciado ou o ponto de extremidade online do Kubernetes, pelos seguintes motivos:

O Gestor de Recursos não consegue encontrar um recurso

Este erro ocorre quando o Azure Resource Manager não consegue encontrar um recurso necessário. Por exemplo, você pode receber esse erro se uma conta de armazenamento não puder ser encontrada no caminho especificado. Verifique novamente as especificações de caminho ou nome para precisão e ortografia. Para obter mais informações, consulte Resolver erros para recurso não encontrado.

Erro de autorização do registro de contêiner

Este erro ocorre quando uma imagem pertencente a um registro de contêiner privado ou inacessível é fornecida para implantação. As APIs do Azure Machine Learning não podem aceitar credenciais de registo privadas.

Para atenuar esse erro, verifique se o registro do contêiner não é particular ou execute as seguintes etapas:

  1. Conceda a função acrPull do seu registro privado à identidade do sistema do seu endpoint online.
  2. Na definição do seu ambiente, especifique o endereço da sua imagem privada e dê a instrução para não modificar ou construir a imagem.

Se essa atenuação for bem-sucedida, a imagem não exigirá a construção e o endereço final da imagem será o endereço da imagem fornecido. No momento da implantação, a identidade do sistema do ponto de extremidade online extrai a imagem do registro privado.

Para obter mais informações de diagnóstico, consulte Como usar o diagnóstico do espaço de trabalho.

ERRO: WorkspaceManagedNetworkNotReady

Este erro ocorre se você tentar criar uma implantação online que habilite uma rede virtual gerenciada pelo espaço de trabalho, mas a rede virtual gerenciada ainda não foi provisionada. Provisione a rede virtual gerenciada pelo espaço de trabalho antes de criar uma implantação online.

Para provisionar manualmente a rede virtual gerenciada pelo espaço de trabalho, siga as instruções em Provisionar manualmente uma VNet gerenciada. Em seguida, você pode começar a criar implantações online. Para obter mais informações, consulte Isolamento de rede com ponto de extremidade online gerenciado e Proteger seus pontos de extremidade online gerenciados com isolamento de rede.

ERRO: OperationCanceled

Você pode obter esse erro ao usar o endpoint online gerenciado ou o ponto de extremidade online do Kubernetes, pelos seguintes motivos:

Operação cancelada por outra operação de prioridade mais alta

As operações do Azure têm um determinado nível de prioridade e são executadas do mais alto ao mais baixo. Este erro acontece quando outra operação que tem uma prioridade mais alta substitui a sua operação. Repetir a operação pode permitir que ela seja executada sem cancelamento.

Operação cancelada aguardando confirmação de bloqueio

As operações do Azure têm um breve período de espera após serem enviadas, durante o qual recuperam um bloqueio para garantir que não encontram condições de corrida. Este erro acontece quando a operação enviada é igual a outra operação. A outra operação aguarda a confirmação de que recebeu o bloqueio antes de prosseguir.

Poderá ter apresentado um pedido semelhante demasiado cedo após o pedido inicial. Repetir a operação depois de esperar até um minuto pode permitir que ela seja executada sem cancelamento.

ERRO: SecretsInjectionError

A recuperação e injeção de segredos durante a criação da implantação online usa a identidade associada ao ponto de extremidade online para recuperar segredos das conexões do espaço de trabalho ou dos cofres de chaves. Este erro acontece por um dos seguintes motivos:

  • A identidade do ponto de extremidade não tem permissão do RBAC do Azure para ler os segredos das conexões do espaço de trabalho ou dos cofres de chaves, mesmo que a definição de implantação tenha especificado os segredos como referências mapeadas para variáveis de ambiente. A atribuição de função pode levar algum tempo para que as alterações entrem em vigor.

  • O formato das referências secretas é inválido ou os segredos especificados não existem nas conexões do espaço de trabalho ou nos cofres de chaves.

Para obter mais informações, consulte Injeção secreta em pontos de extremidade online (visualização) e Acessar segredos da implantação online usando injeção secreta (visualização).

ERRO: InternalServerError

Esse erro significa que há algo errado com o serviço Azure Machine Learning que precisa ser corrigido. Envie um ticket de suporte ao cliente com todas as informações necessárias para resolver o problema.

Erros comuns específicos para implantações do Kubernetes

Erros de identidade e autenticação:

Erros de Crashloopbackoff:

Erros de script de pontuação:

Outros Erros:

ERRO: ACRSecretError

Ao criar ou atualizar implantações online do Kubernetes, você pode receber esse erro por um dos seguintes motivos:

  • A atribuição de função não foi concluída. Aguarde alguns segundos e tente novamente.

  • O cluster Kubernetes habilitado para Azure Arc ou a extensão AKS Azure Machine Learning não está instalada ou configurada corretamente. Verifique a configuração e o status da extensão Kubernetes habilitada para Azure Arc ou Azure Machine Learning.

  • O cluster Kubernetes tem configuração de rede incorreta. Verifique o proxy, a política de rede ou o certificado.

  • Seu cluster AKS privado não tem os pontos de extremidade adequados. Certifique-se de configurar pontos de extremidade privados para o Registro de Contêiner, a conta de armazenamento e o espaço de trabalho na rede virtual AKS.

  • Sua versão de extensão do Azure Machine Learning é v1.1.25 ou inferior. Verifique se a versão da extensão é maior que a v1.1.25.

ERRO: TokenRefreshFailed

Esse erro ocorre porque a identidade do cluster do Kubernetes não está definida corretamente, portanto, a extensão não pode obter uma credencial principal do Azure. Reinstale a extensão do Azure Machine Learning e tente novamente.

ERRO: GetAADTokenFailed

Este erro ocorre porque a solicitação de cluster do Kubernetes Microsoft Entra ID token falhou ou expirou. Verifique o acesso à rede e tente novamente.

  • Siga as instruções em Usar computação do Kubernetes para verificar o proxy de saída e certificar-se de que o cluster pode se conectar ao espaço de trabalho. Você pode encontrar a URL do ponto de extremidade do espaço de trabalho na CRD (Definição de Recursos Personalizados) do ponto de extremidade online no cluster.

  • Verifique se o espaço de trabalho permite acesso público. Independentemente de o cluster AKS em si ser público ou privado, se um espaço de trabalho privado desativar o acesso à rede pública, o cluster Kubernetes poderá se comunicar com esse espaço de trabalho somente por meio de um link privado. Para obter mais informações, consulte O que é um ambiente de inferência AKS seguro.

ERRO: ACRAuthenticationChallengeFailed

Esse erro ocorre porque o cluster Kubernetes não pode acessar o serviço de Registro de Contêiner do espaço de trabalho para fazer um desafio de autenticação. Verifique a sua rede, especialmente o acesso à rede pública do Registo de Contentores, e tente novamente. Você pode seguir as etapas de solução de problemas em GetAADTokenFailed ao verificar a rede.

ERRO: ACRTokenExchangeFailed

Este erro ocorre porque o token de ID do Microsoft Entra ainda não está autorizado, portanto, o token do Registro de Contêiner da troca de cluster do Kubernetes falha. A atribuição de função leva algum tempo, então aguarde um minuto e tente novamente.

Essa falha também pode ser devido a muitas solicitações simultâneas para o serviço Registro de Contêiner. Este erro deve ser transitório e pode tentar novamente mais tarde.

ERRO: KubernetesUnaccessible

Você pode obter o seguinte erro durante as implantações do modelo Kubernetes:

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

Para atenuar esse erro, você pode girar o certificado AKS para o cluster. O novo certificado deve ser atualizado após 5 horas, para que você possa aguardar por 5 horas e reimplantá-lo. Para obter mais informações, consulte Rotação de certificados no Serviço Kubernetes do Azure (AKS).

ERRO: ImagePullLoopBackOff

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque não é possível baixar as imagens do registro do contêiner, resultando na falha de pull de imagens. Verifique a política de rede do cluster e o registro do contêiner do espaço de trabalho para ver se o cluster pode extrair imagens do registro do contêiner.

ERRO: DeploymentCrashLoopBackOff

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque o contêiner do usuário falhou ao inicializar. Há duas razões possíveis para esse erro:

  • O score.py de script de usuário tem um erro de sintaxe ou de importação que gera exceções na inicialização.
  • O pod de implantação precisa de mais memória do que seu limite.

Para atenuar esse erro, primeiro verifique os logs de implantação para quaisquer exceções nos scripts de usuário. Se o erro persistir, tente estender o limite de memória do tipo de recurso/instância.

ERRO: KubernetesCrashLoopBackOff

Você pode receber esse erro ao criar ou atualizar pontos de extremidade ou implantações online do Kubernetes por um dos seguintes motivos:

  • Um ou mais pods estão presos no status CrashLoopBackoff. Verifique se o log de implantação existe e se há mensagens de erro no log.
  • Há um erro no score.py e o contêiner travou ao inicializar seu código de pontuação. Siga as instruções em ERROR: ResourceNotReady.
  • Seu processo de pontuação precisa de mais memória do que seu limite de configuração de implantação. Você pode tentar atualizar a implantação com um limite de memória maior.

ERRO: NamespaceNotFound

Você pode receber esse erro ao criar ou atualizar pontos de extremidade online do Kubernetes porque o namespace usado pelo Kubernetes não está disponível no cluster. Verifique a computação do Kubernetes no portal do espaço de trabalho e verifique o namespace no cluster do Kubernetes. Se o namespace não estiver disponível, desanexe a computação herdada e anexe novamente para criar uma nova, especificando um namespace que já existe no cluster.

ERRO: UserScriptInitFailed

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque a init função em seu arquivo de score.py carregado gerou uma exceção. Verifique os logs de implantação para ver a mensagem de exceção em detalhes e corrija a exceção.

ERRO: UserScriptImportError

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque o arquivo score.py que você carregou importa pacotes indisponíveis. Verifique os logs de implantação para ver a mensagem de exceção em detalhes e corrija a exceção.

ERRO: UserScriptFunctionNotFound

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque o arquivo de score.py que você carregou não tem uma função chamada init() ou run(). Verifique o seu código e adicione a função.

ERRO: EndpointNotFound

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque o sistema não consegue encontrar o recurso de ponto de extremidade para a implantação no cluster. Crie a implantação em um ponto de extremidade existente ou crie o ponto de extremidade primeiro em seu cluster.

ERRO: EndpointAlreadyExists

Você pode receber esse erro ao criar um ponto de extremidade online do Kubernetes porque o ponto de extremidade já existe no cluster. O nome do ponto de extremidade deve ser exclusivo por espaço de trabalho e por cluster, portanto, crie um ponto de extremidade com outro nome.

ERRO: ScoringFeUnhealthy

Você pode receber esse erro ao criar ou atualizar um ponto de extremidade ou implantação online do Kubernetes porque o serviço do sistema azureml-fe executado no cluster não foi encontrado ou não está íntegro. Para atenuar esse problema, reinstale ou atualize a extensão do Azure Machine Learning em seu cluster.

ERRO: ValidateScoringFailed

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque a validação da URL da solicitação de pontuação falhou ao processar o modelo. Verifique o URL do ponto de extremidade e tente reimplantar.

ERRO: InvalidDeploymentSpec

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque a especificação de implantação é inválida. Verifique a mensagem de erro para se certificar de que a instance count é válida. Se tiver ativado o dimensionamento automático, certifique-se de que ambos são minimum instance count maximum instance count válidos.

ERRO: PodUnschedulable

Você pode receber esse erro ao criar ou atualizar pontos de extremidade ou implantações online do Kubernetes por um dos seguintes motivos:

  • O sistema não pode agendar o pod para nós devido a recursos insuficientes em seu cluster.
  • Nenhum nó corresponde ao seletor de afinidade de nó.

Para atenuar este erro, siga estes passos:

  1. Verifique a node selector instance_type definição do que você usou e a node label configuração dos nós do cluster.
  2. Verifique o instance_type e o tamanho da SKU do nó para o cluster AKS ou o recurso de nó para o cluster Kubernetes habilitado para Azure Arc.
  3. Se o cluster tiver poucos recursos, reduza o requisito de recurso de tipo de instância ou use outro tipo de instância com requisitos de recursos menores.
  4. Se o cluster não tiver mais recursos para atender ao requisito da implantação, exclua algumas implantações para liberar recursos.

ERRO: PodOutOfMemory

Você pode receber esse erro ao criar ou atualizar uma implantação online porque o limite de memória fornecido para a implantação é insuficiente. Para atenuar esse erro, você pode definir o limite de memória para um valor maior ou usar um tipo de instância maior.

ERRO: InferencingClientCallFailed

Você pode receber esse erro ao criar ou atualizar pontos de extremidade ou implantações online do Kubernetes porque a extensão k8s do cluster Kubernetes não é conectável. Nesse caso, desanexe e reanexe o computador.

Para solucionar erros reanexando, certifique-se de anexar novamente com a mesma configuração da computação desanexada, como nome de computação e namespace, para evitar outros erros. Se ainda não estiver funcionando, peça a um administrador que possa acessar o cluster para usar kubectl get po -n azureml para verificar se os pods do servidor de retransmissão estão em execução.

Problemas de consumo do modelo

Os erros comuns de consumo do modelo resultantes do status da operação do ponto de extremidade invoke incluem problemas de limite de largura de banda, política CORS e vários códigos de status HTTP.

Problemas de limite de largura de banda

Os endpoints online gerenciados têm limites de largura de banda para cada ponto de extremidade. Você pode encontrar a configuração de limite em limites para pontos de extremidade online. Se o uso da largura de banda exceder o limite, sua solicitação será atrasada.

Para monitorar o atraso de largura de banda, use a métrica Bytes de rede para entender o uso atual da largura de banda. Para obter mais informações, consulte Monitorar pontos de extremidade online gerenciados.

Dois trailers de resposta são retornados se o limite de largura de banda for imposto:

  • ms-azureml-bandwidth-request-delay-ms é o tempo de atraso em milissegundos que levou para a transferência de fluxo de solicitação.
  • ms-azureml-bandwidth-response-delay-msé o tempo de atraso em milissegundos que levou para a transferência do fluxo de resposta.

Bloqueado pela política CORS

Os pontos de extremidade online V2 não suportam CORS (Cross-Origin Resource Sharing) nativamente. Se seu aplicativo Web tentar invocar o ponto de extremidade sem lidar corretamente com as solicitações de comprovação do CORS, você receberá a seguinte mensagem de erro:

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

Você pode usar o Azure Functions, o Gateway de Aplicativo do Azure ou outro serviço como uma camada provisória para lidar com solicitações de comprovação CORS.

Códigos de estado HTTP

Quando você acessa pontos de extremidade online com solicitações REST, os códigos de status retornados aderem aos padrões para códigos de status HTTP. As seções a seguir apresentam detalhes sobre como os erros de invocação e previsão de ponto de extremidade são mapeados para códigos de status HTTP.

Códigos de erro comuns para pontos de extremidade online gerenciados

A tabela a seguir contém códigos de erro comuns quando solicitações REST consomem pontos de extremidade online gerenciados:

Código de estado Motivo Description
200 OK Seu modelo foi executado com sucesso dentro de seus limites de latência.
401 Não autorizado Você não tem permissão para executar a ação solicitada, como pontuação, ou seu token expirou ou no formato errado. Para obter mais informações, consulte Autenticação para pontos de extremidade online gerenciados e Autenticar clientes para pontos de extremidade online.
404 Não encontrado O ponto de extremidade não tem nenhuma implantação válida com peso positivo.
408 Tempo limite do pedido A execução do modelo levou mais tempo do que o tempo limite fornecido na request_timeout_ms request_settings configuração de implantação do modelo.
424 Erro de modelo Se o contêiner modelo retornar uma resposta diferente de 200, o Azure retornará uma resposta 424. Verifique a Model Status Code dimensão sob a Requests Per Minute métrica no Azure Monitor Metric Explorer do seu ponto de extremidade. Ou verifique os cabeçalhos de ms-azureml-model-error-statuscode resposta e ms-azureml-model-error-reason para obter mais informações. Se o 424 vier com falha na sonda de vivacidade ou prontidão, considere ajustar as configurações da sonda para permitir mais tempo para a vida ou prontidão do contêiner.
429 Demasiados pedidos pendentes Atualmente, seu modelo está recebendo mais solicitações do que pode lidar. Para garantir um bom funcionamento, o Azure Machine Learning permite um máximo de 2 * max_concurrent_requests_per_instance * instance_count requests processos em paralelo a qualquer momento. Os pedidos que excedam este máximo são rejeitados.

Você pode revisar a configuração de implantação do request_settings modelo nas seções e scale_settings para verificar e ajustar essas configurações. Certifique-se também de que a variável WORKER_COUNT de ambiente é passada corretamente, conforme descrito em RequestSettings.

Se você receber esse erro quando estiver usando o dimensionamento automático, seu modelo está recebendo solicitações mais rápido do que o sistema pode escalar. Considere reenviar solicitações com um backoff exponencial para dar tempo ao sistema para se ajustar. Você também pode aumentar o número de instâncias usando código para calcular a contagem de instâncias. Combine essas etapas com a configuração do dimensionamento automático para ajudar a garantir que seu modelo esteja pronto para lidar com o fluxo de solicitações.
429 Taxa limitada O número de solicitações por segundo atingiu os limites de endpoints online gerenciados.
500 Erro interno do servidor A infraestrutura provisionada do Azure Machine Learning está falhando.

Códigos de erro comuns para pontos de extremidade online do Kubernetes

A tabela a seguir contém códigos de erro comuns quando solicitações REST consomem pontos de extremidade online do Kubernetes:

Código de estado Erro Description
409 Erro de conflito Quando uma operação já está em andamento, qualquer nova operação nesse mesmo ponto de extremidade online responde com um erro de conflito 409. Por exemplo, se uma operação de ponto de extremidade online de criação ou atualização estiver em andamento, acionar uma nova operação de exclusão gerará um erro.
502 Exceção ou falha no run() método do arquivo score.py Quando há um erro no score.py, por exemplo, um pacote importado que não existe no ambiente conda, um erro de sintaxe ou uma falha no init() método, consulte ERROR: ResourceNotReady para depurar o arquivo.
503 Grandes picos de solicitações por segundo 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 o código de status HTTP 503. Embora o autoscaler reaja rapidamente, o AKS leva uma quantidade significativa de tempo para criar mais contêineres. Consulte Como evitar erros de código de status 503.
504 O pedido excede o limite de tempo Um código de status 504 indica que a solicitação expirou. A configuração de tempo limite padrão é de 5 segundos. Você pode aumentar o tempo limite ou tentar acelerar o ponto de extremidade modificando score.py para remover chamadas desnecessárias. Se essas ações não corrigirem o problema, o código pode estar em um estado não responsivo ou em um loop infinito. Siga ERROR: ResourceNotReady para depurar o arquivo score.py .
500 Erro interno do servidor A infraestrutura provisionada do Azure Machine Learning está falhando.

Como evitar erros de código de status 503

As implantações on-line do Kubernetes suportam dimensionamento automático, o que permite que réplicas sejam adicionadas para suportar carga extra. Para obter mais informações, consulte Roteador de inferência do Azure Machine Learning. A decisão de aumentar ou diminuir a escala é baseada na utilização das réplicas de contêiner atuais.

Duas ações podem ajudar a evitar erros de código de status 503: alterar o nível de utilização para criar novas réplicas ou alterar o número mínimo de réplicas. Você pode usar essas abordagens individualmente ou em combinação.

  • Altere o destino de utilização no qual o dimensionamento automático cria novas réplicas definindo o autoscale_target_utilization para um valor mais baixo. Essa alteração não faz com que as réplicas sejam criadas mais rapidamente, mas com um limite de utilização mais baixo. Por exemplo, alterar o valor para 30% faz com que réplicas sejam criadas quando ocorre uma utilização de 30%, em vez de esperar até que o serviço seja 70% utilizado.

  • Altere o número mínimo de réplicas para fornecer um pool maior que possa lidar com os picos de entrada.

Como calcular a contagem de instâncias

Para aumentar o número de instâncias, você pode calcular as réplicas necessárias da seguinte maneira:

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

Nota

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

Se o ponto de extremidade online do Kubernetes já estiver usando as réplicas máximas atuais e você ainda obtiver 503 códigos de status, aumente o autoscale_max_replicas valor para aumentar o número máximo de réplicas.

Problemas de isolamento de rede

Esta seção fornece informações sobre problemas comuns de isolamento de rede.

A criação de pontos finais online falha com a mensagem V1LegacyMode == true

Você pode configurar o espaço de trabalho do Aprendizado de Máquina do Azure para v1_legacy_mode, que desabilita as APIs v2. Os pontos de extremidade online gerenciados são um recurso da plataforma de API v2 e não funcionam se v1_legacy_mode estiverem habilitados para o espaço de trabalho.

Para desativar v1_legacy_modeo , consulte Isolamento de rede com v2.

Importante

Verifique com sua equipe de segurança de rede antes de desativar v1_legacy_modeo , porque eles podem tê-lo ativado por um motivo.

Falha na criação de pontos finais online com a autenticação baseada em chaves

Use o comando a seguir para listar as regras de rede do cofre de chaves do Azure para seu espaço de trabalho. Substitua <keyvault-name> pelo nome do cofre de chaves:

az keyvault network-rule list -n <keyvault-name>

A resposta para este comando é semelhante ao seguinte código JSON:

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

Se o valor de não AzureServicesfor , use as orientações em Configurar configurações de rede do cofre de bypass chaves para defini-lo como AzureServices.

As implementações online falham com um erro de transferência de imagem

Nota

Esse problema se aplica quando você usa o método de isolamento de rede herdado para pontos de extremidade online gerenciados, no qual o Aprendizado de Máquina do Azure cria uma rede virtual gerenciada para cada implantação sob um ponto de extremidade.

  1. Verifique se o egress-public-network-access sinalizador é disabled para a implantação. Se esse sinalizador estiver habilitado e a visibilidade do registro de contêiner for privada, essa falha será esperada.

  2. Use o comando a seguir para verificar o status da conexão de ponto de extremidade privado. Substitua <registry-name> pelo nome do registro de contêiner do Azure para seu espaço de trabalho:

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"

    No código de resposta, verifique se o status campo está definido como Approved. Caso contrário, use o seguinte comando para aprová-lo. Substitua <private-endpoint-name> pelo nome retornado do comando anterior.

    az network private-endpoint-connection approve -n <private-endpoint-name>

Não é possível resolver o ponto final de classificação

  1. Verifique se o cliente que emite a solicitação de pontuação é uma rede virtual que pode acessar o espaço de trabalho do Azure Machine Learning.

  2. Use o nslookup comando no nome do host do ponto de extremidade para recuperar as informações do endereço IP, por exemplo:

    nslookup endpointname.westcentralus.inference.ml.azure.com

    A resposta contém um endereço que deve estar no intervalo fornecido pela rede virtual.

    Nota

    • Para o ponto de extremidade online do Kubernetes, o nome do host do ponto de extremidade deve ser o CName (nome de domínio) especificado no cluster do Kubernetes.
    • Se o ponto de extremidade for HTTP, o endereço IP estará contido no URI do ponto de extremidade, que você pode obter da interface do usuário do estúdio.
    • Você pode encontrar mais maneiras de obter o endereço IP do ponto de extremidade online do Secure Kubernetes.

  3. Se o nslookup comando não resolver o nome do host, execute as seguintes ações:

Pontos finais online geridos

  1. Use o comando a seguir para verificar se existe um registro A na zona privada do Servidor de Nomes de Domínio (DNS) para a rede virtual.

    az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

    Os resultados devem conter uma entrada semelhante a *.<GUID>.inference.<region>.

  2. Se nenhum valor de inferência retornar, exclua o ponto de extremidade privado do espaço de trabalho e recrie-o. Para obter mais informações, consulte Como configurar um ponto de extremidade privado.

  3. Se o espaço de trabalho com um ponto de extremidade privado usar um servidor DNS personalizado, execute o seguinte comando para verificar se a resolução do DNS personalizado funciona corretamente.

dig endpointname.westcentralus.inference.ml.azure.com

Pontos finais online do Kubernetes

  1. Verifique a configuração de DNS no cluster Kubernetes.

  2. Verifique também se o azureml-fe funciona conforme o esperado, usando o seguinte comando:

    kubectl exec -it deploy/azureml-fe -- /bin/bash
(Run in azureml-fe pod)

curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

    Para HTTP, use o seguinte comando:

     curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

  3. Se o curl HTTPs falhar ou expirar, mas o HTTP funcionar, verifique se o certificado é válido.

  4. Se o processo anterior não conseguir resolver para o registo A, verifique se a resolução funciona a partir do DNS do Azure (168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

  5. Se o comando anterior for bem-sucedido, solucione problemas do encaminhador condicional para link privado no DNS personalizado.

As implementações online não podem ser classificadas

  1. Execute o seguinte comando para ver se a implantação foi bem-sucedida:

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'

    Se a implantação for concluída com êxito, o valor de state é Succeeded.

  2. Se a implantação foi bem-sucedida, use o seguinte comando para verificar se o tráfego está atribuído à implantação. Substitua <endpointname> pelo nome do seu ponto de extremidade.

    az ml online-endpoint show -n <endpointname>  --query traffic

    A resposta desse comando deve listar a porcentagem de tráfego atribuída às implantações.

    Gorjeta

    Esta etapa não será necessária se você usar o azureml-model-deployment cabeçalho em sua solicitação para direcionar essa implantação.

  3. Se as atribuições de tráfego ou o cabeçalho de implantação estiverem definidos corretamente, use o comando a seguir para obter os logs para o ponto de extremidade. Substitua <endpointname> pelo nome do ponto de extremidade e <deploymentname> pela implantação.

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

  4. Revise os logs para ver se há um problema ao executar o código de pontuação ao enviar uma solicitação para a implantação.

Problemas do servidor de inferência

Esta seção fornece dicas básicas de solução de problemas para o servidor HTTP de inferência do Azure Machine Learning.

Verifique os pacotes instalados

Siga estas etapas para resolver problemas com pacotes instalados.

  1. Reúna informações sobre pacotes instalados e versões para seu ambiente Python.

  2. Confirme se a versão do azureml-inference-server-http pacote Python especificada no arquivo de ambiente corresponde à versão do servidor HTTP de inferência do Azure Machine Learning exibida no log de inicialização.

    Em alguns casos, o resolvedor de dependência pip instala versões de pacote inesperadas. Talvez seja necessário executar pip para corrigir os pacotes e versões instalados.

  3. Se você especificar o Flask ou suas dependências em seu ambiente, remova esses itens.

    • Os pacotes dependentes incluem flask, jinja2, itsdangerous, werkzeug, markupsafee click.
    • flask está listado como uma dependência no pacote do servidor. A melhor abordagem é permitir que o servidor de inferência instale o flask pacote.
    • Quando o servidor de inferência é configurado para suportar novas versões do Flask, o servidor recebe automaticamente as atualizações do pacote à medida que ficam disponíveis.

Verificar a versão do servidor

O azureml-inference-server-http pacote do servidor é publicado no PyPI. A página PyPI lista o changelog e todas as versões anteriores.

Se você estiver usando uma versão anterior do pacote, atualize sua configuração para a versão mais recente. A tabela a seguir resume versões estáveis, problemas comuns e ajustes recomendados:

Versão de pacote Description Problema Resolução
0.4.x Incluído em imagens de treinamento datadas 20220601 ou anteriores e azureml-defaults versões .1.34 de pacote através do 1.43. Última versão estável é 0.4.13. Para versões de servidor anteriores à 0.4.11, você pode encontrar problemas de dependência do Flask, como "can't import name Markup from jinja2". Atualize para a versão 0.4.13 ou 0.8.x, a versão mais recente, se possível.
0,6.x Pré-instalado na inferência de imagens datadas 20220516 e anteriores. Última versão estável é 0.6.1. N/A N/A
0,7.x Suporta Flask 2. Última versão estável é 0.7.7. N/A N/A
0.8.x Formato de log alterado. O suporte ao Python 3.6 terminou. N/A N/A

Verificar dependências do pacote

Os pacotes dependentes mais relevantes para o pacote de azureml-inference-server-http servidor incluem:

  • flask
  • opencensus-ext-azure
  • inference-schema

Se você especificou o azureml-defaults pacote em seu ambiente Python, o azureml-inference-server-http pacote é um pacote dependente. A dependência é instalada automaticamente.

Gorjeta

Se você usar o Python SDK v1 e não especificar explicitamente o azureml-defaults pacote em seu ambiente Python, o SDK poderá adicionar automaticamente o pacote. No entanto, a versão do empacotador está bloqueada em relação à versão do SDK. Por exemplo, se a versão do SDK for 1.38.0, a azureml-defaults==1.38.0 entrada será adicionada aos requisitos de pip do ambiente.

TypeError durante a inicialização do servidor

Você pode encontrar o seguinte TypeError durante a inicialização do servidor:

TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Este erro ocorre quando você tem o Flask 2 instalado em seu ambiente Python, mas sua azureml-inference-server-http versão do pacote não suporta o Flask 2. O suporte para o Flask 2 está disponível na versão do pacote 0.7.0 e posterior, e azureml-defaults na azureml-inference-server-http versão do pacote 1.44 e posterior.

  • Se você não usar o pacote Flask 2 em uma imagem do Docker do Azure Machine Learning, use a versão mais recente do azureml-inference-server-http pacote ou azureml-defaults .

  • Se você usar o pacote Flask 2 em uma imagem do Docker do Azure Machine Learning, confirme se a versão de compilação da imagem é julho de 2022 ou posterior.

    Você pode encontrar a versão da imagem nos logs do contêiner. Por exemplo:

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    A data de compilação da imagem aparece após a Materialization Build notação. No exemplo anterior, a versão da imagem é 20220708 ou 8 de julho de 2022. A imagem neste exemplo é compatível com o Flask 2.

    Se você não vir uma mensagem semelhante no log do contêiner, sua imagem está desatualizada e deve ser atualizada. Se você usar uma imagem CUDA (Compute Unified Device Architecture) e não conseguir encontrar uma imagem mais recente, verifique se a imagem foi preterida no AzureML-Containers. Você pode encontrar substitutos designados para imagens obsoletas.

    Se você usar o servidor com um ponto de extremidade online, também poderá encontrar os logs na página Logs nos Pontos de Extremidade no estúdio do Azure Machine Learning.

Se você implantar com o SDK v1 e não especificar explicitamente uma imagem em sua configuração de implantação, o servidor aplicará o pacote com uma versão que corresponda ao openmpi4.1.0-ubuntu20.04 conjunto de ferramentas SDK local. No entanto, a versão instalada pode não ser a versão mais recente disponível da imagem.

Para o SDK versão 1.43, o servidor instala a versão do pacote por padrão, mas essa versão do pacote não é compatível com o openmpi4.1.0-ubuntu20.04:20220616 SDK 1.43. Certifique-se de usar o SDK mais recente para sua implantação.

Se não for possível atualizar a imagem, você poderá evitar temporariamente o problema fixando as azureml-defaults==1.43 entradas ou azureml-inference-server-http~=0.4.13 no arquivo de ambiente. Essas entradas direcionam o servidor para instalar a versão mais antiga com flask 1.0.xo .

ImportError ou ModuleNotFoundError durante a inicialização do servidor

Você pode encontrar um ImportError ou ModuleNotFoundError em módulos específicos, como opencensus, jinja2, markupsafe, ou , durante clicka inicialização do servidor. O exemplo a seguir mostra a mensagem de erro:

ImportError: cannot import name 'Markup' from 'jinja2'

Os erros de importação e módulo ocorrem quando você usa a versão 0.4.10 ou versões anteriores do servidor que não fixam a dependência do Flask em uma versão compatível. Para evitar o problema, instale uma versão posterior do servidor.

Outros problemas comuns

Outros problemas comuns de endpoint on-line estão relacionados à instalação do conda e ao dimensionamento automático.

Problemas de instalação do Conda

Problemas com a implantação do MLflow geralmente decorrem de problemas com a instalação do ambiente do usuário especificado no arquivo conda.yml .

Para depurar problemas de instalação do conda, tente as seguintes etapas:

  1. Verifique os logs de instalação do conda. Se o contêiner travou ou demorou muito para iniciar, a atualização do ambiente conda provavelmente não foi resolvida corretamente.
  2. Instale o arquivo mlflow conda localmente com o comando conda env create -n userenv -f <CONDA_ENV_FILENAME>.
  3. Se houver erros localmente, tente resolver o ambiente conda e criar um funcional antes de reimplantar.
  4. Se o contêiner falhar, mesmo que seja resolvido localmente, o tamanho da SKU usado para implantação pode ser muito pequeno.
    • A instalação do pacote Conda ocorre em tempo de execução, portanto, se o tamanho da SKU for muito pequeno para acomodar todos os pacotes no arquivo de ambiente conda.yml , o contêiner poderá falhar.
    • Uma Standard_F4s_v2 VM é um bom tamanho de SKU inicial, mas você pode precisar de VMs maiores, dependendo das dependências especificadas pelo arquivo conda.
    • Para pontos de extremidade online do Kubernetes, o cluster do Kubernetes deve ter um mínimo de quatro núcleos vCPU e 8 GB de memória.

Problemas de dimensionamento automático

Se você tiver problemas com o dimensionamento automático, consulte Solucionar problemas de dimensionamento automático do Azure Monitor.

Para pontos de extremidade online do Kubernetes, o roteador de inferência do Azure Machine Learning é um componente front-end que lida com o dimensionamento automático para todas as implantações de modelo no cluster do Kubernetes. Para obter mais informações, consulte Roteamento de inferência do Kubernetes em escala automática.

Conteúdos relacionados