Solução de problemas de implantação e pontuação de endpoints on-line

  • Artigo

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

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

Este documento está estruturado da forma como deve abordar a resolução de problemas:

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

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

Pré-requisitos

Implementar localmente

A implementação local está a implementar um modelo num ambiente do Docker local. A implantação local é útil para testar e depurar antes da implantação na nuvem.

Gorjeta

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

A implementação local suporta a criação, a atualização e a eliminação de pontos finais locais. Também permite invocar e obter registos do ponto final.

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

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

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

  • O Docker cria uma nova imagem de contêiner ou extrai uma imagem existente do cache local do Docker. Uma imagem existente é 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 saber mais, consulte Implantar localmente em Implantar e pontuar um modelo de aprendizado de máquina.

Gorjeta

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

Instalação Conda

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

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

  1. Verifique os logs para a instalação do conda. Se o contêiner travou ou demorou muito para iniciar, é provável que a atualização do ambiente conda não tenha sido resolvida corretamente.

  2. Instale o arquivo mlflow conda localmente com o comando conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. Se houver erros localmente, tente resolver o ambiente conda e criar um funcional antes de reimplantar.

  4. Se o contêiner falhar, mesmo que seja resolvido localmente, o tamanho da SKU usado para implantação pode ser muito pequeno.

    1. A instalação do pacote Conda ocorre em tempo de execução, portanto, se o tamanho da SKU for muito pequeno para acomodar todos os pacotes detalhados no conda.yaml arquivo de ambiente, o contêiner poderá falhar.
    2. Uma VM Standard_F4s_v2 é um bom tamanho de SKU inicial, mas podem ser necessárias outras 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 vCPU e 8 GB de memória.

Obter registos dos contentores

Não pode obter acesso direto à VM onde o modelo está implementado. No entanto, pode obter registos de alguns dos contentores que estão em execução na VM. A quantidade de informações que você obtém depende do status de provisionamento da implantação. Se o contêiner especificado estiver em execução, você verá a saída do console; caso contrário, você 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 das funções de impressão/registro do seu script de pontuação (score.pycódigo).
  • Inicializador de armazenamento: os logs contêm informações sobre se os dados de código e modelo foram baixados com êxito para o contêiner. O contêiner é executado antes que o contêiner do servidor de inferência comece a ser executado.

Para ver a saída de log de um 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 via az configure.

Para ver informações sobre como definir esses parâmetros, e se você tiver valores definidos no momento, execute:

az ml online-deployment get-logs -h

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

Nota

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

Você também pode obter logs do contêiner do inicializador de armazenamento passando –-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 onde você implanta o modelo, o que é mais flexível para eles verificarem o log no Kubernetes. Por exemplo:

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

Rastreamento de solicitações

Há dois cabeçalhos de rastreamento suportados:

  • x-request-id está reservado para rastreamento de servidores. Substituímos esse cabeçalho para garantir que seja um GUID válido.

    Nota

    Ao criar um tíquete de suporte para uma solicitação com falha, anexe a ID da solicitação com falha para agilizar a investigação.

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

Erros de implementação comuns

A lista a seguir é de erros comuns de implantação que sã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 para implantações do Kubernetes.

ERRO: ImageBuildFailure

Este erro é retornado quando o ambiente (imagem docker) está sendo criado. Você pode verificar o log de compilação para obter mais informações sobre a(s) falha(s). O log de compilação está localizado no armazenamento padrão para seu espaço de trabalho do Azure Machine Learning. O local exato pode ser retornado como parte do erro. Por exemplo, "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'".

A lista a seguir contém cenários comuns de falha de compilação de imagem:

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

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

Se a mensagem de "container registry authorization failure" erro mencionar, 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 de espaço de trabalho pode causar esse erro e leva algum tempo para sincronizar automaticamente. 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 que estão atrás de uma rede virtual também podem encontrar esse erro se configurados incorretamente. Você deve verificar se a rede virtual está configurada corretamente.

Computação de compilação de imagem não definida em um espaço de trabalho privado com VNet

