Pontos de extremidade e implantações on-line para inferência em tempo real

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

O Azure Machine Learning permite que você execute inferências em tempo real em dados usando modelos implantados em pontos de extremidade online. A inferência é o processo de aplicação de novos dados de entrada a um modelo de aprendizado de máquina para gerar saídas. Embora essas saídas sejam normalmente chamadas de "previsões", a inferência pode ser usada para gerar saídas para outras tarefas de aprendizado de máquina, como classificação e clustering.

Pontos finais online

Os pontos de extremidade online implantam modelos em um servidor Web que pode retornar previsões sob o protocolo HTTP. Use pontos de extremidade on-line para operacionalizar modelos para inferência em tempo real em solicitações síncronas de baixa latência. Recomendamos usá-los quando:

  • Você tem requisitos de baixa latência
  • O seu modelo pode responder ao pedido num período de tempo relativamente curto
  • As entradas do seu modelo cabem na carga HTTP da solicitação
  • Você precisa aumentar a escala em termos de número de solicitações

Para definir um ponto de extremidade, você precisa especificar:

  • Nome do ponto de extremidade: esse nome deve ser exclusivo na região do Azure. Para obter mais informações sobre as regras de nomenclatura, consulte Limites de pontos finais.
  • Modo de autenticação: você pode escolher entre o modo de autenticação baseada em chave, o modo de autenticação baseada em token do Azure Machine Learning ou a autenticação baseada em token do Microsoft Entra (visualização) para o ponto de extremidade. Para obter mais informações sobre autenticação, consulte Autenticar em um ponto de extremidade online.

O Azure Machine Learning oferece a conveniência de usar pontos de extremidade online gerenciados para implantar seus modelos de aprendizado de máquina de maneira turnkey. Esta é a maneira recomendada de usar pontos de extremidade online no Azure Machine Learning. Os pontos finais online geridos funcionam com computadores GPU e CPU avançados no Azure de forma dimensionável e totalmente gerida. Esses pontos de extremidade também cuidam de servir, dimensionar, proteger e monitorar seus modelos, para liberá-lo da sobrecarga de configurar e gerenciar a infraestrutura subjacente. Para saber como definir um ponto de extremidade online gerenciado, consulte Definir o ponto de extremidade.

Por que escolher endpoints online gerenciados em vez de ACI ou AKS(v1)?

O uso de pontos de extremidade online gerenciados é a maneira recomendada de usar pontos de extremidade online no Azure Machine Learning. A tabela a seguir destaca os principais atributos dos pontos de extremidade online gerenciados em comparação com as soluções do Azure Machine Learning SDK/CLI v1 (ACI e AKS(v1)).

Atributos Pontos de extremidade online gerenciados (v2) ACI ou AKS(v1)
Segurança/isolamento de rede Controlo fácil de entrada/saída com alternância rápida Rede virtual não suportada ou requer configuração manual complexa
Serviço gerido - Provisionamento/dimensionamento de computação totalmente gerenciado
- Configuração de rede para prevenção de exfiltração de dados
- Atualização do sistema operacional host, rollout controlado de atualizações in-loco
- O dimensionamento é limitado na v1
- A configuração ou atualização da rede precisa ser gerenciada pelo usuário
Conceito de endpoint/implantação A distinção entre ponto de extremidade e implantação permite cenários complexos, como a implantação segura de modelos Nenhum conceito de ponto final
Diagnóstico e monitorização - Depuração de ponto final local possível com Docker e Visual Studio Code
- Análise avançada de métricas e logs com gráfico/consulta para comparar entre implantações
- Repartição dos custos até ao nível de implementação
Sem depuração local fácil
Escalabilidade Dimensionamento ilimitado, elástico e automático - O ACI não é escalável
- AKS (v1) suporta apenas escala em cluster e requer configuração de escalabilidade
Preparação para empresas Link privado, chaves gerenciadas pelo cliente, ID do Microsoft Entra, gerenciamento de cotas, integração de faturamento, SLA Não suportado
Recursos avançados de ML - Modelo de recolha de dados
- Monitorização de modelos
- Modelo campeão-desafiante, lançamento seguro, espelhamento de tráfego
- Extensibilidade responsável da IA
Não suportado

