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.
Importante
Os novos recursos do Azure Machine Learning só serão iniciados na v2.
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.
| API | Observações |
|---|---|
| REST | Menos dependências e sobrecarga. Use-os para criar aplicativos no Azure Machine Learning como uma plataforma, diretamente em linguagens de programação sem um SDK fornecido ou de acordo com sua preferência pessoal. |
| CLI | Recomendada para automação com CI/CD ou de acordo com a preferência pessoal. Permite a iteração rápida com arquivos YAML e a separação direta entre o código do modelo do ML e o Azure Machine Learning. |
| SDK do Python | Recomendado para scripts complicados (por exemplo, gerar trabalhos de pipeline grandes por meio de programação) ou de acordo com a preferência pessoal. Permite iteração rápida com arquivos YAML ou desenvolvimento somente no Python. |
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 | Artigo |
|---|---|
| Workspace | Gerenciamento de workspace no SDK v1 e SDK v2 |
| Datastore | Gerenciamento de armazenamento de dados no SDK v1 e SDK v2 |
| Dados | Ativos de dados no SDK v1 e v2 |
| Computação | Gerenciamento de computação no SDK v1 e SDK v2 |
| Treinamento | Executar um script |
| Treinamento | Execuções locais |
| Treinamento | Ajuste de hiperparâmetros |
| Treinamento | Execução paralela |
| Treinamento | Pipelines |
| Treinamento | AutoML |
| Modelos | Gerenciamento de modelos no SDK v1 e SDK v2 |
| Implantação | Atualizar pontos de extremidade de implantação para o SDK 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.
Importante
Se o workspace usar um ponto de extremidade privado, ele terá automaticamente o sinalizador v1_legacy_mode habilitado, impedindo o uso de APIs da v2. Confira como configurar o isolamento de rede com a v2 para ver detalhes.
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
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:
| Tipo de ponto de extremidade na v2 | Atualizar a partir do | Observações |
|---|---|---|
| Local | ACI | Teste rápido da implantação de modelo localmente; não para produção. |
| Ponto de extremidade online gerenciado | ACI, AKS | Infraestrutura de implantação de modelo gerenciado de nível empresarial com respostas quase em tempo real e dimensionamento em massa para produção. |
| Ponto de extremidade em lote gerenciado | ParallelRunStep em um pipeline para pontuação em lote | Infraestrutura de implantação de modelo gerenciado de nível empresarial com processamento em lotes amplamente paralelos para produção. |
| AKS (Serviço de Kubernetes do Azure) | ACI, AKS | Gerencie seus clusters do AKS para implantação de modelo, proporcionando flexibilidade e controle granular em detrimento da sobrecarga de TI. |
| Kubernetes do Azure Arc | N/D | Gerencie os seus próprios clusters de Kubernetes em outras nuvens ou localmente, proporcionando flexibilidade e controle granular em detrimento da sobrecarga de TI. |
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.
Importante
Se o workspace usar um ponto de extremidade privado, ele terá automaticamente o sinalizador v1_legacy_mode habilitado, impedindo o uso de APIs da v2. Confira como configurar o isolamento de rede com a v2 para ver detalhes.