Actualización a v2

Las API REST v2 de Azure Machine Learning, la extensión de la CLI de Azure y el SDK de Python introducen coherencia y un conjunto de nuevas características para acelerar el ciclo de vida de aprendizaje automático de producción. En este artículo se proporciona información general sobre la migración a v2, además de recomendaciones que le ayudarán a decidir entre v1, v2 o ambas.

Prerrequisitos

  • Estar familiarizado con los aspectos generales de Azure ML y el SDK de Python v1.
  • Comprender qué es v2.

Cuándo usar v2

Debe usar v2 si va a iniciar un nuevo proyecto o flujo de trabajo de aprendizaje automático. Debe usar v2 si quiere usar las nuevas características que se ofrecen en v2. Las características incluyen:

  • Inferencia administrada
  • Componentes reutilizables en canalizaciones
  • Programación mejorada de canalizaciones
  • Panel de inteligencia artificial responsable
  • Registro de recursos

En un nuevo proyecto v2 se pueden reutilizar recursos existentes, como áreas de trabajo y proceso, y modelos y entornos creados con v1.

Algunas de las carencias de la versión 2 incluyen:

  • Compatibilidad con Spark en trabajos: actualmente se encuentra en versión preliminar en v2.
  • Publicación de trabajos (canalizaciones en v1) como puntos de conexión. Sin embargo, puede programar canalizaciones sin publicarlos.
  • Compatibilidad con almacenes de datos de SQL y bases de datos.
  • Posibilidad de usar componentes precompilados clásicos en el diseñador con v2.

A continuación, debe asegurarse de que las características que necesita en v2 cumplen los requisitos de la organización, como estar disponibles con carácter general.

Importante

Las nuevas características de Azure ML solo se lanzarán en v2.

¿Debo actualizar el código existente a v2?

Puede reutilizar los recursos existentes en los flujos de trabajo v2. Por ejemplo, se puede usar un modelo creado en v1 para realizar la inferencia administrada en v2.

Opcionalmente, si quiere actualizar partes específicas del código existente a v2, consulte los vínculos de comparación proporcionados en los detalles de cada recurso en el resto de este documento.

¿Qué API v2 se debe usar?

En las interfaces v2 a través de la API REST, están disponibles la CLI y el SDK de Python. La interfaz que deba usar dependerá de sus preferencias y escenarios.

API Notas
REST Pocas dependencias y sobrecarga. Se usa para compilar aplicaciones en Azure ML como plataforma, directamente en lenguajes de programación sin proporcionar un SDK o por preferencia personal.
CLI Se recomienda para la automatización con CI/CD o por preferencia personal. Permite una iteración rápida con archivos YAML y una separación sencilla entre el código del modelo de Azure ML y ML.
SDK de Python Se recomienda para scripts complicados (por ejemplo, generar mediante programación trabajos de canalización grandes) o por preferencia personal. Permite una iteración rápida con archivos YAML o el desarrollo únicamente en Python.

¿Puedo usar juntas v1 y v2?

v1 y v2 pueden coexistir en un área de trabajo. Puede reutilizar los recursos existentes en los flujos de trabajo v2. Por ejemplo, se puede usar un modelo creado en v1 para realizar la inferencia administrada en v2. Los recursos como el área de trabajo, el proceso y el almacén de datos funcionan en v1 y v2, con algunas excepciones. Un usuario puede llamar al SDK de Python v1 para cambiar la descripción de un área de trabajo y, luego, usar la extensión de la CLI v2 para cambiarla de nuevo. Los trabajos (experimentos, ejecuciones o canalizaciones en v1) se pueden enviar al mismo área de trabajo desde el SDK de Python v1 o v2. Un área de trabajo puede tener puntos de conexión de implementación de modelos v1 y v2.

Uso de código v1 y v2 juntos

No se recomienda usar los SDK v1 y v2 juntos en el mismo código. Técnicamente es posible usar v1 y v2 en el mismo código porque usan espacios de nombres de Azure diferentes. Sin embargo, hay muchas clases con el mismo nombre en estos espacios de nombres (como Workspace, Model) que pueden causar confusión y dificultar la legibilidad y la capacidad de depuración del código.

Importante

Si el área de trabajo usa un punto de conexión privado, tendrá la marca v1_legacy_mode habilitada automáticamente, lo que impedirá el uso de API v2. Consulte cómo configurar el aislamiento de red con v2 para más información.

Recursos en v1 y v2

En esta sección se proporciona información general de recursos específicos de Azure ML. Consulte el artículo de conceptos de cada entidad para más información sobre su uso en v2.

Área de trabajo

Las áreas de trabajo no necesitan migrarse con v2. Puede usar la misma área de trabajo, independientemente de si usa v1 o v2.

Si crea áreas de trabajo mediante automatización, considere la posibilidad de migrar el código para crear un área de trabajo a v2. Normalmente, los recursos de Azure se administran a través de Azure Resource Manager (y Bicep) o herramientas de aprovisionamiento de recursos similares. Como alternativa, puede usar los archivos de la CLI (v2) y YAML.