Como alternativa, se você preferir usar o Kubernetes para implantar seus modelos e servir endpoints, e estiver confortável com o gerenciamento de requisitos de infraestrutura, poderá usar os endpoints online do Kubernetes. Esses endpoints permitem que você implante modelos e sirva endpoints online em seu cluster Kubernetes totalmente configurado e gerenciado em qualquer lugar, com CPUs ou GPUs.

Porquê escolher terminais online geridos em vez de AKS(v2)?

Os endpoints online gerenciados podem ajudar a simplificar seu processo de implantação e fornecer os seguintes benefícios em relação aos endpoints online do Kubernetes:

  • Infraestrutura gerenciada

    • Provisiona automaticamente a computação e hospeda o modelo (você só precisa especificar o tipo de VM e as configurações de escala)
    • Atualiza e corrige automaticamente a imagem subjacente do sistema operacional host
    • Executa automaticamente a recuperação do nó se houver uma falha do sistema
  • Monitorização e registos

    Captura de ecrã a mostrar o gráfico do Azure Monitor da latência do ponto de extremidade.

  • Ver custos

    Gráfico de custo de captura de tela de um ponto de extremidade e implantação.

    Nota

    Os pontos de extremidade online gerenciados são baseados na computação do Azure Machine Learning. Ao usar um endpoint online gerenciado, você paga pelas taxas de computação e rede. Não há sobretaxa. Para obter mais informações sobre preços, consulte a calculadora de preços do Azure.

    Se você usar uma rede virtual do Azure Machine Learning para proteger o tráfego de saída do ponto de extremidade online gerenciado, será cobrado pelo link privado do Azure e pelas regras de saída FQDN usadas pela rede virtual gerenciada. Para obter mais informações, consulte Preços para rede virtual gerenciada.

Pontos de extremidade online gerenciados vs pontos de extremidade online do kubernetes

A tabela a seguir destaca as principais diferenças entre endpoints online gerenciados e endpoints online do Kubernetes.

Pontos finais online geridos Pontos de extremidade online do Kubernetes (AKS(v2))
Utilizadores recomendados Utilizadores que desejam uma implementação do modelo gerido e uma experiência melhorada do MLOps Utilizadores que preferem o Kubernetes e podem autogerir requisitos de infraestrutura
Provisionamento de nó Provisionamento, atualização e remoção de computação gerenciada Responsabilidade do utilizador
Manutenção de nós Atualizações de imagem do sistema operacional host gerenciado e proteção de segurança Responsabilidade do utilizador
Dimensionamento de cluster (dimensionamento) Manual gerenciado e dimensionamento automático, suportando provisionamento de nós adicionais Dimensionamento manual e automático, suportando o dimensionamento do número de réplicas dentro de limites fixos de cluster
Tipo de computação Gerido pelo serviço Cluster Kubernetes gerenciado pelo cliente (Kubernetes)
Identidade gerida Suportado Suportado
Rede Virtual (VNET) Suportado através de isolamento de rede gerido Responsabilidade do utilizador
Monitoramento imediato e registro em log Azure Monitor e Log Analytics powered (inclui métricas-chave e tabelas de log para pontos de extremidade e implantações) Responsabilidade do utilizador
Registro em log com o Application Insights (legado) Suportado Suportado
Ver custos Detalhado para o ponto de extremidade / nível de implantação Nível do cluster
Custo aplicado a VMs atribuídas às implantações VMs atribuídas ao cluster
Tráfego espelhado Suportado Não suportado
Implantação sem código Suportado (modelos MLflow e Triton ) Suportado (modelos MLflow e Triton )

Implantações on-line

Uma implantação é um conjunto de recursos e cálculos necessários para hospedar o modelo que faz a inferência real. Um único ponto de extremidade pode conter várias implantações com configurações diferentes. Essa configuração ajuda a dissociar a interface apresentada pelo ponto de extremidade dos detalhes de implementação presentes na implantação. Um ponto de extremidade online tem um mecanismo de roteamento que pode direcionar solicitações para implantações específicas no ponto de extremidade.

O diagrama a seguir mostra um ponto de extremidade online que tem duas implantações, azul e verde. A implantação azul usa VMs com uma SKU de CPU e executa a versão 1 de um modelo. A implantação verde usa VMs com uma GPU SKU e executa a versão 2 do modelo. O ponto de extremidade é configurado para rotear 90% do tráfego de entrada para a implantação azul, enquanto a implantação verde recebe os 10% restantes.

