Solução de problemas de implantação e pontuação de pontos de extremidade online

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

Saiba como resolver problemas comuns na implantação e na pontuação de pontos de extremidade online do Azure Machine Learning.

Este documento é estruturado da maneira que 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 os erros de invocação e de previsão são mapeados para códigos de status HTTP ao pontuar pontos de extremidade com solicitações REST.

Pré-requisitos

Implantar localmente

A implantação local está implantando um modelo em um ambiente local do Docker. Ela é útil para teste e depuração antes da implantação na nuvem.

Dica

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

A implantação local dá suporte à criação, à atualização e à exclusão de um ponto de extremidade local. Também permite que você invoque e obtenha logs do ponto de extremidade.

Para usar a implantação local, adicione --local ao comando da CLI apropriado:

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

Como parte da implantação local, ocorrem as seguintes etapas:

  • O Docker cria uma imagem de contêiner ou efetua pull de uma imagem existente do cache local do Docker. Uma imagem existente será usada se houver uma que corresponda à parte do ambiente do arquivo de especificação.
  • O Docker inicia um novo contêiner com artefatos locais montados, como arquivos de modelo e código.

Para obter mais informações, confira Implantar localmente em Implantar e pontuar um modelo de machine learning.

Dica

Use o Visual Studio Code para testar e depurar os pontos de extremidade localmente. Para obter mais informações, confira depurar pontos de extremidade online localmente no Visual Studio Code.

Instalação do Conda

Geralmente, os problemas com a implantação do MLflow decorrem de problemas com a instalação do ambiente do usuário especificado no arquivo conda.yaml.

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.

    1. 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.yaml, o contêiner pode falhar.
    2. Uma VM Standard_F4s_v2 é um bom tamanho de SKU inicial, mas podem ser necessários tamanhos maiores, dependendo de quais dependências são especificadas no arquivo conda.
    3. Para o ponto de extremidade online do Kubernetes, o cluster do Kubernetes deve ter no mínimo 4 núcleos de vCPU e 8 GB de memória.

Obter logs de contêiner

Não é possível obter acesso direto à VM em que o modelo é implantado. No entanto, 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 funcionamento, você verá a saída do console, caso contrário, receberá uma mensagem para tentar novamente mais tarde.

Há dois tipos de contêineres dos quais você pode obter os logs:

  • Servidor de inferência: os logs incluem o log do console (do servidor de inferência) que contém a saída de funções de impressão/registro em log do script de pontuação (código score.py).
  • Inicializador de armazenamento: os logs informam se os dados de código e de modelo foram baixados com êxito no contêiner. O contêiner será executado antes que o contêiner do servidor de inferência comece a ser executado.

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

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

ou

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

Adicione --resource-group e --workspace-name a esses comandos se você ainda não tiver definido esses parâmetros por meio de az configure.

Para ver informações sobre como definir esses parâmetros, e se você já definiu atualmente os valores, execute:

az ml online-deployment get-logs -h

Por padrão, os logs são extraídos do servidor de inferência.

Observação

Se você usar o log do Python, lembre-se de usar a ordem de nível de registros em log correta para que as mensagens sejam publicadas nos logs. Por exemplo, INFO.

Você também pode obter os logs do contêiner do inicializador de armazenamento transmitindo –-container storage-initializer.

Adicione --help e/ou --debug aos comandos para ver mais informações.

Para o ponto de extremidade online do Kubernetes, os administradores podem acessar diretamente o cluster em que o modelo é implantado, o que flexibiliza a verificação do log no Kubernetes. Por exemplo:

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

Rastreamento de solicitação

Há dois cabeçalhos de rastreamento com suporte:

  • x-request-id é reservado para rastreamento de servidor. Substituimos esse cabeçalho para garantir que ele seja um GUID válido.

    Observação

    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.

  • x-ms-client-request-id está disponíveis para cenários de rastreamento de cliente. Esse cabeçalho é corrigido para aceitar apenas caracteres alfanuméricos, hifens e sublinhados e é truncado para um máximo de 40 caracteres.

Erros de implantação comuns

A lista a seguir é de erros comuns de implantação relatados como parte do status da operação de implantação:

Se você estiver criando ou atualizando uma implantação online do Kubernetes, poderá ver Erros comuns específicos às implantações do Kubernetes.

ERRO: ImageBuildFailure

Esse erro é retornado quando o ambiente (imagem do docker) está sendo criado. Você pode verificar o log de build para obter mais informações sobre as falhas. O log de build está localizado no armazenamento padrão do workspace do Azure Machine Learning. A localização exata pode ser retornada 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]'".

A lista a seguir contém cenários comuns de falha de build de imagem:

Também recomendamos revisar as configurações de investigação de padrão se você tiver tempos limite do ImageBuild.

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

