AWS versus Azure: una inmersión profunda en la capacitación de modelos – Parte 2

Habiendo establecido cómo estas plataformas manejan la configuración del proyecto y el acceso a los datos, en la Parte 2 examinaremos los recursos informáticos y los entornos de ejecución que impulsan los trabajos de entrenamiento del modelo.

Calcular

Compute es la máquina virtual donde se ejecuta su modelo y código. Junto con la red y el almacenamiento, es uno de los componentes fundamentales de la computación en la nube. Los recursos informáticos suelen representar el componente de coste más grande de un proyecto de aprendizaje automático, ya que los modelos de entrenamiento (especialmente los modelos grandes de IA) requieren largos tiempos de entrenamiento y, a menudo, instancias informáticas especializadas (por ejemplo, instancias de GPU) con costos más altos. Por lo tanto, Azure ML diseña una función de operador informático de AzureML dedicada (consulte los detalles en la Parte 1) para administrar los recursos informáticos.

Azure y AWS ofrecen varios tipos de instancias que se diferencian en la cantidad de CPU/GPU, memoria, espacio en disco y tipo, cada una diseñada para propósitos específicos. Ambas plataformas utilizan un modelo de precios de pago por uso y cobran solo por el tiempo de procesamiento activo.

Las series de máquinas virtuales de Azure se nombran en orden alfabético; por ejemplo, las máquinas virtuales de la familia D están diseñadas para cargas de trabajo de uso general y cumplen con los requisitos de la mayoría de los entornos de desarrollo y producción. Las instancias informáticas de AWS también se agrupan en familias según su finalidad; por ejemplo, la familia m5 contiene instancias de uso general para el desarrollo de SageMaker ML. La siguiente tabla compara las instancias informáticas ofrecidas por Azure y AWS según su propósito, precio por hora y casos de uso típicos. (Tenga en cuenta que la estructura de precios varía según la región y el plan, por lo que recomiendo consultar sus sitios web oficiales).

Ahora que hemos comparado los precios de computación en AWS y Azure, exploremos en qué se diferencian las dos plataformas en la integración de recursos informáticos en sistemas de aprendizaje automático.

Aprendizaje automático de Azure

Los procesos son recursos persistentes en el espacio de trabajo de Azure ML, normalmente creados una vez por el operador de procesos de AzureML y reutilizados por el equipo de ciencia de datos. Dado que los recursos informáticos son costosos, esta estructura permite que una persona con experiencia en infraestructura de nube los administre de manera centralizada, mientras que los científicos e ingenieros de datos pueden concentrarse en el trabajo de desarrollo.

Azure ofrece un espectro de opciones de destino informático designadas para el desarrollo y la implementación de ML, según la escala de la carga de trabajo. Una instancia informática es una máquina de un solo nodo adecuada para el desarrollo y las pruebas interactivas en el entorno del portátil Jupyter. Un clúster de cómputo es otro tipo de destino de cómputo que pone en marcha máquinas de clúster de múltiples nodos. Se puede escalar para procesamiento paralelo según la demanda de la carga de trabajo y admite el escalado automático configurando los parámetros min_instances y max_instances. Además, hay computación sin servidor, clústeres de Kubernetes y contenedores que se adaptan a diferentes propósitos. Aquí hay un resumen visual útil que lo ayudará a tomar la decisión según su caso de uso.

Para crear un destino informático administrado de Azure ML, creamos un objeto AmlCompute usando el siguiente código:

escriba: utilice "amlcompute" para el clúster de cálculo. Como alternativa, utilice "computeinstance" para el desarrollo interactivo de un solo nodo y "kubernetes" para clústeres de AKS. nombre: especifique el nombre del destino de cálculo. tamaño: especifique el tamaño de la instancia. min_instances y max_instances (opcional): establece el rango de instancias permitidas para ejecutarse simultáneamente. idle_time_before_scale_down (opcional): apaga automáticamente el clúster de computación cuando está inactivo para evitar incurrir en costos innecesarios. # Crear un clúster de cómputo cpu_cluster = AmlCompute( name="cpu-cluster", type="amlcompute", size="Standard_DS3_v2", min_instances=0, max_instances=4, idle_time_before_scale_down=120 ) # Crear o actualizar el cómputo ml_client.compute.begin_create_or_update(cpu_cluster)

Una vez creado el recurso informático, cualquier persona en el espacio de trabajo compartido puede usarlo simplemente haciendo referencia a su nombre en un trabajo de aprendizaje automático, lo que lo hace fácilmente accesible para la colaboración en equipo.

# Utilice el cálculo persistente "cpu-cluster" en el trabajo job = comando( code='./src', comando='python code.py', compute='cpu-cluster', display_name='train-custom-env', experiment_name='training')

