Solucionar problemas de implantação e pontuação de ponto de extremidade online

APLICA-SE A:Extensão de ML da CLI do Azure v2 (atual)SDK do Python azure-ai-ml v2 (atual)

Este artigo descreve como solucionar 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. Use a implantação local para testar e depurar seus modelos localmente antes de implantá-los na nuvem.
2. Use logs de contêiner para ajudar a depurar os problemas.
3. Entenda os erros comuns de implantação que podem surgir e como corrigi-los.

A seção códigos de status HTTP explica como 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 assinatura ativa do Azure com uma versão gratuita ou paga do Azure Machine Learning. Obter uma assinatura do Azure de avaliação gratuita.

Rastreamento de solicitação

Há dois cabeçalhos de rastreamento com suporte:

• x-request-id é reservado para rastreamento de servidor. O Azure Machine Learning substitui esse cabeçalho para garantir que ele seja um GUID válido. Ao criar um tíquete de suporte para uma solicitação com falha, anexe a ID de 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íveis para cenários de rastreamento de cliente. Esse cabeçalho aceita apenas caracteres alfanuméricos, hifens e sublinhados e é truncado até um máximo de 40 caracteres.

Implantar localmente

A implantação local significa implantar um modelo em um ambiente local do Docker. A implantação local dá suporte à criação, atualização e exclusão de um ponto de extremidade local e permite invocar e obter logs do ponto de extremidade. Ela é útil para teste e depuração antes da implantação na nuvem.

Você pode implantar localmente com a CLI do Azure ou o SDK do Python. O Estúdio do ML não dá suporte à implantação local nem 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 etapas a seguir ocorrem durante a implantação local:

1. O Docker cria uma imagem de contêiner ou efetua pull de uma imagem existente do cache local do Docker. O Docker usará 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 logs de contêiner

Não é possível obter acesso direto a uma VM (máquina virtual) em que um modelo é implantado, mas você pode obter logs de alguns dos contêineres em execução na VM. A quantidade de informações depende do status de provisionamento da implantação. Se o contêiner especificado estiver 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 de console do servidor de inferência contém a saída das funções de impressão e registro em log do seu código do script de pontuação score.py.
• Logs do inicializador de armazenamento contêm informações sobre se o código e os dados do modelo foram baixados com sucesso para o contêiner. O contêiner será 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 em que você implanta o modelo e verificar os logs no Kubernetes. Por exemplo:

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

Ver a 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 implantaçã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 build de imagem não definida em um workspace privado com rede virtual
  • Tempo limite do build de imagem
  • Falha genérica ou desconhecida

• OutOfQuota

  • CPU
  • Cluster
  • Disco
  • Memória
  • Atribuições de função
  • Pontos de extremidade
  • Capacidade de VM em toda a região
  • Outras

• BadArgument

  Comum ao ponto de extremidade online gerenciado e ao ponto de extremidade online do Kubernetes:

  • A assinatura não existe
  • Falha na tarefa de inicialização devido a um erro de autorização
  • Falha na tarefa de inicialização devido a atribuições de função incorretas no recurso
  • Especificação de função de modelo inválida
  • Não foi possível baixar a imagem de contêiner do usuário
  • Não é possível baixar o modelo de usuários

  Limitado ao ponto de extremidade online do Kubernetes:

  • A solicitação de recursos foi maior que os limites
  • O ponto de extremidade online do Azureml-fe para 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 está inacessível

• WorkspaceManagedNetworkNotReady

• OperationCanceled

  • A operação foi cancelada por outra operação que tem uma prioridade maior
  • A operação foi cancelada devido a uma operação anterior que estava aguardando 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 às implantações do Kubernetes.

ERRO: ImageBuildFailure

Esse erro é retornado quando o ambiente de imagem do Docker está sendo criado. Você pode verificar o log de build para obter mais informações sobre a falha. O log de build está localizado no armazenamento padrão do workspace 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 build de imagem:

• Falha de autorização do Registro de Contêiner do Azure
• Computação de build de imagem não definida em um workspace privado com rede virtual
• Tempo limite do build 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 das chaves de recurso do workspace pode causar esse erro e leva algum tempo para sincronizar automaticamente. No entanto, você pode chamar manualmente a sincronização de chaves com az ml workspace sync-keys, o que pode resolver a falha de autorização.

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

Computação de build de imagem não definida em um workspace privado com rede virtual

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

Tempo limite do build de imagem

Os tempos limite de build de imagem geralmente se devem ao fato de uma imagem ser muito grande para que seja possível concluir o build dentro do período de criação da implantação. Verifique os logs de build de imagem no local especificado pelo erro. Os logs são cortados no ponto em que a compilação da imagem atingiu o tempo limite.

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 investigação padrão se você tiver tempos limite do ImageBuild.

Falha no build da imagem genérica

Verifique o log de build para obter mais informações sobre a falha. Se nenhum erro óbvio for encontrado no log de build e a última linha for Installing pip dependencies: ...working..., o erro pode ter sido causado por uma dependência. A fixação das dependências de versão no arquivo conda pode corrigir esse problema.

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

ERROR: OutOfQuota

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

• CPU
• Cluster
• Disco
• Memória
• Atribuições de função
• Pontos de extremidade
• Capacidade de VM em toda a região
• Outras

Somente para pontos de extremidade online do Kubernetes, o recurso Kubernetes também pode ficar sem cota.

Cota 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 workspace, por SKU e por região. Cada implantação subtrai núcleos da cota disponível e os adiciona novamente após a exclusão, com base no tipo de SKU.

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

Cota do cluster

O erro OutOfQuota 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.

Cota de disco

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

Cota de memória

O erro OutOfQuota ocorre quando o volume de memória do modelo é maior que a memória disponível. Teste um SKU com mais memória.

Cota de atribuição de função

Quando você cria um ponto de extremidade online gerenciado, a atribuição de função é necessária para a identidade gerenciada acessar recursos do workspace. 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 de extremidade

Tente excluir alguns pontos de extremidade não utilizados desta assinatura. Se todos os pontos de extremidade estiverem ativamente em uso, tente solicitar um aumento da cota de ponto de extremidade. Para saber mais sobre o limite de ponto de extremidade, consulte Cota de ponto de extremidade com pontos de extremidade online do Azure Machine Learning e pontos de extremidade em lote.

Kubernetes quota

O erro OutOfQuota ocorre quando a CPU ou memória solicitada não pode ser fornecida devido a nós não poderem ser programados para essa implantação. Por exemplo, os nós podem estar isolados ou não disponíveis.

A mensagem de erro normalmente indica a insuficiência do recurso 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.

Experimente as seguintes mitigações para resolver esse problema:

• Os operadores de TI que mantêm o cluster do 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 recurso 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 o recurso para implantação de modelo, entre em contato com o operador de TI para ajustar a configuração de recurso de 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 falhou ao provisionar o tamanho especificado da VM. Tente mais tarde ou implante em um local diferente.

Outra cota

Para executar o arquivo score.py que você fornece como parte da implantação, o Azure cria um contêiner que inclui todos os recursos necessários para o score.py. 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 a capacidade de suporte de instance_type. Considere atualizar o instance_type da implantação online.

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

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
)

ERROR: BadArgument

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

• A assinatura não existe
• Falha na tarefa de inicialização devido a um erro de autorização
• Falha na tarefa de inicialização devido a atribuições de função incorretas no recurso
• Especificação de função de modelo inválida
• Não foi possível baixar a imagem de contêiner do usuário
• Não é possível baixar o modelo de usuários
• O formato de modelo do MLflow com rede privada não tem suporte

Você também pode receber esse erro ao usar somente pontos de extremidade online do Kubernetes, pelos seguintes motivos:

• A solicitação de recursos foi maior que os limites
• O ponto de extremidade online do Azureml-fe para Kubernetes não está pronto

A assinatura não existe

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

Erro de autorização

