Capacitación distribuida con Amazon EKS y Torch Distributed Elastic

La capacitación del modelo de aprendizaje profundo distribuido se está volviendo cada vez más importante a medida que el tamaño de los datos crece en muchas industrias. Muchas aplicaciones de visión por computadora y procesamiento de lenguaje natural ahora requieren el entrenamiento de modelos de aprendizaje profundo, que están creciendo exponencialmente en complejidad y, a menudo, se entrenan con cientos de terabytes de datos. Entonces se vuelve importante usar una gran infraestructura en la nube para escalar el entrenamiento de modelos tan grandes.

Los desarrolladores pueden usar marcos de trabajo de código abierto como PyTorch para diseñar fácilmente arquitecturas modelo intuitivas. Sin embargo, escalar el entrenamiento de estos modelos en múltiples nodos puede ser un desafío debido a la mayor complejidad de orquestación.

El entrenamiento de modelos distribuidos consta principalmente de dos paradigmas:

• modelo paralelo – En el entrenamiento paralelo de modelos, el modelo en sí es tan grande que no cabe en la memoria de una sola GPU y se necesitan varias GPU para entrenar el modelo. El modelo GPT-3 de Open AI con 175 mil millones de parámetros entrenables (aproximadamente 350 GB de tamaño) es un buen ejemplo de esto.
• Datos paralelos – En el entrenamiento paralelo de datos, el modelo puede residir en una sola GPU, pero debido a que los datos son tan grandes, puede llevar días o semanas entrenar un modelo. Distribuir los datos a través de múltiples nodos de GPU puede reducir significativamente el tiempo de entrenamiento.

En esta publicación, proporcionamos una arquitectura de ejemplo para entrenar modelos de PyTorch usando el Antorcha Elástico Distribuido framework en una forma paralela de datos distribuidos usando Servicio Amazon Elastic Kubernetes (Amazon EKS).

Requisitos previos

Para replicar los resultados informados en esta publicación, el único requisito previo es una cuenta de AWS. En esta cuenta, creamos un clúster EKS y un Amazon FSx para Lustre sistema de archivos También llevamos imágenes de contenedores a un Registro de contenedores elásticos de Amazon (Amazon ECR) repositorio en la cuenta. Las instrucciones para configurar estos componentes se proporcionan según sea necesario a lo largo de la publicación.

Clústeres de EKS

Amazon EKS es un servicio de contenedor administrado para ejecutar y escalar aplicaciones de Kubernetes en AWS. Con Amazon EKS, puede ejecutar de manera eficiente trabajos de capacitación distribuidos utilizando la última Nube informática elástica de Amazon (Amazon EC2) sin necesidad de instalar, operar y mantener su propio plano de control o nodos. es un popular orquestador para aprendizaje automático (ML) y flujos de trabajo de IA. Un clúster típico de EKS en AWS se parece a la siguiente figura.

Hemos lanzado un proyecto de código abierto, AWS DevOps para EKS (aws-do-eks), que proporciona una gran colección de scripts y herramientas fáciles de usar y configurables para aprovisionar clústeres de EKS y ejecutar trabajos de capacitación distribuidos. Este proyecto está construido siguiendo los principios de la hacer marco: Simplicidad, Flexibilidad y Universalidad. Puede configurar el clúster que desee utilizando el eks.conf y luego inícielo ejecutando el eks-create.sh guion. Se proporcionan instrucciones detalladas en el Repositorio GitHub.

Entrene modelos de PyTorch usando Torch Distributed Elastic

Torch Distributed Elastic (TDE) es una biblioteca nativa de PyTorch para entrenar modelos de aprendizaje profundo a gran escala en los que es fundamental escalar los recursos informáticos de forma dinámica en función de la disponibilidad. los Controlador TorchElastic para Kubernetes es una implementación nativa de Kubernetes para TDE que administra automáticamente el ciclo de vida de los pods y los servicios necesarios para la capacitación de TDE. Permite escalar dinámicamente los recursos informáticos durante el entrenamiento según sea necesario. También proporciona capacitación tolerante a fallas mediante la recuperación de trabajos de fallas de nodos.

En esta publicación, discutimos los pasos para entrenar PyTorch EfficientNet-B7 y ResNet50 modelos usando ImagenNet datos de forma distribuida con TDE. Usamos el PyTorch Datos distribuidos en paralelo API y el controlador TorchElastic de Kubernetes, y ejecute nuestros trabajos de capacitación en un clúster de EKS que contiene varios nodos de GPU. El siguiente diagrama muestra el diagrama de arquitectura para este modelo de entrenamiento.