AWS SageMaker IA

Los recursos informáticos son administrados por un servicio independiente de AWS: EC2 (Elastic Compute Cloud). Cuando se utilizan estos recursos informáticos en SageMaker, es necesario que los desarrolladores configuren explícitamente el tipo de instancia para cada trabajo, luego las instancias informáticas se crean según demanda y finalizan cuando finaliza el trabajo. Este enfoque ofrece a los desarrolladores más flexibilidad en la selección de recursos informáticos en función de la tarea, pero requiere más conocimiento de infraestructura para seleccionar y administrar el recurso informático adecuado. Por ejemplo, los tipos de instancias disponibles difieren según el tipo de trabajo. ml.t3.medium y ml.t3.large se usan comúnmente para alimentar portátiles SageMaker en entornos de desarrollo interactivos, pero no están disponibles para trabajos de capacitación, que requieren tipos de instancias más potentes de las familias m5, c5, p3 o g4dn.

Como se muestra en el fragmento de código a continuación, AWS SageMaker especifica la instancia informática y la cantidad de instancias que se ejecutan simultáneamente como parámetros del trabajo. Durante la ejecución del trabajo se crea una instancia informática con el tipo ml.m5.xlarge y se cobra según el tiempo de ejecución del trabajo.

estimador = Estimador (image_uri=image_uri, rol=rol, instancia_tipo="ml.m5.xlarge", instancia_count=1)

Los trabajos de SageMaker activan instancias bajo demanda de forma predeterminada. Se cobran por segundos y proporcionan capacidad garantizada para ejecutar trabajos urgentes. Para trabajos que pueden tolerar interrupciones y una mayor latencia, la instancia puntual es una opción que ahorra más costos y utiliza instancias informáticas no utilizadas. La desventaja es el período de espera adicional cuando no hay instancias puntuales disponibles. Usamos el siguiente fragmento de código para implementar una opción de instancia puntual para un trabajo de capacitación.

use_spot_instances: establecido como Verdadero para usar instancias puntuales; de lo contrario, se establece de forma predeterminada bajo demanda max_wait: la cantidad máxima de tiempo que está dispuesto a esperar por las instancias puntuales disponibles (el tiempo de espera no se cobra)
max_run: la cantidad máxima de tiempo de entrenamiento permitido para el trabajo checkpoint_s3_uri: la ruta URI del depósito de S3 para guardar los puntos de control del modelo, de modo que el entrenamiento pueda reiniciarse de manera segura después de esperar estimator = Estimator( image_uri=image_uri, role=role, instancia_type="ml.m5.xlarge", instancia_count=1, use_spot_instances=True, max_run=3600, max_wait=7200, punto de control_s3_uri="" )

¿Qué significa esto en la práctica?

Azure ML: el enfoque de computación persistente de Azure permite la administración centralizada y el uso compartido entre múltiples desarrolladores, lo que permite a los científicos de datos centrarse en el desarrollo de modelos en lugar de en la administración de la infraestructura. AWS SageMaker AI: SageMaker requiere que los desarrolladores definan explícitamente el tipo de instancia informática para cada trabajo, lo que proporciona más flexibilidad pero también exige un conocimiento más profundo de la infraestructura de los tipos de instancias, los costos y las restricciones de disponibilidad.

Referencia

Ambiente

El entorno define dónde se ejecuta el código o el trabajo, incluido el software, el sistema operativo, los paquetes de programas, la imagen de la ventana acoplable y las variables de entorno. Si bien la computación es responsable de la infraestructura subyacente y las selecciones de hardware, la configuración del entorno es crucial para garantizar comportamientos consistentes y reproducibles en todo el entorno de desarrollo y producción, mitigando los conflictos de paquetes y los problemas de dependencia al ejecutar el mismo código en diferentes configuraciones de tiempo de ejecución por parte de diferentes desarrolladores. Azure ML y SageMaker admiten el uso de sus entornos seleccionados y la configuración de entornos personalizados.

Aprendizaje automático de Azure

De manera similar a los datos y la computación, el entorno se considera un tipo de recurso y activo en el espacio de trabajo de Azure ML. Azure ML ofrece una lista completa de entornos seleccionados para marcos de Python populares (por ejemplo, PyTorch, Tensorflow, scikit-learn) diseñados para CPU o GPU/CUDA.

El siguiente fragmento de código ayuda a recuperar la lista de todos los entornos seleccionados en Azure ML. Por lo general, siguen una convención de nomenclatura que incluye el nombre del marco, la versión, el sistema operativo, la versión de Python y el destino de cálculo (CPU/GPU); por ejemplo, AzureML-sklearn-1.0-ubuntu20.04-py38-cpu indica la versión 1.0 de scikit-learn, que se ejecuta en Ubuntu 20.04 con Python 3.8 para el cálculo de la CPU.