Depois de provisionar o recurso de computação ao criar uma implantação, o Azure efetua pull da imagem de contêiner do usuário do registro de contêiner do workspace e monta o modelo de usuário e os artefatos de código no contêiner do usuário da conta de armazenamento do workspace. 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 a identidade atribuída pelo usuário, a identidade gerenciada do usuário deverá ter permissão do Leitor de dados de blob de armazenamento na conta de armazenamento do workspace e permissão do AcrPull no registro de contêiner do workspace. Verifique se sua identidade atribuída pelo usuário tem as permissões certas.

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

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

Esse erro ocorre quando uma função de modelo foi especificada incorretamente. Corrija a política ou remova a atribuição de política para desbloquear. A mensagem de erro pode incluir o nome da atribuição de política e a definição de política para ajudar você a depurar esse erro. Consulte Estrutura de definição de política do Azure para obter dicas para evitar falhas de modelo.

Não foi possível baixar a imagem de contêiner do usuário

Talvez o contêiner do usuário não seja encontrado. Verifique os logs de contêiner para obter mais detalhes.

Verifique se a imagem do contêiner está disponível no registro de contêiner do workspace. Por exemplo, se a imagem for testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, você poderá 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 baixar o modelo de usuários

Talvez o modelo de usuário não seja encontrado. Verifique os logs de contêiner para obter mais detalhes. Verifique se você registrou o modelo no mesmo workspace que a implantação.

Para mostrar detalhes de um modelo em um workspace, execute a ação a seguir. 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 workspace. Por exemplo, se o blob for https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, você poderá 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ê poderá 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 do MLflow com rede privada não tem suporte

Você não poderá 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 de MLflow com a abordagem de implantação sem código, tente usar a rede virtual gerenciada do workspace.

Solicitações de recursos maiores que os limites

As solicitações de recursos devem ser menores ou iguais aos limites. Se você não definir limites, o Azure Machine Learning definirá valores padrão ao anexar sua computação a um workspace. Você pode verificar esses limites no portal do Azure ou usando o comando az ml compute show.

O Azureml-fe não está pronto

O componente front-end azureml-fe que roteia as solicitações de inferência de entrada para os serviços implantados é instalado durante a instalação da k8s-extension 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ê disparar um ponto de extremidade online do Kubernetes ou uma solicitação de criação ou atualização de implantação. Verifique o status do pod e os logs para corrigir esse problema. Você também pode tentar atualizar a k8s-extension instalada no cluster.

ERROR: ResourceNotReady

Para executar o arquivo score.py que você fornece como parte da implantação, o Azure cria um contêiner que inclui todos os recursos 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 ao ser executado, portanto, a pontuação não pode acontecer. Esse erro pode ocorrer em uma das seguintes condições:

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

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

  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 investigações de preparação ou de atividade não estão configuradas corretamente.

• A inicialização do contêiner demora muito, portanto, a investigação de atividade ou de preparação falha além do limite de falha. Nesse caso, ajuste as configurações de investigação para permitir mais tempo para inicializar o contêiner. Ou tente um SKU de VM com suporte maior, o que acelera a inicialização.

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

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

ERROR: ResourceNotFound

Você pode receber esse erro ao usar o ponto de extremidade 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 está inacessível

O Resource Manager não consegue encontrar um recurso

Esse erro ocorre quando o Azure Resource Manager não consegue encontrar um recurso necessário. Por exemplo, você poderá 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 quanto à 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

Esse 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 privadas do registro.

Para mitigar esse erro, verifique se o registro de contêiner não é privado ou execute as seguintes etapas:

1. Conceda a função acrPull do seu registro privado à identidade do sistema do seu ponto de extremidade online.
2. Em sua definição de ambiente, especifique o endereço de sua imagem privada e dê a instrução para não modificar ou compilar a imagem.

Se essa mitigação for bem-sucedida, a imagem não exigirá compilação e o endereço da imagem final será o endereço de imagem especificado. 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 de workspace.

ERROR: WorkspaceManagedNetworkNotReady

Esse erro ocorre se você tentar criar uma implantação online que habilite uma rede virtual gerenciada de workspace, mas a rede virtual gerenciada ainda não estiver provisionada. Provisione a rede virtual gerenciada do workspace antes de criar uma implantação online.

