Cómo montar una fábrica de modelos Physical AI con NVIDIA Cosmos 3 y SageMaker HyperPod

Por qué una fábrica de modelos para Physical AI

Sistemas Physical AI —robots, vehículos autónomos y otros agentes que traducen datos del mundo real en acciones físicas— no se construyen con un único entrenamiento. Requieren un pipeline continuo: generación de datos sintéticos, post-entrenamiento de modelos de percepción y política, y evaluación en simulación cerrada. Poner a correr ese loop de forma sostenida es lo que entendemos por una “fábrica de modelos”: convertir un flujo de datos reales en mejoras iterativas de los modelos.

Este artículo explica cómo combinar el modelo de mundo omnimodal NVIDIA Cosmos 3 con Amazon SageMaker HyperPod y Amazon EKS para operar una fábrica de modelos Physical AI, describiendo la arquitectura del modelo, su encaje operativo en SageMaker HyperPod y consideraciones prácticas de infraestructura y costo.

Qué aporta NVIDIA Cosmos 3

Cosmos 3 es un modelo de base open-source orientado a tareas físicas: trata video, imagen, acción y sonido como una única secuencia de tokens. Eso le permite cubrir tres tareas clave en un pipeline Physical AI con una sola familia de modelos: generación sintética (mundo hacia adelante), etiquetado de acciones (mundo inverso) y una política ejecutable.

Tres decisiones arquitectónicas claves lo distinguen:

• Un solo flujo de tokens: todas las modalidades (texto, visión, audio, acciones) se integran en una secuencia compartida. Cada modalidad tiene su propio encoder —ViT para entendimiento de imágenes y un VAE de video congelado para generación de píxeles— y un vector de acción compacto por embodiment que permite controlar desde un vehículo hasta un brazo robótico.

• Mixture-of-Transformers con atención por capa (MoT): cada capa ejecuta dos expertos enlazados por atención dual: un “reasoner” que predice tokens autoregresivos y un “generator” que realiza el denoising para video, audio y acciones. La atención por capa mantiene la generación anclada al razonamiento a lo largo de toda la arquitectura.

• Asimetría entre entrenamiento e inferencia: durante el entrenamiento se completa el calendario de denoising y se decodifica video porque la predicción de video está en la función de pérdida. En inferencia para el robot se ejecutan pocos pasos de denoise y se omite la decodificación de video; los latentes de video se producen internamente para anclar la acción, pero solo se decodifican los tokens de acción hacia las posiciones conjuntas.

NVIDIA publicó Cosmos 3 bajo la licencia OpenMDW-1.1 y describe la arquitectura en su informe técnico. El diseño hace que generación, post-entrenamiento y evaluación puedan ser tratados como tres modos de trabajo del mismo modelo, en lugar de tres infraestructuras distintas.

Por qué SageMaker HyperPod y EKS encajan naturalemente

En pipelines tradicionales de Physical AI es común provisionar conjuntos de GPU separados para cada etapa (generación, post-entrenamiento y evaluación). Eso genera ciclos de levantar y derribar nodos y problemas de disponibilidad de capacidad en distintas regiones o zonas.

Cosmos 3 permite consolidar esas cargas en una sola piscina persistente de GPUs: un clúster gestionado por Amazon EKS y orquestado por SageMaker HyperPod que ejecuta los tres modos como workloads que comparten la misma infraestructura. En vez de pools separados, se usa capacidad time-shared bajo un único plano de control, lo que simplifica operaciones y reduce la variabilidad operacional.

Además, SageMaker HyperPod facilita desplegar nodos GPU, gestionar scheduling y escalar dentro de un clúster EKS, mientras una capa de almacenamiento compartido multi-terabyte aloja datos sintéticos, checkpoints y snapshots para las distintas etapas del loop.

Componentes operativos: clúster, almacenamiento y trabajos distribuidos

El patrón operativo mostrado en la referencia incluye:

