Upgrade para a v2

As APIs REST v2 do Azure Machine Learning, a extensão da CLI do Azure e o SDK do Python são consistentes e têm um conjunto de novos recursos que aceleram o ciclo de vida do aprendizado de máquina para produção. Este artigo fornece uma visão geral da atualização para a v2 com recomendações que ajudam você a decidir entre a v1, a v2 ou ambas.

Pré-requisitos

• Familiaridade geral com o Azure Machine Learning e o SDK v1 do Python.
• Entender o que é a v2?

Devo usar a v2?

Use a v2 para começar um fluxo de trabalho ou projeto de aprendizado de máquina. Use a v2 para aproveitar os novos recursos oferecidos nela. Os recursos incluem:

• Inferência gerenciada
• Componentes reutilizáveis em pipelines
• Melhor agendamento de pipelines
• Painel de IA responsável
• Registro de ativos

Um novo projeto da v2 pode reutilizar recursos existentes da v1, como workspaces e computação, e ativos existentes, como modelos e ambientes criados com a v1.

Algumas deficiências de recursos na v2 incluem:

• Suporte ao Spark em trabalhos ─ atualmente em versão prévia na v2.
• Publicação de trabalhos (pipelines na v1) como pontos de extremidade. No entanto, é possível agendar pipelines sem publicar.
• Suporte para armazenamentos de dados SQL/de banco de dados.
• Capacidade de usar componentes pré-construídos clássicos no designer com a v2.

Em seguida, você deve garantir que os recursos necessários na v2 atendam aos requisitos da sua organização, como disponibilidade geral.

Qual API da v2 devo usar?

Em interfaces da v2 por meio da API REST, a CLI e o SDK do Python estão disponíveis. A interface que você deve usar depende do cenário e das suas preferências.

Mapeamento do SDK do Python v1 para v2

Consulte cada um dos artigos a seguir para obter um mapeamento de códigos de comparação para SDK v1 versus v2.

Recursos e ativos na v1 e na v2

Esta seção fornece uma visão geral de recursos e ativos específicos do Azure Machine Learning. Confira o artigo de conceito de cada entidade para ver detalhes sobre o uso dela na v2.

Workspace

Os espaços de trabalho não precisam ser migrados com a v2. Você pode usar o mesmo workspace, independentemente de estar usando a v1 ou a v2.

Para criar espaços de trabalho usando automação, considere fazer upgrade do código para criar um espaço de trabalho na v2. Normalmente, os recursos do Azure são gerenciados por meio do Azure Resource Manager (e do Bicep) ou de ferramentas de provisionamento de recursos semelhantes. Como alternativa, você pode usar a CLI (v2) e os arquivos YAML.

Para uma comparação do código do SDK da v1 e da v2, confira Gerenciamento de workspace no SDK da v1 e no SDK da v2.

Conexão (conexão de workspace na v1)

As conexões de workspace da v1 são mantidas no workspace e ficam totalmente disponíveis na v2.

Para uma comparação do código do SDK da v1 e da v2, confira Gerenciamento de workspace no SDK da v1 e no SDK da v2.

Repositório de dados

Os tipos de armazenamento de dados de armazenamento de objetos criados com a v1 estão totalmente disponíveis para uso na v2. Não há suporte para armazenamentos de dados de banco de dados. A exportação para o armazenamento de objetos (geralmente, Blob do Azure) é o caminho de migração recomendado.

Para uma comparação do código do SDK da v1 e da v2, confira Gerenciamento do armazenamento de dados no SDK da v1 e no SDK da v2.

Dados (conjuntos de dados na v1)

Os conjuntos de dados foram renomeados para ativos de dados. A compatibilidade com versões anteriores é fornecida, o que significa que é possível usar conjuntos de dados da V1 na V2. Ao consumir um conjunto de dados da V1 em um trabalho da V2, você observará que eles são mapeados automaticamente para tipos da V2 da seguinte maneira:

• FileDataset da V1 = pasta da V2 (uri_folder)
• TabularDataset da V1 = Tabela da V2 (mltable)

A compatibilidade com versões anterioresnão é fornecida, o que significa que não é possível usar os ativos de dados da V2 na V1.

Este artigo fala mais sobre como lidar com dados na v2 – Ler e gravar dados em um trabalho

Para uma comparação do código do SDK da v1 e da v2, confira Ativos de dados no SDK da v1 e da v2.

Computação