Diagrama mostrando um ponto de extremidade dividindo o tráfego para duas implantações.

Para implantar um modelo, você deve ter:

  • Arquivos de modelo (ou o nome e a versão de um modelo que já está registrado em seu espaço de trabalho).
  • Um script de pontuação, ou seja, código que executa o modelo em uma determinada solicitação de entrada. O script de pontuação recebe dados enviados a um serviço Web implantado e os passa para o modelo. Em seguida, o script executa o modelo e retorna sua resposta ao cliente. O script de pontuação é específico para o seu modelo e deve entender os dados que o modelo espera como entrada e retorna como saída.
  • Um ambiente no qual seu modelo é executado. O ambiente pode ser uma imagem do Docker com dependências do Conda ou um Dockerfile.
  • Configurações para especificar o tipo de instância e a capacidade de dimensionamento.

Principais atributos de uma implantação

A tabela a seguir descreve os principais atributos de uma implantação:

Atributo Description
Name O nome da implantação.
Nome do ponto final O nome do ponto de extremidade sob o qual criar a implantação.
Modelo1 O modelo a ser usado para a implantação. Esse valor pode ser uma referência a um modelo versionado existente no espaço de trabalho ou uma especificação de modelo embutido. Para obter mais informações sobre como controlar e especificar o caminho para o modelo, consulte Identificar o caminho do modelo em relação ao AZUREML_MODEL_DIR.
Caminho do código O caminho para o diretório no ambiente de desenvolvimento local que contém todo o código-fonte Python para pontuar o modelo. Você pode usar diretórios e pacotes aninhados.
Roteiro de pontuação O caminho relativo para o arquivo de pontuação no diretório do código-fonte. Este código Python deve ter uma init() função e uma run() função. A init() função será chamada depois que o modelo for criado ou atualizado (você pode usá-la para armazenar o modelo em cache na memória, por exemplo). A run() função é chamada a cada invocação do ponto final para fazer a pontuação e previsão reais.
Ambiente1 O ambiente para hospedar o modelo e o código. Esse valor pode ser uma referência a um ambiente versionado existente no espaço de trabalho ou uma especificação de ambiente embutido. Nota: A Microsoft corrige regularmente as imagens base para vulnerabilidades de segurança conhecidas. Você precisará reimplantar seu ponto de extremidade para usar a imagem corrigida. Se fornecer a sua própria imagem, é responsável por atualizá-la. Para obter mais informações, consulte Correção de imagem.
Tipo de instância O tamanho da VM a ser usado para a implantação. Para obter a lista de tamanhos suportados, consulte Lista de SKU de pontos de extremidade online gerenciados.
Contagem de instâncias O número de instâncias a serem usadas para a implantação. Baseie o valor na carga de trabalho esperada. Para alta disponibilidade, recomendamos que você defina o valor como pelo menos 3. Reservamos um extra de 20% para a realização de upgrades. Para obter mais informações, consulte Alocação de cota de máquina virtual para implantações.

1 Algumas coisas a observar sobre o modelo e o ambiente:

  • O modelo e a imagem do contêiner (conforme definido em Ambiente) podem ser referenciados novamente a qualquer momento pela implantação quando as instâncias por trás da implantação passam por patches de segurança e/ou outras operações de recuperação. Se você usar um modelo registrado ou uma imagem de contêiner no Registro de Contêiner do Azure para implantação e remover o modelo ou a imagem de contêiner, as implantações que dependem desses ativos poderão falhar quando ocorrer uma nova geração de imagens. Se você remover o modelo ou a imagem de contêiner, certifique-se de que as implantações dependentes sejam recriadas ou atualizadas com um modelo alternativo ou uma imagem de contêiner.
  • O registro de contêiner ao qual o ambiente se refere pode ser privado somente se a identidade do ponto de extremidade tiver a permissão para acessá-lo por meio da autenticação do Microsoft Entra e do RBAC do Azure. Pelo mesmo motivo, não há suporte para registros privados do Docker diferentes do Registro de Contêiner do Azure.

Para saber como implantar pontos de extremidade online usando o modelo CLI, SDK, estúdio e ARM, consulte Implantar um modelo de ML com um ponto de extremidade online.

