Ray en SageMaker HyperPod: Simplificando entrenamiento y serving de modelos a escala
Amazon anuncia nuevas capacidades que integran Ray con SageMaker HyperPod, permitiendo crear y operar clusters Ray desde SageMaker Studio. La integración reduce la carga operativa y habilita tolerancia a fallos y checkpointing por niveles para entrenamientos grandes.
Qué anuncia AWS y por qué importa
AWS presentó nuevas capacidades que integran Ray con SageMaker HyperPod, conectando el framework open-source Ray con la infraestructura diseñada para entrenar y servir modelos fundacionales en clusters grandes. Ray facilita escalar cargas distribuidas de Python —desde entrenamiento con Ray Train hasta serving con Ray Serve— y ahora se beneficia de las funciones de HyperPod para manejo de nodos, recuperación automática y almacenamiento en niveles.
Esta integración es relevante porque elimina gran parte de la complejidad operativa que tradicionalmente acompaña a Ray sobre Kubernetes: ya no es necesario escribir manifiestos YAML a mano, rehacer imágenes Docker por cada cambio de dependencia, establecer port-forward locales para acceder al Ray Dashboard, ni configurar Prometheus y Grafana manualmente. Todo esto puede gestionarse desde la interfaz de SageMaker Studio.
Componentes y requisitos previos
Para aprovechar estas capacidades en su entorno necesita un clúster SageMaker HyperPod con orquestación en Amazon EKS y los siguientes elementos instalados en el clúster:
- SageMaker Spaces EKS add-on: habilita JupyterLab y Code Editor conectados a clusters Ray para desarrollo interactivo.
- HyperPod Observability EKS add-on: recolecta métricas de cargas Ray y provisiona dashboards en Amazon Managed Grafana.
- KubeRay operator: administra RayCluster, RayJob y RayService como recursos nativos de Kubernetes.
- HyperPod Ray Endpoint Operator (Helm chart): crea endpoints públicos autenticados para acceso al dashboard y envío remoto de jobs.
- Un dominio de SageMaker Studio: ofrece la consola para crear clusters Ray, ver cargas, abrir dashboards y gestionar HyperPod Spaces.
Para los detalles de instalación y configuración, consulte la guía de “Ray on HyperPod” en la documentación de AWS.
Experiencia integrada para data scientists
SageMaker Studio ahora entrega una experiencia completa para desarrollar con Ray sin exponer al usuario a los detalles de Kubernetes. Desde Studio pueden crear, gestionar y monitorear clusters Ray con formularios y acciones en la consola.
Flujo típico desde Studio:
- Navegar a SageMaker Studio y seleccionar HyperPod.
- Elegir el clúster HyperPod deseado y abrir la pestaña Tasks.
- Seleccionar el tipo de tarea RayCluster y pulsar Create Ray Cluster.
- Completar nombre del cluster, tipos de instancia para head y workers, conteo de workers y la imagen de contenedor.
Por defecto, los clusters usan la SageMaker Distribution image, que incluye Ray preinstalado y es gestionada por AWS con parches y actualizaciones. Si su carga requiere dependencias adicionales, puede indicar una imagen personalizada. Para quienes prefieren kubectl o necesitan ajustes avanzados, Studio incluye un editor YAML inline que expone el manifiesto Kubernetes completo.
Además, KubeRay se integra con la gobernanza de tareas de HyperPod, lo que permite a administradores fijar cuotas de cómputo y prioridades de scheduling para workloads Ray junto a otros trabajos de entrenamiento.
Acceso al Ray Dashboard y endpoints remotos
Durante la creación del cluster puede habilitar endpoints remotos para acceder al Ray Dashboard, enviar jobs y recuperar logs desde cualquier lugar con acceso a Internet, sin necesidad de port-forward locales. Cuando el cluster alcanza el estado Running, Studio puede generar una URL autenticada y de corta duración vinculada al creador del cluster. El Dashboard muestra salud del cluster, jobs en ejecución y estado de los nodos.
Envío remoto de jobs para producción
Para escenarios de producción es posible enviar trabajos de manera remota desde Studio, una laptop o pipelines CI/CD usando el paquete toolkit-for-ray-on-sagemaker-ai. Ese paquete resuelve endpoints y genera credenciales EKS mediante IAM, de modo que puede usar las APIs estándar de Ray con un resolvedor consciente de SageMaker.
Ejemplo de comandos:
$ aws eks update-kubeconfig --name <eks-cluster-name> --region <region>
$ pip install toolkit-for-ray-on-sagemaker-ai
$ ray job submit --address sagemaker_ray://<ray-cluster-name>/<namespace> \
--working-dir <your-code-directory> \
--python your-code.py
# Para listar jobs
$ ray job list --address sagemaker_ray://<ray-cluster-name>/<namespace>
Estos comandos permiten integrar envío de jobs en flujos automatizados sin cambiar la forma en que los equipos ya usan Ray.
Desarrollo interactivo con SageMaker Spaces
Los data scientists pueden adjuntar un cluster Ray a un espacio HyperPod JupyterLab o Code Editor desde Studio. El espacio se incorpora al cluster como un worker de “cero cómputo”, permitiendo que los notebooks interactúen con el cluster para experimentar y depurar sin consumir nodos adicionales. Esto acelera la iteración y facilita la transición desde experimentos locales a ejecuciones distribuidas.
Tolerancia a fallos y checkpointing por niveles
A nivel de aplicación, los jobs de entrenamiento con Ray obtienen tolerancia a fallos automática gracias al monitoreo de salud de nodos de HyperPod y su capacidad de recuperación. HyperPod también aporta un esquema de checkpointing por niveles mediante su almacenamiento distribuido por niveles, lo que permite reanudar más rápido cuando hay interrupciones.
En serving, la integración con SageMaker JumpStart permite cargar pesos de modelos directamente en endpoints Ray Serve, y el offloading de caché KV a almacenamiento por niveles ayuda a atender solicitudes con contextos largos de forma más eficiente.
Compatibilidad y migración
Las capacidades funcionan con KubeRay open-source y las APIs estándar de Ray, por lo que la mayoría de scripts y flujos de trabajo existentes deberían ejecutarse sin modificaciones. Esto facilita la adopción por equipos que ya usan Ray y buscan delegar la operación del clúster a la infraestructura gestionada.
¿Qué significa esto para equipos en América Latina?
Para organizaciones en la región, esta integración puede reducir significativamente la barrera operativa para entrenar y desplegar modelos grandes. Equipos de startups, universidades y empresas pueden escalar clusters Ray sin necesitar expertos dedicados en Kubernetes, lo cual resulta especialmente valioso en mercados donde recursos especializados pueden ser escasos o costosos.
Además, la capacidad de administrar cuotas y prioridades en HyperPod ayuda a compartir infraestructura entre equipos y proyectos, lo que es útil para iniciativas de IA en empresas medianas y grandes que requieren gobernanza clara del consumo de GPU.
Recomendaciones prácticas
- Evalúen un piloto integrando un cluster Ray en HyperPod con uno o dos proyectos pilotos de entrenamiento distribuido.
- Aprovechen la imagen por defecto de SageMaker Distribution para empezar rápido y migrar a imágenes personalizadas a medida que crezcan las dependencias.
- Habiliten observabilidad (HyperPod Observability EKS add-on) y los endpoints remotos para facilitar operaciones y automatización CI/CD.
- Si su equipo usa Ray hoy, prueben la compatibilidad de sus scripts con el resolvedor sagemaker_ray para validar una migración sin cambios en la lógica de ejecución.
Conclusión
La integración de Ray con SageMaker HyperPod consolida herramientas de desarrollo, operación y observabilidad en una experiencia gestionada dentro de SageMaker Studio. Para equipos que desean escalar entrenamiento y serving de modelos grandes sin aumentar la complejidad operativa, representa un paso práctico hacia entornos más productivos y resilientes.
Fuente original: AWS ML Blog