Para provisionar manualmente a rede virtual gerenciada do workspace, 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 de ponto de extremidade online gerenciado e Proteger seus pontos de extremidade online gerenciados com de isolamento de rede.

ERRO: OperationCanceled

Você pode receber esse erro ao usar o ponto de extremidade 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 maior
• A operação foi cancelada devido a uma operação anterior que estava aguardando confirmação de bloqueio

Operação cancelada por outra operação de maior prioridade

As operações do Azure têm determinado nível de prioridade e são executadas do nível mais alto para o mais baixo. Esse erro ocorre quando outra operação que tem uma prioridade mais alta substitui 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 depois de serem enviadas, durante o qual recuperam um bloqueio para garantir que não encontrem condições de corrida. Esse erro ocorre quando a operação enviada é a mesma que outra operação. No momento, a outra operação está aguardando a confirmação de que recebeu o bloqueio antes de continuar.

Você pode ter enviado uma solicitação semelhante muito cedo após a solicitação 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 a injeção de segredo durante a criação da implantação online usam a identidade associada ao ponto de extremidade online para recuperar segredos das conexões do workspace ou dos cofres de chaves. Esse erro ocorre por um dos seguintes motivos:

• A identidade do ponto de extremidade não tem permissão RBAC do Azure para ler os segredos das conexões do workspace 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 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 workspace ou nos cofres de chaves.

Para obter mais informações, confira Injeção de segredos em pontos de extremidade online (versão prévia) e Acesse os segredos da implantação online usando a injeção de segredos (versão prévia).

ERROR: InternalServerError

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

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

Erros de identidade e autenticação:

• ACRSecretError
• TokenRefreshFailed
• GetAADTokenFailed
• ACRAuthenticationChallengeFailed
• ACRTokenExchangeFailed
• KubernetesUnaccessible

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

ERROR: ACRSecretError

Ao criar ou atualizar implantações online do Kubernetes, você poderá 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 do Kubernetes habilitado para Azure Arc ou a extensão do AKS do Azure Machine Learning não está instalado ou configurado corretamente. Verifique a configuração e o status do Kubernetes habilitado para Azure Arc ou da extensão do Azure Machine Learning.

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

• O cluster do 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 workspace na rede virtual do 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

Esse erro ocorre porque o token do Microsoft Entra ID solicitado pelo cluster do Kubernetes falhou ou atingiu o tempo limite. 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 verificar se o cluster pode se conectar ao workspace. Você pode encontrar a URL do ponto de extremidade do workspace na CRD (Definição de Recurso Personalizado) do ponto de extremidade online no cluster.

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

ERRO: ACRAuthenticationChallengeFailed

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

ERRO: ACRTokenExchangeFailed

Esse erro ocorre porque o token do Microsoft Entra ID ainda não está autorizado, portanto, o token do Registro de Contêiner de 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 devida a muitas solicitações simultâneas ao serviço de Registro de Contêiner. Esse erro deve ser transitório e você pode tentar novamente mais tarde.

ERROR: KubernetesUnaccessible

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

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

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

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 de contêiner, resultando na falha de pull das imagens. Verifique a política de rede do cluster e o registro de contêiner do workspace para ver se o cluster pode efetuar pull de imagens do registro de 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á dois motivos possíveis para esse erro:

• O script do usuário score.py tem um erro de sintaxe ou erro 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 mitigar esse erro, primeiro verifique os logs de implantação em busca de exceções em scripts de usuário. Se o erro persistir, tente estender o limite de memória de tipo de instância/recursos.

ERROR: 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 falhou ao inicializar o código de pontuação. Siga as instruções em ERROR: ResourceNotReady.
• Seu processo de pontuação precisa de mais memória do que o limite de configuração de implantação. Você pode tentar atualizar a implantação com um limite de memória maior.

ERROR: NamespaceNotFound

Você pode receber esse erro ao criar ou atualizar os pontos de extremidade online do Kubernetes porque o namespace usado pelo computador do Kubernetes não está disponível em seu cluster. Verifique a computação do Kubernetes no portal do workspace e verifique o namespace no cluster do Kubernetes. Se o namespace não estiver disponível, desanexe a computação herdada e reanexe para criar um novo, especificando um namespace que já existe em seu cluster.