TorchElastic for Kubernetes consta principalmente de dos componentes: TorchElastic Kubernetes Controller (TEC) y el servidor de parámetros (etcd). El controlador es responsable de monitorear y administrar los trabajos de capacitación, y el servidor de parámetros realiza un seguimiento de los nodos trabajadores para la sincronización distribuida y el descubrimiento de pares.

Para que los pods de entrenamiento accedan a los datos, necesitamos un volumen de datos compartido que cada pod pueda montar. Algunas opciones para volúmenes compartidos a través de Interfaz de almacenamiento de contenedores (CSI) controladores incluidos en AWS DevOps para EKS en Sistema de archivos elástico de Amazon (Amazon EFS) y FSx para brillo.

Configuración de clúster

En nuestra configuración de clúster, usamos una instancia c5.2xlarge para los módulos del sistema. Usamos tres instancias p4d.24xlarge como módulos de trabajadores para entrenar un modelo EfficientNet. Para la capacitación de ResNet50, usamos instancias p3.8xlarge como módulos de trabajadores. Además, usamos un sistema de archivos compartidos FSx para almacenar nuestros datos de entrenamiento y artefactos de modelo.

Las instancias AWS p4d.24xlarge están equipadas con Adaptador de tela elástica (EFA) para proporcionar redes entre nodos. Discutimos EPT más adelante en la publicación. Para habilitar la comunicación a través de EFA, debemos configurar el clúster a través de un archivo .yaml. Un archivo de ejemplo se proporciona en el repositorio de GitHub.

Después de que este archivo .yaml esté configurado correctamente, podemos iniciar el clúster mediante el script proporcionado en el repositorio de GitHub:

./eks-create.sh

Para obtener más detalles sobre cómo diseñar y realizar los esfuerzos de seguimiento y evaluación, refierase a Repositorio GitHub para obtener instrucciones detalladas.

Prácticamente no hay diferencia entre ejecutar trabajos en p4d.24xlarge y p3.8xlarge. Los pasos descritos en esta publicación funcionan para ambos. La única diferencia es la disponibilidad de EFA en instancias p4d.24xlarge. Para modelos más pequeños como ResNet50, la red estándar en comparación con la red EFA tiene un impacto mínimo en la velocidad del entrenamiento.

FSx para el sistema de archivos Lustre

FSx está diseñado para cargas de trabajo informáticas de alto rendimiento y proporciona una latencia inferior al milisegundo utilizando volúmenes de almacenamiento de unidades de estado sólido. Elegimos FSx porque proporcionó un mejor rendimiento a medida que escalamos a una gran cantidad de nodos. Un detalle importante a tener en cuenta es que FSx solo puede existir en una única zona de disponibilidad. Por lo tanto, todos los nodos que acceden al sistema de archivos FSx deben existir en la misma zona de disponibilidad que el sistema de archivos FSx. Una forma de lograr esto es especificar la zona de disponibilidad relevante en el archivo .yaml del clúster para los grupos de nodos específicos antes de crear el clúster. Como alternativa, podemos modificar la parte de la red del grupo de escalado automático para estos nodos después de configurar el clúster y limitarlo a usar una única subred. Esto se puede hacer fácilmente en la consola de Amazon EC2.

Suponiendo que el clúster de EKS esté en funcionamiento y que se conozca el ID de subred para la zona de disponibilidad, podemos configurar un sistema de archivos FSx proporcionando la información necesaria en el fsx.conf archivo como se describe en el readme y ejecutando el desplegar.sh guión en el fsx carpeta. Esto configura la política y el grupo de seguridad correctos para acceder al sistema de archivos. El script también instala el controlador CSI para FSx como un conjunto de demonios. Finalmente, podemos crear el reclamo de volumen persistente FSx en Kubernetes aplicando un solo archivo .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Esto crea un sistema de archivos FSx en la zona de disponibilidad especificada en el fsx.conf archivo, y también crea una reclamación de volumen persistente fsx-pvc, que puede ser montado por cualquiera de los pods en el clúster en modo de lectura y escritura (RWX).