Se a mensagem de erro mencionar "container registry authorization failure" isso significa que você não pode acessar o registro de contêiner com as credenciais atuais. A dessincronização das chaves de um recurso do workspace pode causar esse erro e demora um pouco para que a sincronização ocorra novamente. No entanto, você pode chamar manualmente uma sincronização de chaves, o que pode resolver a falha de autorização.

Os registros de contêiner protegidos por uma rede virtual também podem encontrar esse erro se configurados incorretamente. Você precisa verificar se a rede virtual está configurada corretamente.

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

Se a mensagem de erro mencionar "failed to communicate with the workspace's container registry" e você estiver usando redes virtuais e o Registro de Contêiner do Azure do workspace for privado e configurado com um ponto de extremidade privado, você precisará habilitar o Registro de Contêiner do Azure para permitir a criação de imagens na rede virtual.

Falha no build da imagem genérica

Conforme indicado anteriormente, você pode verificar 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.

Também recomendamos usar a implantação local para testar e depurar os modelos localmente antes de implantá-los na nuvem.

ERROR: OutOfQuota

A lista a seguir é de recursos comuns que podem ficar sem cota ao usar os serviços do Azure:

Além disso, a lista a seguir é de recursos comuns que podem ficar sem cota somente para o ponto de extremidade online do Kubernetes:

Cota de CPU

Antes de implantar um modelo, você precisa ter uma cota de computação suficiente. Essa cota define a quantidade de núcleos virtuais 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.

Uma possível mitigação é verificar se há implantações não usadas que possam ser excluídas. Ou, então, você pode enviar uma solicitação de aumento de cota.

Cota do cluster

Esse problema ocorre quando você não tem cota suficiente de cluster de Computação do Machine Learning. Essa cota define o número total de clusters que podem estar em uso ao mesmo tempo, por assinatura, para implantar nós de CPU ou GPU na Nuvem do Azure.

Uma possível mitigação é verificar se há implantações não usadas que possam ser excluídas. Ou, então, você pode enviar uma solicitação de aumento de cota. Certifique-se de selecionar Machine Learning Service: Cluster Quota como o tipo de cota para essa solicitação de aumento de cota.

Cota de disco

Esse problema ocorre quando o tamanho do modelo é maior do que o espaço em disco disponível e o modelo não pode ser baixado. Teste um SKU com mais espaço em disco ou reduzindo o tamanho da imagem e do modelo.

Cota de memória

Esse problema 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ê está criando um ponto de extremidade online gerenciado, a atribuição de função é necessária para que a identidade gerenciada acesse os recursos do workspace. Se você tiver atingido 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 no portal do Azure navegando até o menu Controle de acesso.

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, você poderá tentar 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

Esse problema ocorre quando a CPU ou memória solicitada não pode ser fornecida devido aos nós não serem programados para essa implantação. Por exemplo, nós podem estar isolados ou não disponíveis.

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

Você pode tentar a seguinte mitigação para resolver esse problema:

  • Para operações de TI que mantêm o cluster de Kubernetes, você pode tentar adicionar mais nós ou limpar alguns pods não utilizados no cluster para liberar alguns recursos.
  • Para engenheiros de machine learning que implantam modelos, você pode 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, poderá tentar reduzir a solicitação de recurso.
    • Se você usar instance type para definir o recurso para implantação de modelo, entre em contato com as operações de TI para ajustar a configuração de recurso de tipo de instância, mais detalhes você pode consultar em Como gerenciar o tipo de instância do Kubernetes.

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 score.py fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos necessários para o score.py e executa o script de pontuação nesse contêiner.

Se o contêiner não pôde ser iniciado, isso significa que a pontuação não poderia acontecer. Pode ser que o contêiner esteja solicitando mais recursos do que instance_type pode proporcionar. Nesse caso, considere a atualização do instance_type da implantação online.

Para obter o motivo exato de um erro, execute:

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

ERROR: BadArgument

A lista a seguir é uma das razões pelas quais você pode encontrar esse erro ao usar o ponto de extremidade online gerenciado ou o ponto de extremidade online do Kubernetes:

A lista a seguir é uma das razões pelas quais você pode encontrar esse erro somente ao usar o ponto de extremidade online do Kubernetes:

A assinatura não existe

A assinatura do Azure que foi inserida deve existir. Esse erro ocorre quando não é possível localizar a assinatura do Azure que foi referenciada. Esse erro provavelmente ocorre devido a um erro de digitação na ID da assinatura. Verifique se a ID da assinatura foi digitada corretamente e se ela está ativa no momento.

Para obter mais informações sobre assinaturas do Azure, confira a seção de pré-requisitos.

Erro de autorização

Depois de provisionar o recurso de computação (durante a criação de uma implantação), o Azure tenta extrair a imagem de contêiner do usuário do ACR (Registro de Contêiner do Azure) do workspace. Ele tenta montar o modelo de usuário e os artefatos de código no contêiner do usuário da conta de armazenamento do workspace.