ERRO: UserScriptInitFailed

Você pode receber esse erro ao criar ou atualizar implantações online do Kubernetes porque a função init em seu arquivo 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 não disponí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 score.py que você carregou não tem uma função chamada init() ou run(). Verifique 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 workspace 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 de sistema azureml-fe executado no cluster não foi encontrado ou não está íntegro. Para mitigar 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 a 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 ter certeza de que o instance count é válido. Se você habilitou o dimensionamento automático, verifique se minimum instance count e maximum instance count são 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 mitigar esse erro, siga estas etapas:

1. Verifique a definição de node selector do instance_type usado e a configuração node label de seus nós de cluster.
2. Verifique o instance_type e o tamanho do SKU do nó para o cluster do AKS ou o recurso de nó para o cluster do Kubernetes habilitado para Azure Arc.
3. Se o cluster estiver sem 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 implantação é insuficiente. Para mitigar esse erro, você pode definir o limite de memória como um valor maior ou usar um tipo de instância maior.

ERROR: InferencingClientCallFailed

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

Para solucionar erros ao reanexar, certifique-se de reanexar com a mesma configuração que a 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 Relay Server estão em execução.

Problemas de consumo de modelo

Erros comuns de consumo de modelo resultantes do status da operação de invoke do ponto de extremidade 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 pontos de extremidade 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 da largura de banda, use a métrica Bytes de rede para entender o uso atual da largura de banda. Para obter mais informações, confira Monitorar pontos de extremidade online gerenciados.

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

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

Bloqueado pela política do CORS

Os pontos de extremidade online V2 não dão suporte ao CORS (Compartilhamento de Recursos entre Origens) nativamente. Se seu aplicativo Web tentar invocar o ponto de extremidade sem lidar corretamente com as solicitações preflight de CORS, você poderá obter 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 preflight de CORS.

Códigos de status HTTP

Quando você acessa pontos de extremidade online com solicitações REST, os códigos de status retornados seguem os padrões de códigos de status HTTP. As seções a seguir apresentam detalhes sobre como os erros de invocação e previsão do 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 as 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 online do Kubernetes dão suporte ao dimensionamento automático, o que permite que as réplicas sejam adicionadas para dar suporte a carga extra. Para obter mais informações, consulte Roteador de inferência do Azure Machine Learning. A decisão de escalar ou reduzir verticalmente é 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 combinadas.

• Altere o destino de utilização no qual o dimensionamento automático cria novas réplicas configurando o autoscale_target_utilization como um valor mais baixo. Essa alteração não faz com que as réplicas sejam criadas mais rapidamente, mas em um limite de utilização menor. Por exemplo, alterar o valor para 30% faz com que as réplicas sejam criadas quando ocorrer 30% de utilização, 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 receber códigos de status 503, aumente o valor autoscale_max_replicas 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 ponto de extremidade online tem uma falha com uma mensagem V1LegacyMode == true

Você pode configurar o workspace do Azure Machine Learning 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 estiver habilitado para o workspace.

Para desabilitar v1_legacy_mode, consulte Isolamento de rede com v2.

Falha na criação de ponto de extremidade online com autenticação baseada em chave

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

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

A resposta para esse comando é semelhante ao código JSON a seguir:

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

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

As implantações online falham com um erro de download de imagem

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

2. Use o comando a seguir para verificar o status da conexão do ponto de extremidade privado. Substitua <registry-name> pelo nome do Registro de Contêiner do Azure para o seu workspace:

   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 campo status está definido como Approved. Caso contrário, use o comando a seguir para aprová-lo. Substitua <private-endpoint-name> pelo nome retornado do comando anterior.

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

O ponto de extremidade de pontuação não pode ser resolvido

1. Verifique se o cliente que está emitindo a solicitação de pontuação é uma rede virtual que pode acessar o workspace do Azure Machine Learning.

2. Use o comando nslookup no nome do host do ponto de extremidade para recuperar as informações de 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.

   Observação

   • 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 outras maneiras de obter o endereço IP do ponto de extremidade em Ponto de extremidade online seguro do Kubernetes.

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