En nuestro experimento, utilizamos datos completos de ImageNet, que contienen más de 12 millones de imágenes de entrenamiento divididas en 1,000 clases. Los datos se pueden descargar de la Sitio web de ImageNet. La pelota TAR original tiene varios directorios, pero para nuestro modelo de entrenamiento, solo nos interesa ILSVRC/Data/CLS-LOC/, que incluye el train y val subdirectorios. Antes de entrenar, necesitamos reorganizar las imágenes en el val subdirectorio para que coincida con la estructura de directorio requerida por PyTorch ImagenCarpeta clase. Esto se puede hacer usando un simple Script de Python después de que los datos se copien al volumen persistente en el siguiente paso.

Para copiar los datos de un Servicio de almacenamiento simple de Amazon (Amazon S3) al sistema de archivos FSx, creamos una imagen de Docker que incluye scripts para esta tarea. Un Dockerfile de ejemplo y un script de shell se incluyen en el csi carpeta dentro del repositorio de GitHub. Podemos construir la imagen usando el build.sh script y luego enviarlo a Amazon ECR usando el push.sh guion. Antes de usar estos scripts, debemos proporcionar el URI correcto para el repositorio de ECR en el .env archivo en la carpeta raíz del repositorio de GitHub. Después de enviar la imagen de Docker a Amazon ECR, podemos iniciar un pod para copiar los datos aplicando el archivo .yaml correspondiente:

kubectl apply -f fsx-data-prep-pod.yaml

El pod ejecuta automáticamente el script. preparación-de-datos.sh para copiar los datos de Amazon S3 al volumen compartido. Debido a que los datos de ImageNet tienen más de 12 millones de archivos, el proceso de copia lleva un par de horas. El guión de Python imagenet_data_prep.py también se ejecuta para reorganizar el val conjunto de datos como esperaba PyTorch.

Aceleración de red

Podemos usar el adaptador de tela elástica (EFA) en combinación con tipos de instancias EC2 compatibles para acelerar el tráfico de red entre los nodos de GPU en su clúster. Esto puede ser útil cuando se ejecutan grandes trabajos de capacitación distribuidos donde la comunicación de red estándar puede ser un cuello de botella. Los scripts para implementar y probar el complemento del dispositivo EFA en el clúster de EKS que usamos aquí se incluyen en el complemento-de-dispositivo-efa carpeta en el repositorio de GitHub. Para habilitar un trabajo con EFA en su clúster de EKS, además de que los nodos del clúster tengan el hardware y el software necesarios, el complemento del dispositivo EFA debe implementarse en el clúster y su contenedor de trabajo debe tener CUDA y NCCL compatibles. versiones instalado.

Para demostrar la ejecución de pruebas NCCL y la evaluación del rendimiento de EFA en instancias p4d.24xlarge, primero debemos implementar el operador Kubeflow MPI ejecutando el correspondiente desplegar.sh guión en el operador mpi carpeta. Luego ejecutamos el desplegar.sh guión y actualizar el prueba-efa-nccl.yaml manifiesto así límites y solicitudes de recurso vpc.amazonaws.com están configurados en 4. Los cuatro adaptadores EFA disponibles en los nodos p4d.24xlarge se agrupan para proporcionar el máximo rendimiento.

Ejecutar kubectl apply -f ./test-efa-nccl.yaml para aplicar la prueba y luego mostrar los registros del módulo de prueba. La siguiente línea en la salida del registro confirma que se está utilizando EFA:

NCCL INFO NET/OFI Selected Provider is efa

Los resultados de la prueba deben ser similares a la siguiente salida:

[1,0]<stdout>:#                                                       out-of-place                       in-place
[1,0]<stdout>:#       size         count      type   redop     time   algbw   busbw  error     time   algbw   busbw  error
[1,0]<stdout>:#        (B)    (elements)                       (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
[1,0]<stdout>:           8             2     float     sum    629.7    0.00    0.00  2e-07    631.4    0.00    0.00  1e-07
[1,0]<stdout>:          16             4     float     sum    630.5    0.00    0.00  1e-07    628.1    0.00    0.00  1e-07
[1,0]<stdout>:          32             8     float     sum    627.6    0.00    0.00  1e-07    628.2    0.00    0.00  1e-07
[1,0]<stdout>:          64            16     float     sum    633.6    0.00    0.00  1e-07    628.4    0.00    0.00  6e-08
[1,0]<stdout>:         128            32     float     sum    627.5    0.00    0.00  6e-08    632.0    0.00    0.00  6e-08
[1,0]<stdout>:         256            64     float     sum    634.5    0.00    0.00  6e-08    636.5    0.00    0.00  6e-08
[1,0]<stdout>:         512           128     float     sum    634.8    0.00    0.00  6e-08    635.2    0.00    0.00  6e-08
[1,0]<stdout>:        1024           256     float     sum    646.6    0.00    0.00  2e-07    643.6    0.00    0.00  2e-07
[1,0]<stdout>:        2048           512     float     sum    745.0    0.00    0.01  5e-07    746.0    0.00    0.01  5e-07
[1,0]<stdout>:        4096          1024     float     sum    958.2    0.00    0.01  5e-07    955.8    0.00    0.01  5e-07
[1,0]<stdout>:        8192          2048     float     sum    963.0    0.01    0.02  5e-07    954.5    0.01    0.02  5e-07
[1,0]<stdout>:       16384          4096     float     sum    955.0    0.02    0.03  5e-07    955.5    0.02    0.03  5e-07
[1,0]<stdout>:       32768          8192     float     sum    975.5    0.03    0.06  5e-07   1009.0    0.03    0.06  5e-07
[1,0]<stdout>:       65536         16384     float     sum   1353.4    0.05    0.09  5e-07   1343.5    0.05    0.09  5e-07
[1,0]<stdout>:      131072         32768     float     sum   1395.9    0.09    0.18  5e-07   1392.6    0.09    0.18  5e-07
[1,0]<stdout>:      262144         65536     float     sum   1476.7    0.18    0.33  5e-07   1536.3    0.17    0.32  5e-07
[1,0]<stdout>:      524288        131072     float     sum   1560.3    0.34    0.63  5e-07   1568.3    0.33    0.63  5e-07
[1,0]<stdout>:     1048576        262144     float     sum   1599.2    0.66    1.23  5e-07   1595.3    0.66    1.23  5e-07
[1,0]<stdout>:     2097152        524288     float     sum   1671.1    1.25    2.35  5e-07   1672.5    1.25    2.35  5e-07
[1,0]<stdout>:     4194304       1048576     float     sum   1785.1    2.35    4.41  5e-07   1780.3    2.36    4.42  5e-07
[1,0]<stdout>:     8388608       2097152     float     sum   2133.6    3.93    7.37  5e-07   2135.0    3.93    7.37  5e-07
[1,0]<stdout>:    16777216       4194304     float     sum   2650.9    6.33   11.87  5e-07   2649.9    6.33   11.87  5e-07
[1,0]<stdout>:    33554432       8388608     float     sum   3422.0    9.81   18.39  5e-07   3478.7    9.65   18.09  5e-07
[1,0]<stdout>:    67108864      16777216     float     sum   4783.2   14.03   26.31  5e-07   4782.6   14.03   26.31  5e-07
[1,0]<stdout>:   134217728      33554432     float     sum   7216.9   18.60   34.87  5e-07   7240.9   18.54   34.75  5e-07
[1,0]<stdout>:   268435456      67108864     float     sum    12738   21.07   39.51  5e-07    12802   20.97   39.31  5e-07
[1,0]<stdout>:   536870912     134217728     float     sum    24375   22.03   41.30  5e-07    24403   22.00   41.25  5e-07
[1,0]<stdout>:  1073741824     268435456     float     sum    47904   22.41   42.03  5e-07    47893   22.42   42.04  5e-07
[1,4]<stdout>:test-efa-nccl-worker-0:33:33 [4] NCCL INFO comm 0x7fd4a0000f60 rank 4 nranks 16 cudaDev 4 busId 901c0 - Destroy COMPLETE
[1,0]<stdout>:# Out of bounds values : 0 OK
[1,0]<stdout>:# Avg bus bandwidth    : 8.23785

Podemos observar en los resultados de la prueba que el rendimiento máximo es de aproximadamente 42 GB/s y el ancho de banda promedio del bus es de aproximadamente 8 GB.

También realizamos experimentos con un solo adaptador EFA habilitado y sin adaptadores EFA. Todos los resultados se resumen en la siguiente tabla.