Se a mensagem de "failed to communicate with the workspace's container registry" erro mencionar e você estiver usando redes virtuais e o Registro de Contêiner do Azure do espaço de trabalho 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 na compilação de imagem genérica

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

Também recomendamos implantar localmente para testar e depurar seus modelos localmente antes de implantar na nuvem.

ERRO: 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 apenas para o ponto de extremidade online do Kubernetes:

CPU Quota

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

Uma atenuação possível é verificar se há implantações não utilizadas que você pode excluir. Ou pode apresentar um pedido de aumento de quota.

Cota de cluster

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

Uma atenuação possível é verificar se há implantações não utilizadas que você pode excluir. Ou pode apresentar um pedido de aumento de quota. Certifique-se de selecionar Machine Learning Service: Cluster Quota como o tipo de cota para essa solicitação de aumento de cota.

Quota de disco

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

Quota de memória

Esse problema acontece quando o espaço ocupado pela memória do modelo é maior do que a memória disponível. Experimente um SKU com mais memória.

Quota de atribuição de funções

Quando você 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 espaço de trabalho. Se o limite de atribuição de função for atingido, 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 final

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

Cota do Kubernetes

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

A mensagem de erro normalmente indica que 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 na sua solicitação.

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

  • Para operações de TI que mantêm o cluster do Kubernetes, você pode tentar adicionar mais nós ou limpar alguns pods não utilizados no cluster para liberar alguns recursos.
  • Para engenheiros de aprendizado de máquina que implantam modelos, você pode tentar reduzir a solicitação de recursos de sua implantação:
    • Se você definir diretamente a solicitação de recurso na seção de configuração de implantação via recurso, poderá tentar reduzir a solicitação de recurso.
    • Se você usar instance type para definir recurso para implantação de modelo, poderá entrar em contato com as operações de TI para ajustar a configuração de recurso do tipo de instância, mais detalhes você pode consultar 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 não conseguiu provisionar o tamanho de VM especificado. Tente novamente mais tarde ou tente implantar em uma região diferente.

Outras quotas

Para executar o score.py fornecido como parte da implantação, o Azure cria um contêiner que inclui todos os recursos necessários score.py e executa o script de pontuação nesse contêiner.

Se o seu contêiner não pôde começar, isso significa que a pontuação não poderia acontecer. Pode ser que o contêiner esteja solicitando mais recursos do que o que instance_type pode suportar. Em caso afirmativo, considere atualizar a instance_type implantação on-line.

Para obter o motivo exato de um erro, execute:

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

ERRO: BadArgument

A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao usar o endpoint online gerenciado ou o endpoint 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 subscrição não existe

A assinatura do Azure inserida deve existir. Este erro ocorre quando não conseguimos encontrar a subscrição do Azure que foi referenciada. Este erro é provavelmente devido a um erro de digitação no ID da assinatura. Verifique se o ID da assinatura foi digitado corretamente e se está ativo no momento.

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

Erro de autorização

Depois de provisionar o recurso de computação (ao criar uma implantação), o Azure tenta extrair a imagem do contêiner do usuário do espaço de trabalho Azure Container Registry (ACR). Ele tenta montar o modelo de usuário e codificar artefatos no contêiner do usuário a partir da conta de armazenamento do espaço de trabalho.

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 a Identidade Atribuída ao 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.

  • Se você criou o ponto de extremidade associado com a Identidade Atribuída pelo Usuário, a identidade gerenciada do usuário deve ter permissão de leitor de dados de blob de armazenamento 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. Certifique-se de que a sua Identidade Atribuída ao Utilizador tem a permissão certa.

Para obter mais informações, consulte Erro de autorização do registro de contêiner.

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

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

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

É 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 do contêiner está disponível no ACR do espaço de trabalho.

Por exemplo, se a imagem estiver testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest verificando o repositório com az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

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

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

Certifique-se de ter registrado o modelo no mesmo espaço de trabalho da implantação. Para mostrar detalhes de um modelo em um espaço de trabalho:

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

Aviso

Você deve 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 espaço de trabalho.

  • Por exemplo, se o blob for https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl, você pode usar este 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 este comando para obter os logs do inicializador de armazenamento:

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

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