Pontos de extremidade online gerenciados

1. Use o comando a seguir para verificar se um registro A existe na zona DNS (Servidor de Nomes de Domínio) 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 for retornado, exclua o ponto de extremidade privado para o workspace e recrie-o. Para obter mais informações, consulte Como configurar um ponto de extremidade privado.

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

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

Pontos de extremidade online do Kubernetes

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

2. Além disso, verifique se 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 HTTP falhar ou atingir o tempo limite, mas o HTTP funcionar, verifique se o certificado é válido.

4. Se o processo anterior não conseguir resolver para o registro 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 do link privado no DNS personalizado.

Implantações online não podem ser pontuadas

1. Execute o comando a seguir 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 sucesso, o valor de state será Succeeded.

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

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

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

   Dica

   Essa etapa não será necessária se você usar o cabeçalho azureml-model-deployment 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 do 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 na execução do código de pontuação ao enviar uma solicitação para a implantação.

Problemas de 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. Colete informações sobre versões e pacotes instalados para o seu ambiente Python.

2. Confirme que a versão do pacote Python azureml-inference-server-http 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 inesperadas do pacote. Talvez seja necessário executar pip para corrigir pacotes e versões instalados.

3. Se você tiver especificado o Flask ou as respectivas dependências em seu ambiente, remova esses itens.

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

Verificar a versão do servidor

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

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

Verificar dependências do pacote

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

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

Se você especificou o pacote azureml-defaults em seu ambiente Python, o pacote azureml-inference-server-http será 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

Esse erro ocorre quando você tem o Flask 2 instalado em seu ambiente Python, mas sua versão do pacote azureml-inference-server-http não dá suporte ao Flask 2. O suporte para Flask 2 está disponível no pacote azureml-inference-server-http versão 0.7.0 e posterior, e no pacote azureml-defaults versão 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 pacote azureml-inference-server-http 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 build da imagem é de Julho de 2022 ou posterior.

  Você pode encontrar a versão da imagem nos logs de 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 build da imagem é exibida após a notação Materialization Build. No exemplo anterior, a versão da imagem é 20220708 ou 8 de julho de 2022. Neste exemplo, a imagem é compatível com o Flask 2.

  Se você não vir uma mensagem similar no log de contêineres, sua imagem estará desatualizada e deverá ser atualizada. Se você usar uma imagem CUDA (arquitetura de dispositivo unificado de computação) e não encontrar uma imagem mais recente, verifique se sua imagem foi preterida em AzureML-Containers. Você pode encontrar substituições designadas para imagens preteridas.

  Se você usar o servidor com um ponto de extremidade online, também poderá encontrar os logs em Logs na página 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 openmpi4.1.0-ubuntu20.04 com uma versão que corresponda ao conjunto de ferramentas do 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 openmpi4.1.0-ubuntu20.04:20220616 por padrão, mas essa versão do pacote não é compatível com o 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 entradas azureml-defaults==1.43 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.x.

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 click, durante a 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 a uma versão compatível. Para evitar o problema, instale uma versão posterior do servidor.

Outros problemas comuns

Outros problemas comuns de ponto de extremidade online estão relacionados à instalação do Conda e ao dimensionamento automático.

Problemas de instalação do Conda

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

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

1. Verifique os logs para a instalação do Conda. Se o contêiner falhou ou demorou muito para ser iniciado, é provável que a atualização do ambiente do Conda não tenha sido resolvida corretamente.
2. Instale o arquivo conda do mlflow 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 runtime, portanto, se o tamanho da SKU for muito pequeno para acomodar todos os pacotes detalhados no arquivo de ambiente conda.yml, o contêiner poderá falhar.
   • Uma VM Standard_F4s_v2 é um bom tamanho de SKU inicial, mas talvez você precise de VMs maiores, de acordo com as dependências especificadas pelo arquivo Conda.
   • Para pontos de extremidade online do Kubernetes, o cluster do Kubernetes deve ter no mínimo quatro núcleos de 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 de dimensionamento automático.

Conteúdo relacionado

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