También descubrimos que para modelos relativamente pequeños como ImageNet, el uso de redes aceleradas reduce el tiempo de entrenamiento por época solo entre un 5% y un 8% con un tamaño de lote de 64. Para modelos más grandes y tamaños de lote más pequeños, cuando se necesita una mayor comunicación de pesos en la red. , el uso de redes aceleradas tiene mayor impacto. Observamos una disminución del tiempo de entrenamiento de época con un 15-18 % para el entrenamiento de EfficientNet-B7 con tamaño de lote 1. El impacto real de EFA en su entrenamiento dependerá del tamaño de su modelo.

Monitoreo de GPU

Antes de ejecutar el trabajo de entrenamiento, también podemos configurar Reloj en la nube de Amazon Métricas para visualizar la utilización de la GPU durante el entrenamiento. Puede ser útil saber si los recursos se están utilizando de manera óptima o identificar potencialmente la falta de recursos y los cuellos de botella en el proceso de capacitación.

Los scripts relevantes para configurar CloudWatch se encuentran en la gpu-métricas carpeta. Primero, creamos una imagen de Docker con amazon-cloudwatch-agent y nvidia-smi. Podemos usar el Dockerfile en el gpu-metrics carpeta para crear esta imagen. Suponiendo que el registro ECR ya está configurado en el .env archivo del paso anterior, podemos construir y empujar la imagen usando build.sh y push.sh. Después de esto, ejecutar el deploy.sh script completa automáticamente la configuración. Lanza un daemonset con amazon-cloudwatch-agent y envía varias métricas a CloudWatch. Las métricas de la GPU aparecen debajo de la CWAgent espacio de nombres en la consola de CloudWatch. El resto de las métricas del clúster se muestran bajo el ContainerInsights espacio de nombres

Entrenamiento modelo

Todos los scripts necesarios para el entrenamiento de PyTorch se encuentran en el trabajo elastico carpeta en el repositorio de GitHub. Antes de iniciar el trabajo de entrenamiento, necesitamos ejecutar el etcd servidor, que es utilizado por el TEC para el descubrimiento de trabajadores y el intercambio de parámetros. los desplegar.sh guión en el elasticjob carpeta hace exactamente eso.

Para aprovechar EFA en instancias p4d.24xlarge, necesitamos usar una imagen de Docker específica disponible en el Galería pública de Amazon ECR que apoya la comunicación de NCCL a través de EFA. Solo necesitamos copiar nuestro código de entrenamiento en esta imagen de Docker. los Dockerfile bajo el cualquier La carpeta crea una imagen que se usará cuando se ejecute un trabajo de entrenamiento en instancias de p4d. Como siempre, podemos usar el construir.sh y empujar.sh scripts en la carpeta para construir y enviar la imagen.

El imagenet-efa.yaml El archivo describe el trabajo de entrenamiento. Este archivo .yaml configura los recursos necesarios para ejecutar el trabajo de entrenamiento y también monta el volumen persistente con los datos de entrenamiento configurados en la sección anterior.

Un par de cosas vale la pena señalar aquí. El número de réplicas debe establecerse en el número de nodos disponibles en el clúster. En nuestro caso, configuramos esto en 3 porque teníamos tres nodos p4d.24xlarge. En el imagenet-efa.yaml archivo, el nvidia.com/gpu parámetro bajo recursos y nproc_per_node bajo args debe establecerse en la cantidad de GPU por nodo, que en el caso de p4d.24xlarge es 8. Además, el argumento de trabajo para el script de Python establece la cantidad de CPU por proceso. Elegimos que sea 4 porque, en nuestros experimentos, proporciona un rendimiento óptimo cuando se ejecuta en instancias p4d.24xlarge. Estas configuraciones son necesarias para maximizar el uso de todos los recursos de hardware disponibles en el clúster.

Cuando el trabajo se está ejecutando, podemos observar el uso de GPU en CloudWatch para todas las GPU del clúster. El siguiente es un ejemplo de uno de nuestros trabajos de entrenamiento con tres nodos p4d.24xlarge en el clúster. Aquí hemos seleccionado una GPU de cada nodo. Con la configuración mencionada anteriormente, el uso de GPU está cerca del 100 % durante la fase de entrenamiento de la época para todos los nodos del clúster.

Para entrenar un modelo ResNet50 usando instancias p3.8xlarge, necesitamos exactamente los mismos pasos que se describen para el entrenamiento de EfficientNet usando p4d.24xlarge. También podemos usar la misma imagen de Docker. Como se mencionó anteriormente, las instancias p3.8xlarge no están equipadas con EFA. Sin embargo, para el modelo ResNet50, esto no es un inconveniente significativo. los imagenet-fsx.yaml El script proporcionado en el repositorio de GitHub configura el trabajo de entrenamiento con los recursos apropiados para el tipo de nodo p3.8xlarge. El trabajo utiliza el mismo conjunto de datos del sistema de archivos FSx.