Para ver una comparación del código del SDK v1 y v2, consulte Administración de áreas de trabajo en SDK v1 y v2.

Importante

Si el área de trabajo usa un punto de conexión privado, tendrá la marca v1_legacy_mode habilitada automáticamente, lo que impedirá el uso de API v2. Consulte cómo configurar el aislamiento de red con v2 para más información.

Conexión (conexión del área de trabajo en v1)

Las conexiones del área de trabajo desde v1 se conservan en el área de trabajo y están totalmente disponibles con v2.

Para ver una comparación del código del SDK v1 y v2, consulte Administración de áreas de trabajo en SDK v1 y v2.

Almacén de datos

Los tipos de almacén de datos de almacenamiento de objetos creados con v1 están totalmente disponibles para su uso en v2. No se admiten almacenes de datos de base de datos; la ruta de migración recomendada es exportarlos al almacenamiento de objetos (normalmente Azure Blob).

Para ver una comparación del código del SDK v1 y v2, consulte Administración de almacenes de datos en el SDK v1 y v2.

Proceso

El proceso de tipo AmlCompute y ComputeInstance está totalmente disponible para su uso en v2.

Para ver una comparación del código del SDK v1 y v2, consulte Administración de procesos en el SDK v1 y v2.

Punto de conexión e implementación (punto de conexión o servicio web en v1)

Con el SDK y la CLI v1, puede implementar modelos en ACI o AKS como servicios web. Las implementaciones de modelos v1 y los servicios web existentes seguirán funcionando como están, pero el uso del SDK o la CLI v1 para implementar modelos en ACI o AKS como servicios web ahora se considera heredado. Para las nuevas implementaciones de modelos, se recomienda migrar a v2. En v2, se ofrecen puntos de conexión administrados o puntos de conexión de Kubernetes. En la tabla siguiente se incluye nuestra recomendación:

Tipo de punto de conexión en v2 Migrar desde Notas
Local ACI Prueba rápida de la implementación del modelo localmente; no para producción.
Punto de conexión en línea administrado ACI, AKS Infraestructura de implementación de modelos administrados de nivel empresarial con respuestas casi en tiempo real y escalado masivo para producción.
Punto de conexión por lotes administrado ParallelRunStep en una canalización para la puntuación por lotes Infraestructura de implementación de modelos administrados de nivel empresarial con procesamiento paralelo masivo por lotes para producción.
Azure Kubernetes Service (AKS) ACI, AKS Administre sus propios clústeres de AKS para la implementación de modelos, lo que proporciona flexibilidad y control pormenorizado a costa de la sobrecarga de TI.
Azure Arc Kubernetes N/D Administre sus propios clústeres de Kubernetes en otras nubes o en el entorno local, proporcionando flexibilidad y control pormenorizado a costa de la sobrecarga de TI.

Para ver una comparación del código del SDK v1 y v2, consulte Actualización de puntos de conexión de implementación al SDK v2. Para conocer los pasos de actualización de los servicios web de ACI existentes a puntos de conexión en línea administrados, consulte nuestro artículo de la guía de actualización y el blog.

Trabajos (experimentos, ejecuciones, canalizaciones en v1)

En v2, los "experimentos", las "ejecuciones" y las "canalizaciones" se consolidan en trabajos. Un trabajo tiene un tipo. La mayoría de los trabajos son trabajos command que ejecutan un comando, como python main.py. Lo que se ejecuta en un trabajo es independiente de cualquier lenguaje de programación, por lo que puede ejecutar scripts bash, invocar intérpretes python, ejecutar un montón de comandos curl o cualquier otra cosa. Otro tipo común de trabajo es pipeline, que define trabajos secundarios que pueden tener relaciones de entrada y salida, lo que forma un gráfico acíclico dirigido (DAG).

Para ver una comparación del código del SDK v1 y v2, consulte:

Diseñador

Puede usar el diseñador para crear canalizaciones con sus propios componentes personalizados v2 y los nuevos componentes creados previamente desde el Registro. En esta situación, puede usar recursos de datos v1 o v2 en la canalización.

Puede seguir usando el diseñador para crear canalizaciones mediante componentes precompilados clásicos y tipos de conjunto de datos v1 (tabular, archivo). No puede usar componentes precompilados clásicos del diseñador existentes con el recurso de datos v2.

No puede crear una canalización mediante componentes precompilados clásicos del diseñador existentes y componentes personalizados v2.

Datos (conjuntos de datos en v1)

Los conjuntos de datos se llaman ahora recursos de datos. Se proporciona compatibilidad con versiones anteriores, lo que significa que puede usar conjuntos de datos V1 en V2. Al consumir un conjunto de datos V1 en un trabajo de V2, observará que se asignan automáticamente a los tipos V2 de la siguiente manera:

  • V1 FileDataset = V2 Folder (uri_folder)
  • V1 TabularDataset = V2 Table (mltable)

