Aprovecha cada hora de GPU: Seguimiento del progreso en Red Hat OpenShift AI

Es viernes por la noche. Priya, una ingeniera de machine learning (ML) de una empresa de servicios financieros, pone en cola un trabajo de ajuste de detección de fraudes en un clúster de GPU que cuesta 55 USD por hora. La ejecución debería demorar alrededor de 40 horas, lo cual equivale a aproximadamente 2200 USD en recursos informáticos. Verifica los hiperparámetros, envía el trabajo y se marcha a casa para pasar el fin de semana.

El lunes por la mañana abre su computadora portátil. El modelo dejó de aprender en algún momento del viernes por la noche, pero el trabajo siguió ejecutándose. Esto supuso dos días completos de tiempo de GPU en una ejecución de entrenamiento que no llevaba a ninguna parte. Eso representa más de 1500 USD en recursos informáticos desperdiciados y tiene que comenzar de nuevo.

Si esto te resulta familiar, no estás solo. Todos los profesionales que han realizado un trabajo de entrenamiento de varios días conocen las preguntas incómodas:

• ¿El modelo realmente está aprendiendo algo?
• ¿Debería detenerme antes y probar diferentes hiperparámetros?
• ¿Terminará antes de la revisión de las partes interesadas el martes?

El costo de no saberlo es real. Los clústeres de GPU bajo demanda pueden costar más de 50 USD por hora. Una sola ejecución de entrenamiento de varios días puede costar miles de dólares. Además, una ejecución mal configurada puede desperdiciar todo un fin de semana de recursos informáticos antes de que alguien lo note. En los clústeres compartidos, el impacto se multiplica. Un trabajo estancado no solo desperdicia el presupuesto de un equipo, sino que también bloquea el acceso de otros equipos a las GPU que necesitan. La ejecución a ciegas de un equipo se convierte en la demora de otro. El problema no es que los equipos sean descuidados. Es que operan sin visibilidad. Cada hora de GPU es importante. Sin la supervisión en tiempo real del progreso del entrenamiento, muchas de ellas se desperdician.

La brecha de observabilidad

Esta es la verdad incómoda: desde el punto de vista de la plataforma, un trabajo de entrenamiento que converge a la perfección y otro que está completamente estancado parecen idénticas. Ambos son pods en estado de ejecución que consumen los mismos recursos y muestran el mismo indicador de estado verde. Kubernetes desconoce si el modelo está aprendiendo.

Hoy en día, es posible supervisar el progreso del entrenamiento, pero es más difícil de lo que debería ser.

• Los registros están dispersos y son difíciles de usar: En un trabajo de entrenamiento distribuido, los registros se reparten en varios pods. Encontrar el resultado relevante implica saber qué pod buscar, cómo acceder a él y cómo interpretar los formatos de registro específicos de cada marco. Para ello, se requiere experiencia en Kubernetes. Este es un conjunto de habilidades adicionales que la mayoría de los analistas de datos e ingenieros de inteligencia artificial no deberían tener que adquirir solo para supervisar sus ejecuciones de entrenamiento. Los registros erróneos y no estructurados no son fáciles de leer para las máquinas, por lo que no impulsan la automatización.
• Las herramientas externas resuelven la observabilidad, pero aumentan la sobrecarga de gestión: Las plataformas de seguimiento de experimentos, como MLflow y Weights & Biases, son excelentes para su propósito. Sin embargo, requieren una infraestructura adicional para su implementación y mantenimiento, además de claves de API y controles de acceso. También funcionan por encima de la capa de la plataforma. Además, están desconectadas de la API de Kubernetes. Esto dificulta su integración con flujos de trabajo y operadores personalizados nativos de Kubernetes. Te informan de lo que sucedió dentro del ciclo de entrenamiento, pero no pueden decirle a la plataforma lo que está ocurriendo.
• Cada marco lo hace de manera diferente: PyTorch DDP, FSDP, DeepSpeed, JAX: cada uno tiene sus propias convenciones de registro, su propio formato de indicadores y su propia forma de informar el progreso. No hay uniformidad entre los marcos. Esto significa que los equipos de plataformas que gestionan un entorno de entrenamiento heterogéneo no tienen una visión unificada.
• No hay una API estándar: Hasta ahora, los trabajos de entrenamiento no tenían una forma estandarizada de informar el progreso a la plataforma. Como resultado, los administradores de plataformas que gestionan clústeres de GPU compartidos deben adivinar qué trabajos progresan, cuáles están estancados y cuáles están por finalizar. Sin esa supervisión, la planificación de la capacidad y la resolución de problemas son solo conjeturas.