Esse erro acontece quando você tenta implantar um modelo 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 pode 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 MLflow com a abordagem de implantação sem código, tente usar a VNet gerenciada pelo espaço de trabalho.

Solicitações de recursos maiores que os limites

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

azureml-fe não está pronto

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

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

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

ERRO: ResourceNotReady

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

  • Há um erro no score.py. Use 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 init() método.
  • Se get-logs não estiver produzindo logs, isso geralmente significa que o contêiner falhou ao iniciar. Para depurar esse problema, tente implantar localmente .
  • As sondas de prontidão ou vivacidade não estão configuradas corretamente.
  • A inicialização do contêiner está demorando muito para que a sonda de prontidão ou vivacidade falhe além do limite de falha. Nesse caso, ajuste as configurações da sonda para permitir mais tempo para inicializar o contêiner. Ou tente uma SKU de VM maior entre as SKUs de VM suportadas, o que acelera a inicialização.
  • Há um erro na configuração do ambiente do contêiner, como uma dependência ausente.
  • Quando receber o TypeError: register() takes 3 positional arguments but 4 were given erro, verifique a dependência entre o frasco v2 e azureml-inference-server-httpo . Para obter mais informações, consulte Perguntas frequentes sobre o servidor HTTP de inferência.

ERRO: ResourceNotFound

A lista a seguir mostra os motivos pelos quais você pode se deparar com esse erro somente ao usar o endpoint online gerenciado ou o endpoint online do Kubernetes:

O Resource Manager não consegue encontrar um recurso

Este erro ocorre quando o Azure Resource Manager não consegue encontrar um recurso necessário. Por exemplo, você pode receber esse erro se uma conta de armazenamento foi referida, mas não pode ser encontrada no caminho no qual ela foi especificada. Certifique-se de verificar novamente os recursos que podem ter sido fornecidos pelo caminho exato ou pela ortografia de seus nomes.

Para obter mais informações, consulte Resolver erros de recurso não encontrado.

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

Este erro ocorre quando uma imagem pertencente a um registro de contêiner privado ou inacessível foi fornecida para implantação. No momento, nossas APIs não podem aceitar credenciais de registro privadas.

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

  1. Conceda a função do acrPull seu registo privado à identidade do sistema do seu ponto de extremidade online.
  2. Na definição do seu ambiente, especifique o endereço da sua imagem privada e a instrução para não modificar (construir) a imagem.

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

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

ERRO: OperationCanceled

A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao usar o endpoint online gerenciado ou o endpoint online do Kubernetes:

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

As operações do Azure têm um determinado nível de prioridade e são executadas do mais alto para o mais baixo. Este erro acontece quando a 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 após serem enviadas, durante o qual recuperam um bloqueio para garantir que não nos deparamos com condições de corrida. Este erro acontece quando a operação enviada é igual a outra operação. A outra operação aguarda a confirmação de que recebeu o bloqueio para prosseguir. Isso pode indicar que você enviou uma solicitação semelhante muito cedo após a solicitação inicial.