Identificar o caminho do modelo em relação a AZUREML_MODEL_DIR

Ao implantar seu modelo no Azure Machine Learning, você precisa especificar o local do modelo que deseja implantar como parte de sua configuração de implantação. No Azure Machine Learning, o caminho para o seu modelo é rastreado com a AZUREML_MODEL_DIR variável de ambiente. Ao identificar o caminho do modelo em relação ao AZUREML_MODEL_DIR, você pode implantar um ou mais modelos armazenados localmente em sua máquina ou implantar um modelo registrado em seu espaço de trabalho do Azure Machine Learning.

Para ilustração, fazemos referência à seguinte estrutura de pastas locais para os dois primeiros casos em que você implanta um único modelo ou implanta vários modelos armazenados localmente:

Uma captura de tela mostrando uma estrutura de pastas contendo vários modelos.

Usar um único modelo local em uma implantação

Para usar um único modelo que você tem em sua máquina local em uma implantação, especifique o path para o model em sua implantação YAML. Aqui está um exemplo do YAML de implantação com o caminho /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

Depois de criar sua implantação, a variável AZUREML_MODEL_DIR de ambiente apontará para o local de armazenamento no Azure onde seu modelo está armazenado. Por exemplo, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 conterá o modelo sample_m1.pkl.

Dentro do seu script de pontuação (score.py), você pode carregar seu modelo (neste exemplo, sample_m1.pkl) na init() função:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl") 
    model = joblib.load(model_path) 

Usar vários modelos locais em uma implantação

Embora a CLI do Azure, o SDK do Python e outras ferramentas de cliente permitam especificar apenas um modelo por implantação na definição de implantação, você ainda pode usar vários modelos em uma implantação registrando uma pasta de modelo que contém todos os modelos como arquivos ou subdiretórios.

No exemplo anterior de estrutura de pastas, você percebe que há vários modelos na models pasta. Em sua implantação YAML, você pode especificar o caminho para a models pasta da seguinte maneira:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/ 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

Depois de criar sua implantação, a variável AZUREML_MODEL_DIR de ambiente apontará para o local de armazenamento no Azure onde seus modelos estão armazenados. Por exemplo, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 conterá os modelos e a estrutura do arquivo.

Neste exemplo, o AZUREML_MODEL_DIR conteúdo da pasta terá esta aparência:

Uma captura de tela da estrutura de pastas do local de armazenamento para vários modelos.

Dentro do init() seu script de pontuação (score.py), você pode carregar seus modelos na função. O código a seguir carrega o sample_m1.pkl modelo:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "models","model_1","v1", "sample_m1.pkl ") 
    model = joblib.load(model_path) 

Para obter um exemplo de como implantar vários modelos em uma implantação, consulte Implantar vários modelos em uma implantação (exemplo de CLI) e Implantar vários modelos em uma implantação (exemplo de SDK).

Gorjeta

Se você tiver mais de 1500 arquivos para registrar, considere compactar os arquivos ou subdiretórios como .tar.gz ao registrar os modelos. Para consumir os modelos, você pode descompactar os arquivos ou subdiretórios na função a init() partir do script de pontuação. Como alternativa, ao registrar os modelos, defina a azureml.unpack propriedade como True, para descompactar automaticamente os arquivos ou subdiretórios. Em ambos os casos, a descompactação acontece uma vez no estágio de inicialização.

Usar modelos registrados em seu espaço de trabalho do Azure Machine Learning em uma implantação

Para usar um ou mais modelos, que estão registrados em seu espaço de trabalho do Azure Machine Learning, em sua implantação, especifique o nome do(s) modelo(s) registrado(s) em sua implantação YAML. Por exemplo, a seguinte configuração de implantação do YAML especifica o nome registrado model como azureml:local-multimodel:3:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: azureml:local-multimodel:3 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1 

Para este exemplo, considere que local-multimodel:3 contém os seguintes artefatos de modelo, que podem ser exibidos na guia Modelos no estúdio do Azure Machine Learning:

Uma captura de tela da estrutura de pastas mostrando os artefatos de modelo do modelo registrado.

