Atualizar para v2
As APIs REST v2 do Azure Machine Learning, a extensão da CLI do Azure e o Python SDK introduzem consistência e um conjunto de novos recursos para acelerar o ciclo de vida do aprendizado de máquina de produção. Este artigo fornece uma visão geral da atualização para v2 com recomendações para ajudá-lo a decidir sobre v1, v2 ou ambos.
Pré-requisitos
- Familiaridade geral com o Azure Machine Learning e o SDK Python v1.
- Entendeu o que é v2?
Devo usar a v2?
Você deve usar a v2 se estiver iniciando um novo projeto ou fluxo de trabalho de aprendizado de máquina. Você deve usar a v2 se quiser usar os novos recursos oferecidos na v2. As funcionalidades incluem:
- Inferência gerenciada
- Componentes reutilizáveis em condutas
- Melhor agendamento de dutos
- Painel de IA responsável
- Registo de bens
Um novo projeto v2 pode reutilizar recursos v1 existentes, como espaços de trabalho e computação, e ativos existentes, como modelos e ambientes criados usando v1.
Algumas lacunas de recursos na v2 incluem:
- Suporte a faíscas em trabalhos - isso está atualmente em visualização na v2.
- Publicação de trabalhos (pipelines na v1) como pontos de extremidade. No entanto, você pode agendar pipelines sem publicar.
- Suporte para armazenamento de dados SQL/banco de dados.
- Capacidade de usar componentes pré-construídos clássicos no designer com v2.
Em seguida, você deve garantir que os recursos necessários na v2 atendam aos requisitos da sua organização, como estar disponível em geral.
Importante
Os novos recursos do Azure Machine Learning só serão iniciados na v2.
Qual API v2 devo usar?
Em interfaces v2 via REST API, CLI e Python SDK estão disponíveis. A interface que você deve usar depende do seu cenário e preferências.
| API | Notas |
|---|---|
| REST | Menor número de dependências e despesas gerais. Use para criar aplicativos no Azure Machine Learning como uma plataforma, diretamente em linguagens de programação sem um SDK fornecido ou por preferência pessoal. |
| CLI | Recomendado para automação com CI/CD ou por preferência pessoal. Permite iteração rápida com arquivos YAML e separação direta entre o Azure Machine Learning e o código de modelo de ML. |
| Python SDK | Recomendado para scripts complicados (por exemplo, geração programática de grandes trabalhos de pipeline) ou por preferência pessoal. Permite iteração rápida com arquivos YAML ou desenvolvimento somente em Python. |
Mapeamento do Python SDK v1 para v2
Consulte cada um dos seguintes artigos para obter um mapeamento de código de comparação para SDK v1 vs v2.
| Recursos e ativos | Artigo |
|---|---|
| Área de trabalho | Gerenciamento de espaço de trabalho no SDK v1 e SDK v2 |
| Arquivo de dados | 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 |
| Formação | Executar um script |
| Formação | Corridas locais |
| Formação | Ajuste de hiperparâmetros |
| Formação | Execução paralela |
| Formação | Pipelines |
| Formação | AutoML |
| Modelos | Gerenciamento de modelos no SDK v1 e SDK v2 |
| Implementação | Atualizar pontos de extremidade de implantação para SDK v2 |
Recursos e ativos em v1 e v2
Esta seção fornece uma visão geral de recursos e ativos específicos no Azure Machine Learning. Consulte o artigo de conceito para cada entidade para obter detalhes sobre seu uso na v2.
Área de trabalho
Os espaços de trabalho não precisam ser atualizados com a v2. Você pode usar o mesmo espaço de trabalho, independentemente de estar usando v1 ou v2.
Se você criar espaços de trabalho usando automação, considere atualizar o código para criar um espaço de trabalho para v2. Normalmente, os recursos do Azure são geridos através do Azure Resource Manager (e Bicep) ou de ferramentas de aprovisionamento de recursos semelhantes. Como alternativa, você pode usar os arquivos CLI (v2) e YAML.
Para obter uma comparação do código do SDK v1 e v2, consulte Gerenciamento de espaço de trabalho no SDK v1 e SDK v2.
Importante
Se o seu espaço de trabalho usar um ponto de extremidade privado, ele terá automaticamente o sinalizador ativado, impedindo o v1_legacy_mode uso de APIs v2. Veja como configurar o isolamento de rede com v2 para obter detalhes.
Conexão (conexão de espaço de trabalho na v1)
As conexões do espaço de trabalho da v1 são mantidas no espaço de trabalho e totalmente disponíveis com a v2.
Para obter uma comparação do código do SDK v1 e v2, consulte Gerenciamento de espaço de trabalho no SDK v1 e SDK v2.
Arquivo de dados
Os tipos de armazenamento de dados de armazenamento de objetos criados com v1 estão totalmente disponíveis para uso na v2. Não há suporte para armazenamentos de dados de banco de dados; exportar para o armazenamento de objetos (geralmente o Blob do Azure) é o caminho de migração recomendado.
Para obter uma comparação do código do SDK v1 e v2, consulte Gerenciamento de armazenamento de dados no SDK v1 e SDK v2.
Dados (conjuntos de dados em v1)
Os conjuntos de dados são renomeados para ativos de dados. A compatibilidade com versões anteriores é fornecida, o que significa que você pode usar conjuntos de dados V1 em V2. Quando você consome um conjunto de dados V1 em um trabalho V2, você notará que eles são automaticamente mapeados em tipos V2 da seguinte maneira:
- V1 FileDataset = Pasta V2 (
uri_folder) - V1 TabularDataset = Tabela V2 (
mltable)
Deve-se notar que a compatibilidade de encaminhamentos não é fornecida, o que significa que você não pode usar ativos de dados V2 em V1.
Este artigo fala mais sobre como lidar com dados na v2 - Ler e gravar dados em um trabalho
Para obter uma comparação do código do SDK v1 e v2, consulte Ativos de dados no SDK v1 e v2.
Computação
Computação do tipo AmlCompute e ComputeInstance estão totalmente disponíveis para uso na v2.
Para obter uma comparação do código do SDK v1 e v2, consulte Gerenciamento de computação no SDK v1 e SDK v2.
Trabalhos (experimentos, execuções, pipelines na v1)
Na v2, "experimentações", "execuções" e "pipelines" são consolidados como trabalhos. Um trabalho tem um tipo. A maioria dos trabalhos são command trabalhos que executam um comando, como python main.py. O que é executado em um trabalho é agnóstico a qualquer linguagem de programação, então você pode executar bash scripts, invocar python intérpretes, executar um monte de curl comandos ou qualquer outra coisa. Outro tipo comum de trabalho é pipelineo , que define trabalhos filhos que podem ter relações de entrada/saída, formando um gráfico acíclico direcionado (DAG).
Para obter uma comparação do código SDK v1 e v2, consulte
Estruturador
Você pode usar o designer para criar pipelines usando seus próprios componentes personalizados v2 e os novos componentes pré-construídos do registro. Nessa situação, você pode usar ativos de dados v1 ou v2 em seu pipeline.
Você pode continuar a usar o designer para criar pipelines usando componentes pré-construídos clássicos e tipos de conjunto de dados v1 (tabular, arquivo). Não é possível usar componentes pré-construídos clássicos do designer existentes com o ativo de dados v2.
Não é possível criar um pipeline usando componentes pré-construídos clássicos do designer existentes e componentes personalizados v2.
Modelo
Os modelos criados a partir da v1 podem ser usados na v2.
Para obter uma comparação do código do SDK v1 e v2, consulte Gerenciamento de modelos no SDK v1 e SDK v2
Ponto de extremidade e implantação (ponto de extremidade e serviço Web na v1)
Com o SDK/CLI v1, você pode implantar modelos em ACI ou AKS como serviços Web. Suas implantações de modelo v1 e serviços Web existentes continuarão a funcionar como estão, mas usar SDK/CLI v1 para implantar modelos em ACI ou AKS como serviços Web agora é considerado como legado. Para implantações de novos modelos, recomendamos a atualização para v2. Na v2, oferecemos endpoints gerenciados ou pontos de extremidade Kubernetes. A tabela seguinte orienta a nossa recomendação:
| Tipo de ponto final na v2 | Atualize a partir de | Notas |
|---|---|---|
| Local | ACI | Teste rápido de implantação do 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 maciço 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 lote paralelo maciço para produção. |
| Azure Kubernetes Service (AKS) | ACI, AKS | Gerencie seus próprios clusters AKS para implantação de modelos, oferecendo flexibilidade e controle granular ao custo das despesas gerais de TI. |
| Kubernetes para o Azure Arc | N/A | Gerencie seus próprios clusters Kubernetes em outras nuvens ou no local, oferecendo flexibilidade e controle granular ao custo da sobrecarga de TI. |
Para obter uma comparação do código do SDK v1 e v2, consulte Atualizar pontos de extremidade de implantação para o SDK v2. Para conhecer as etapas de migração de seus serviços Web ACI existentes para endpoints online gerenciados, consulte nosso artigo e blog do guia de atualização.
Environment
Os ambientes criados a partir da v1 podem ser usados na v2. Na v2, os ambientes têm novos recursos, como a criação a partir de um contexto Docker local.
Gestão de segredos
O gerenciamento de segredos do Key Vault difere significativamente na V2 em comparação com a V1. Os métodos V1 set_secret e get_secret SDK não estão disponíveis na V2. Em vez disso, o acesso direto usando bibliotecas de cliente do Key Vault deve ser usado. Ao acessar segredos de um script de treinamento, você pode usar a identidade gerenciada da computação ou sua identidade.
Para obter detalhes sobre o Cofre da Chave, consulte Usar segredos de credenciais de autenticação em trabalhos de treinamento do Azure Machine Learning.
Cenários em todo o ciclo de vida do aprendizado de máquina
Há alguns cenários que são comuns em todo o ciclo de vida do aprendizado de máquina usando o Azure Machine Learning. Veremos alguns e daremos recomendações gerais para atualizar para a v2.
Configuração do Azure
O Azure recomenda modelos do Azure Resource Manager (geralmente via Bicep para facilitar o uso) para criar recursos. O mesmo também é uma boa abordagem para criar recursos do Azure Machine Learning.
Se sua equipe estiver usando apenas o Azure Machine Learning, você pode considerar provisionar o espaço de trabalho e quaisquer outros recursos por meio de arquivos YAML e CLI.
Modelos de prototipagem
Recomendamos v2 para modelos de prototipagem. Você pode considerar usar a CLI para um uso interativo do Azure Machine Learning, enquanto seu código de treinamento de modelo é Python ou qualquer outra linguagem de programação. Como alternativa, você pode adotar uma abordagem de pilha completa com Python usando apenas o SDK do Azure Machine Learning ou uma abordagem mista com o SDK Python do Azure Machine Learning e os arquivos YAML.
Treinamento de modelo de produção
Recomendamos v2 para treinamento de 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 ao GitOps para serializar trabalhos em arquivos YAML.
Com a v2, você deve separar seu código de aprendizado de máquina do código do plano de controle. Essa separação permite uma iteração mais fácil e permite uma transição mais fácil entre local e nuvem. Também recomendamos o uso do MLflow para rastreamento e registro de modelos. Consulte o artigo do conceito MLflow para obter detalhes.
Implantação do modelo de produção
Recomendamos a v2 para implantação do modelo de produção. Os endpoints gerenciados abstraem a sobrecarga de TI e fornecem uma solução de desempenho para implantação e pontuação de modelos, tanto para cenários on-line (quase em tempo real) quanto em lote (massivamente paralelos).
As implantações do Kubernetes são suportadas na v2 por meio do AKS ou do Azure Arc, permitindo implantações na nuvem e no local do Azure gerenciadas pela sua organização.
Operações de machine learning (MLOps)
Um fluxo de trabalho MLOps normalmente envolve CI/CD por meio de uma ferramenta externa. Normalmente, uma CLI é usada em CI/CD, embora você possa invocar alternativamente Python ou usar diretamente REST.
O acelerador de solução para MLOps com v2 está sendo desenvolvido e https://github.com/Azure/mlops-v2 pode ser usado como referência ou adotado para configuração e automação do ciclo de vida do aprendizado de máquina.
Uma nota sobre GitOps com v2
Um paradigma chave com v2 é serializar entidades de aprendizado de máquina como arquivos YAML para controle do código-fonte com git, permitindo melhores abordagens GitOps do que eram possíveis com 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 pull com revisores necessários. Como os arquivos no controle do código-fonte são YAML, eles são fáceis de diferenciar e controlar as alterações ao longo do tempo. Você e sua equipe podem considerar mudar para esse paradigma à medida que atualizam para a v2.
Você pode obter uma representação YAML de qualquer entidade com a CLI via 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 v1 existente para v2
Você pode reutilizar seus ativos v1 existentes em seus fluxos de trabalho v2. Por exemplo, um modelo criado na v1 pode ser usado para executar a Inferência Gerenciada na v2.
Opcionalmente, se você quiser atualizar partes específicas do seu código v1 existente para v2, consulte os links de comparação fornecidos neste documento.
Posso usar v1 e v2 juntos?
v1 e v2 podem coexistir em um espaço de trabalho. Você pode reutilizar seus ativos existentes em seus fluxos de trabalho v2. Por exemplo, um modelo criado na v1 pode ser usado para executar a Inferência Gerenciada na v2. Recursos como espaço de trabalho, computação e armazenamento de dados funcionam nas v1 e v2, com exceções. Um usuário pode chamar o SDK do Python v1 para alterar a descrição de um espaço de trabalho e, em seguida, usar a extensão da CLI v2, alterá-lo novamente. Os trabalhos (experimentos/execuções/pipelines na v1) podem ser enviados para o mesmo espaço de trabalho a partir do SDK Python v1 ou v2. Um espaço de trabalho pode ter pontos de extremidade de implantação de modelo v1 e v2.
Usando o código v1 e v2 juntos
Não recomendamos o uso dos SDKs v1 e v2 juntos no mesmo código. É tecnicamente possível usar v1 e v2 no mesmo código porque eles usam namespaces do Azure diferentes. No entanto, há muitas classes com o mesmo nome nesses namespaces (como Workspace, Model) que podem causar confusão e tornar a legibilidade e a depuração do código desafiadoras.
Importante
Se o seu espaço de trabalho usar um ponto de extremidade privado, ele terá automaticamente o sinalizador ativado, impedindo o v1_legacy_mode uso de APIs v2. Veja como configurar o isolamento de rede com v2 para obter detalhes.