Repetir 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 injeção de segredos durante a criação da implantação online usa a identidade associada ao ponto de extremidade online para recuperar segredos das conexões do espaço de trabalho e/ou cofres de chaves. Este erro acontece quando:

  • A identidade do ponto de extremidade não tem a permissão do RBAC do Azure para ler os segredos das conexões de espaço de trabalho e/ou cofres de chave, mesmo que os segredos tenham sido especificados pela definição de implantação como referências (mapeados 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 secretas é inválido ou os segredos especificados não existem nas conexões de espaço de trabalho e/ou cofres de chaves.

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

ERRO: InternalServerError

Embora façamos o nosso melhor para fornecer um serviço estável e confiável, às vezes as coisas não saem conforme o planejado. Se você receber esse erro, isso significa que algo não está bem do nosso lado, e precisamos corrigi-lo. Envie um ticket de suporte ao cliente com todas as informações relacionadas e podemos resolver o problema.

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

Erros relativos à identidade e autenticação:

Erros relativos ao crashloopbackoff:

Erros em relação ao script de pontuação:

Outros:

ERRO: ACRSecretError

A lista a seguir mostra os motivos pelos quais você pode se deparar com 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 (Para cluster do Azure Arc Kubernetes) ou a extensão do Azure Machine Learning (Para AKS) não está instalada ou configurada corretamente. Tente verificar a configuração e o status da extensão Azure ARC ou Azure Machine Learning.
  • O cluster Kubernetes tem configuração de rede incorreta, verifique o proxy, a diretiva de rede ou o certificado.
    • Se você estiver usando um cluster AKS privado, é necessário configurar pontos de extremidade privados para ACR, conta de armazenamento, espaço de trabalho na vnet 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

Este erro ocorre porque o token do Azure AD de solicitação de cluster do Kubernetes falhou ou expirou, verifique a acessibilidade da rede e tente novamente.

  • Você pode seguir a opção 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.
  • A URL do ponto de extremidade do espaço de trabalho pode ser encontrada no CRD do ponto de extremidade online no cluster.

Se o seu espaço de trabalho for um espaço de trabalho privado, que desativou o acesso à rede pública, o cluster do Kubernetes só deverá se comunicar com esse espaço de trabalho privado por meio do link privado.

  • Você pode verificar se o acesso ao espaço de trabalho permite acesso público, não importa se um cluster AKS em si é público ou privado, ele não pode acessar o espaço de trabalho privado.
  • Para obter mais informações, consulte Secure Azure Kubernetes Service inferencing environment

ERRO: ACRAuthenticationChallengeFailed

Esse erro ocorre porque o cluster do Kubernetes não pode acessar o serviço ACR do espaço de trabalho para fazer o desafio de autenticação. Verifique a sua rede, especialmente o acesso à rede pública ACR, e tente novamente.

Você pode seguir as etapas de solução de problemas em GetAADTokenFailed ao verificar a rede.

ERRO: ACRTokenExchangeFailed

Este erro ocorre porque o token ACR da troca de cluster do Kubernetes falhou porque o token do Azure AD ainda não está autorizado. Como a atribuição de função leva algum tempo, você pode esperar um momento e tentar novamente.

Esta falha também pode ser devido a muitas solicitações para o serviço ACR naquele momento, deve ser um erro transitório, você pode tentar novamente mais tarde.

ERRO: KubernetesUnaccessible

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

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

Para atenuar esse erro, você pode:

ERRO: ImagePullLoopBackOff

A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque não é possível baixar as imagens do registro do contêiner, resultando na falha de pull de imagens.

Nesse caso, você pode verificar a diretiva de rede do cluster e o registro do contêiner do espaço de trabalho se o cluster puder extrair a imagem do registro do contêiner.

ERRO: DeploymentCrashLoopBackOff

A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é que o contêiner do usuário falhou ao inicializar. Há duas razões possíveis para esse erro:

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

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

ERRO: KubernetesCrashLoopBackOff

A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao criar/atualizar os endpoints/implantações online do Kubernetes:

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

ERRO: NamespaceNotFound

A razão pela qual você pode encontrar esse erro ao criar/atualizar os pontos de extremidade online do Kubernetes é porque o namespace usado pelo Kubernetes não está disponível no cluster.

Você pode verificar a computação do Kubernetes no portal do espaço de trabalho e verificar o namespace no cluster do Kubernetes. Se o namespace não estiver disponível, você poderá desanexar a computação herdada e anexá-la novamente para criar uma nova, especificando um namespace que já existe no cluster.

ERRO: UserScriptInitFailed

A razão pela qual você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes é porque a função init no arquivo carregado score.py gerou 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

A razão pela qual você pode encontrar esse erro ao criar/atualizar as implantações online do Kubernetes é porque o score.py arquivo carregado importou pacotes indisponí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

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

ERRO: EndpointNotFound

A razão pela qual você pode encontrar esse erro ao criar/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. Você deve criar a implantação em um ponto de extremidade existente ou criar esse ponto de extremidade primeiro em seu cluster.

ERRO: EndpointAlreadyExists

A razão pela qual você pode encontrar esse erro ao criar um ponto de extremidade online do Kubernetes é porque o ponto de extremidade de criação já existe no cluster.

O nome do ponto de extremidade deve ser exclusivo por espaço de trabalho e por cluster, portanto, nesse caso, você deve criar o ponto de extremidade com outro nome.

ERRO: ScoringFeUnhealthy

A razão pela 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 em seu cluster.

ERRO: ValidateScoringFailed

A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque a validação da URL da solicitação de pontuação falhou ao processar a implantação do modelo.

Nesse caso, você pode primeiro verificar a URL do ponto de extremidade e, em seguida, tentar reimplantar a implantação.

ERRO: InvalidDeploymentSpec

A razão pela qual você pode encontrar esse erro ao criar/atualizar implantações online do Kubernetes é porque a especificação de implantação é inválida.

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

  • Certifique-se de que o instance count é válido.
  • Se tiver ativado o dimensionamento automático, certifique-se de que ambos são minimum instance countmaximum instance count válidos.

ERRO: PodUnschedulable

A lista a seguir mostra os motivos pelos quais você pode encontrar esse erro ao criar/atualizar os endpoints/implantações online do Kubernetes:

  • Não é possível agendar pod para nós, devido a recursos insuficientes em seu cluster.
  • Nenhuma afinidade/seletor de nó corresponde ao nó.

Para atenuar esse erro, você pode seguir estas etapas:

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

ERRO: PodOutOfMemory

A razão pela qual você pode encontrar esse erro ao criar/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 atenuar esse erro.

ERRO: InferencingClientCallFailed

A razão pela qual você pode encontrar esse erro ao criar/atualizar endpoints/implantações online do Kubernetes é porque a extensão k8s do cluster do Kubernetes não é conectável.

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

Nota

Para solucionar erros reanexando, garanta reanexar com a mesma configuração da computação desanexada anteriormente, como o mesmo nome de computação e namespace, caso contrário, você poderá encontrar outros erros.

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

Problemas de dimensionamento automático

Se estiver a ter problemas com o dimensionamento automático, consulte Resolução de problemas de dimensionamento automático do Azure.

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

Erros comuns de consumo do modelo

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

Problemas de limite de largura de banda

Os endpoints 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 de largura de banda:

  • Use a métrica "Bytes de rede" para entender o uso atual da largura de banda. Para obter mais informações, consulte Monitorar pontos de extremidade online gerenciados.
  • Há dois trailers de resposta retornados se o limite de largura de banda for aplicado:
    • ms-azureml-bandwidth-request-delay-ms: tempo de atraso em milissegundos que levou para a transferência de 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 estado HTTP

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

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

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

Código de estado Frase da razão Por que esse código pode ser retornado
200 OK Seu modelo foi executado com sucesso, dentro do limite de latência.
401 Não autorizado Você não tem permissão para executar a ação solicitada, como pontuação, ou seu token expirou ou no formato errado. Para obter mais informações, consulte 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 do pedido A execução do modelo levou mais tempo do que o tempo limite fornecido na request_timeout_msrequest_settings configuração de implantação do modelo.
424 Erro de modelo Se o contêiner modelo retornar uma resposta diferente de 200, o Azure retornará uma resposta 424. Verifique a Model Status Code dimensão sob a Requests Per Minute métrica no Azure Monitor Metric Explorer do seu ponto de extremidade. Ou verifique os cabeçalhos de ms-azureml-model-error-statuscode resposta e ms-azureml-model-error-reason para obter mais informações. Se o 424 vier com falha na sonda de vivacidade ou prontidão, considere ajustar as configurações da sonda para permitir mais tempo para a vida da sonda ou a prontidão do contêiner.
429 Demasiados pedidos pendentes Atualmente, seu modelo está recebendo mais solicitações do que pode lidar. O Azure Machine Learning implementou um sistema que permite que um máximo de 2 * max_concurrent_requests_per_instance * instance_count requests processos sejam processados em paralelo a qualquer momento para garantir um bom funcionamento. Outros pedidos que excedam este limite são rejeitados. Você pode revisar 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 YAML para RequestSettings, é importante garantir que a variável WORKER_COUNT de ambiente 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. Nessa situação, considere reenviar solicitações com um backoff exponencial para dar ao sistema o tempo necessário para ajustar. Você também pode aumentar o número de instâncias usando código para calcular a contagem de instâncias. Essas etapas, combinadas com a configuração do dimensionamento automático, ajudam a garantir que seu modelo esteja pronto para lidar com o fluxo de solicitações.
429 Taxa limitada O número de solicitações por segundo atingiu os limites dos endpoints online gerenciados.
500 Erro interno do servidor A infraestrutura provisionada do Azure Machine Learning está falhando.

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

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

Código de estado Frase da razão Por que esse código pode ser retornado
409 Erro de conflito Quando uma operação já está em andamento, qualquer nova operação nesse mesmo ponto de extremidade online responde com 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 se você acionar uma nova operação Excluir, ela gerará um erro.
502 Lançou uma exceção ou falhou no run() método do arquivo score.py Quando há um erro no score.py, por exemplo, um pacote importado não existe no ambiente conda, um erro de sintaxe ou uma falha no init() método. Você pode seguir aqui para depurar o arquivo.
503 Receba grandes picos de solicitações por segundo O autoscaler é projetado para lidar com mudanças graduais na carga. Se você receber grandes picos de solicitações por segundo, os clientes poderão receber um código de status HTTP 503. Embora o autoscaler reaja rapidamente, o AKS leva uma quantidade significativa de tempo para criar mais contêineres. Você pode seguir aqui para evitar códigos de status 503.
504 O tempo limite do pedido expirou Um código de status 504 indica que a solicitação expirou. A configuração de tempo limite padrão é de 5 segundos. Você pode aumentar o tempo limite ou tentar acelerar o ponto de extremidade modificando o score.py para remover chamadas desnecessárias. Se essas ações não corrigirem o problema, você pode seguir aqui para depurar o arquivo score.py. O código pode estar em um estado sem resposta ou em um loop infinito.
500 Erro interno do servidor A infraestrutura provisionada do Azure Machine Learning está falhando.

Como impedir códigos de estado 503

As implantações online do Kubernetes dão suporte ao dimensionamento automático, que permite que réplicas sejam adicionadas para dar suporte a carga extra, mais informações que você pode encontrar no roteador de inferência do Azure Machine Learning. As decisões de aumentar/reduzir a escala baseiam-se na utilização das réplicas de contêiner atuais.

Há duas coisas que podem ajudar a evitar códigos de status 503:

Gorjeta

Estas duas abordagens podem ser utilizadas individualmente ou em combinação.

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

    Importante

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

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

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

    Para aumentar o número de instâncias, você pode calcular as réplicas necessárias seguindo esses 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)

    Nota

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

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 seguinte código:

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 CORS