Depois de criar sua implantação, a variável AZUREML_MODEL_DIR de ambiente apontará para o local de armazenamento no Azure onde seus modelos estão armazenados. Por exemplo, /var/azureml-app/azureml-models/local-multimodel/3 conterá os modelos e a estrutura do arquivo. AZUREML_MODEL_DIR apontará para a pasta que contém a raiz dos artefatos do modelo. Com base neste exemplo, o AZUREML_MODEL_DIR conteúdo da pasta terá esta aparência:

Uma captura de tela da estrutura de pastas mostrando vários modelos.

Dentro do init() seu script de pontuação (score.py), você pode carregar seus modelos na função. Por exemplo, carregue o diabetes.sav modelo:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR"), "models", "diabetes", "1", "diabetes.sav") 
    model = joblib.load(model_path) 

Alocação de cota de máquina virtual para implantação

Para pontos de extremidade online gerenciados, o Aprendizado de Máquina do Azure reserva 20% de seus recursos de computação para executar atualizações em algumas SKUs de VM. Se você solicitar um determinado número de instâncias para essas SKUs de VM em uma implantação, deverá ter uma cota disponível para ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU evitar obter um erro. Por exemplo, se você solicitar 10 instâncias de uma VM Standard_DS3_v2 (que vem com quatro núcleos) em uma implantação, deverá ter uma cota para 48 núcleos (12 instances * 4 cores) disponível. Essa cota extra é reservada para operações iniciadas pelo sistema, como atualizações do sistema operacional e recuperação de VM, e não incorrerá em custo, a menos que essas operações sejam executadas.

Existem certas VM SKUs que estão isentas de reserva de cota extra. Para exibir a lista completa, consulte Lista de SKU de pontos de extremidade online gerenciados.

Para ver o seu uso e solicitar aumentos de cota, consulte Exibir seu uso e cotas no portal do Azure. Para ver o custo de execução de um endpoint online gerenciado, consulte Exibir custos de um endpoint online gerenciado.

O Azure Machine Learning fornece um pool de cotas compartilhadas a partir do qual todos os usuários podem acessar a cota para executar testes por um tempo limitado. Quando você usa o estúdio para implantar modelos Llama (do catálogo de modelos) em um ponto de extremidade online gerenciado, o Aprendizado de Máquina do Azure permite que você acesse essa cota compartilhada por um curto período de tempo.

Para implantar um modelo de bate-papo Llama-2-70b ou Llama-2-70b, no entanto, você deve ter uma assinatura do Enterprise Agreement antes de implantar usando a cota compartilhada. Para obter mais informações sobre como usar a cota compartilhada para implantação de ponto de extremidade online, consulte Como implantar modelos básicos usando o estúdio.

Para obter mais informações sobre cotas e limites para recursos no Azure Machine Learning, consulte Gerenciar e aumentar cotas e limites para recursos com o Azure Machine Learning.

Implantação para codificadores e não codificadores

O Azure Machine Learning dá suporte à implantação de modelo em pontos de extremidade online para codificadores e não codificadores, fornecendo opções para implantação sem código, implantação de baixo código e implantação Bring Your Own Container (BYOC).

  • A implantação sem código fornece inferência pronta para uso para estruturas comuns (por exemplo, scikit-learn, TensorFlow, PyTorch e ONNX) via MLflow e Triton.
  • A implantação low-code permite que você forneça código mínimo junto com seu modelo de aprendizado de máquina para implantação.
  • A implantação do BYOC permite que você traga virtualmente todos os contêineres para executar seu endpoint online. Você pode usar todos os recursos da plataforma Azure Machine Learning, como dimensionamento automático, GitOps, depuração e distribuição segura para gerenciar seus pipelines de MLOps.

A tabela a seguir destaca os principais aspetos sobre as opções de implantação online:

Sem código Low-code BYOC
Resumo Usa inferência pronta para uso para estruturas populares como scikit-learn, TensorFlow, PyTorch e ONNX, via MLflow e Triton. Para obter mais informações, consulte Implantar modelos MLflow em pontos de extremidade online. Usa imagens seguras e publicadas publicamente para estruturas populares, com atualizações a cada duas semanas para resolver vulnerabilidades. Você fornece script de pontuação e/ou dependências do Python. Para obter mais informações, consulte Ambientes curados do Azure Machine Learning. Você fornece sua pilha completa por meio do suporte do Azure Machine Learning para imagens personalizadas. Para obter mais informações, consulte Usar um contêiner personalizado para implantar um modelo em um ponto de extremidade online.
Imagem de base personalizada Não, o ambiente com curadoria fornecerá isso para facilitar a implantação. Sim e Não, você pode usar a imagem selecionada ou sua imagem personalizada. Sim, traga um local de imagem de contêiner acessível (por exemplo, docker.io, Azure Container Registry (ACR) ou Microsoft Container Registry (MCR)) ou um Dockerfile que você possa criar/enviar por push com ACR para seu contêiner.
Dependências personalizadas Não, o ambiente com curadoria fornecerá isso para facilitar a implantação. Sim, traga o ambiente do Azure Machine Learning no qual o modelo é executado; uma imagem do Docker com dependências do Conda ou um dockerfile. Sim, isso será incluído na imagem do contêiner.
Código personalizado Não, o script de pontuação será gerado automaticamente para facilitar a implantação. Sim, traga o seu roteiro de pontuação. Sim, isso será incluído na imagem do contêiner.

Nota

As execuções do AutoML criam um script de pontuação e dependências automaticamente para os usuários, para que você possa implantar qualquer modelo de AutoML sem criar código adicional (para implantação sem código) ou modificar scripts gerados automaticamente de acordo com suas necessidades de negócios (para implantação de baixo código). Para saber como implantar com modelos AutoML, consulte Implantar um modelo AutoML com um ponto de extremidade online.

Depuração de ponto de extremidade on-line

É altamente recomendável que você teste e execute seu ponto de extremidade localmente para validar e depurar seu código e configuração antes de implantar no Azure. A CLI do Azure e o SDK do Python dão suporte a pontos de extremidade e implantações locais, enquanto o estúdio do Azure Machine Learning e o modelo ARM não.

O Azure Machine Learning fornece várias maneiras de depurar pontos de extremidade online localmente e usando logs de contêiner.

Depuração local com o servidor HTTP de inferência do Azure Machine Learning

Você pode depurar seu script de pontuação localmente usando o servidor HTTP de inferência do Aprendizado de Máquina do Azure. O servidor HTTP é um pacote Python que expõe sua função de pontuação como um ponto de extremidade HTTP e encapsula o código e as dependências do servidor Flask em um pacote singular. Ele está incluído nas imagens pré-criadas do Docker para inferência que são usadas ao implantar um modelo com o Azure Machine Learning. Usando apenas o pacote, você pode implantar o modelo localmente para produção e também pode validar facilmente seu script de pontuação (entrada) em um ambiente de desenvolvimento local. Se houver um problema com o script de pontuação, o servidor retornará um erro e o local onde o erro ocorreu. Você também pode usar o Visual Studio Code para depurar com o servidor HTTP de inferência do Azure Machine Learning.

Gorjeta

Você pode usar o pacote Python do servidor HTTP de inferência do Azure Machine Learning para depurar seu script de pontuação localmente sem o Docker Engine. 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.

Para saber mais sobre depuração com o servidor HTTP, consulte Script de pontuação de depuração com o servidor HTTP de inferência do Azure Machine Learning.

Depuração local com ponto de extremidade local

Para depuração local, você precisa de uma implantação local, ou seja, um modelo implantado em um ambiente Docker local. Você pode usar essa implantação local para testar e depurar antes da implantação na nuvem. Para implantar localmente, você precisará ter o Docker Engine instalado e em execução. Em seguida, o Azure Machine Learning cria uma imagem local do Docker que imita a imagem do Azure Machine Learning. O Azure Machine Learning criará e executará implantações para você localmente e armazenará em cache a imagem para iterações rápidas.

Gorjeta

O mecanismo do Docker normalmente é iniciado quando o computador é iniciado. Se isso não acontecer, você poderá solucionar problemas do Docker Engine. Você pode usar ferramentas do lado do cliente, como o Docker Desktop , para depurar o que acontece no contêiner.

As etapas para depuração local normalmente incluem:

  • Verificando se a implantação local foi bem-sucedida
  • Invocando o ponto de extremidade local para inferência
  • Examinando os logs para a saída da operação invoke

Nota

