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.
Requisitos previos
- Estar familiarizado con los aspectos generales de Azure Machine Learning 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 c1 existentes, como áreas de trabajo y proceso, y modelos y entornos creados con v1.
Algunas de las carencias de la v2 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 Machine Learning solo se lanzarán en v2.
¿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 Machine Learning 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 Machine Learning 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. |
Asignar SDK de Python v1 a v2
Consulte cada uno de los siguientes artículos para obtener una comparación de la asignación de código para SDK v1 frente a v2.
| Recursos y activos | Artículo |
|---|---|
| Área de trabajo | Administración del área de trabajo en SDK v1 y SDK v2 |
| Almacén de datos | Administración del almacén de datos en SDK v1 y SDK v2 |
| Data | Recursos de datos en SDK v1 y v2 |
| Proceso | Administración de procesos en SDK v1 y SDK v2 |
| Cursos | Ejecutar un script |
| Cursos | Ejecuciones locales |
| Cursos | Ajuste de hiperparámetros |
| Cursos | Ejecución en paralelo |
| Cursos | Canalizaciones |
| Cursos | AutoML |
| Modelos | Administración de modelos en SDK v1 y SDK v2 |
| Implementación | Actualización de los puntos de conexión de implementación al SDK v2 |
Recursos en v1 y v2
En esta sección se proporciona información general de recursos específicos de Azure Machine Learning. 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 actualizarse 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 actualizar 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.
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.
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.
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:
- Ejecutar un script
- Ejecuciones locales
- Ajuste de hiperparámetros
- Ejecución en paralelo
- Canalizaciones
- AutoML
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.
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.
Punto de conexión e implementación (punto de conexión y 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 actualizar 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 | Actualización de | 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 migració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.
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. Al acceder a secretos desde un script de entrenamiento, puede usar la identidad administrada del proceso o la identidad.
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 Machine Learning. Veremos algunos y proporcionaremos recomendaciones generales para actualizar 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 Machine Learning.
Si su equipo solo usa Azure Machine Learning, 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 Machine Learning, 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 Machine Learning o un enfoque mixto con el SDK de Python de Azure Machine Learning 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 actualice 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.
¿Debo actualizar el código v1 existente a v2?
Puede reutilizar los recursos v1 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 desea actualizar partes específicas del código v1 existente a v2, consulte los vínculos de comparación proporcionados en este documento.
¿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.