Programación de jobs de GPU usando un pool de GPU de inferencia inactivas

Programación de jobs de GPU usando un pool de GPU de inferencia inactivas: caso de optimización de infraestructura del LG AI Research Institute

Este artículo, publicado por el equipo Platform&Infra de LG AI Research Institute, aborda cómo reutilizaron recursos de GPU inactivos generados durante la operación de servicios de modelos de lenguaje a gran escala (LLM) para tareas de investigación y experimentación. Las empresas que operan servicios de IA normalmente aseguran GPU por adelantado con base en el pico máximo de tráfico, por lo que en las franjas horarias en que el tráfico baja, esas costosas GPU quedan ociosas ocupando solo memoria. El instituto construyó un pipeline que asigna automáticamente esas GPU disponibles en esas ventanas a trabajos de entrenamiento y evaluación, logrando asegurar recursos de cómputo sin comprar equipo adicional.

Problema central

• Límites del autoescalado en servicios LLM: a diferencia de los servicios web tradicionales, en los LLM el consumo de GPU por solicitud varía bastante según la longitud de los tokens de entrada y salida y la estructura del modelo. Por eso, con métricas tradicionales como uso de CPU u ocupación de memoria es difícil medir la carga real.
• Magnitud de los recursos inactivos: en un entorno donde una réplica (copia de instancia de servicio) usa 4 GPU, durante las horas nocturnas de baja congestión (de las 20:00 a las 8:00 del día siguiente) había en promedio 52 GPU ociosas durante unas 12 horas al día.

Método de solución

• Uso de métricas internas de vLLM: en lugar de métricas generales del sistema, tomaron como criterio de autoescalado indicadores como throughput en tiempo real y estado de espera en cola que provee el motor de inferencia LLM vLLM, implementando así un ajuste de recursos más preciso y alineado con las características de los LLM.
• Ejecución de trabajos con enfoque Best-effort: lanzaron trabajos de investigación sobre las GPU nocturnas inactivas, pero con una arquitectura diseñada para interrumpir esos trabajos en cualquier momento y devolver las GPU al servicio si el tráfico vuelve a subir, sin afectar la estabilidad del servicio.
• Pipeline basado en Argo Workflows: definieron los trabajos por unidad de imagen Docker y habilitaron la ejecución secuencial o paralela de etapas como preprocesamiento de datos, preentrenamiento, ajuste fino supervisado, aprendizaje por refuerzo y evaluación.

Ventajas de los principios de diseño

• Versatilidad: tanto entrenamiento como inferencia, y cualquier framework, pueden ejecutarse tal cual si se encapsulan en una imagen Docker.
• Escalabilidad y flexibilidad: incluso si se agregan nuevos tipos de trabajo, pueden incorporarse sin modificar el código del pipeline.
• Reproducibilidad: todas las configuraciones se inyectan como parámetros externos en lugar de estar codificadas, y las entradas y salidas se gestionan en almacenamiento en la nube, de modo que bajo las mismas condiciones se garantizan los mismos resultados. El hecho de que el pipeline tenga una arquitectura Stateless, sin preservar estado, también contribuye a la estabilidad operativa.

Resultados operativos

• Uso acumulado: entre noviembre de 2025 y enero de 2026, durante unos 3 meses, se ejecutaron 85 trabajos y el uso acumulado alcanzó 95,000 horas-GPU.
• Tendencia de crecimiento: el uso de GPU en enero aumentó aproximadamente 70% frente a noviembre, lo que equivale a haber asegurado unas 55 GPU nuevas en términos de operación continua de 24 horas.
• Reducción de costos: si se convierte el mismo volumen de cómputo usando como referencia un compromiso de 3 años en nube pública, el ahorro fue de aproximadamente 75 millones de wones solo en enero y de unos 185 millones de wones acumulados en 3 meses.

Planes futuros

• Mejora de las métricas de escalado: planean refinar la lógica de asignación de recursos segmentando con mayor detalle los patrones de uso por servicio.
• Expansión hacia programación continua: con Kubernetes y su modelo propio EXAONE, buscan ampliar el sistema para que ejecute trabajos no solo por la noche, sino en cualquier momento en que queden recursos libres.
• Mejora de UX: planean ofrecer una interfaz para que los investigadores puedan realizar de forma intuitiva todo el proceso, desde la solicitud del trabajo hasta el monitoreo.

Este caso deja una señal interesante porque enfrenta un problema común de la industria —la escasez de GPU— no mediante expansión de hardware, sino mejorando la estructura operativa. Destaca especialmente el uso de métricas internas de vLLM para sortear la dificultad de medir la carga propia de los servicios LLM, así como el enfoque Best-effort para los trabajos de investigación, con el que lograron equilibrar dos objetivos normalmente opuestos: estabilidad del servicio y aprovechamiento de recursos. El resultado cuantitativo, con un ahorro cercano a 180 millones de wones sin inversión adicional, presenta un modelo operativo suficientemente útil como referencia para otras organizaciones que administran infraestructura de GPU.