Os pontos de extremidade locais têm as seguintes limitações:

  • Eles não suportam regras de tráfego, autenticação ou configurações de teste.
  • Eles suportam apenas uma implantação por ponto de extremidade.
  • Eles suportam arquivos de modelo local e ambiente apenas com arquivo conda local. Se você quiser testar modelos registrados, primeiro baixe-os usando CLI ou SDK e, em seguida, use path na definição de implantação para fazer referência à pasta pai. Se você quiser testar ambientes registrados, verifique o contexto do ambiente no estúdio do Azure Machine Learning e prepare um arquivo conda local para usar.

Para saber mais sobre depuração local, consulte Implantar e depurar localmente usando um ponto de extremidade local.

Depuração local com ponto de extremidade local e Visual Studio Code (visualização)

Importante

Esta funcionalidade está atualmente em pré-visualização pública. Esta versão de pré-visualização é fornecida sem um contrato de nível de serviço e não a recomendamos para cargas de trabalho de produção. Algumas funcionalidades poderão não ser suportadas ou poderão ter capacidades limitadas.

Para obter mais informações, veja Termos Suplementares de Utilização para Pré-visualizações do Microsoft Azure.

Assim como na depuração local, primeiro você precisa ter o mecanismo do Docker instalado e em execução e, em seguida, implantar um modelo no ambiente local do Docker. Depois de ter uma implantação local, os pontos de extremidade locais do Aprendizado de Máquina do Azure usam contêineres de desenvolvimento do Docker e do Visual Studio Code (contêineres de desenvolvimento) para criar e configurar um ambiente de depuração local. Com contêineres de desenvolvimento, você pode aproveitar os recursos do Visual Studio Code, como depuração interativa, de dentro de um contêiner do Docker.

Para saber mais sobre como depurar pontos de extremidade online interativamente no VS Code, consulte Depurar pontos de extremidade online localmente no Visual Studio Code.

Depuração com logs de contêiner

Para uma implantação, você não pode obter acesso direto à VM onde o modelo é implantado. No entanto, pode obter registos de alguns dos contentores que estão em execução na VM. 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 saber mais sobre depuração com logs de contêiner, consulte Obter logs de contêiner.

Roteamento e espelhamento de tráfego para implantações online

Lembre-se de que um único ponto de extremidade online pode ter várias implantações. À medida que o ponto de extremidade recebe tráfego de entrada (ou solicitações), ele pode rotear porcentagens de tráfego para cada implantação, conforme usado na estratégia de implantação nativa azul/verde. Ele também pode espelhar (ou copiar) o tráfego de uma implantação para outra, também chamado de espelhamento de tráfego ou sombreamento.

Roteamento de tráfego para implantação azul/verde

A implantação azul/verde é uma estratégia de implantação que permite implantar uma nova implantação (a implantação verde) para um pequeno subconjunto de usuários ou solicitações antes de implementá-la completamente. O ponto de extremidade pode implementar o balanceamento de carga para alocar determinadas porcentagens do tráfego para cada implantação, com a alocação total em todas as implantações somando até 100%.

Gorjeta

Uma solicitação pode ignorar o balanceamento de carga de tráfego configurado incluindo um cabeçalho HTTP de azureml-model-deployment. Defina o valor do cabeçalho como o nome da implantação para a qual você deseja que a solicitação seja roteada.

A imagem a seguir mostra as configurações no estúdio do Azure Machine Learning para alocar tráfego entre uma implantação azul e verde.

Captura de tela mostrando a interface deslizante para definir a alocação de tráfego entre implantações.

Essa alocação de tráfego roteia o tráfego conforme mostrado na imagem a seguir, com 10% do tráfego indo para a implantação verde e 90% do tráfego indo para a implantação azul.

Diagrama mostrando um ponto de extremidade dividindo o tráfego para duas implantações.

Espelhamento de tráfego para implantações online

O ponto de extremidade também pode espelhar (ou copiar) o tráfego de uma implantação para outra. O espelhamento de tráfego (também chamado de teste de sombra) é útil quando você deseja testar uma nova implantação com tráfego de produção sem afetar os resultados que os clientes estão recebendo de implantações existentes. Por exemplo, ao implementar uma implantação azul/verde em que 100% do tráfego é roteado para azul e 10% é espelhado para a implantação verde, os resultados do tráfego espelhado para a implantação verde não são retornados aos clientes, mas as métricas e os logs são registrados.