A computação do tipo AmlCompute e ComputeInstance está totalmente disponível para uso na v2.

Para uma comparação do código do SDK da v1 e da v2, confira Gerenciamento de computação no SDK da v1 e no SDK da v2.

Trabalhos (experimentos, execuções e pipelines na v1)

Na v2, "experimentos", "execuções" e "pipelines" são consolidados em trabalhos. Um trabalho tem um tipo. A maioria dos trabalhos são trabalhos command que executam um comando, como python main.py. O que é executado em um trabalho é independente de qualquer linguagem de programação, ou seja, você possa executar scripts bash, invocar interpretadores python, executar vários comandos curl ou qualquer outra coisa. Outro tipo comum de trabalho é pipeline, que define os trabalhos filho que podem ter relações de entrada/saída, formando um DAG (grafo direcionado acíclico).

Para uma comparação do código do SDK da v1 e da v2, confira

• Executar um script
• Execuções locais
• Ajuste de hiperparâmetros
• Execução paralela
• Pipelines
• AutoML

Designer

É possível usar o designer para criar pipelines usando seus próprios componentes personalizados da v2 e os novos componentes predefinidos do registro. Nesse caso, é possível usar ativos de dados da v1 ou da v2 no pipeline.

O designer pode continuar sendo usado para a criação de pipelines por meio componentes predefinidos clássicos e tipos de conjunto de dados da v1 (tabular, arquivo). Não é possível usar componentes predefinidos clássicos existentes do designer com o ativo de dados da v2.

Também não é possível criar um pipeline usando tanto os componentes predefinidos clássicos existentes do designer quanto os componentes personalizados da v2.

Modelar

Os modelos criados com base na v1 podem ser usados na v2.

Para uma comparação do código do SDK da v1 e da v2, confira Gerenciamento de modelo no SDK da v1 e no SDK da v2

Ponto de extremidade e implantação (ponto de extremidade ou serviço Web na v1)

Com o SDK ou a CLI da v1, é possível implantar modelos no ACI ou no AKS como serviços Web. Suas implantações de modelos v1 e serviços Web existentes continuarão funcionando como estão, mas o uso do SDK/CLI v1 para implantar modelos na ACI ou no AKS como serviços Web agora é considerado como herdado. Para novas implantações de modelo, recomendamos fazer upgrade para a v2. Na v2, são oferecidos pontos de extremidade gerenciados ou pontos de extremidade do Kubernetes. A seguinte tabela apresenta nossas recomendações:

Para uma comparação do código do SDK da v1 e da v2, confira Atualizar pontos de extremidade de implantação para o SDK da v2. Para obter as etapas de atualização dos serviços Web do ACI existentes para pontos de extremidade online gerenciados, consulte o artigo do guia de atualização e o blog.

Ambiente

Os ambientes criados com base na v1 podem ser usados na v2. Na v2, os ambientes têm novos recursos, como a criação de um contexto local do Docker.

Gerenciamento de segredos

O gerenciamento de segredos do Key Vault difere significativamente na V2 em comparação com a V1. Os métodos de SDK da V1 set_secret e get_secret não estão disponíveis na V2. Como alternativa, deve-se usar o acesso direto por meio das bibliotecas de clientes do Key Vault. Ao acessar segredos de um script de treinamento, você pode usar a identidade gerenciada da computação ou sua identidade.

Para saber mais sobre o Key Vault, confira Usar segredos de credencial de autenticação em trabalhos de treinamento do Azure Machine Learning.

Cenários no ciclo de vida de machine learning

Há alguns cenários comuns no ciclo de vida de machine learning com o Azure Machine Learning. Daremos uma olhada em alguns deles e forneceremos recomendações gerais de migração para a v2.

Configuração do Azure

O Azure recomenda os modelos do Azure Resource Manager (geralmente por meio do Bicep, a fim de facilitar o uso) para criar recursos. O mesmo é uma boa abordagem para criar recursos do Azure Machine Learning também.

Se a sua equipe só estiver usando o Azure Machine Learning, você poderá considerar a possibilidade provisionar o workspace e os outros recursos por meio de arquivos YAML e da CLI.

Como criar protótipos de modelos

Recomendamos a v2 para a criação de protótipos de modelos. Você pode considerar o uso da CLI para um uso interativo do Azure Machine Learning, enquanto o código de treinamento do modelo é o Python ou qualquer outra linguagem de programação. Como alternativa, você poderá adotar uma abordagem de pilha completa com o Python usando apenas o SDK do Azure Machine Learning ou uma abordagem mista com os arquivos YAML e o SDK do Python para o Azure Machine Learning.

