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

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.

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.

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

ml_client.begin_create_or_update(online_deployment, local=True)

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.

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>

Ver saída de log de contêineres

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

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

az ml online-deployment get-logs -h

ml_client.online_deployments.get_logs(
    name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100
)

ml_client.online_deployments.get_logs(
    name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100, container_type="storage-initializer"
)

Erros de implementação comuns

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

• ImageBuildFailure

  • Falha de autorização do Registro de Contêiner do Azure
  • Computação de construção de imagem não definida em um espaço de trabalho privado com rede virtual
  • Tempo limite de construção de imagem
  • Falha genérica ou desconhecida

• OutOfQuota

  • Processador
  • Cluster
  • Disk
  • Memória
  • Atribuições de funções
  • Parâmetros de avaliação
  • Capacidade de VM em toda a região
  • Outro

• BadArgument

  Comum ao endpoint online gerenciado e ao endpoint online do Kubernetes:

  • A subscrição não existe
  • A tarefa de arranque falhou devido a um erro de autorização
  • A tarefa de arranque falhou devido a atribuições de funções incorretas no recurso
  • Especificação de função de modelo inválida
  • Não é possível transferir a imagem de contentor do utilizador
  • Não é possível transferir o modelo de utilizador

  Limitado ao endpoint online do Kubernetes:

  • O pedido de recurso sfoi superior aos limites
  • O ponto de extremidade online Azureml-fe for Kubernetes não está pronto

• ResourceNotReady

• ResourceNotFound

  • O Azure Resource Manager não consegue encontrar um recurso necessário
  • O registro de contêiner é privado ou inacessível

• WorkspaceManagedNetworkNotReady

• OperationCanceled

  • A operação foi cancelada por outra operação que tem uma prioridade superior
  • A operação foi cancelada devido a uma operação anterior a aguardar confirmação de bloqueio

• SecretsInjectionError

• InternalServerError

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
• Computação de construção de imagem não definida em um espaço de trabalho privado com rede virtual
• Tempo limite de construção de imagem
• Falha genérica ou desconhecida

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:

• Processador
• Cluster
• Disk
• Memória
• Atribuições de funções
• Parâmetros de avaliação
• Capacidade de VM em toda a região
• Outro

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.

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

ml_client.online_deployments.get_logs(
    name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100
)

ERRO: BadArgument

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

• A subscrição não existe
• A tarefa de arranque falhou devido a um erro de autorização
• A tarefa de arranque falhou devido a atribuições de funções incorretas no recurso
• Especificação de função de modelo inválida
• Não é possível transferir a imagem de contentor do utilizador
• Não é possível transferir o modelo de utilizador
• O formato de modelo MLflow com rede privada não é suportado

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

• O pedido de recurso sfoi superior aos limites
• O ponto de extremidade online Azureml-fe for kubernetes não está pronto

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.

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

ml_client.models.get(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`

ml_client.online_deployments.get_logs(
  name="<deployment-name>", endpoint_name="<endpoint-name>", lines=100, container_type="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 Azure Resource Manager não consegue encontrar um recurso necessário
• O registro de contêiner é privado ou inacessível

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:

• A operação foi cancelada por outra operação que tem uma prioridade superior
• A operação foi cancelada devido a uma operação anterior a aguardar confirmação de bloqueio

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:

• ACRSecretError
• TokenRefreshFailed
• GetAADTokenFailed
• ACRAuthenticationChallengeFailed
• ACRTokenExchangeFailed
• KubernetesInacessível

Erros de Crashloopbackoff:

• ImagePullLoopBackOff
• DeploymentCrashLoopBackOff
• KubernetesCrashLoopBackOff

Erros de script de pontuação:

• UserScriptInitFailed
• UserScriptImportError
• UserScriptFunctionNotFound

Outros Erros:

• NamespaceNotFound
• EndpointAlreadyExists
• ScoringFeUnhealthy
• ValidateScoringFailed
• InvalidDeploymentSpec
• PodUnschedulable
• PodOutOfMemory
• InferencingClientCallFailed

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ó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:

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)

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.

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

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:

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.

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

• Implantar e pontuar um modelo de aprendizado de máquina usando um ponto de extremidade online
• Implementação segura para terminais online
• Referência YAML do endpoint online
• Solucionar problemas de computação do Kubernetes