Escalado de GPU

Realizamos algunos experimentos para observar cómo se escala el tiempo de entrenamiento para el modelo EfficientNet-B7 al aumentar la cantidad de GPU. Para hacer esto, cambiamos la cantidad de réplicas de 1 a 3 en nuestro archivo de entrenamiento .yaml para cada ejecución de entrenamiento. Solo observamos el tiempo de una sola época mientras usamos el conjunto de datos completo de ImageNet. La siguiente figura muestra los resultados de nuestro experimento de escalado de GPU. La línea punteada roja representa cómo debe reducirse el tiempo de entrenamiento de una carrera con 8 GPU al aumentar la cantidad de GPU. Como podemos ver, el escalado está bastante cerca de lo esperado.

De manera similar, obtuvimos el diagrama de escalado de GPU para el entrenamiento de ResNet50 en instancias p3.8xlarge. Para este caso, cambiamos las réplicas en nuestro archivo .yaml de 1 a 4. Los resultados de este experimento se muestran en la siguiente figura.

Limpiar

Es importante reducir los recursos después del entrenamiento del modelo para evitar los costos asociados con la ejecución de instancias inactivas. Con cada script que crea recursos, el Repositorio GitHub proporciona un script coincidente para eliminarlos. Para limpiar nuestra configuración, debemos eliminar el sistema de archivos FSx antes de eliminar el clúster porque está asociado con una subred en la VPC del clúster. Para eliminar el sistema de archivos FSx, solo necesitamos ejecutar el siguiente comando (desde dentro del fsx carpeta):

kubectl delete -f fsx-pvc-dynamic.yaml
./delete.sh

Tenga en cuenta que esto no solo eliminará el volumen persistente, sino que también eliminará el sistema de archivos FSx y se perderán todos los datos del sistema de archivos. Cuando se completa este paso, podemos eliminar el clúster mediante el siguiente script en el EKS carpeta:

./eks-delete.sh

Esto eliminará todos los pods existentes, eliminará el clúster y eliminará la VPC creada al principio.

Conclusión

En esta publicación, detallamos los pasos necesarios para ejecutar el entrenamiento del modelo paralelo de datos distribuidos de PyTorch en clústeres de EKS. Esta tarea puede parecer abrumadora, pero la AWS DevOps para EKS El proyecto creado por el equipo de ML Frameworks en AWS proporciona todos los scripts y herramientas necesarios para simplificar el proceso y hacer que el entrenamiento de modelos distribuidos sea fácilmente accesible.

Para obtener más información sobre las tecnologías utilizadas en esta publicación, visite Amazon EKS y Antorcha Elástico Distribuido. Lo alentamos a que aplique el enfoque descrito aquí a sus propios casos de uso de capacitación distribuida.

Recursos

Sobre los autores

imran yunus es Arquitecto Principal de Soluciones para el equipo de ML Frameworks en AWS. Se centra en cargas de trabajo de aprendizaje profundo y aprendizaje automático a gran escala en servicios de AWS como Amazon EKS y AWS ParallelCluster. Tiene amplia experiencia en aplicaciones de Deep Leaning en Visión por Computador e IoT Industrial. Imran obtuvo su doctorado en Física de Partículas de Alta Energía, donde ha estado involucrado en el análisis de datos experimentales a escalas de peta-bytes.

Alex Iankoulski es un arquitecto de software e infraestructura de pila completa al que le gusta hacer un trabajo profundo y práctico. Actualmente es arquitecto principal de soluciones para el aprendizaje automático autogestionado en AWS. En su función, se enfoca en ayudar a los clientes con la creación de contenedores y la orquestación de cargas de trabajo de ML e IA en servicios de AWS impulsados ​​por contenedores. También es el autor del código abierto. hacer marco y un capitán de Docker al que le encanta aplicar tecnologías de contenedores para acelerar el ritmo de la innovación mientras resuelve los mayores desafíos del mundo. Durante los últimos 10 años, Alex ha trabajado para combatir el cambio climático, democratizar la IA y el ML, hacer que los viajes sean más seguros, que la atención médica sea mejor y que la energía sea más inteligente.