envs = ml_client.environments.list() para env en envs: print(env.name) # >>> Auzre ML Curated Environments """ AzureML-AI-Studio-Development AzureML-ACPT-pytorch-1.13-py38-cuda11.7-gpu AzureML-ACPT-pytorch-1.12-py38-cuda11.6-gpu AzureML-ACPT-pytorch-1.12-py39-cuda11.6-gpu AzureML-ACPT-pytorch-1.11-py38-cuda11.5-gpu AzureML-ACPT-pytorch-1.11-py38-cuda11.3-gpu AzureML-responsibleai-0.21-ubuntu20.04-py38-cpu AzureML-responsibleai-0.20-ubuntu20.04-py38-cpu AzureML-tensorflow-2.5-ubuntu20.04-py38-cuda11-gpu AzureML-tensorflow-2.6-ubuntu20.04-py38-cuda11-gpu AzureML-tensorflow-2.7-ubuntu20.04-py38-cuda11-gpu AzureML-sklearn-1.0-ubuntu20.04-py38-cpu AzureML-pytorch-1.10-ubuntu18.04-py38-cuda11-gpu AzureML-pytorch-1.9-ubuntu18.04-py37-cuda11-gpu AzureML-pytorch-1.8-ubuntu18.04-py37-cuda11-gpu AzureML-sklearn-0.24-ubuntu18.04-py37-cpu AzureML-lightgbm-3.2-ubuntu18.04-py37-cpu AzureML-pytorch-1.7-ubuntu18.04-py37-cuda11-gpu AzureML-tensorflow-2.4-ubuntu18.04-py37-cuda11-gpu AzureML-Triton AzureML-Designer-Score AzureML-VowpalWabbit-8.8.0 AzureML-PyTorch-1.3-CPU """

Para ejecutar el trabajo de capacitación en un entorno seleccionado, creamos un objeto de entorno haciendo referencia a su nombre y versión y luego pasándolo como parámetro de trabajo.

# Obtener un entorno seleccionado Environment = ml_client.environments.get("AzureML-sklearn-1.0-ubuntu20.04-py38-cpu", version=44) # Usar el entorno seleccionado en Job job = command( code=".", command="python train.py", Environment=environment, Compute="cpu-cluster" ) ml_client.jobs.create_or_update(job)

Alternativamente, cree un entorno personalizado a partir de una imagen de Docker registrada en Docker Hob usando el siguiente fragmento de código.

# Obtener un entorno seleccionado Environment = ml_client.environments.get("AzureML-sklearn-1.0-ubuntu20.04-py38-cpu", version=44) # Usar el entorno seleccionado en Job job = command( code=".", command="python train.py", Environment=environment, Compute="cpu-cluster" ) ml_client.jobs.create_or_update(job)

AWS SageMaker IA

La configuración del entorno de SageMaker está estrechamente relacionada con las definiciones de trabajo, ofreciendo tres niveles de personalización para establecer el sistema operativo, los marcos y los paquetes necesarios para la ejecución del trabajo. Estos son el algoritmo integrado, Bring Your Own Script (modo Script) y Bring Your Own Container (BYOC), que van desde la opción más simple pero rígida hasta la opción más compleja pero personalizable.

Algoritmos incorporados

Esta es la opción con el menor esfuerzo para que los desarrolladores entrenen e implementen modelos de aprendizaje automático a escala en AWS SageMaker y Azure actualmente no ofrece un enfoque de algoritmo integrado equivalente que utilice el SDK de Python a partir de febrero de 2026.

SageMaker encapsula el algoritmo de aprendizaje automático, así como su biblioteca Python y las dependencias del marco dentro de un objeto estimador. Por ejemplo, aquí creamos una instancia de un estimador de KMeans especificando el hiperparámetro k específico del algoritmo y pasando los datos de entrenamiento para que se ajusten al modelo. Luego, el trabajo de entrenamiento activará una instancia informática ml.m5.large y el modelo entrenado se guardará en la ubicación de salida.

Trae tu propio guión

El enfoque Traiga su propio script (también conocido como modo script o traiga su propio modelo) permite a los desarrolladores aprovechar los contenedores prediseñados de SageMaker para marcos de Python populares para el aprendizaje automático como scikit-learn, PyTorch y Tensorflow. Proporciona la flexibilidad de personalizar el trabajo de capacitación a través de su propio script sin la necesidad de administrar el entorno de ejecución del trabajo, lo que la convierte en la opción más popular cuando se utilizan algoritmos especializados no incluidos en las opciones integradas de SageMaker.