Atualmente, os pontos de extremidade online (v2) não suportam o CORS (Cross-Origin Resource Sharing ) nativamente. Se o seu aplicativo Web tentar invocar o ponto de extremidade sem o tratamento adequado das solicitações de comprovação do CORS, você poderá 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 comprovação CORS.

Problemas comuns de isolamento de rede

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

O espaço de trabalho do Azure Machine Learning pode ser configurado para v1_legacy_mode, o que desativa as APIs v2. Os pontos de extremidade online gerenciados são um recurso da plataforma de API v2 e não funcionarão se v1_legacy_mode estiverem habilitados para o espaço de trabalho.

Importante

Consulte a sua equipa de segurança de rede antes de desativar o v1_legacy_mode. Ele pode ter sido habilitado pela sua equipe de segurança de rede por um motivo.

Para obter informações sobre como desativar v1_legacy_modeo , consulte Isolamento de rede com v2.

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

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

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

A resposta para este comando é semelhante ao seguinte documento JSON:

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

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

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

Nota

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

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

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

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

    No documento de resposta, verifique se o status campo está definido como Approved. Se não for aprovado, use o seguinte comando para aprová-lo. Substitua <private-endpoint-name> pelo nome retornado do comando anterior:

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

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

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

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

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

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

    Nota

    Para o ponto de extremidade online do Kubernetes, o nome do host do ponto de extremidade deve ser o CName (nome de domínio) que foi 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 Studio. Mais maneiras de obter o endereço IP do ponto de extremidade podem ser encontradas em Secure Kubernetes online endpoint.

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

    Para o endpoint online gerenciado,

    1. Verifique se existe um registo A na zona DNS privada da 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 do espaço de trabalho e recrie-o. Para obter mais informações, consulte Como configurar um ponto de extremidade privado.

    3. Se o espaço de trabalho com um ponto de extremidade privado estiver configurado usando um DNS personalizado Como usar seu espaço de trabalho com um servidor DNS personalizado, use o seguinte comando para verificar se a resolução funciona corretamente a partir do DNS personalizado.

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

    Para o ponto de extremidade online do Kubernetes,

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

    2. Além disso, você pode verificar se o 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 curl HTTPs falhar (por exemplo, tempo limite), mas HTTP funcionar, verifique se o certificado é válido.

    Se isso não resolver para um registro, 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

    Se isso for bem-sucedido, você poderá solucionar problemas do encaminhador condicional para link privado no DNS personalizado.

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

  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 seguinte comando para verificar se o tráfego está atribuído à implantação. Substitua <endpointname> pelo nome do seu ponto de extremidade:

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

    Gorjeta

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

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

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

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

    Examine os logs para ver se há um problema ao executar o código de pontuação quando você envia 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.