Cerrar la brecha: Seguimiento del progreso en Red Hat OpenShift AI

Red Hat OpenShift AI ahora incluye el seguimiento del progreso de los trabajos de entrenamiento distribuidos listos para la producción. Está integrado en Kubeflow Trainer v2 y disponible de forma general a partir de Red Hat OpenShift AI 3.4. Puedes ver lo que ocurre mientras sucede y actuar antes de que sea demasiado tarde. Esta función aborda directamente la brecha de observabilidad. Ofrece a los analistas de datos, ingenieros de machine learning (ML) y administradores de plataformas visibilidad en tiempo real sobre el rendimiento de los trabajos de entrenamiento.

Esta visibilidad se basa en 3 pilares:

1. Visualización del panel: Los indicadores de progreso en tiempo real aparecen directamente en el panel de Red Hat OpenShift AI. De un vistazo, puedes ver el porcentaje de progreso, el paso actual y el total de pasos, la época actual, el tiempo restante estimado, la pérdida de entrenamiento y los indicadores de evaluación de tus TrainJobs. Sin herramientas independientes ni configuraciones adicionales.
2. Integración con el SDK: Los mismos datos de progreso están disponibles mediante programación a través del SDK de Kubeflow. Esto permite que los equipos diseñen pipelines automatizados que reaccionen al progreso del entrenamiento. Pueden activar la detención anticipada, enviar notificaciones o volver a asignar recursos basándose en indicadores en tiempo real.
3. Uniformidad con varios marcos: El seguimiento del progreso funciona de la misma manera independientemente de si utilizas PyTorch DDP, FSDP, DeepSpeed o JAX. También admite código de entrenamiento personalizado a través de la API CustomTrainer. Esto proporciona una experiencia unificada en todos los marcos.

Tu entrenamiento en marcha

La mejor manera de comprender el seguimiento del progreso es analizar cómo se siente realmente al usarlo. Hay 3 pasos que son importantes.

1. Inicia tu trabajo de entrenamiento: Envías un trabajo de entrenamiento desde un notebook con el SDK de Kubeflow, tal como lo harías en la actualidad. Si utilizas HuggingFace Transformers, el seguimiento del progreso es automático, por lo que no es necesario realizar cambios en el código. La integración detecta el entorno de Kubeflow y comienza a generar informes sobre los indicadores del ciclo de entrenamiento.
2. Mira su progreso: A medida que se ejecuta el entrenamiento, aparecen indicadores en tiempo real en el panel de Red Hat OpenShift AI: porcentaje de progreso, tiempo restante estimado, pasos completados, épocas, norma de gradiente, pérdida del entrenamiento y tasa de aprendizaje. Sin seguir registros, sin conexión SSH a los pods y sin necesidad de configurar herramientas externas.

Figura 1: El panel de Red Hat OpenShift AI muestra una lista de trabajos con una barra de progreso que indica que un TrainJob en ejecución se completó en un 40 %.

Figura 2:  Un panel lateral detallado para el progreso del trabajo y los indicadores en tiempo real.

3. Actúa según lo que ves: Aquí es donde el seguimiento del progreso realmente ahorra tiempo y recursos informáticos. ¿Notas que la pérdida no mejora? Detén el trabajo antes de tiempo y ahorra horas de GPU. ¿Ves una ejecución que converge más rápido de lo esperado? Libera recursos para tus compañeros de equipo. Podrás saber exactamente cuándo finalizará un trabajo para planificarlo. Ya no tendrás que adivinar si los resultados estarán listos para la revisión de las partes interesadas del martes.

Las características clave que hacen que esto sea práctico:

• Configuración cero: Sin infraestructura adicional, sin dependencias externas ni configuraciones adicionales. El seguimiento del progreso funciona de forma nativa.
• Sobrecarga mínima: Los indicadores se notifican en los puntos de control naturales del entrenamiento, sin afectar su rendimiento.
• Funciona en todos los marcos: Ya sea que utilices PyTorch DDP, FSDP, DeepSpeed, JAX o código de entrenamiento personalizado, la experiencia es la misma.

