(AWS) son las dos plataformas de computación en la nube más grandes del mundo y proporcionan bases de datos, redes y recursos informáticos a escala global. Juntos, poseen alrededor del 50% del mercado global de servicios de infraestructura de nube empresarial: AWS con el 30% y Azure con el 20%. Azure ML y AWS SageMaker son servicios de aprendizaje automático que permiten a los científicos de datos y a los ingenieros de ML desarrollar y administrar todo el ciclo de vida de ML, desde el preprocesamiento de datos y la ingeniería de funciones hasta el entrenamiento, la implementación y el monitoreo de modelos. Puede crear y administrar estos servicios de aprendizaje automático en AWS y Azure a través de interfaces de consola, CLI en la nube o kits de desarrollo de software (SDK) en su lenguaje de programación preferido: el enfoque que se analiza en este artículo.
Trabajos de capacitación de Azure ML y AWS SageMaker
Si bien ofrecen funcionalidades similares de alto nivel, Azure ML y AWS SageMaker tienen diferencias fundamentales que determinan qué plataforma se adapta mejor a usted, su equipo o su empresa. En primer lugar, considere el ecosistema de almacenamiento de datos, recursos informáticos y servicios de monitoreo existentes. Por ejemplo, si los datos de su empresa se encuentran principalmente en un depósito AWS S3, entonces SageMaker puede convertirse en una opción más natural para desarrollar sus servicios de aprendizaje automático, ya que reduce la sobrecarga de conectarse y transferir datos entre diferentes proveedores de nube. Sin embargo, esto no significa que no valga la pena considerar otros factores, y profundizaremos en los detalles de cómo Azure ML se diferencia de AWS SageMaker en un escenario de ML común: entrenamiento y creación de modelos a escala utilizando trabajos.
Aunque los cuadernos Jupyter son valiosos para la experimentación y exploración en un flujo de trabajo de desarrollo interactivo en un solo dispositivo, no están diseñados para producción o distribución. Los trabajos de capacitación (y otros trabajos de ML) se vuelven esenciales en el flujo de trabajo de ML en esta etapa al implementar la tarea en múltiples instancias de la nube para que se ejecute durante más tiempo y procese más datos. Esto requiere configurar los datos, el código, las instancias informáticas y los entornos de ejecución para garantizar resultados consistentes cuando ya no se ejecutan en una máquina local. Piense en ello como la diferencia entre desarrollar una receta para la cena (cuaderno Jupyter) y contratar un equipo de catering para cocinarla para 500 clientes (trabajo de ML). Necesita que todos los miembros del equipo de catering tengan acceso a los mismos ingredientes, recetas y herramientas, siguiendo el mismo procedimiento de cocción.
Ahora que entendemos la importancia de los trabajos de capacitación, veamos en pocas palabras cómo se definen en Azure ML frente a SageMaker.
Definir el trabajo de capacitación de Azure ML
desde azure.ai.ml comando de importación trabajo = comando (código=… comando=… entorno=… computar=…) ml_client.jobs.create_or_update(trabajo)
Crear un estimador de trabajos de capacitación de SageMaker
de sagemaker.estimator importar Estimador estimador = Estimador (image_uri=… rol=… tipo_instancia=…) estimador.fit(training_data_s3_location)
Dividiremos la comparación en las siguientes dimensiones:
Gestión de proyectos y permisos Almacenamiento de datos Entorno informático
En la parte 1, comenzaremos comparando la configuración del proyecto de alto nivel y la gestión de permisos, luego hablaremos sobre el almacenamiento y el acceso a los datos necesarios para el entrenamiento del modelo. La parte 2 analizará varias opciones informáticas en ambas plataformas en la nube y cómo crear y administrar entornos de ejecución para trabajos de capacitación.
Gestión de proyectos y permisos
Comencemos por comprender un flujo de trabajo de ML típico en un equipo mediano a grande de científicos de datos, ingenieros de datos e ingenieros de ML. Cada miembro puede especializarse en un rol y responsabilidad específicos, y estar asignado a uno o más proyectos. Por ejemplo, un ingeniero de datos tiene la tarea de extraer datos de la fuente y almacenarlos en una ubicación centralizada para que los procesen los científicos de datos. No necesitan activar instancias informáticas para ejecutar trabajos de capacitación. En este caso, es posible que tengan acceso de lectura y escritura a la ubicación de almacenamiento de datos, pero no necesariamente necesitan acceso para crear instancias de GPU para cargas de trabajo pesadas. Dependiendo de la sensibilidad de los datos y su función en un proyecto de aprendizaje automático, los miembros del equipo necesitan diferentes niveles de acceso a los datos y a la infraestructura de la nube subyacente. Exploraremos cómo dos plataformas en la nube estructuran sus recursos y servicios para equilibrar los requisitos de colaboración en equipo y separación de responsabilidades.
Aprendizaje automático de Azure
La administración de proyectos en Azure ML se centra en el espacio de trabajo y comienza con la creación de un espacio de trabajo (bajo su ID de suscripción de Azure y grupo de recursos) para almacenar recursos y activos relevantes, y compartirlos entre todo el equipo del proyecto para la colaboración.
Los permisos para acceder y administrar recursos se otorgan a nivel de usuario según sus roles, es decir, control de acceso basado en roles (RBAC). Los roles genéricos en Azure incluyen propietario, colaborador y lector. Los roles especializados en ML incluyen AzureML Data Scientist y AzureML Compute Operador, que es responsable de crear y administrar instancias informáticas, ya que generalmente son el elemento de mayor costo en un proyecto de ML. El objetivo de configurar un espacio de trabajo de Azure ML es crear entornos contenidos para almacenar datos, computación, modelos y otros recursos, de modo que solo los usuarios dentro del espacio de trabajo tengan acceso relevante para leer o editar los activos de datos, usar instancias de computación existentes o crear nuevas según sus responsabilidades.
En el fragmento de código siguiente, nos conectamos al espacio de trabajo de Azure ML a través de MLClient pasando el ID de suscripción del espacio de trabajo, el grupo de recursos y la credencial predeterminada. Azure sigue la estructura jerárquica Suscripción > Grupo de recursos > Espacio de trabajo.
Tras la creación del espacio de trabajo, también se crean instancias automáticamente de servicios asociados como una cuenta de Azure Storage (almacena metadatos y artefactos y puede almacenar datos de entrenamiento) y Azure Key Vault (almacena secretos como nombres de usuarios, contraseñas y credenciales).
de azure.ai.ml importar MLClient de azure.identity importar DefaultAzureCredential suscripción_id = '' recurso_grupo = '' espacio de trabajo = '' # Conectarse a la credencial del espacio de trabajo = DefaultAzureCredential() ml_client = MLClient(credencial, suscripción, grupo_recursos, espacio de trabajo)
Cuando los desarrolladores ejecutan el código durante una sesión de desarrollo interactiva, la conexión del espacio de trabajo se autentica mediante las credenciales personales del desarrollador. Podrían crear un trabajo de capacitación usando el comando ml_client.jobs.create_or_update(job) como se muestra a continuación. Para desconectar las credenciales de cuentas personales en el entorno de producción, se recomienda utilizar una cuenta principal de servicio para autenticarse en canalizaciones automatizadas o trabajos programados. Puede encontrar más información en este artículo "Autenticar en su espacio de trabajo utilizando una entidad de servicio".
# Definir el trabajo de entrenamiento de Azure ML desde azure.ai.ml import comando trabajo = comando (código =… comando =… entorno =… computar =…) ml_client.jobs.create_or_update (trabajo)
AWS SageMaker
Los roles y permisos en SageMaker están diseñados según un principio completamente diferente, principalmente utilizando "roles" en el servicio AWS Identity Access Management (IAM). Aunque IAM permite crear acceso a nivel de usuario (o a nivel de cuenta) similar a Azure, AWS recomienda otorgar permisos a nivel de trabajo durante todo el ciclo de vida de ML. De esta manera, sus permisos personales de AWS son irrelevantes en tiempo de ejecución y SageMaker asume una función (es decir, función de ejecución de SageMaker) para acceder a servicios relevantes de AWS, como el depósito S3, SageMaker Training Pipeline e instancias informáticas para ejecutar el trabajo.
Por ejemplo, aquí se ofrece un vistazo rápido a cómo configurar un Estimador con la función de ejecución de SageMaker para ejecutar el trabajo de capacitación.
importar sagemaker desde sagemaker.estimator importar Estimador # Obtener el rol de ejecución de SageMaker role = sagemaker.get_execution_role() # Definir el estimador estimador = Estimator( image_uri=image_uri, role=role, # asumir el rol de ejecución de SageMaker durante el tiempo de ejecución instancia_tipo="ml.m5.xlarge", instancia_count=1, ) # Iniciar entrenamiento estimador.fit("s3://mi-cubo-de-entrenamiento/tren/")
Significa que podemos configurar suficiente granularidad para otorgar permisos de rol para ejecutar solo trabajos de capacitación en el entorno de desarrollo pero sin tocar el entorno de producción. Por ejemplo, al rol se le otorga acceso a un depósito de S3 que contiene datos de prueba y se le bloquea el que contiene datos de producción, entonces el trabajo de capacitación que asume este rol no tendrá la oportunidad de sobrescribir los datos de producción por accidente.
La gestión de permisos en AWS es un dominio sofisticado en sí mismo y no pretendo explicar completamente este tema. Recomiendo leer este artículo para conocer más prácticas recomendadas de la documentación oficial de AWS "Gestión de permisos".
¿Qué significa esto en la práctica?
Azure ML: el control de acceso basado en roles (RBAC) de Azure se adapta a empresas o equipos que administran qué usuario necesita acceder a qué recursos. Más intuitivo de entender y útil para el control de acceso de usuarios centralizado. AWS SageMaker AI: AWS se adapta a sistemas que se preocupan por qué trabajo necesita acceder a qué servicios. Desacople los permisos de usuarios individuales con la ejecución de trabajos para una mejor automatización y prácticas de MLOps. AWS se adapta a grandes equipos de ciencia de datos con definiciones granulares de trabajos y canalizaciones y entornos aislados.
Referencia
Almacenamiento de datos
Quizás tengas la pregunta: ¿puedo almacenar los datos en el directorio de trabajo? Al menos esa ha sido mi pregunta durante mucho tiempo, y creo que la respuesta sigue siendo sí si estás experimentando o creando prototipos usando un script simple o un cuaderno en un entorno de desarrollo interactivo. Pero es importante considerar la ubicación del almacenamiento de datos en el contexto de la creación de trabajos de aprendizaje automático.
Dado que el código se ejecuta en un entorno administrado en la nube o en un contenedor acoplable independiente de su directorio local, no se puede acceder a los datos almacenados localmente al ejecutar canalizaciones y trabajos en SageMaker o Azure ML. Esto requiere servicios de almacenamiento de datos gestionados y centralizados. En Azure, esto se maneja a través de una cuenta de almacenamiento dentro del espacio de trabajo que admite almacenes de datos y activos de datos.
Los almacenes de datos contienen información de conexión, mientras que los activos de datos son instantáneas versionadas de los datos que se utilizan para entrenamiento o inferencia. AWS, por otro lado, depende en gran medida de los depósitos S3 como ubicaciones de almacenamiento centralizado que permiten un acceso seguro, duradero y entre regiones a través de diferentes cuentas, y los usuarios pueden acceder a los datos a través de su ruta URI única.
Aprendizaje automático de Azure
Azure ML trata los datos como recursos y activos adjuntos en los espacios de trabajo, con una cuenta de almacenamiento y cuatro almacenes de datos integrados creados automáticamente al crear una instancia de cada espacio de trabajo para almacenar archivos (en Azure File Share) y conjuntos de datos (en Azure Blob Storage).
Dado que los almacenes de datos mantienen de forma segura la información de la conexión de datos y manejan automáticamente la credencial/identidad detrás de escena, desacoplan la ubicación de los datos y el permiso de acceso del código, de modo que el código permanezca sin cambios incluso si cambia la conexión de datos subyacente. Se puede acceder a los almacenes de datos a través de su URI único. A continuación se muestra un ejemplo de cómo crear un objeto de entrada con el tipo uri_file pasando la ruta del almacén de datos.
# crear datos de entrenamiento usando Datastore Training_data=Input( type="uri_file", path="", )
Luego, estos datos se pueden utilizar como datos de entrenamiento para un trabajo de clasificación de AutoML.
clasificación_trabajo = automl.clasificación (compute='aml-cluster', datos_de_formación=datos_de_formación, nombre_columna_objetivo='Sobrevivido', métrica_primaria='precisión',)
El activo de datos es otra opción para acceder a los datos en un trabajo de aprendizaje automático, especialmente cuando es beneficioso realizar un seguimiento de múltiples versiones de datos, de modo que los científicos de datos puedan identificar las instantáneas de datos correctas que se utilizan para la creación de modelos o experimentos. A continuación se muestra un código de ejemplo para crear un objeto de entrada con el tipo AssetTypes.URI_FILE pasando la ruta del activo de datos "azureml:my_train_data:1" (que incluye el nombre del activo de datos + número de versión) y usando el modo InputOutputModes.RO_MOUNT para acceso de solo lectura. Puedes encontrar más información en la documentación “Acceder a datos en un trabajo”.
# crear datos de entrenamiento usando el activo de datos datos_entrenamiento = Entrada( tipo=AssetTypes.URI_FILE, ruta="azureml:my_train_data:1", modo=InputOutputModes.RO_MOUNT )
AWS SageMaker
AWS SageMaker está estrechamente integrado con Amazon S3 (Simple Storage Service) para flujos de trabajo de aprendizaje automático, de modo que los trabajos de entrenamiento, los puntos finales de inferencia y las canalizaciones de SageMaker puedan procesar datos de entrada de depósitos de S3 y escribir datos de salida en ellos. Es posible que descubra que la creación de un entorno de trabajo administrado por SageMaker (que se analizará en la Parte 2) requiere la ubicación del depósito S3 como parámetro clave; alternativamente, se creará un depósito predeterminado si no se especifica.
A diferencia del enfoque de almacén de datos centrado en el espacio de trabajo de Azure ML, AWS S3 es un servicio de almacenamiento de datos independiente que proporciona almacenamiento en la nube escalable, duradero y seguro que se puede compartir entre otros servicios y cuentas de AWS. Esto ofrece más flexibilidad para la gestión de permisos a nivel de carpeta individual, pero al mismo tiempo requiere otorgar explícitamente acceso al rol de ejecución de SageMaker al depósito de S3.
En este fragmento de código, utilizamos estimator.fit(train_data_uri) para ajustar el modelo a los datos de entrenamiento pasando su URI de S3 directamente, luego genera el modelo de salida y lo almacena en la ubicación del depósito de S3 especificada. Se pueden encontrar más escenarios en su documentación: “Ejemplos de Amazon S3 usando SDK para Python (Boto3)”.
import sagemaker # Definir rutas S3 train_data_uri = "" output_folder_uri = "" # Usar en el trabajo de entrenamiento estimador = Estimator( image_uri=image_uri, role=role, instancia_type="ml.m5.xlarge", output_path=output_folder_uri ) estimator.fit(train_data_uri)
¿Qué significa en la práctica?
Azure ML: use Datastore para administrar conexiones de datos, que maneja la información de credenciales/identidad detrás de escena. Por lo tanto, este enfoque desacopla la ubicación de los datos y el permiso de acceso del código, permitiendo que el código permanezca sin cambios cuando cambia la conexión subyacente. AWS SageMaker: utilice depósitos S3 como servicio de almacenamiento de datos principal para administrar datos de entrada y salida de trabajos de SageMaker a través de sus rutas URI. Este enfoque requiere una administración de permisos explícita para otorgar acceso al rol de ejecución de SageMaker al depósito de S3 requerido.
Referencia
Mensaje para llevar a casa
Compare Azure ML y AWS SageMaker para obtener capacitación de modelos escalables, centrándose en la configuración de proyectos, la administración de permisos y los patrones de almacenamiento de datos, para que los equipos puedan alinear mejor las opciones de plataforma con su ecosistema de nube existente y sus flujos de trabajo MLOps preferidos.
En la parte 1, comparamos la configuración del proyecto de alto nivel y la gestión de permisos, almacenando y accediendo a los datos necesarios para la capacitación del modelo. La parte 2 analizará varias opciones informáticas en ambas plataformas en la nube y la creación y gestión de entornos de ejecución para trabajos de capacitación.
Recursos relacionados
[insertar]https://www.youtube.com/watch?v=u4uHqYaI3yQ[/embed]