Para executar essas ações, o Azure usa identidades gerenciadas para acessar a conta de armazenamento e o registro de contêiner.

  • Se você criou o ponto de extremidade associado com Identidade atribuída pelo sistema, a permissão do controle de acesso baseado em função do Azure (RBAC) é automaticamente concedida e nenhuma outra permissão é necessária.

  • Se você criou o ponto de extremidade associado à Identidade Atribuída pelo Usuário, a identidade gerenciada do usuário deve ter permissão de leitura de dados de armazenamento blob na conta de armazenamento para o espaço de trabalho, e permissão AcrPull no Registro de Contêiner do Azure (ACR) para o espaço de trabalho. Cerifique-se de que sua Identidade Atribuída pelo Usuário tenha a permissão correta.

Para obter mais informações, confira 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 ajudá-lo a depurar esse erro e o artigo da estrutura de definição de política do Azure, que discute dicas para evitar falhas de modelo.

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

É possível que o contêiner do usuário não tenha sido encontrado. Verifique os logs de contêiner para obter mais detalhes.

Verifique se a imagem de contêiner está disponível no ACR do workspace.

Por exemplo, se a imagem for testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest, verifique o repositório com 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

É possível que o modelo do usuário não possa ser 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 exibir detalhes de um modelo em um workspace:

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

Aviso

Você precisa especificar a versão ou o rótulo para obter as informações do modelo.