Passos básicos

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

  1. Reúna informações de versão para seu ambiente Python.
  2. Verifique 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 dos pacotes instalados.
  3. Se você especificar Flask (e ou suas dependências) em seu ambiente, remova-os. As dependências incluem Flask, Jinja2, itsdangerous, Werkzeug, MarkupSafee click. O Flask está listado como uma dependência no pacote do servidor e é melhor deixar o nosso servidor instalá-lo. Desta forma, quando o servidor suporta novas versões do Flask, você as obterá automaticamente.

Versão do servidor

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

  • 0.4.x: A versão incluída nas imagens de treinamento ≤ 20220601 e no 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 é possível importar o nome Markup do jinja2. Recomenda-se que atualize para 0.4.13 ou 0.8.x (a versão mais recente), se possível.
  • 0.6.x: A versão pré-instalada na inferência de imagens ≤ 20220516. A última versão estável é 0.6.1.
  • 0.7.x: A primeira versão que suporta o 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 caiu.

Dependências do pacote

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

  • frasco
  • opencensus-ext-azure
  • Esquema de inferência

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

Gorjeta

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

Perguntas mais 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 que azureml-inference-server-http não suporta o Flask 2. Suporte para Flask 2 é adicionado em azureml-inference-server-http>=0.7.0, que também está em azureml-defaults>=1.44.

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

  • Se estiver a utilizar este pacote com uma imagem docker do AzureML, certifique-se de que está a utilizar uma imagem incorporada ou posterior a julho de 2022. A versão da imagem está disponível nos logs do contêiner. Você deve ser capaz de 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 construção da imagem aparece após "Materialization Build", que no exemplo acima é 20220708, ou 8 de julho de 2022. Esta imagem é compatível com o Flask 2. Se você não vir um banner como este no log do contêiner, sua imagem está desatualizada e deve ser atualizada. Se você estiver usando uma imagem CUDA e não conseguir encontrar uma imagem mais recente, verifique se sua imagem foi preterida no AzureML-Containers. Se for, você deve ser capaz de encontrar substitutos.

  • Se estiver a utilizar o servidor com um ponto de extremidade online, também pode encontrar os registos em "Registos de implementação" na página do 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 que corresponda ao conjunto de ferramentas do openmpi4.1.0-ubuntu20.04 SDK local, que pode não ser a versão mais recente da imagem. Por exemplo, o openmpi4.1.0-ubuntu20.04:20220616SDK 1.43 usará como padrão 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, o que instalará o servidor da versão mais antiga com Flask 1.0.xo .

2. Encontrei um ImportError ou ModuleNotFoundError em 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 fixavam a dependência do Flask em versões compatíveis. Esse problema é corrigido na versão mais recente do servidor.

Próximos passos