Cuando varias tareas de cálculo tienen que compartir una misma tarjeta gráfica, alguien —o algo— tiene que decidir cómo repartírsela: si conviene trocearla en piezas pequeñas para muchas tareas ligeras, reservarla entera para una tarea exigente, o ir cambiando esa configuración sobre la marcha según van llegando nuevos trabajos. Las GPUs más recientes de los centros de datos permiten justo eso, dividirse en varias GPUs virtuales aisladas entre sí mediante una tecnología llamada Multi-Instance GPU (MIG), y hasta pueden reconfigurarse en caliente sin interrumpir lo que ya se está ejecutando.
El problema es que decidir bien cómo y cuándo trocear el dispositivo es un rompecabezas de una complejidad enorme, del tipo que los informáticos llaman NP-duro, y los métodos que se usaban hasta ahora recurrían a simplificaciones que dejaban mucho rendimiento sobre la mesa.
Un equipo de la Universidad Complutense de Madrid ha entrenado un agente de Aprendizaje por Refuerzo Profundo para que aprenda, por ensayo y error, a tomar esas decisiones sin necesidad de las simplificaciones habituales, considerando a la vez qué tamaño de instancia asignar a cada tarea, en qué orden ejecutarlas y cuándo merece la pena reconfigurar la tarjeta. Los resultados muestran mejoras consistentes frente a los planificadores más recientes, especialmente en las situaciones más difíciles de gestionar: aquellas en las que conviven tareas con necesidades muy distintas entre sí. Este artículo cuenta cómo funciona esa propuesta y qué la hace distinta de los enfoques anteriores.
Compartir una GPU no es tan sencillo como parece
Las GPUs de última generación que se instalan en los centros de datos son auténticos monstruos de cálculo: miles de núcleos y cientos de gigabytes de memoria capaces de ofrecer varios PetaFLOPS de rendimiento. El problema es que buena parte de las tareas que se ejecutan en ellas —ya sean cargas de computación de altas prestaciones o ciertos procesos de aprendizaje profundo— no logran aprovechar toda esa capacidad. El resultado es una GPU carísima trabajando muy por debajo de sus posibilidades, con el consiguiente derroche de tiempo y de energía.
La solución evidente es hacer que varias tareas compartan la misma tarjeta al mismo tiempo. NVIDIA ofrece dos vías para conseguirlo. Una es Multi-Process Service (MPS), que permite la ejecución simultánea pero compartiendo recursos como el ancho de banda de memoria, lo que a veces genera interferencias entre tareas. La otra, más reciente, es Multi-Instance GPU (MIG), que en lugar de compartir recursos los aísla: divide físicamente la GPU en instancias virtuales independientes, cada una con sus propios núcleos de cálculo, su porción de caché y su memoria dedicada, garantizando que una tarea no afecte al rendimiento de las demás.
Una GPU con MIG está formada por unidades básicas llamadas slices: 4 en el modelo A30 y 7 en modelos como el A100, H100, B100 o B200. Esos slices pueden agruparse en instancias de distinto tamaño, y el conjunto de instancias activas en un momento dado se llama configuración. Lo interesante es que esa configuración puede cambiarse dinámicamente mientras el resto de la GPU sigue funcionando, aunque el proceso de crear o destruir una instancia no es instantáneo: según los datos que aporta el estudio, puede llevar entre una y cuatro décimas de segundo dependiendo del tamaño y del modelo de GPU.
El rompecabezas de decidir quién usa qué y cuándo
Aquí es donde aparece el verdadero problema. No basta con decidir cuántos recursos dar a cada tarea; hay que decidir también en qué orden ejecutarlas y cuándo conviene reconfigurar la GPU para adaptarla a las tareas que van llegando. A este tipo de problema se le llama planificación de tareas moldeables, porque el propio planificador es quien decide cuántos recursos recibe cada tarea, en lugar de recibir esa asignación como un dato fijo. Incluso sin tener en cuenta la posibilidad de reconfigurar el dispositivo, este tipo de planificación ya es un problema NP-duro, es decir, de los que se vuelven prácticamente imposibles de resolver de forma exacta según crece su tamaño.
Los planificadores usados hasta ahora, tanto en herramientas de gestión de trabajos como SLURM o Kubernetes como en propuestas de investigación recientes, recurren a heurísticas que simplifican el problema para hacerlo manejable. Una simplificación muy habitual consiste en decidir primero, de forma aislada, qué tamaño de instancia le conviene a cada tarea —el que maximiza su eficiencia individual— y luego, por separado, planificar el orden de ejecución. El propio equipo de investigación demuestra con un ejemplo por qué esto puede salir mal: si tres tareas cuya eficiencia individual óptima se logra con instancias de tamaño 2, 4 y 4 slices se planifican siguiendo ese criterio, el tiempo total resultante puede ser más de un 40% peor que si, en cambio, se asigna a todas un tamaño de instancia de solo 2 slices y se ejecutan de forma conjunta y coordinada.
Un agente que aprende a base de prueba y error
Para evitar este tipo de simplificaciones, los investigadores recurrieron al Aprendizaje por Refuerzo Profundo (DRL), una técnica en la que un agente artificial aprende a tomar decisiones interactuando repetidamente con un entorno simulado, recibiendo una recompensa o penalización según el resultado de cada decisión, hasta que su comportamiento converge hacia una buena estrategia.
En este caso, el entorno que percibe el agente combina dos piezas de información en cada instante: el estado actual de la GPU (qué configuración tiene activa y cuánto tiempo le queda libre a cada slice) y el lote de tareas pendientes, con una estimación de cuánto tardaría cada una según el tamaño de instancia que se le asigne. Con esa información, el agente —una red neuronal tipo perceptrón multicapa— decide entre tres tipos de acciones: dejar pasar el tiempo hasta que se libere algún recurso, reconfigurar la GPU a una nueva partición, o asignar una tarea concreta a una instancia libre. El objetivo que se le marca es minimizar el makespan, es decir, el tiempo total necesario para completar todas las tareas pendientes.
El espacio de posibilidades que debe explorar el agente es descomunal, así que el equipo tuvo que introducir varias optimizaciones para hacer viable el aprendizaje. Descartaron, por ejemplo, configuraciones que dejan slices de cómputo inactivos aunque sigan consumiendo memoria, ya que siempre resultan peores que las alternativas equivalentes. También identificaron que ciertas configuraciones distintas representan en realidad escenarios idénticos por simetría, y las agruparon en una única representación canónica para no obligar al agente a aprender lo mismo varias veces. Y, algo especialmente delicado, tuvieron que asegurarse de que el agente nunca eligiera una acción imposible —como asignar una tarea a una instancia que todavía está ocupada—: penalizar esos errores durante el entrenamiento no fue suficiente ni siquiera tras 200 millones de pasos de entrenamiento, así que optaron por enmascarar directamente las acciones inviables, de forma que el agente solo pudiera elegir entre las opciones realmente disponibles en cada momento.
Cuando la mezcla de tareas se complica, el agente destaca
Para poner a prueba el sistema, el equipo empleó tanto tareas reales —18 kernels de cálculo tomados de las conocidas suites de benchmarking Rodinia y Altis, con comportamientos muy variados: algunas apenas se benefician de más recursos, otras escalan de forma prácticamente lineal— como cargas sintéticas generadas para simular distintos escenarios: desde conjuntos de tareas que escalan mal, hasta mezclas extremas en las que conviven tareas muy distintas entre sí.
Los resultados, medidos como el porcentaje de distancia respecto a una cota inferior del tiempo óptimo teórico, muestran que la versión final del agente (bautizada como Direct Reconfig) se sitúa de media a menos de un 20% de esa cota óptima. Comparado con los planificadores de referencia utilizados en el estudio, el agente supera a FAR —un algoritmo heurístico de los mismos autores— entre un 2% y un 4%, y a MISO, un planificador del estado del arte que procesa las tareas por orden de llegada, entre un 5% y un 7%. La diferencia se dispara frente a enfoques sin reconfiguración dinámica o sin co-ejecución de tareas, donde las mejoras superan el 100% en muchos de los escenarios probados.
Un dato revelador es en qué escenarios brilla más el agente. Cuando las tareas del lote son parecidas entre sí en su forma de escalar, los métodos heurísticos ya funcionan razonablemente bien y el margen de mejora es pequeño. Pero en las cargas mixtas, donde conviven tareas que escalan muy bien con otras que apenas se benefician de más recursos, es donde las simplificaciones de los métodos anteriores fallan y donde el enfoque holístico del agente marca una diferencia mayor. Los investigadores tuvieron que reforzar específicamente la tendencia del agente a explorar reconfiguraciones —aumentando el llamado coeficiente de entropía durante el entrenamiento— y a ejecutar reconfiguraciones de forma más directa, sin exigir que todos los recursos implicados estuvieran completamente libres de antemano, porque el modelo inicial tendía a evitar esas acciones y quedarse atascado en soluciones mediocres.
Un planificador rápido y listo para usarse en producción
Más allá de la calidad de las decisiones, un planificador de este tipo solo es útil si puede tomar decisiones con la suficiente rapidez como para operar en tiempo real. Los investigadores midieron el tiempo de inferencia del modelo —es decir, cuánto tarda en decidir la siguiente acción— en un servidor con procesador Intel Xeon Silver, obteniendo una latencia media de apenas 3,04 milisegundos, con un percentil 99 de 3,09 milisegundos. Es una velocidad más que suficiente para integrarse en un entorno de producción real sin convertirse en un cuello de botella.
El equipo también exploró una variante dinámica del planificador, en la que las tareas nuevas se incorporan al lote de decisión en cuanto llegan, en lugar de esperar a procesar lotes cerrados de tareas. Esta versión, más compleja de entrenar por su naturaleza estocástica, logra mejoras adicionales de en torno al 1% frente a la versión estática en las cargas más heterogéneas, precisamente aquellas donde más margen de mejora existe.
Los autores han publicado en abierto el código de entrenamiento del agente, una herramienta para ejecutar tareas en GPUs MIG reales siguiendo sus decisiones y una interfaz gráfica para visualizar el estado de la planificación, con el objetivo de que la comunidad pueda construir sobre este trabajo. Más allá del caso concreto de las GPUs con MIG, los propios investigadores señalan que las lecciones aprendidas —cómo representar un espacio de estados gigantesco de forma manejable, cómo evitar que el agente tome decisiones imposibles, o cómo incentivar la exploración de las acciones más complejas— son extrapolables a otros problemas de gestión de recursos dinámicamente reconfigurables, un terreno que solo va a ganar relevancia a medida que crece la demanda de cómputo paralelo para la inteligencia artificial.
Este trabajo ha sido financiado por PID2024-158311NB-I00 (MCIN/AEI/10.13039501100011033), PCI2024-162578-3 (MICIU/AEI/10.13039/501100011033 /) y por la Unión Europea NextGeneration EU/PRTR y ERDF A way of making Europe.
Artículo creado a partir del trabajo Planificación de tareas moldeables en GPUs dinámicamente reconfigurables mediante Aprendizaje por Refuerzo Profundo, de Jorge Villarrubia, Luis Costero, Francisco D. Igual y Katzalin Olcoz, del Departamento de Arquitectura de Computadores y Automática de la Universidad Complutense de Madrid.