Você também pode verificar 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 ele existe:

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`
    
  • Se o blob estiver presente, você poderá usar esse comando para obter os logs do inicializador de armazenamento:

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

O formato de modelo do MLFlow com rede privada não tem suporte

Esse erro ocorre quando você tenta implantar um modelo de MLflow com uma abordagem de implantação sem código em conjunto com o método de isolamento de rede herdado para pontos de extremidade online gerenciados. Esse recurso de rede privada não poderá ser usado em conjunto com um formato de modelo MLFlow se você estiver usando o método de isolamento de rede herdado. Se você precisar implantar um modelo de MLflow com a abordagem de implantação sem código, tente usar VNet 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, ao anexar sua computação a um workspace do Azure Machine Learning, serão definidos valores padrão. Você pode verificar esses limites no portal do Azure ou usando o comando az ml compute show.

azureml-fe não está pronto

O componente de front-end (azureml-fe) que roteia as solicitações de inferência de entrada para os serviços implantados dimensiona automaticamente conforme necessário. Ele é instalado durante a instalação da extensão k8s.

Esse componente deve estar íntegro no cluster, pelo menos uma réplica íntegra. Você receberá essa mensagem de erro se ela não estiver disponível quando você disparar o ponto de extremidade online do kubernetes e a solicitação de criação/atualização de implantação.

Verifique o status do pod e os logs para corrigir esse problema, você também pode tentar atualizar a extensão k8s instalada no cluster.

ERROR: ResourceNotReady

Para executar o score.py fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos necessários para o score.py e executa o script de pontuação nesse contêiner. O erro desse cenário é que esse contêiner falha durante a execução, o que significa que a pontuação não pode acontecer. Esse erro ocorre quando:

  • Há um erro em score.py. Use o get-logs para diagnosticar problemas comuns:
    • Um pacote que score.py tenta importar não está incluído no ambiente conda.
    • Um erro de sintaxe.
    • Uma falha no método init().
  • Se get-logs não estiver produzindo nenhum log, isso geralmente significa que o contêiner não iniciou. 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 está demorando muito para que a investigação de preparação ou de vida falhe 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 experimente um SKU de VM maior entre SKUs de VM com suporte, o que acelera a inicialização.
  • Há um erro na configuração do ambiente do contêiner, como uma dependência ausente.
  • Ao 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 perguntas frequentes sobre de servidor HTTP de inferência.

ERROR: ResourceNotFound

A lista a seguir é uma das razões pelas quais você pode encontrar esse erro somente ao usar o ponto de extremidade online gerenciado ou o ponto de extremidade online do Kubernetes:

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ê receberá esse erro se uma conta de armazenamento tiver sido referenciada, mas não for encontrada no caminho em que foi especificada. Verifique os recursos que podem ter sido fornecidos pelo caminho exato ou pela ortografia dos nomes deles.

Para obter mais informações, confira Solucionar erros de 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 foi fornecida para implantação. Neste momento, nossas APIs não podem aceitar credenciais privadas do Registro.

Para atenuar esse erro, verifique se o registro de contêiner não é privado ou siga 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 a instrução para não modificar (compilar) a imagem.

Se a mitigação for bem-sucedida, a imagem não exigirá a criaçã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, confira Como usar a API de Diagnóstico do Workspace.

ERRO: OperationCanceled

A lista a seguir é uma das razões pelas quais você pode encontrar esse erro ao usar o ponto de extremidade online gerenciado ou o ponto de extremidade online do Kubernetes:

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 sua operação foi substituída por outra operação que tem uma prioridade mais alta.

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 encontremos condições de corrida. Esse erro ocorre quando a operação enviada é a mesma que outra operação. A outra operação está aguardando confirmação de que recebeu o bloqueio para continuar. Pode indicar que você enviou uma solicitação semelhante muito cedo após a solicitação inicial.

Tentar novamente a operação depois de esperar vários segundos, até um minuto, pode permitir que ela seja executada sem cancelamento.

ERRO: SecretsInjectionError

A recuperação e a injeção de segredos durante a criação da implantação online usam a identidade associada ao ponto de extremidade online para recuperar os segredos das conexões do espaço de trabalho e/ou dos cofres de chaves. Esse erro ocorre quando:

  • A identidade do ponto de extremidade não tem a permissão RBAC do Azure para ler os segredos das conexões do espaço de trabalho e/ou dos cofres de chaves, embora os segredos tenham sido especificados pela definição de implantação como referências (mapeadas para variáveis de ambiente). Lembre-se de que a atribuição de função pode levar algum tempo para que as alterações entrem em vigor.
  • O formato das referências de segredo é inválido ou os segredos especificados não existem nas conexões do espaço de trabalho e/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

Embora façamos o melhor para fornecer um serviço estável e confiável, às vezes, as coisas não saem conforme o planejado. Se você recebe esse erro, isso indica que algo deu errado do nosso lado e precisamos corrigir. Envie um tíquete de suporte ao cliente com todas as informações relacionadas e solucionaremos o problema.

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

Erros relacionados à identidade e autenticação:

Erros relacionados a crashloopbackoff:

Erros relacionados ao script de pontuação:

Outros:

ERROR: ACRSecretError

A lista a seguir é um dos motivos pelos quais você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes:

  • A atribuição de função não foi concluída. Nesse caso, aguarde alguns segundos e tente novamente mais tarde.
  • O Azure ARC (cluster DO Kubernetes do Azure Arc) ou a extensão do Azure Machine Learning (para AKS) não está instalado ou configurado corretamente. Tente verificar a configuração e o status da extensão do Azure ARC ou do Azure Machine Learning.
  • O cluster do Kubernetes tem configuração de rede inadequada, verifique o proxy, a política de rede ou o certificado.
    • Se você estiver usando um cluster privado do AKS, será necessário configurar pontos de extremidade privados para a ACR, a conta de armazenamento e o workspace na vnet do AKS.
  • Verifique se a versão da extensão do Azure Machine Learning é maior que a v1.1.25.

ERRO: TokenRefreshFailed

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

ERRO: GetAADTokenFailed

Esse erro ocorre porque o token do Azure AD da solicitação de cluster do Kubernetes falhou ou atingiu o tempo limite. Verifique a acessibilidade de rede e tente novamente.

  • Você pode seguir as orientações em Configurar o tráfego de rede necessário para verificar o proxy de saída. Certifique-se de que o cluster possa se conectar ao espaço de trabalho.
  • O URL do ponto de extremidade do espaço de trabalho pode ser encontrado na CRD do ponto de extremidade online no cluster.

Se o workspace for um workspace privado, que desabilitou o acesso à rede pública, o cluster do Kubernetes só deverá se comunicar com esse workspace privado por meio do link privado.

ERRO: ACRAuthenticationChallengeFailed

Esse erro ocorre porque o cluster do Kubernetes não pode acessar o serviço ACR do workspace para realizar o desafio de autenticação. Verifique sua rede, especialmente o acesso à rede pública do ACR 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 ACR da troca de cluster do Kubernetes falhou porque o token do Azure AD ainda não foi autorizado. Como a atribuição de função leva algum tempo, para que você possa aguardar um momento e tentar novamente.

Essa falha também pode ser devido a muitas solicitações ao serviço ACR naquele momento e deve ser um erro temporário. Você pode tentar novamente mais tarde.

ERROR: KubernetesUnaccessible

Você pode receber o seguinte erro durante as implantações do modelo do 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:

ERRO: ImagePullLoopBackOff

O motivo provável desse erro durante a criação ou atualização de implantações online do Kubernetes é que as imagens não podem ser baixadas do registro de contêiner, resultando na falha de pull das imagens.

Nesse caso, você pode verificar a política de rede de cluster e o registro de contêiner do workspace se o cluster puder efetuar pull da imagem do registro de contêiner.

ERRO: DeploymentCrashLoopBackOff

O motivo provável desse erro durante a criação ou atualização de implantações online do Kubernetes é que o contêiner do usuário falhou durante a inicialização. Há dois motivos possíveis para esse erro:

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

Para atenuar esse erro, primeiro você pode verificar os logs de implantação 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

A lista a seguir é um dos motivos pelos quais você pode encontrar esse erro ao criar/atualizar os pontos de extremidade/implantações online do Kubernetes:

  • Um ou mais pods presos no status CrashLoopBackoff. Verifique se o log de implantação existe e se há mensagens de erro no log.
  • Há um erro em score.py e o contêiner falhou ao inserir seu código de pontuação, você pode seguir ERROR: ResourceNotReady parte.
  • Seu processo de pontuação precisa de mais memória e o limite de configuração de implantação é insuficiente. É possível tentar atualizar a implantação com um limite de memória maior.

ERROR: NamespaceNotFound

O motivo provável desse erro durante a criação ou atualização dos ponto de extremidade online do Kubernetes é que o namespace usado pela computação do Kubernetes não está disponível no cluster.

É possível verificar a computação do Kubernetes no portal do workspace e verificar o namespace no cluster do Kubernetes. Se o namespace não estiver disponível, você poderá desanexar a computação herdada e reanexar para criar um novo, especificando um namespace que já existe em seu cluster.

ERRO: UserScriptInitFailed

O motivo pelo qual você pode encontrar esse erro ao criar ou atualizar as implantações online do Kubernetes é que a função de inicialização no arquivo carregado score.py gerou uma exceção.

Você pode verificar os logs de implantação para ver a mensagem de exceção em detalhes e corrigir a exceção.

ERRO: UserScriptImportError

O motivo pelo qual você pode encontrar esse erro ao criar ou atualizar as implantações online do Kubernetes é que o arquivo score.py carregado importou pacotes não disponíveis.

Você pode verificar os logs de implantação para ver a mensagem de exceção em detalhes e corrigir a exceção.

ERRO: UserScriptFunctionNotFound

O motivo pelo qual você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes é porque o arquivo score.py que você carregou não tem uma função chamada init() ou run(). Você pode verificar o código e adicionar a função.

ERRO: EndpointNotFound

O motivo provável desse erro durante a criação ou atualização de implantações online do Kubernetes é que o sistema não consegue encontrar o recurso de ponto de extremidade da implantação no cluster. Você deve criar a implantação em um ponto de extremidade existente ou criar esse ponto de extremidade primeiro no cluster.

ERRO: EndpointAlreadyExists

O motivo provável desse erro durante a criação de um ponto de extremidade online do Kubernetes é que esse ponto de extremidade já existe no cluster.

O nome do ponto de extremidade deve ser exclusivo por workspace e por cluster, portanto, nesse caso, você deve criar um ponto de extremidade com outro nome.

ERRO: ScoringFeUnhealthy

O motivo pelo qual você pode encontrar esse erro ao criar/atualizar um ponto de extremidade/implantação online do Kubernetes é porque o Azureml-fe que é o serviço do sistema em execução no cluster não foi encontrado ou não está íntegro.

Para solucionar esse problema, você pode reinstalar ou atualizar a extensão do Azure Machine Learning no cluster.

ERRO: ValidateScoringFailed

O motivo provável desse erro durante a criação ou atualização de implantações online do Kubernetes é que a validação da URL da solicitação de pontuação falhou ao processar a implantação do modelo.

Nesse caso, primeiro você pode verificar a URL do ponto de extremidade e depois tentar fazer a reimplantação.

ERRO: InvalidDeploymentSpec

O motivo provável desse erro durante a criação ou atualização de implantações online do Kubernetes é que a especificação de implantação é inválida.

Nesse caso, você pode verificar a mensagem de erro.

  • Verifique se 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

A lista a seguir é um dos motivos pelos quais você pode encontrar esse erro ao criar/atualizar os pontos de extremidade/implantações online do Kubernetes:

  • Não é possível agendar o pod para nós devido a recursos insuficientes no cluster.
  • Não há nenhuma afinidade ou seletor de nó de correspondência de nós.

Para atenuar esse erro, siga estas etapas:

  • Verifique a definição node selector do instance type usado e a configuração node label dos nós de cluster.
  • Verifique instance type e o tamanho do SKU do nó do cluster do AKS ou o recurso de nó do cluster do Arc-Kubernetes.
    • Se o cluster não tiver recursos suficientes, você poderá reduzir o requisito de recursos do tipo de instância ou usar outro tipo de instância com um recurso menor necessário.
  • Se o cluster não tiver mais recursos para atender ao requisito da implantação, exclua alguma implantação para liberar recursos.

ERRO: PodOutOfMemory

O motivo pelo qual você pode encontrar esse erro ao criar ou atualizar a implantação online é que o limite de memória fornecido para a implantação é insuficiente. Você pode definir o limite de memória para um valor maior ou usar um tipo de instância maior para mitigar esse erro.

ERROR: InferencingClientCallFailed

O motivo pelo qual você pode encontrar esse erro ao criar/atualizar pontos de extremidade/implantações online do Kubernetes é porque a extensão k8s do cluster kubernetes não é conectável.

Nesse caso, você pode desanexar e anexar novamente sua computação.

Observação

Para solucionar erros por meio da reanexação, use a mesma configuração exata que a computação desanexada anteriormente, como os mesmos nome de computação e namespace. Caso contrário, poderá haver outros erros.

Se ainda não estiver funcionando, você poderá perguntar ao administrador que pode acessar o cluster para usar kubectl get po -n azureml para verificar se o servidor de retransmissão pods estão em execução.

Problemas de dimensionamento automático

Se você estiver tendo problemas com o dimensionamento automático, confira Solução de problemas no dimensionamento automático do Azure.

Para o ponto de extremidade online do Kubernetes, há roteador de inferência do Azure Machine Learning que é um componente de front-end para lidar com o dimensionamento automático de todas as implantações de modelo no cluster do Kubernetes, você pode encontrar mais informações no Dimensionamento Automático de roteamento de inferência do Kubernetes

Erros comuns de consumo de modelo

A lista a seguir contém erros comuns de consumo de modelo resultantes do status de operação invoke do ponto de extremidade.

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ê encontra 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 de largura de banda atual. Para obter mais informações, confira Monitorar pontos de extremidade online gerenciados.
  • Há dois trailers de resposta retornados se o limite de largura de banda for imposto:
    • ms-azureml-bandwidth-request-delay-ms: tempo de atraso em milissegundos que levou para a transferência do fluxo de solicitação.
    • ms-azureml-bandwidth-response-delay-ms: tempo de atraso em milissegundos que levou para a transferência do fluxo de resposta.

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. Estes são detalhes de como os erros de invocação e de 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 ao consumir pontos de extremidade online gerenciados com solicitações REST:

Código de status Frase explicativa Por que esse código pode ser retornado
200 OK Seu modelo foi executado com êxito, dentro da latência associada.
401 Não Autorizado Você não tem permissão para realizar a ação solicitada, como pontuação, ou seu token expirou ou está no formato errado. Para obter mais informações, veja conceito de autenticação de ponto de extremidade e como autenticar para ponto de extremidade.
404 Não encontrado O ponto de extremidade não tem nenhuma implantação válida com peso positivo.
408 Tempo limite da solicitação A execução do modelo demorou mais do que o tempo limite fornecido em request_timeout_ms nas request_settings da configuração de implantação de modelo.
424 Erro do Modelo Se o contêiner de modelo retornar uma resposta diferente de 200, o Azure retornará um erro 424. Verifique a dimensão Model Status Code na métrica Requests Per Minute no Gerenciador de Métricas do Azure Monitor do seu ponto de extremidade. Ou então, verifique os cabeçalhos de resposta ms-azureml-model-error-statuscode e ms-azureml-model-error-reason para obter mais informações. Se o 424 vier com falha na investigação de disponibilidade ou preparação, considere ajustar as configurações de investigação para permitir mais tempo de vida ou preparação do contêiner.
429 Excesso de solicitações pendentes Seu modelo está recebendo mais solicitações do que pode suportar. O Azure Machine Learning implementou um sistema que permite que um máximo de 2 * max_concurrent_requests_per_instance * instance_count requests seja processado paralelamente em qualquer momento para garantir uma operação tranquila. Outras solicitações que excedem esse máximo são rejeitadas. Você pode analisar a configuração de implantação do modelo nas seções request_settings e scale_settings para verificar e ajustar essas configurações. Além disso, conforme descrito na definição de YAML para RequestSettings, é importante garantir que a variável de ambiente WORKER_COUNT seja passada corretamente.

Se você estiver usando o dimensionamento automático e receber esse erro, isso significa que seu modelo está recebendo solicitações mais rapidamente do que o sistema pode escalar verticalmente. Nesta situação, considere reenviar solicitações com uma retirada exponencial para dar ao sistema o tempo necessário para ajustar. Você também pode aumentar o número de instâncias usando o código para calcular a contagem de instâncias. Essas etapas, combinadas com a configuração do dimensionamento automático, ajudam a garantir que o modelo esteja pronto para lidar com o fluxo de solicitações.
429 Limitado por taxa O número de solicitações por segundo atingiu o limite de pontos de extremidade online gerenciados.
500 Erro interno do servidor A infraestrutura provisionada do Azure Machine Learning está com uma falha.

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

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

Código de status Frase explicativa Por que esse código pode ser retornado
409 Erro de conflito Quando uma operação já estiver em andamento, uma operação nova no mesmo ponto de extremidade online causará o erro de conflito 409. Por exemplo, se a operação de criação ou atualização de ponto de extremidade online estiver em andamento e você disparar uma nova operação de exclusão, um erro será gerado.
502 Gerou uma exceção ou falhou no método run() do arquivo score.py Quando há um erro em score.py, por exemplo, um pacote importado não existe no ambiente conda, um erro de sintaxe ou uma falha no método init(). Você pode seguir as instruções aqui para depurar o arquivo.
503 Receber picos grandes em solicitações por segundo O dimensionador automático foi criado para lidar com mudanças gradativas na carga. Se você receber grandes picos em solicitações por segundo, os clientes podem receber um código de status HTTP 503. Embora o dimensionamento automático reaja rapidamente, o AKS leva um tempo significativo para criar mais contêineres. Você pode seguir as instruções aqui para evitar códigos de status 503.
504 O tempo limite da solicitação foi atingido O código de status 504 indica que a solicitação atingiu o tempo limite. O tempo limite padrão é de cinco segundos. Você pode aumentar o tempo limite ou tentar acelerar o ponto de extremidade, modificando o score.py para remover as chamadas desnecessárias. Se essas ações não corrigirem o problema, você poderá seguir as instruções aqui para depurar o arquivo score.py. O código pode estar em um estado não responsivo ou em um loop infinito.
500 Erro interno do servidor A infraestrutura provisionada do Azure Machine Learning está com uma falha.

Como evitar códigos de status 503

As implantações online do Kubernetes dão suporte ao dimensionamento automático, que permite que réplicas sejam adicionadas para dar suporte à carga extra. Mais informações podem ser encontradas em Roteador de inferência do Azure Machine Learning. As decisões para dimensionar verticalmente/horizontalmente baseiam-se na utilização das réplicas de contêiner.

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

Dica

Essas duas abordagens podem ser usadas individualmente ou combinadas.

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

    Importante

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

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

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

    Para aumentar o número de instâncias, você pode calcular as réplicas necessárias seguindo estes códigos.

    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)
    

    Observação

    Se você receber um número de picos de solicitação superior à capacidade de suporte do novo mínimo de réplicas, poderá haver códigos 503 novamente. Por exemplo, à medida que o tráfego para o ponto de extremidade aumenta, talvez seja necessário aumentar as réplicas mínimas.

Como calcular a contagem de instâncias

Para aumentar o número de instâncias, você pode calcular as réplicas necessárias usando o código a seguir:

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)

Bloqueado pela política do CORS

Atualmente, os pontos de extremidade online (v2) não dão suporte ao Compartilhamento de Recursos entre Origens (CORS) nativamente. Se o aplicativo Web tentar invocar o ponto de extremidade sem o tratamento adequado das solicitações de simulação do CORS, você verá 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.

Recomendamos que você use o Azure Functions, o Gateway de Aplicativo do Azure ou qualquer serviço como uma camada provisória para lidar com solicitações de simulação do CORS.

Problemas comuns de isolamento de rede

A criação de ponto de extremidade online tem uma falha com uma mensagem V1LegacyMode == true

O workspace do Azure Machine Learning pode ser configurado como v1_legacy_mode, o que desabilita as APIs v2. Os pontos de extremidade online gerenciados são um recurso da plataforma da API v2 e não funcionarão se v1_legacy_mode estiver habilitado no workspace.

Importante

Antes de desabilitar v1_legacy_mode, verifique com sua equipe de segurança de rede. Ele pode ter sido habilitado pela sua equipe de segurança de rede por um motivo.

Para obter informações sobre como desabilitar v1_legacy_mode, confira Isolamento de rede com a 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 documento 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

Observação

Esse problema se aplica quando você usa o método de isolamento de rede herdado para pontos de extremidade online gerenciados, no qual o Azure Machine Learning cria uma VNet gerenciada para cada implantação em um ponto de extremidade.

  1. Verifique se o sinalizador egress-public-network-access está desabilitado 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 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 documento de resposta, verifique se o campo status está definido como Approved. Se não estiver aprovado, 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:

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

    Se a resposta contiver um endereço. Esse endereço 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 for um ponto de extremidade HTTP, o endereço IP estará contido no URI do ponto de extremidade que você pode obter diretamente na interface do usuário do Estúdio. Veja outras formas de obter o endereço IP do ponto de extremidade em Ponto de extremidade online seguro do Kubernetes.

  3. Se o nome do host não for resolvido pelo comando nslookup:

    Para um ponto de extremidade online gerenciado,

    1. Verifique se existe um registro A na zona DNS privada para a rede virtual.

      Para verificar os registros, use o seguinte comando:

      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 estiver configurado usando um DNS personalizado, consulte Como usar o workspace com um servidor DNS personalizado, use o seguinte comando para verificar se a resolução funciona corretamente no DNS personalizado.

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

    Para um ponto de extremidade online do Kubernetes,

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

    2. Além disso, você pode verificar se o comando azureml-fe funciona conforme o esperado. Use 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

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

    Se os HTTPs do curl falharem (por exemplo, alcançarem o tempo limite), mas o HTTP funcionar, verifique se o certificado está válido.

    Se isso não resolver para o registro A, verifique se a resolução funciona no DNS do Azure (168.63.129.16).

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

    Se isso der certo, solucione problemas do encaminhador condicional do link privado no DNS personalizado.

Implantações online não podem ser pontuadas

  1. Use o seguinte comando para ver se a implantação foi implantada com êxito:

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

    Dica

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

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

  3. Se as atribuições de tráfego (ou o cabeçalho de implantação) forem definidas 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> 
    

    Examine 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.

Solucionar problemas do servidor de inferência

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

Etapas básicas

As etapas básicas para solução de problemas são:

  1. Reunir informações de versão para seu ambiente do Python.
  2. Verificar se 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 AzureML exibida no log de inicialização. Às vezes, o resolvedor de dependência do pip leva a versões inesperadas de pacotes instalados.
  3. Se você tiver especificado o Flask (e suas dependências) em seu ambiente, remova-os. As dependências incluem Flask, Jinja2, itsdangerous, Werkzeug, MarkupSafee click. O Flask é listado como uma dependência no pacote do servidor e é melhor permitir que nosso servidor o instale. Dessa forma, quando o servidor der suporte a novas versões do Flask, você as obterá automaticamente.

Versão do servidor __

O pacote do servidor azureml-inference-server-http é publicado no PyPI. Você pode encontrar nossa lista de alterações e todas as versões anteriores em nossa página PyPI. Atualize para a versão mais recente se você estiver usando uma versão anterior.

  • 0.4.x: A versão agrupada em imagens de treinamento ≤ 20220601 e em azureml-defaults>=1.34,<=1.43. 0.4.13 é a última versão estável. Se você usar o servidor antes da versão 0.4.11, poderá ver problemas de dependência do Flask, como não poder importar o nome Markup de jinja2. É recomendável atualizar para 0.4.13 ou 0.8.x (a versão mais recente), se possível.
  • 0.6.x: A versão pré-instalada em imagens de inferência ≤ 20220516. A última versão estável é 0.6.1.
  • 0.7.x: A primeira versão que dá suporte ao Flask 2. A última versão estável é 0.7.7.
  • 0.8.x: O formato de log foi alterado e o suporte ao Python 3.6 foi descartado.

Dependências do pacote

Os pacotes mais relevantes para o servidor azureml-inference-server-http são os seguintes pacotes:

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

Se você especificou azureml-defaults em seu ambiente Python, o pacote azureml-inference-server-http é dependente e será instalado automaticamente.

Dica

Se você estiver usando o SDK do Python v1 e não especificar azureml-defaults explicitamente em seu ambiente python, o SDK poderá adicionar o pacote para você. No entanto, ele o bloqueará na versão em que o SDK está. Por exemplo, se a versão do SDK for 1.38.0, ela adicionará azureml-defaults==1.38.0 aos requisitos de pip do ambiente.

Perguntas frequentes

1. Encontrei o seguinte erro 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

Você tem o Flask 2 instalado em seu ambiente Python, mas está executando uma versão de azureml-inference-server-http que não dá suporte ao Flask 2. O suporte para Flask 2 é adicionado azureml-inference-server-http>=0.7.0, que também está em azureml-defaults>=1.44.

  • Se você não estiver usando esse pacote em uma imagem do Docker do AzureML, use a versão mais recente azureml-inference-server-http ou azureml-defaults.

  • Se você estiver usando esse pacote com uma imagem do Docker do AzureML, verifique se está usando uma imagem interna ou após julho de 2022. A versão da imagem está disponível nos logs de contêiner. Você deve encontrar um log semelhante ao seguinte:

    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, Materializaton 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 é exibida após “Compilação de Materialização”, que no exemplo acima é 20220708, ou 8 de julho de 2022. Essa imagem é compatível com o Flask 2. Se você não vir uma faixa como essa no log de contêineres, sua imagem estará desatualizada e deverá ser atualizada. Se você estiver usando uma imagem CUDA e não conseguir encontrar uma imagem mais recente, verifique se sua imagem foi preterida em Contêineres do AzureML. Se for, você deve encontrar substituições.

  • Se você estiver usando o servidor com um ponto de extremidade online, você também poderá encontrar os logs em “Logs de implantação” na página de ponto de extremidade online 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 padrão será usar uma versão de openmpi4.1.0-ubuntu20.04 que corresponda ao conjunto de ferramentas do SDK local, que pode não ser a versão mais recente da imagem. Por exemplo, o SDK 1.43 usará o padrão openmpi4.1.0-ubuntu20.04:20220616, o que é incompatível. Certifique-se de usar o SDK mais recente para sua implantação.

  • Se, por algum motivo, você não conseguir atualizar a imagem, poderá evitar temporariamente o problema fixando azureml-defaults==1.43 ou azureml-inference-server-http~=0.4.13, que instalará o servidor de versão mais antigo com Flask 1.0.x.

2. Encontrei um ImportError ou ModuleNotFoundError nos módulos opencensus, jinja2, MarkupSafe ou click durante a inicialização, como a seguinte mensagem:

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

As versões mais antigas (<= 0.4.10) do servidor não fixaram a dependência do Flask em versões compatíveis. Esse problema foi corrigido na versão mais recente do servidor.

Próximas etapas