Quiénes se benefician

Los analistas de datos y los ingenieros de machine learning (ML) e inteligencia artificial ven la pérdida del entrenamiento, el porcentaje de progreso y la hora estimada de finalización en tiempo real. Todo esto sin conectarse por SSH a los pods ni seguir los registros. Detección temprana de divergencias o entrenamientos estancados: detectar un trabajo detenido el sábado por la mañana en lugar del lunes ahorra horas de GPU desperdiciadas. Compara las ejecuciones de entrenamiento de un vistazo desde el panel. Así identificarás rápidamente qué configuración de hiperparámetros ofrece el mejor rendimiento.

Los administradores de la plataforma obtienen una visión única en el panel de todos los trabajos de entrenamiento del clúster. Verán indicadores uniformes, independientemente de si un trabajo utiliza DDP, FSDP o DeepSpeed. Además, tomarán mejores decisiones de planificación de capacidad al comprender qué trabajos progresan, cuáles están estancados y cuáles están cerca de finalizar.

En entornos de GPU multiinquilino donde varios equipos comparten el mismo clúster, esta visibilidad mejora directamente el uso de los recursos y el retorno sobre la inversión. Para las organizaciones que diseñan un modelo de GPU como servicio, el seguimiento del progreso cierra una brecha crítica. Convierte la "caja negra de uso de la GPU" en un sistema observable y gestionable. En última instancia, esto permite que los equipos de plataformas eliminen los cuellos de botella de la infraestructura. Así, pueden entregar con confianza a los analistas de datos los recursos necesarios para acelerar la innovación en inteligencia artificial.

Más allá de la supervisión: Creación de una base para un entrenamiento más inteligente

El seguimiento del progreso es más que una función de supervisión: es una base. Una vez que la plataforma tiene acceso a los datos del progreso del entrenamiento en tiempo real, es posible una cascada de comportamientos más inteligentes. Si bien estas funciones avanzadas aún no son compromisos de productos de Red Hat, ya se estableció la base. La comunidad upstream de Kubeflow Trainer está explorando varias direcciones:

• Ajuste más inteligente de los hiperparámetros: En la actualidad, los motores de optimización de hiperparámetros como Katib dependen del análisis de registros con patrones de expresiones regulares frágiles para evaluar el rendimiento de las pruebas. Con los indicadores de entrenamiento disponibles directamente en la API de Kubernetes, Katib puede leer el estado de forma nativa. Esto permite una integración más estrecha y una orquestación de pruebas más eficiente. Este es el KEP que se debate en la comunidad upstream.
• Escalado elástico: La velocidad de convergencia y los datos sobre la hora estimada de finalización podrían fundamentar las decisiones de expansión y reducción. Un modelo que converja rápido podría liberar GPU para otros equipos. Por el contrario, uno estancado podría solicitar trabajadores adicionales. La comunidad upstream está analizando la compatibilidad con PyTorch elástico en TrainJob para que esto sea posible.
• Visibilidad del progreso en la CLI: kubectl get trainjob con una columna PROGRESS % integrada mostraría el progreso del entrenamiento directamente en la línea de comandos. Esto ofrece a los operadores visibilidad instantánea sin necesidad del panel o el SDK.
• Puntos de control más inteligentes: OpenShift AI ya admite los puntos de control de modelos periódicos y oportunos. Con los datos de la hora estimada de finalización y progreso disponibles, la plataforma podría decidir de forma más inteligente cuándo crear puntos de control; por ejemplo, guardando el estado automáticamente según la hora estimada de finalización del trabajo. La comunidad upstream analiza puntos de control de GPU transparentes con CRIU para mejorar la tolerancia a fallos y la resiliencia de TrainJob.

Estas son áreas de exploración activa en el proyecto Kubeflow, no compromisos de productos. Sin embargo, ilustran por qué el seguimiento del progreso es importante más allá de la función inmediata: crea la capa de datos sobre la cual se puede desarrollar toda la stack de entrenamiento.

El seguimiento del progreso para el entrenamiento distribuido está disponible de forma general en Red Hat OpenShift AI 3.4. Para obtener más información, lee la documentación de Red Hat OpenShift AI. O compruébalo tú mismo iniciando una versión de prueba de 60 días de Red Hat OpenShift AI.