Treinamento do modelo de produção

Recomendamos a v2 para o treinamento do modelo de produção. Os trabalhos consolidam a terminologia e fornecem um conjunto de consistência que permite uma transição mais fácil entre tipos (por exemplo, command para sweep) e um processo amigável do GitOps para serializar trabalhos em arquivos YAML.

Com a v2, você deve separar o código do machine learning do código do painel de controle. Essa separação permite uma iteração e uma transição mais fáceis entre o local e a nuvem. Também é recomendado usar o MLflow para acompanhamento e registro em log de modelos. Confira o artigo de conceito do MLflow para ver detalhes.

Implantação do modelo de produção

Recomendamos a v2 para a implantação do modelo de produção. Os pontos de extremidade gerenciados eliminam a sobrecarga de TI e fornecem uma solução de desempenho para implantar e pontuar modelos, tanto para cenários online (quase em tempo real) quanto em lotes (amplamente paralelos).

As implantações do Kubernetes são compatíveis com a v2 por meio do AKS ou do Azure Arc, habilitando implantações locais e da nuvem do Azure gerenciadas por sua organização.

MLOps (operações de machine learning)

Um fluxo de trabalho de MLOps normalmente envolve a CI/CD por meio de uma ferramenta externa. Normalmente, uma CLI é usada em CI/CD, embora você possa invocar o Python ou usar a REST diretamente.

O acelerador de solução para MLOps com a v2 está sendo desenvolvido em https://github.com/Azure/mlops-v2 e pode ser usado como referência ou adotado para instalação e automação do ciclo de vida de machine learning.

Uma observação sobre o GitOps com a v2

Um paradigma fundamental na v2 é serializar entidades de machine learning como arquivos YAML para controle do código-fonte com git, permitindo melhores abordagens de GitOps do que eram possíveis com a v1. Por exemplo, você pode impor uma política pela qual apenas uma entidade de serviço usada em pipelines de CI/CD pode criar/atualizar/excluir algumas ou todas as entidades, garantindo que as alterações passem por um processo controlado, como solicitações de pull com os revisores obrigatórios. Como os arquivos do controle do código-fonte estão em YAML, é fácil compará-los e controlar as alterações deles ao longo do tempo. Você e sua equipe podem considerar a possibilidade de mudar para esse paradigma ao fazer upgrade para a v2.

Você pode obter uma representação YAML de qualquer entidade com a CLI por meio de az ml <entity> show --output yaml. Observe que essa saída terá propriedades geradas pelo sistema, que podem ser ignoradas ou excluídas.

Devo atualizar o código existente da v1 para a v2?

É possível reutilizar os ativos existentes da v1 nos fluxos de trabalho da v2. Por exemplo, um modelo criado na v1 pode ser usado para realizar a inferência gerenciada na v2.

Opcionalmente, se você quiser atualizar partes específicas do código da v1 existente para a v2, consulte os links de comparação fornecidos neste documento.

Posso usar a v1 e a v2 juntas?

A v1 e a v2 podem coexistir em um workspace. É possível reutilizar os ativos existentes nos fluxos de trabalho da v2. Por exemplo, um modelo criado na v1 pode ser usado para realizar a inferência gerenciada na v2. Recursos como workspace, computação e armazenamento de dados funcionam entre a v1 e a v2, com algumas exceções. Um usuário pode chamar o SDK v1 do Python para alterar a descrição de um workspace e usar a extensão da CLI v2 para alterá-la novamente. Os trabalhos (experimentos/execuções/pipelines na v1) podem ser enviados para o mesmo workspace do SDK v1 ou v2 do Python. Um workspace pode ter pontos de extremidade de implantação de modelo da v1 e da v2.

Usar os códigos da v1 e da v2 juntos

Não é recomendado usar os SDKs da v1 e da v2 no mesmo código. É tecnicamente possível usar a v1 e a v2 no mesmo código porque elas usam namespaces diferentes do Azure. No entanto, há muitas classes com o mesmo nome nesses namespaces (como Workspace, Modelo) que podem causar confusão e dificultar a legibilidade e a depuração do código.

Próximas etapas

• Introdução à CLI (v2)
• Introdução ao SDK do Python (v2)