Diagrama mostrando um tráfego de espelhamento de ponto de extremidade para uma implantação.

Para saber como usar o espelhamento de tráfego, consulte Distribuição segura para pontos de extremidade online.

Mais recursos de pontos de extremidade online no Azure Machine Learning

Autenticação e encriptação

  • Autenticação: Chave e Tokens do Azure Machine Learning
  • Identidade gerenciada: atribuído pelo usuário e atribuído pelo sistema
  • SSL por padrão para invocação de ponto de extremidade

Dimensionamento automático

O dimensionamento automático executa a quantidade certa de recursos para processar a carga da aplicação. Os pontos de extremidade gerenciados oferecem suporte ao dimensionamento automático por meio da integração com o recurso de dimensionamento automático do monitor do Azure. Você pode configurar o dimensionamento baseado em métricas (por exemplo, utilização >da CPU 70%), o dimensionamento baseado em programação (por exemplo, regras de dimensionamento para horários comerciais de pico) ou uma combinação.

Captura de tela mostrando que o dimensionamento automático de forma flexível fornece entre instâncias min e max, dependendo das regras.

Para saber como configurar o dimensionamento automático, consulte Como dimensionar automaticamente os pontos de extremidade online.

Isolamento de rede gerenciado

Ao implantar um modelo de aprendizado de máquina em um ponto de extremidade online gerenciado, você pode proteger a comunicação com o ponto de extremidade online usando pontos de extremidade privados.

Você pode configurar a segurança para solicitações de pontuação de entrada e comunicações de saída com o espaço de trabalho e outros serviços separadamente. As comunicações de entrada usam o ponto de extremidade privado do espaço de trabalho do Azure Machine Learning. As comunicações de saída usam pontos de extremidade privados criados para a rede virtual gerenciada do espaço de trabalho.

Para obter mais informações, consulte Isolamento de rede com pontos de extremidade online gerenciados.

Monitoramento de endpoints e implantações on-line

O monitoramento de pontos de extremidade do Azure Machine Learning é possível por meio da integração com o Azure Monitor. Essa integração permite visualizar métricas em gráficos, configurar alertas, consultar tabelas de log, usar o Application Insights para analisar eventos de contêineres de usuário e assim por diante.

  • Métricas: use o Azure Monitor para acompanhar várias métricas de ponto de extremidade, como latência de solicitação, e faça drill down para implantação ou nível de status. Você também pode acompanhar métricas no nível da implantação, como a utilização da CPU/GPU e detalhar até o nível da instância. O Azure Monitor permite que você acompanhe essas métricas em gráficos e configure painéis e alertas para análise posterior.

  • Logs: envie métricas para o espaço de trabalho do Log Analytics onde você pode consultar logs usando a sintaxe de consulta Kusto. Você também pode enviar métricas para Conta de Armazenamento e/ou Hubs de Eventos para processamento posterior. Além disso, você pode usar tabelas de log dedicadas para eventos relacionados a pontos finais online, tráfego e logs de contêiner. A consulta Kusto permite uma análise complexa unindo várias tabelas.

  • Informações sobre aplicativos: os ambientes com curadoria incluem a integração com o Application Insights, e você pode habilitá-la/desativá-la ao criar uma implantação online. Métricas e logs internos são enviados para o Application insights, e você pode usar seus recursos internos, como métricas em tempo real, pesquisa de transações, falhas e desempenho para análise adicional.

Para obter mais informações sobre monitoramento, consulte Monitorar pontos de extremidade online.

Injeção secreta em implantações online (visualização)

A injeção secreta no contexto de uma implantação online é um processo de recuperar segredos (como chaves de API) de armazenamentos secretos e injetá-los em seu contêiner de usuário que é executado dentro de uma implantação online. Os segredos serão eventualmente acessíveis por meio de variáveis de ambiente, fornecendo assim uma maneira segura de serem consumidos pelo servidor de inferência que executa seu script de pontuação ou pela pilha de inferência que você traz com uma abordagem de implantação BYOC (bring your own container).

Existem duas maneiras de injetar segredos. Você mesmo pode injetar segredos, usando identidades gerenciadas, ou pode usar o recurso de injeção secreta. Para saber mais sobre as formas de injetar segredos, consulte Injeção secreta em pontos finais online (pré-visualização).

Próximos passos