En el siguiente ejemplo, creamos una instancia de un estimador utilizando el marco scikit-learn proporcionando un script de entrenamiento personalizado train.py, los hiperparámetros del modelo, junto con la versión del marco y la versión de Python.

de sagemaker.sklearn import SKLearn sk_estimator = SKLearn( Entry_point="train.py", role=role,stance_count=1,stance_type="ml.m5.large", py_version="py3", framework_version="1.2-1", script_mode=True, hyperparameters={"estimators": 20},) # Entrena el estimador sk_estimator.fit({"train": datos_entrenamiento})

Traiga su propio contenedor

Este es el enfoque con el mayor nivel de personalización, que permite a los desarrolladores crear un entorno personalizado utilizando una imagen de Docker. Se adapta a escenarios que dependen de marcos de Python no compatibles, paquetes especializados u otros lenguajes de programación (por ejemplo, R, Java, etc.). El flujo de trabajo implica crear una imagen de Docker que contenga todas las dependencias de paquetes requeridas y scripts de entrenamiento de modelos, y luego enviarla a Elastic Container Registry (ECR), que es el servicio de registro de contenedores de AWS equivalente a Docker Hub.

En el código siguiente, especificamos el URI de la imagen acoplable personalizada como parámetro para crear el estimador y ajustarlo con datos de entrenamiento.

de sagemaker.estimator importar Estimador image_uri = ":" byoc_estimator = Estimador( image_uri=image_uri, rol=role, instancia_count=1, instancia_tipo="ml.m5.large", salida_path="", sagemaker_session=sess,) byoc_estimator.fit(training_data)

¿Qué significa en la práctica?

Azure ML: brinda soporte para ejecutar trabajos de capacitación utilizando su amplia colección de entornos seleccionados que cubren marcos populares como PyTorch, TensorFlow y scikit-learn, además de ofrecer la capacidad de crear y configurar entornos personalizados a partir de imágenes de Docker para casos de uso más especializados. Sin embargo, es importante tener en cuenta que Azure ML no ofrece actualmente el enfoque de algoritmo integrado que encapsula y empaqueta algoritmos populares de aprendizaje automático directamente en el entorno de la misma manera que lo hace SageMaker. AWS SageMaker AI: SageMaker es conocido por sus tres niveles de personalizaciones (algoritmo integrado, trae tu propio script y trae tu propio contenedor), que cubren un espectro de requisitos de los desarrolladores. El algoritmo integrado y Bring Your Own Script utilizan los entornos administrados de AWS y se integran estrechamente con marcos o algoritmos de aprendizaje automático. Ofrecen simplicidad pero son menos adecuados para procesos de formación de modelos altamente especializados.

En resumen

Con base en las comparaciones anteriores de Computación y Medio Ambiente junto con lo que discutimos en AWS vs. Azure: Una inmersión profunda en la capacitación de modelos – Parte 1 (Configuración del proyecto y almacenamiento de datos), nos habríamos dado cuenta de que las dos plataformas adoptan diferentes principios de diseño para estructurar sus ecosistemas de aprendizaje automático.

Azure ML sigue una arquitectura más modular en la que los datos, la informática y el entorno se tratan como recursos y activos independientes dentro del espacio de trabajo de Azure ML. Dado que se pueden configurar y administrar por separado, este enfoque es más amigable para los principiantes, especialmente para usuarios sin amplios conocimientos de computación en la nube o administración de permisos. Por ejemplo, un científico de datos puede crear un trabajo de capacitación adjuntando una computación existente en el espacio de trabajo sin necesidad de experiencia en infraestructura para administrar instancias de computación.

AWS SageMaker tiene una curva de aprendizaje más pronunciada, ya que múltiples servicios están estrechamente acoplados y orquestados juntos como un sistema holístico para la ejecución de trabajos de aprendizaje automático. Sin embargo, este enfoque centrado en el trabajo ofrece una clara separación entre la capacitación de modelos y los entornos de implementación de modelos, así como la capacidad de capacitación distribuida a escala. Al brindar a los desarrolladores más control de la infraestructura, SageMaker es ideal para equipos de inteligencia artificial y ciencia de datos a gran escala con una alta madurez de MLOps y la necesidad de canales de CI/CD.

Mensaje para llevar a casa

En esta serie, comparamos las dos plataformas en la nube más populares, Azure y AWS, para el entrenamiento de modelos escalables, dividiendo la comparación en las siguientes dimensiones:

Gestión de proyectos y permisos Almacenamiento de datos Entorno informático

En la Parte 1, analizamos la configuración de proyectos de alto nivel y la gestión de permisos, luego hablamos sobre el almacenamiento y el acceso a los datos necesarios para el entrenamiento del modelo.