La IA física está pasando de la investigación a la producción. Los robots se entrenan cada vez más en simulación de alta fidelidad antes de ser implementados en fábricas, almacenes y centros logísticos, porque la capacitación en el mundo real es lenta, costosa y a menudo insegura, mientras que la simulación acelerada por GPU puede comprimir meses de aprendizaje en horas.
Esto cambia el desafío de calcular. El aprendizaje por refuerzo (RL) para comportamientos complejos como la locomoción humanoide en terreno accidentado requiere un uso intensivo de computación, con ejecuciones de entrenamiento de un solo nodo que se extienden desde horas hasta días. Los equipos de robótica necesitan iterar rápidamente durante la investigación y también ejecutar trabajos de capacitación de largo plazo y de nivel de producción sin la carga operativa de mantener los clústeres de cómputo.
En esta publicación, mostramos cómo entrenar políticas de robot para el humanoide Unitree H1 con NVIDIA Isaac Lab en Amazon SageMaker AI a través de dos opciones informáticas: Amazon SageMaker HyperPod y Amazon SageMaker Training Jobs. El código completo de esta solución está disponible en el repositorio de GitHub adjunto.
Crédito de la imagen: NVIDIA
1. Por qué Amazon SageMaker AI para el entrenamiento de IA física
Amazon SageMaker AI elimina el pesado trabajo indiferenciado de administrar la infraestructura informática para la capacitación en aprendizaje automático (ML). El servicio aprovisiona instancias, configura controladores y redes, monitorea el estado de los nodos y elimina los recursos cuando finalizan los trabajos, por lo que el esfuerzo de ingeniería se concentra en desarrollar la política del robot en lugar de en la infraestructura subyacente. Esto es especialmente relevante para la política de robots RL, que requiere una gran infraestructura: las ejecuciones son largas, requieren mucha GPU y, a menudo, se distribuyen en varios nodos. El desarrollo normalmente implica dos fases: experimentos iterativos cortos para ajustar funciones de recompensa, espacios de observación y arquitecturas de modelos, y ciclos de producción más largos que entrenan una configuración sintonizada para la convergencia. SageMaker AI ofrece dos opciones informáticas que se ajustan a estas fases.
Resiliencia y control del clúster con SageMaker HyperPod
SageMaker HyperPod es una infraestructura administrada y diseñada específicamente para capacitación distribuida e inferencia de modelos básicos a gran escala. La resiliencia es el núcleo de SageMaker HyperPod. Las fallas de hardware se convierten en un problema a escala, y cada falla en una ejecución de RL de múltiples nodos significa una pérdida de progreso de capacitación más tiempo para detectar la falla, reemplazar el nodo y reiniciar desde el último punto de control. SageMaker HyperPod ejecuta un agente de supervisión del estado en cada nodo que realiza comprobaciones de estado básicas y profundas. Cuando se detecta una falla, se reinicia o reemplaza automáticamente la instancia defectuosa. Con la funcionalidad de reanudación automática, el trabajo de capacitación se reinicia desde el último punto de control después de que el nodo de reemplazo esté listo, sin intervención manual.
Orquestado con Amazon Elastic Kubernetes Service (Amazon EKS) o Slurm, HyperPod proporciona acceso directo a los nodos del clúster y un entorno estable que persiste en todas las ejecuciones. El complemento de observabilidad HyperPod publica cientos de métricas de clústeres, nodos y trabajos en Amazon Managed Service for Prometheus y las visualiza en paneles prediseñados de Amazon Managed Grafana. Los equipos obtienen utilización de GPU, presión de memoria, rendimiento de red y rendimiento a nivel de tareas sin configurar un canal de métricas. La gobernanza de tareas de HyperPod, basada en Kueue, permite a los administradores dividir el clúster en colas con ámbito de espacio de nombres con cuotas de computación, prioridades y preferencia. Las asignaciones se pueden definir por instancia, por GPU completa o por partición de GPU con NVIDIA Multi-Instance GPU (MIG). Las cuotas específicas cubren aceleradores, vCPU y memoria.
Computación efímera con trabajos de capacitación de SageMaker
Los trabajos de capacitación de SageMaker son una forma bajo demanda totalmente administrada de ejecutar cargas de trabajo de capacitación en contenedores sin mantener ningún proceso de larga duración. Cada trabajo aprovisiona instancias de GPU, extrae el contenedor de Amazon Elastic Container Registry (Amazon ECR), ejecuta el script de entrenamiento, carga artefactos en Amazon Simple Storage Service (Amazon S3) y finaliza las instancias cuando finaliza el trabajo. No hay costos de computación inactiva entre ejecuciones. Este modelo se ajusta a la fase de iteración del desarrollo de políticas, donde las funciones de recompensa, los espacios de observación y las arquitecturas de red cambian con frecuencia entre ejecuciones cortas. También es una buena opción para barridos de ajuste de hiperparámetros, donde muchas ejecuciones cortas se ejecutan en paralelo y luego liberan su cálculo.
2. NVIDIA Isaac Lab y la tarea de formación
NVIDIA Isaac Lab es un marco de aprendizaje de robots de código abierto construido sobre NVIDIA Isaac Sim. Utiliza simulación paralela de GPU para ejecutar miles de instancias de robots simultáneamente en una o varias GPU, convirtiendo lo que serían meses de experiencia del mundo real en horas de entrenamiento simulado. Isaac Lab proporciona API estructuradas para definir tareas, espacios de observación y acción, funciones de recompensa y bucles de entrenamiento tanto para el aprendizaje por refuerzo como para el aprendizaje por imitación.
Crédito de la imagen: NVIDIA
La tarea de entrenamiento de muestra en esta publicación es Isaac-Velocity-Rough-H1-v0, donde un robot humanoide Unitree H1 aprende a rastrear comandos de velocidad mientras camina por terreno accidentado. El robot debe coordinar sus 19 articulaciones para mantener el equilibrio sobre superficies irregulares generadas por procedimientos. La capacitación utiliza la optimización de políticas próximas (PPO) a través de skrl, uno de los varios marcos de RL admitidos por Isaac Lab. La ampliación a múltiples nodos multiplica la cantidad de entornos paralelos, lo que produce una experiencia más diversa por actualización de políticas y acelera la convergencia. Puede ampliar los scripts y la configuración proporcionados en esta solución a otras tareas de aprendizaje de robots.
3. Descripción general de la solución
La solución en el repositorio de GitHub adjunto consta de dos partes principales: (1) una única imagen de Docker que ejecuta el código de entrenamiento tanto en SageMaker HyperPod como en SageMaker Training Jobs, y (2) un script generador que representa los manifiestos de Kubernetes y el script de inicio de SageMaker desde un archivo de configuración compartido. Las dos opciones de servicio solo difieren en cómo se inicia la imagen: como Kubernetes PyTorchJob en SageMaker HyperPod o mediante una llamada a la API CreateTrainingJob para un trabajo de capacitación de SageMaker.
La tarea de locomoción H1 utilizada aquí es la misma que en el taller de NVIDIA Isaac Lab en AWS, que ejecuta la carga de trabajo en Amazon Elastic Compute Cloud (Amazon EC2) y AWS Batch. Pasar a SageMaker AI mantiene el código de capacitación sin cambios y agrega clústeres administrados, recuperación de fallas integrada y ejecución de trabajos de capacitación sin servidor.
Imagen de entrenamiento
La imagen del contenedor de entrenamiento se crea a partir de nvcr.io/nvidia/isaac-sim:5.1.0. El Dockerfile proporcionado clona Isaac Lab v2.3.2, lo instala en el entorno Python incluido de Isaac Sim y lo copia en el script de punto de entrada que analiza la configuración del recurso SageMaker Training Jobs para iniciar torchrun. El Dockerfile completo está en Docker/Dockerfile. Ambas opciones de servicio utilizan la misma imagen.
Seguimiento de experimentos
Las métricas de capacitación se transmiten a MLflow administrado por Amazon SageMaker para un seguimiento de experimentos persistente y con capacidad de búsqueda en ambos backends cuando se configura un servidor de seguimiento. MLflow es opcional: deje el URI de seguimiento vacío para deshabilitarlo por completo. La sección 4.5 cubre la configuración.
Configuración y script del generador.
El script del generador se configura a través de variables específicas del entorno definidas en config.yaml. El script generate.py lee la configuración y procesa las plantillas en templates/ en archivos listos para aplicar en generate/.
Ejecutar el generador es un solo comando:
Los archivos específicos utilizados por cada backend se tratan en los tutoriales de la Sección 4 y la Sección 5 para SageMaker HyperPod y SageMaker Training Jobs, respectivamente.
Topología de entrenamiento en backends
En la solución proporcionada, ambas rutas terminan con la misma invocación de torchrun del entrenador skrl de Isaac Lab en la misma imagen. La principal diferencia es cómo cada entorno proporciona la topología al contenedor. En SageMaker HyperPod, el operador de capacitación de Kubeflow inyecta MASTER_ADDR, MASTER_PORT, RANK y WORLD_SIZE en cada pod. Estos describen la topología a nivel de pod (WORLD_SIZE es el recuento de pods, RANK es el índice por pod). El punto de entrada los reenvía a torchrun, que genera un proceso por GPU dentro de cada pod. Los lanzadores por pod se encuentran a través de MASTER_ADDR:MASTER_PORT para formar el grupo de procesos global. En los trabajos de capacitación de SageMaker, SageMaker escribe la lista de hosts en /opt/ml/input/config/resourceconfig.json y el punto de entrada del contenedor la analiza al inicio.
Compatibilidad de instancias de GPU
Isaac Sim se basa en NVIDIA Omniverse y utiliza Omniverse RTX Renderer, que requiere GPU con núcleos RT de hardware. La familia G de instancias de GPU de AWS es adecuada para las cargas de trabajo de Isaac Lab. La familia P no lo es, porque utiliza GPU de centro de datos sin RT Cores. Consulte la página de requisitos de Isaac Sim 5.1 para obtener la lista completa de hardware compatible y no compatible.
Familia de instancias Tipo y generación de GPU Compatibilidad RT Cores / Isaac Sim ml.g5 NVIDIA A10G (Ampere) Sí ml.g6 NVIDIA L4 (Ada Lovelace) Sí ml.g6e NVIDIA L40S (Ada Lovelace) Sí ml.g7e NVIDIA RTX PRO 6000 (Blackwell) Sí ml.p4d, ml.p4de, ml.p5, ml.p5e, ml.p5en, ml.p6-b200, ml.p6-b300, ml.p6e-gb200 NVIDIA A100 (Amperios), H100/H200 (Hopper), B200/B300/GB200 (Blackwell) No
Los ejemplos de esta publicación utilizan ml.g6.12xlarge en todas partes. Puede cambiar el tipo de instancia en config.yaml. Las familias ml.g6, ml.g6e y ml.g7e admiten Elastic Fabric Adapter (EFA) en tamaño 8xlarge y superiores, lo que proporciona a NCCL un transporte compatible con RDMA y bypass de kernel para colectivos de múltiples nodos. Habilitar EFA en HyperPod requiere el complemento de dispositivo AWS EFA y solicitar recursos vpc.amazonaws.com/efa en la especificación del pod. En los trabajos de formación de SageMaker, debe configurar EFA en la imagen del contenedor y en la configuración de la nube privada virtual (VPC). EFA se configura automáticamente a través de la solución para los backends de SageMaker HyperPod y SageMaker Training Jobs. La configuración del trabajo de capacitación de SageMaker se encuentra en la documentación.
Configuración: clonar el repositorio y crear la imagen
Ambos tutoriales comparten dos pasos de configuración: clonar el repositorio adjunto y crear la imagen de entrenamiento.
Clona el repositorio de la solución:
El repositorio contiene el Dockerfile, la plantilla de configuración, el generador y los scripts de punto de entrada utilizados por ambos backends.
Cree la imagen desde la raíz del repositorio y envíela a Amazon ECR.
Defina las variables de entorno según su configuración:
Compruebe si existe el repositorio ECR correspondiente y, en caso contrario, créelo:
Autenticar con Amazon ECR:
Cree y etiquete la imagen de Docker:
Envíe la imagen de Docker a Amazon ECR:
Si en su lugar desea utilizar Trabajos de capacitación, vaya a la Sección 5.
4. Tutorial: capacitación sobre SageMaker HyperPod con Amazon EKS
Para este tutorial, utilizamos un clúster SageMaker HyperPod existente orquestado por Amazon EKS, con un grupo de instancias de GPU de dos nodos ml.g6.12xlarge (4× NVIDIA L4 cada uno, 8 GPU en total). El objetivo es un trabajo de entrenamiento distribuido para la tarea de locomoción H1, con métricas en vivo en MLflow administrado por SageMaker y los puntos de control resultantes escritos en FSx para Lustre.
4.1 Requisitos previos
La solución requiere que se cumplan los siguientes requisitos previos:
Cuota de servicio suficiente para el clúster y el tipo de instancia de GPU elegido en la región de destino. Los clústeres de HyperPod consumen la cuota correspondiente de ml.g6.* (u otra familia de GPU) para SageMaker HyperPod. Solicite un aumento a través de las cuotas de servicio de AWS antes de crear o escalar el clúster. Un clúster de SageMaker HyperPod orquestado por Amazon EKS con un grupo de instancias de GPU de dos nodos ml.g6.12xlarge. Consulte Creación de un clúster de SageMaker HyperPod con orquestación de Amazon EKS. kubectl configurado en el clúster y el operador de capacitación de Kubeflow instalado en él para que se reconozcan los recursos personalizados de PyTorchJob. El controlador CSI de FSx for Lustre instalado y un sistema de archivos de Amazon FSx for Lustre en la misma VPC y subred que los nodos HyperPod. Este sistema de archivos almacena los registros y puntos de control escritos por el trabajo de capacitación.
4.2 Configurar y generar manifiestos
Copie la configuración de ejemplo:
Complete los valores de su entorno y el ID de cuenta de AWS, la región y los detalles del clúster:
Los campos de configuración importantes incluyen los siguientes:
aws, ecr: se utilizan para formar el URI de la imagen del contenedor (.dkr.ecr..amazonaws.com/:) al que hace referencia cada pod y trabajo de capacitación. Puede establecer un URI explícito a través de hyperpod_eks.image como anulación. Training.task: el identificador de tareas de Isaac Lab. Puede seleccionar una tarea de locomoción o manipulación diferente cambiando este valor. Training.max_iterations: el número de iteraciones de PPO. Para una prueba de humo es suficiente un valor de 1000. Las tiradas de producción para H1 en terreno accidentado normalmente requieren un orden de magnitud más. hyperpod_eks.fsx: ID del sistema de archivos, nombre DNS y nombre de montaje del sistema de archivos FSx for Lustre. Estos valores están disponibles desde la consola FSx o el comando aws fsx describe-file-systems. jobs.training_job.fsx_log_dir: el directorio en FSx donde se escriben los registros de entrenamiento y los puntos de control.
Genere los manifiestos ejecutando el script:
Los siguientes manifiestos de Kubernetes se generan y utilizan en las siguientes partes del tutorial:
Archivo generado Qué es Cuándo aplicar Storage.yaml PersistentVolume y PersistentVolumeClaim que se vinculan a su sistema de archivos FSx for Lustre, exponiéndolo a pods en /fsx. Una vez por grupo. Training-job.yaml Kubeflow PyTorchJob con una réplica maestra y num_nodes: 1 réplicas de trabajador. Se ejecuta en un nodo cuando num_nodes: 1 y en varios nodos en caso contrario. Por carrera de entrenamiento. viz-eks-webrtc-pod.yaml Pod que ejecuta Isaac Sim en modo de transmisión sin cabeza junto con un cliente WebRTC basado en navegador, para visualizar políticas entrenadas. Opcional. Cubierto en la Sección 6.
El archivo restante, launch-sm-training.py, se trata en el tutorial de Trabajos de capacitación de SageMaker (Sección 5).
4.3 Implementar almacenamiento compartido
FSx for Lustre es la capa de almacenamiento para este tutorial. Proporciona escrituras paralelas de alto rendimiento que manejan puntos de control de múltiples pods sin obstaculizar el ciclo de entrenamiento y permite que el trabajo de entrenamiento y el pod de visualización utilicen el mismo volumen.
El archivo generado/storage.yaml contiene un PersistentVolume y un PersistentVolumeClaim que apuntan a su sistema de archivos FSx. Aplícalo a tu clúster:
4.4 Iniciar la formación
El archivo generado/training-job.yaml es un PyTorchJob de Kubeflow con una réplica maestra y num_nodes – 1 réplicas de trabajador. Con el valor predeterminado jobs.training_job.num_nodes: 2 en config.yaml, se ejecuta en dos nodos ml.g6.12xlarge (8 GPU en total). La configuración de num_nodes: 1 produce un trabajo de un solo nodo sin réplicas de trabajador.
Cuando comienza el trabajo, el operador de capacitación de Kubeflow inyecta las variables de entorno distribuido estándar de PyTorch (MASTER_ADDR, MASTER_PORT, RANK, WORLD_SIZE) en cada pod. El script de lanzamiento del contenedor los pasa a torchrun, que maneja el encuentro y la configuración del grupo de procesos:
Aplicar el manifiesto:
Observe el estado del trabajo:
Los primeros registros muestran que cada pod imprime su rango, la dirección maestra y la salida de nvidia-smi. Después de que los trabajadores se conectan al maestro, Isaac Lab carga la escena (lo que demora uno o dos minutos la primera vez en cada nodo mientras se calientan los cachés de activos), genera entornos paralelos en todas las GPU disponibles y comienza a registrar métricas de pérdida de valor y recompensa cada pocos segundos. El punto de entrada imprime la topología a nivel de pod inyectada por Kubeflow antes de pasarla a torchrun.
El manifiesto de entrenamiento también verifica que FSx tenga un best_agent.pt existente al inicio. Si se encuentra uno de una ejecución anterior, pasa –checkpoint a train.py para que el entrenamiento se reanude desde ese punto en lugar de comenzar desde cero. Un reinicio del pod o un reemplazo de nodo desencadenado por el monitoreo del estado de HyperPod continúa automáticamente desde el último punto de control.
=== Información del nodo maestro === Nombre de host: isaaclab-h1-master-0 MASTER_ADDR: isaaclab-h1-master-0 WORLD_SIZE: 2 RANK: 0 GPU 0: NVIDIA L4 (UUID: GPU-dd5102c3-be08-…) GPU 1: NVIDIA L4 (UUID: GPU-3c0d70fe-519f-…) GPU 2: NVIDIA L4 (UUID: GPU-42485aa5-6a2a-…) GPU 3: NVIDIA L4 (UUID: GPU-18f62bef-4155-…) === Maestro inicial (2 nodos, 8 GPU en total, 1000 iteraciones) === … [INFO][AppLauncher]: Uso del dispositivo: cuda:0 [INFO]: Administrador de escenas: Número de entornos: 4096 Espaciado de entornos: 2.5 [INFO]: Tiempo necesario para la creación de la escena: 16,30 segundos 10%|▉ | 118/24000 [00:09<01:02, 17.21it/s] …
Aquí WORLD_SIZE: 2 es el recuento de pods, no el recuento de procesos globales. torchrun genera 8 procesos en total (4 por pod en 2 pods) después de que comienza, y dentro de esos procesos WORLD_SIZE se convierte en 8.
4.5 Seguimiento de experimentos con MLflow administrado por SageMaker
Las métricas de entrenamiento, los parámetros de ejecución (tarea, iteraciones, semilla) y el directorio del punto de control final se reenvían a MLflow administrado por Amazon SageMaker para un almacén de experimentos persistente y con capacidad de búsqueda. Las métricas del sistema, como la utilización de GPU y el uso de CPU/memoria, se muestrean mediante el propio subproceso en segundo plano de MLflow.
Habilitar MLflow es una opción. Cuando MLFLOW_TRACKING_URI está vacío (el valor predeterminado), el script de entrenamiento omite todas las llamadas de MLflow. Establezca el URI de seguimiento y el nombre del experimento en config.yaml:
Regenerar los manifiestos y relanzar el trabajo de entrenamiento. Los registros del módulo de entrenamiento imprimen la URL de ejecución unos segundos después del inicio:
INFORMACIÓN mlflow.tracking.fluent: El experimento con el nombre 'isaaclab-h1' no existe. Creando un nuevo experimento. INFORMACIÓN mlflow.system_metrics.system_metrics_monitor: Se inició el seguimiento de las métricas del sistema. … Ver ejecución 2026-04-27_18-59-29_ppo_torch en: https://mlflow.sagemaker.us-east-2.app.aws/#/experiments/1/runs/ Ver experimento en: https://mlflow.sagemaker.us-east-2.app.aws/#/experiments/1
Cuando se completa la ejecución, MLflow cierra el subproceso de métricas del sistema y aparece la línea Tiempo de entrenamiento: de skrl:
Tiempo de entrenamiento: 91,9 segundos INFORMACIÓN mlflow.system_metrics.system_metrics_monitor: Deteniendo el monitoreo de métricas del sistema… INFORMACIÓN mlflow.system_metrics.system_metrics_monitor: ¡Se finalizó exitosamente el monitoreo de métricas del sistema!
Abra la URL o navegue hasta la interfaz de usuario de MLflow desde SageMaker Studio para ver las curvas de recompensa y la actualización de la pérdida de valor en vivo junto con la utilización de la GPU.
Existen dos modelos de autorización para MLflow administrado por SageMaker:
Servidor de seguimiento de MLflow (arn:aws:sagemaker:::mlflow-tracking-server/): las acciones de IAM bajo el prefijo de servicio sagemaker-mlflow rigen el acceso. Asigne el rol de capacitación sagemaker-mlflow:* en el recurso del servidor de seguimiento. Aplicación Studio MLflow (arn:aws:sagemaker:::mlflow-app/): la aplicación está vinculada a un perfil de usuario de Studio y autoriza a las personas que llaman a través de esa función de ejecución de Studio. Los trabajos de capacitación se ejecutan bajo una función diferente, por lo que deben asumir la función de ejecución de Studio antes de cada llamada de MLflow. Establezca asumir_role_arn en el ARN del rol de Studio. El generador lo pasa como SAGEMAKER_MLFLOW_ASSUME_ROLE_ARN y el complemento sagemaker-mlflow maneja la llamada sts:AssumeRole en cada solicitud. Actualice la política de confianza del rol de ejecución de Studio para que el rol de capacitación pueda asumirla y adjunte sts:AssumeRole al rol de capacitación.
5. Tutorial: capacitación sobre trabajos de capacitación de SageMaker
Los trabajos de formación de SageMaker ejecutan la misma imagen durante un ciclo de vida diferente. Cada trabajo aprovisiona las instancias de GPU solicitadas, extrae la imagen de Amazon ECR, ejecuta el punto de entrada, carga todos los archivos que el script de entrenamiento copió en /opt/ml/model/ a la ruta de salida de S3 y finaliza las instancias.
5.1 Requisitos previos
Cuota de servicio suficiente para el clúster y el tipo de instancia de GPU elegido en la región de destino. Los trabajos de formación de SageMaker consumen la cuota correspondiente de ml.g6.* (u otra familia de GPU) para los trabajos de formación de SageMaker. Solicite un aumento a través de las cuotas de servicio de AWS antes de crear o escalar el clúster. Una función de IAM que SageMaker puede asumir para el trabajo de capacitación, con permisos para extraer datos de su repositorio de Amazon ECR, leer el punto de entrada de su depósito de S3 y escribir artefactos en Amazon S3. Consulte la documentación del rol de ejecución de SageMaker. Un depósito de S3 para el script de punto de entrada (entrada) y los artefactos de entrenamiento (salida). La misma imagen de Amazon ECR incluida en la Sección 3. No es necesaria ninguna reconstrucción. boto3 instalado localmente (pip install boto3).
5.2 Configurar
La sección Trabajos de capacitación de config.yaml captura la función de ejecución, el tipo y el recuento de instancias y la ubicación de salida. Los scripts S3 URI y la ruta de salida S3 se derivan automáticamente del valor s3.bucket de nivel superior cuando se dejan vacíos.
Los campos de configuración importantes incluyen los siguientes:
role_arn: el rol de IAM que asume SageMaker para el trabajo. El rol debe tener ecr:BatchGetImage, s3:GetObject en la ruta de los scripts y s3:PutObject en la ruta de salida. instancia_count: la cantidad de instancias que utiliza el trabajo. Cuando configura esto en más de uno, SageMaker inicia un trabajo de múltiples nodos y completa el archivo Resourceconfig.json en cada instancia con la lista de hosts. El punto de entrada del contenedor lee este archivo para derivar su rango y la dirección maestra, por lo que se reutiliza el mismo script de entrenamiento sin modificaciones.
5.3 Cargar el punto de entrada
SageMaker extrae el script del punto de entrada de Amazon S3 en cada instancia de capacitación en el momento de inicio del trabajo. Súbelo una vez. Cada trabajo posterior se lee desde la misma ubicación hasta que se carga una nueva versión. Reemplace el nombre del depósito con el depósito de Amazon S3 elegido:
5.4 Generar y lanzar
La ejecución de python generate.py produce un script launch-sm-training.py en generate/ con el URI de imagen, la función de IAM, las rutas de S3 y la configuración de instancia previamente completadas desde config.yaml. El script expone una pequeña CLI para valores que puede anular entre ejecuciones:
El iniciador llama a CreateTrainingJob con un nombre de trabajo con sufijo de marca de tiempo, la imagen de Amazon ECR y la ubicación del punto de entrada de S3. También pasa por las variables de entorno de Isaac Sim que requiere el contenedor (ACCEPT_EULA, NVIDIA_VISIBLE_DEVICES=all, MAX_ITERACIONES, entre otras). Si tiene éxito, imprime el nombre del trabajo y un comando describe-training-job para monitorear el progreso.
5.5 Monitorear
El campo SecondaryStatus avanza a través de Pendiente → Descargando → Entrenamiento → Cargando → Completado:
Los registros de capacitación se transmiten a Amazon CloudWatch Logs en el grupo de registros /aws/sagemaker/TrainingJobs, con una secuencia de registros por instancia. La consola de SageMaker enlaza directamente desde la página del trabajo a la transmisión si prefiere una interfaz de usuario. Una transmisión exitosa de rango 0 comienza con la autoprueba del punto de entrada:
=== Trabajo de capacitación de SageMaker === Nombre de host: ip-10-0-195-224.us-east-2.compute.internal GPU 0: NVIDIA L4 (UUID: GPU-66e3a452-…) GPU 1: NVIDIA L4 (UUID: GPU-a075bb9c-…) GPU 2: NVIDIA L4 (UUID: GPU-2ba15062-…) GPU 3: NVIDIA L4 (UUID: GPU-e25c05a4-…) === Configuración de recursos === {"current_host":"algo-1","hosts":["algo-1","algo-2"],"network_interface_name":"eth0"} === Configuración de entrenamiento === CURRENT_HOST=algo-1 MASTER_HOST=algo-1 NNODES=2 NODE_RANK=0 NPROC=4 MAX_ITERACIONES=1000 === Iniciando el entrenamiento Isaac Lab H1 ===
Cuando finaliza el trabajo, SageMaker empaqueta cualquier punto de entrada copiado en /opt/ml/model/ como model.tar.gz y lo carga en la ruta de salida S3. Para H1, el archivo contiene el directorio skrl logs/ con los puntos de control de entrenamiento y best_agent.pt.
Cuando configura sagemaker_training.checkpoint_s3_path en config.yaml, el iniciador incluye un CheckpointConfig que le indica a SageMaker que sincronice continuamente /opt/ml/checkpoints con Amazon S3 durante el entrenamiento. El punto de entrada vincula simbólicamente el directorio de registro de skrl a esa ruta, por lo que cada punto de control escrito por skrl se respalda en Amazon S3 casi en tiempo real. Si el trabajo falla o se interrumpe, reiniciarlo con el mismo checkpoint_prefix restaura el último punto de control y reanuda el entrenamiento automáticamente.
La misma integración de MLflow descrita en la Sección 4.5 se aplica a los trabajos de capacitación. Cuando configura mlflow.tracking_uri, el launch-sm-training.py generado reenvía las variables de entorno de MLflow al contenedor de entrenamiento como parte de la solicitud CreateTrainingJob y el código de entrenamiento escribe métricas en el mismo experimento. Para las aplicaciones Studio MLflow, la función de ejecución del trabajo de capacitación debe figurar en la política de confianza de la función de ejecución de Studio y tener sts:AssumeRole en sus propios permisos.
6. Visualizar políticas capacitadas
El repositorio proporciona un módulo de visualización para SageMaker HyperPod que transmite la GUI de Isaac Sim directamente a un navegador a través de WebRTC, utilizando el mismo volumen FSx que los trabajos de entrenamiento para que se pueda reproducir cualquier punto de control producido en HyperPod.
Transmisión WebRTC en el clúster HyperPod
Isaac Sim incluye transmisión WebRTC sin cabeza incorporada. El pod de visualización incluye dos contenedores que comparten la red del pod:
isaacsim: la imagen de entrenamiento, iniciada con el script skrl play.py en modo de transmisión en vivo. Carga el best_agent.pt más reciente desde el directorio de registro de FSx, ejecuta la tarea con 25 entornos paralelos y transmite la ventana gráfica a través de WebRTC (señalización en TCP 49100, medios en UDP 47998). web-viewer: un nodo estándar:22-slim que estructura el cliente WebRTC de NVIDIA desde @nvidia/create-ov-web-rtc-app, lo apunta al contenedor Isaac Sim en 127.0.0.1 y lo sirve en TCP 8210.
El módulo de visualización se ejecuta en un nodo GPU en el mismo clúster y monta el volumen FSx utilizado por los trabajos de entrenamiento, de modo que los puntos de control producidos por una ejecución de HyperPod estén directamente disponibles para su reproducción. El manifiesto lo representa generate.py en generate/viz-eks-webrtc-pod.yaml junto con los manifiestos de entrenamiento:
La conectividad necesita un paso adicional: el reenvío de puertos kubectl solo admite TCP, pero los medios WebRTC requieren UDP. krelay es un complemento de kubectl que agrega reenvío UDP. Instálelo con el siguiente comando:
Inicie el reenvío de puertos ejecutando los siguientes comandos:
El navegador se conecta al sidecar del visor web, que negocia una sesión WebRTC con el contenedor Isaac Sim y muestra la ventana gráfica en vivo. Para reproducir un punto de control diferente, edite los argumentos del contenedor isaacsim en el manifiesto del pod de visualización (o elimine el pod y regenere después de actualizar Training.task en config.yaml).
Para implementaciones accesibles para el equipo, reemplace la retransmisión local con un AWS Network Load Balancer que exponga los puertos TCP y UDP, y establezca el indicador publicIp de Isaac Sim en la dirección pública de NLB.
El módulo de visualización proporcionado es específico de skrl. Si cambia el marco en config.yaml, actualice la ruta del punto de control y reproduzca el script en consecuencia.
Alternativa: Amazon EC2 con NICE DCV
Si es preferible un escritorio Linux completo a un visor basado en navegador (por ejemplo, para ejecutar Isaac Sim junto con terminales y un navegador de archivos), el taller de NVIDIA Isaac Lab en AWS explica cómo configurar una instancia de GPU Amazon EC2 independiente con NICE DCV y ejecutar la misma imagen de Isaac Lab de forma interactiva a través de streaming de escritorio remoto de baja latencia. Los puntos de control generados por los trabajos de SageMaker en esta publicación se pueden reproducir en esa instancia montando el sistema de archivos FSx o descargándolos desde el depósito S3.
7. Consideraciones de costos y limpieza
Las dos opciones de cálculo tienen formas de costos diferentes. SageMaker HyperPod es un clúster persistente: las instancias se facturan mientras forman parte del clúster. FSx for Lustre factura por hora por capacidad aprovisionada, y el módulo de visualización de la Sección 6 mantiene un nodo GPU mientras esté en ejecución. Los trabajos de capacitación de SageMaker facturan solo por el tiempo de ejecución de cada trabajo. Consulte las páginas de precios de SageMaker AI y FSx for Lustre para conocer las tarifas actuales.
7.1 Limpiar
HiperPod SageMaker
Escale el grupo de instancias de GPU a cero entre sesiones para pausar los costos de las instancias mientras mantiene el clúster configurado, o elimine el clúster por completo. Consulte Administrar un clúster de SageMaker HyperPod.
Al eliminar el sistema de archivos FSx, se eliminan permanentemente todos los puntos de control y registros de entrenamiento almacenados en él. Descargue los puntos de control que desee conservar antes de continuar.
Trabajos de formación de SageMaker
Los trabajos de capacitación finalizan automáticamente cuando el trabajo se completa o falla. No se requiere limpieza informática.
Los siguientes comandos eliminan permanentemente artefactos de entrenamiento y puntos de control. Descargue los archivos que desee conservar antes de ejecutarlos.
ECR de Amazon
8. Conclusión
A medida que las cargas de trabajo de IA física pasan a producción, los equipos necesitan escalar la capacitación en políticas sin la sobrecarga operativa de administrar la infraestructura informática. En esta publicación, mostramos cómo SageMaker HyperPod y SageMaker Training Jobs permiten a los equipos de robótica ejecutar capacitación distribuida de Isaac Lab en una infraestructura de GPU administrada, utilizando una única imagen de contenedor y una configuración compartida en ambos modelos informáticos.
SageMaker HyperPod ofrece clústeres de GPU persistentes con entrenamiento resistente y de larga duración. Los trabajos de formación de SageMaker ofrecen ejecuciones efímeras bajo demanda adecuadas para experimentos y barridos de hiperparámetros. Ambos ejecutan la misma imagen de contenedor y la misma invocación de torchrun del entrenador skrl, por lo que cambiar entre ellos es solo un cambio de configuración.
Para comenzar, explore el repositorio adjunto para iniciar su primera ejecución de entrenamiento H1 y extender el patrón a otras tareas de Isaac Lab (manipulación humanoide, cuadrúpedos, manos diestras). Para obtener más información, consulte la documentación de Amazon SageMaker HyperPod y la documentación de Amazon SageMaker Training Jobs.
Sobre los autores
Roy Allela
Roy es arquitecto senior de soluciones especializado en IA/ML en AWS. Ayuda a los clientes de AWS, desde nuevas empresas hasta grandes empresas, a entrenar e implementar modelos básicos de manera eficiente en AWS. Tiene experiencia en ingeniería de microprocesadores y le apasionan los problemas de optimización computacional y la mejora del rendimiento de las cargas de trabajo de IA.
Nicolás Jourdan
Nicolas es arquitecto de soluciones especializado en AWS, donde ayuda a los clientes a desbloquear todo el potencial de la IA y el aprendizaje automático en la nube. Nicolas tiene una amplia experiencia práctica en distintos sectores, incluidos la conducción autónoma, los drones y la fabricación, y ha trabajado en puestos que van desde científico investigador hasta director de ingeniería. Ha contribuido a investigaciones galardonadas, posee patentes en detección de objetos y anomalías, y le apasiona aplicar IA de vanguardia para resolver problemas complejos del mundo real.