Debe tenerse en cuenta que no se proporciona compatibilidad con versiones posteriores, lo que significa que no se pueden usar recursos de datos V2 en V1.

En este artículo se habla más sobre el control de datos en v2: Lectura y escritura de datos en un trabajo.

Para ver una comparación del código del SDK v1 y v2, consulte Recursos de datos en el SDK v1 y v2.

Modelo

Los modelos creados a partir de v1 se pueden usar en v2.

Para ver una comparación del código del SDK v1 y v2, consulte Administración de modelos en el SDK v1 y v2.

Entorno

Los entornos creados a partir de v1 se pueden usar en v2. En v2, los entornos tienen nuevas características, como la creación desde un contexto de Docker local.

Administración de secretos

La administración de secretos de Key Vault difiere significativamente en V2 en comparación con V1. Los métodos set_secret y get_secret del SDK V1 no están disponibles en V2. En su lugar, se debe usar el acceso directo mediante bibliotecas cliente de Key Vault.

Para más información sobre Key Vault, consulte Uso de secretos de credenciales de autenticación en trabajos de entrenamiento de Azure Machine Learning.

Escenarios en todo el ciclo de vida de aprendizaje automático

Hay algunos escenarios que son comunes en el ciclo de vida de aprendizaje automático mediante Azure ML. Veremos algunos y proporcionaremos recomendaciones generales para migrar a v2.

Configuración de Azure

Azure recomienda plantillas de Azure Resource Manager (a menudo a través de Bicep para facilitar el uso) para crear recursos. El mismo enfoque es también bueno para crear recursos de Azure ML.

Si su equipo solo usa Azure ML, puede considerar la posibilidad de aprovisionar el área de trabajo y cualquier otro recurso a través de archivos YAML y la CLI.

Creación de prototipos de modelos

Se recomienda v2 para la creación de prototipos de modelos. Puede considerar la utilización de la CLI para un uso interactivo de Azure ML, mientras que el código de entrenamiento del modelo es Python o cualquier otro lenguaje de programación. Como alternativa, puede adoptar un enfoque de pila completa con Python únicamente mediante el SDK de Azure ML o un enfoque mixto con el SDK de Python de Azure ML y los archivos YAML.

Entrenamiento del modelo de producción

Se recomienda v2 para el entrenamiento del modelo de producción. Los trabajos consolidan la terminología y proporcionan un conjunto de coherencia que permite una transición más sencilla entre tipos (por ejemplo, de command a sweep) y un proceso descriptivo de GitOps para serializar trabajos en archivos YAML.

Con v2, debe separar el código de aprendizaje automático del código del plano de control. Esta separación permite una iteración y una transición más sencillas entre local y nube. También se recomienda usar MLflow para el seguimiento y el registro de modelos. Consulte el artículo sobre el concepto de MLflow para más información.

Implementación del modelo de producción

Se recomienda v2 para la implementación del modelo de producción. Los puntos de conexión administrados abstraen la sobrecarga de TI y proporcionan una solución eficaz para implementar y puntuar modelos, tanto para escenarios en línea (casi en tiempo real) como para escenarios por lotes (en paralelo masivos).

Las implementaciones de Kubernetes se admiten en v2 a través de AKS o Azure Arc, lo que permite las implementaciones locales y en la nube de Azure administradas por su organización.

Operaciones de Machine Learning (MLOps)

Normalmente, un flujo de trabajo de MLOps implica CI/CD mediante una herramienta externa. Normalmente, se usa una CLI en CI/CD, aunque también puede invocar Python o usar directamente REST.

El acelerador de soluciones para MLOps con v2 se está desarrollando en https://github.com/Azure/mlops-v2 y se puede usar como referencia o se puede adoptar para la configuración y la automatización del ciclo de vida de aprendizaje automático.

Nota sobre GitOps con v2

Un paradigma clave con v2 es serializar entidades de aprendizaje automático como archivos YAML para el control de código fuente con git, lo que permite un mejor enfoque de GitOps que el que era posible con v1. Por ejemplo, puede aplicar la directiva por la que solo una entidad de servicio usada en canalizaciones de CI/CD puede crear, actualizar o eliminar algunas o todas las entidades, lo que garantiza que los cambios pasen por un proceso regulado como las solicitudes de incorporación de cambios que necesitan revisores. Dado que los archivos del control de código fuente son YAML, son fáciles de diferenciar y resulta sencillo realizar un seguimiento de sus cambios a lo largo del tiempo. Usted y su equipo pueden considerar la posibilidad de cambiar a este paradigma cuando migre a v2.

Puede obtener una representación YAML de cualquier entidad con la CLI mediante az ml <entity> show --output yaml. Tenga en cuenta que esta salida tendrá propiedades generadas por el sistema, que se pueden omitir o eliminar.

Pasos siguientes