• Un clúster EKS gestionado con un pool persistente de nodos GPU. Ese pool ejecuta las distintas etapas del pipeline según demanda, aprovechando que Cosmos 3 es la misma arquitectura para generar y para controlar.

• Una capa de almacenamiento compartido de varios terabytes para datasets sintéticos, checkpoints y artefactos de post-entrenamiento. El acceso centralizado evita la duplicación costosa de datos entre Availability Zones.

• Manifiestos y plantillas de infraestructura que automatizan la creación de jobs distribuidos para las tres cargas representativas: generación de video sintético, post-entrenamiento de percepción/política y evaluación en simulación.

El repositorio awsome-distributed-ai contiene los manifiestos y archivos de configuración usados en esta integración, incluyendo plantillas de infraestructura y ejemplos ejecutables. También se presenta un walkthrough end-to-end del stage de robot-policy usando el dataset público DROID.

Un ejemplo práctico: post-entrenamiento y el dataset DROID

La integración mostró un caso concreto de post-entrenamiento para el componente de política de un robot utilizando el dataset público DROID. El flujo completo cubre cómo ejecutar jobs distribuidos que toman un checkpoint base de Cosmos 3, especializan el modelo a una modalidad (por ejemplo, acción) y ajustan la frecuencia de control para despliegue en el agente físico.

Al usar un único checkpoint de base mid-trained y cambiar qué tokens inician como ruido, es posible correr tres modos distintos: forward dynamics (mundo hacia adelante), inverse dynamics (etiquetado de acción) y la política desplegable. El post-entrenamiento especializa el checkpoint para el modo y la frecuencia de control deseada.

Costos operativos: compromiso de capacidad y GPU goodput

Operar este loop continuamente es un compromiso de capacidad. Comprar GPUs etapa por etapa introduce variabilidad —tiempos de disponibilidad y diferencias entre zonas o regiones— que pueden romper la continuidad del pipeline. Reservar capacidad para todo el loop o definir planes de entrenamiento flexibles para campañas limitadas reduce esa fricción.

Importante: cuando se reserva capacidad, el costo no se mide por el throughput pico de un job aislado, sino por la GPU goodput: el progreso útil del pipeline por hora-GPU reservada en el conjunto del loop. Consolidar las cargas en una piscina persistente y time-shared suele aumentar la goodput frente a tener pools separados que pasan tiempo inactivos entre etapas.

Qué significa esto para equipos en América Latina

Para equipos y empresas en América Latina, la propuesta tiene varias implicaciones prácticas:

• Simplificación operativa: menos ciclos de levantar/derribar nodos y menos riesgo de quedar a la espera de capacidad en otra región.

• Eficiencia de costo: mejorar la GPU goodput reduce el costo efectivo por iteración del pipeline, algo crítico cuando los presupuestos de cómputo son limitados.

• Acceso al ecosistema: usar SageMaker HyperPod y EKS permite alinearse con prácticas de nube gestionada que facilitan la adopción en equipos con experiencia operativa en AWS.

Sin embargo, conviene evaluar la disponibilidad de capacidad GPU en la región AWS local y considerar estrategias de despliegue híbrido o multi-región si la latencia hacia laboratorios o robots físicos lo exige.

Conclusión y próximos pasos

Combinar NVIDIA Cosmos 3 con SageMaker HyperPod y EKS ofrece un camino operativo claro para ejecutar una fábrica de modelos Physical AI: un mismo modelo cubre generación, post-entrenamiento y evaluación; una piscina persistente de GPUs reduce la fricción operativa; y las plantillas y manifiestos reproducibles permiten desplegar el loop de forma consistente.

Si están evaluando implementar un pipeline de este tipo, revisen el repositorio awsome-distributed-ai para los manifiestos y ejemplos, prueben el walkthrough con el dataset DROID para validar la etapa de política, y consideren métricas de GPU goodput al diseñar su estrategia de capacidad.