Agrupación y planificación de GPU en Kubernetes

La agrupación de recursos de GPU en Kubernetes consiste en convertir un conjunto de aceleradores físicos en capacidad gestionada que las cargas de trabajo puedan solicitar mediante políticas, en lugar de tener que elegir servidores individuales a mano. Kubernetes aporta la capa básica de planificación de dispositivos, mientras que un modelo completo de programación para IA suele incorporar clases de recursos, colas de trabajos, cuotas, reglas de topología, conocimiento del estado de salud y recuperación de recursos.

Resulta útil separar el hecho de que «Kubernetes pueda ver una GPU» de que «la organización pueda operar un grupo de GPU». Lo primero es un problema de integración de dispositivos, y lo segundo es un problema de gestión de recursos.

¿Cómo ve Kubernetes una GPU?

Kubernetes detecta dispositivos especializados mediante integraciones que anuncian dichos dispositivos a kubelet y al planificador.

El mecanismo tradicional es el entorno de Device Plugins. Un plugin del proveedor detecta los dispositivos compatibles en un nodo y notifica la capacidad de recursos correspondiente. Un Pod puede solicitar ese recurso y Kubernetes lo planifica en un nodo que disponga de capacidad suficiente. La documentación de Kubernetes detalla el soporte para la planificación de GPU mediante device plugins y describe este framework como estable desde Kubernetes 1.26.

Los clústeres más recientes también pueden utilizar la asignación dinámica de recursos (Dynamic Resource Allocation o DRA). DRA proporciona a las cargas de trabajo una forma más rica de solicitar dispositivos y permite a los controladores describir propiedades de los dispositivos y comportamientos de asignación. A partir de Kubernetes 1.35, la función principal de DRA figura como estable y viene habilitada por defecto.

En la práctica, Kubernetes sigue dependiendo de los controladores del fabricante y de la integración de dispositivos, y no puede descubrir todos los aceleradores existentes sin ayuda. Para entornos heterogéneos, conviene leer cómo gestionar GPU y NPU de múltiples proveedores antes de diseñar el grupo de recursos.

¿Qué es un grupo de recursos de GPU?

Un grupo de recursos de GPU es una provisión lógica de capacidad de aceleradores gestionada bajo reglas comunes.

Las tarjetas físicas pueden residir en diferentes nodos y pertenecer a distintos modelos. Algunas pueden ser tarjetas completas y otras estar particionadas; algunas pueden formar parte de un clúster de entrenamiento mientras que otras se reservan para inferencia. El grupo de recursos crea una capa de gestión por encima de los dispositivos individuales. En vez de decirle a un usuario: «Ejecuta en el servidor 27, GPU 3», la plataforma puede ofrecer una clase de recursos como «cuatro GPU de entrenamiento de alta memoria», y el planificador selecciona entonces los dispositivos idóneos.

Un grupo de recursos útil supervisa al menos cinco elementos:

Qué recursos existen
Cuáles están disponibles
Cuáles están en buen estado operativo
Qué cargas de trabajo tienen autorización para utilizarlos
Cómo se recuperan los recursos tras su uso

Sin esos controles, hablar de «agrupación» es poco más que una etiqueta en un panel.

¿Cuál es la diferencia entre planificar dispositivos y planificar trabajos?

La planificación de dispositivos decide dónde puede ejecutarse un Pod. La planificación de trabajos decide cuándo debe admitirse una carga de trabajo más grande y cómo se reparte la capacidad escasa entre trabajos que compiten.

Esta distinción es crítica en IA. Un trabajo de entrenamiento distribuido puede requerir muchos Pods y muchas GPU al mismo tiempo, y arrancar solo una parte del trabajo puede ser inútil. Una plataforma también puede necesitar cuotas por tenant, prioridades de cola, reglas de préstamo y preemption.

La planificación básica de Kubernetes se centra en ubicar Pods. Kueue es un proyecto nativo de Kubernetes diseñado para la gestión de colas de trabajos y la admisión de recursos. Puede gestionar cuotas y distribución para cargas de procesamiento por lotes, HPC e IA, y admite distintas variantes de recursos (resource flavors) para diferentes tipos de hardware.

Esto se traduce habitualmente en la siguiente arquitectura:

Kubernetes gestiona la planificación de nodos y Pods.
Los plugins de proveedor o controladores DRA exponen los dispositivos aceleradores.
Kueue u otro planificador por lotes gestiona las colas y la admisión según cuotas.
La capa de operaciones aporta salud, topología, costes y contexto de negocio.

Estas capas deben colaborar entre sí en lugar de duplicar funciones.

¿Cómo se deben diseñar las clases de recursos de GPU?

Las clases de recursos de GPU deben describir la capacidad relevante para la carga de trabajo, lo que va más allá del nombre comercial de la tarjeta. Una clase útil puede codificar tamaño de memoria, familia de acelerador, cantidad, topología, modo de uso compartido, CPU y memoria del sistema. Por ejemplo, una plataforma puede definir clases separadas para entrenamiento distribuido de gran escala, entrenamiento menor, inferencia dedicada, inferencia compartida y desarrollo.

No conviene crear demasiadas clases. Si los usuarios se encuentran con 40 opciones prácticamente idénticas, la abstracción ha fracasado. Al mismo tiempo, no ocultes restricciones que condicionen el éxito del trabajo. Si un modelo solo funciona sobre una pila de software específica, la clase debe preservar esa compatibilidad.

Las variantes de recursos (resource flavors) resultan de gran ayuda en este punto. Kueue puede representar distintas versiones de un recurso, como diferentes modelos de GPU, y asignar cuotas a esas variantes. DRA también permite que las propiedades del dispositivo formen parte del modelo de asignación. El resultado es una interfaz de usuario más simple que el inventario de hardware sin fingir que todo el hardware es idéntico.

¿Cómo funcionan las cuotas en grupos de GPU?

Las cuotas limitan cuánta capacidad escasa de aceleradores puede consumir un tenant o equipo. Una cuota estática reserva una cantidad definida para un equipo. Los modelos de cuota compartida permiten que los equipos tomen prestada capacidad ociosa entre sí, y el reparto equitativo evita que un equipo acapare recursos libres indefinidamente. Kueue admite cuota nominal, políticas de préstamo, cesión y preemption entre ClusterQueues y cohortes.

Esto es útil porque la demanda de GPU suele producirse por picos. Un equipo de investigación puede necesitar una gran capacidad durante unas pocas horas y apenas nada el resto del día; dividir rígidamente cada GPU por departamento puede generar hardware inactivo.

El préstamo mejora la eficiencia del grupo, pero exige reglas claras de recuperación. Si el Equipo A toma prestada la capacidad inactiva del Equipo B y el Equipo B la necesita de repente, el planificador requiere una política clara sobre qué hacer a continuación, y ahí es donde la prioridad y la preemption cobran importancia operativa.

¿Cómo debe funcionar la preemption en trabajos de entrenamiento?

La preemption debe proteger el trabajo útil antes de reclamar el recurso. En una tarea breve de inferencia sin estado, reiniciar suele ser poco costoso. En un trabajo de entrenamiento que lleva horas ejecutándose, un desalojo repentino puede desperdiciar una gran cantidad de computación a menos que la tarea cuente con un checkpoint reciente.

Un flujo más adecuado sigue estos pasos:

Identificar la carga de trabajo de menor prioridad.
Activar o verificar un checkpoint donde sea compatible.
Esperar a que se complete el checkpoint.
Desalojar o suspender la carga de trabajo.
Liberar las GPU.
Reanudar más adelante a partir del checkpoint.

El planificador de Kubernetes no puede resolver esto por sí solo. El entorno de entrenamiento, el controlador de la carga, el sistema de almacenamiento y el gestor de colas pueden intervenir conjuntamente. Por tanto, «admitir preemption» es un requisito insuficiente por sí solo; hay que preguntarse qué ocurre con el trabajo ya realizado.

¿Qué es la planificación de GPU basada en el estado de salud?

La planificación basada en el estado de salud retira o reduce la prioridad de los aceleradores que son técnicamente visibles pero operativamente poco fiables.

El planificador no debe esperar a que una tarjeta falle del todo. Una tarjeta degradada puede mostrar un aumento de errores ECC, temperatura inestable, reinicios repetidos, comportamiento anómalo de frecuencias o fallos de controladores. El sistema de operaciones puede convertir esas observaciones en un estado de salud, y la capa de planificación puede excluir entonces la tarjeta de nuevas asignaciones o marcar el nodo como no planificable.

Esto crea un ciclo muy útil:

La monitorización de hardware detecta la degradación.
El modelo de recursos marca el dispositivo.
El planificador lo evita.
Las cargas de trabajo existentes se protegen o se migran.
Se abre un flujo de trabajo de reparación.
El dispositivo regresa al grupo solo tras su validación.

Esta es una de las razones por las que un centro de datos para IA requiere una visibilidad de hardware mucho más profunda que un clúster genérico de contenedores.

¿Cómo encajan las particiones de GPU en el grupo?

Las particiones de GPU permiten exponer un acelerador físico como múltiples recursos más pequeños, aunque el modelo de aislamiento depende de la tecnología empleada.

NVIDIA Multi Instance GPU, en hardware compatible, divide una GPU física en instancias aisladas con recursos dedicados de computación y memoria. El tiempo compartido (time sharing) funciona de otro modo: permite que varias cargas utilicen una GPU a lo largo del tiempo sin la misma partición a nivel de hardware.

Desde la perspectiva de la planificación, deben tratarse como clases de recursos distintas. Un usuario que solicite una GPU completa y dedicada no debe recibir por error un recurso de tiempo compartido, y un usuario que pida una pequeña fracción para inferencia no debe acaparar una tarjeta grande entera si el hardware se puede particionar con seguridad. La eficiencia del grupo aumenta cuando la forma del recurso coincide con la carga de trabajo.

¿Por qué importa la topología en trabajos multi-GPU?

La topología importa porque la comunicación entre GPU puede representar una parte sustancial del tiempo en entrenamientos distribuidos. Dos conjuntos de ocho GPU pueden parecer idénticos por número de tarjetas, pero comportarse de manera muy distinta si uno cuenta con mejor interconexión local o una ruta de red superior.

La planificación con reconocimiento de topología procura ubicar las cargas fuertemente acopladas donde la comunicación sea más eficiente. Esto puede implicar mantener un trabajo multi-GPU dentro del mismo nodo, dentro del mismo dominio de conmutación de alta velocidad o bajo otro límite topológico definido. Kueue también ofrece funciones de planificación conscientes de la topología para cargas que requieren ubicación según la arquitectura del centro de datos.

Los usuarios no deberían tener que memorizar la topología. El planificador debe aplicarla como una restricción detrás de la clase de recurso.

¿Cómo saber por qué espera un trabajo de GPU?

Una buena cola debe mostrar la causa exacta por la que una carga de trabajo está esperando, ya que un simple estado «Pending» resulta insuficiente para tomar decisiones. Motivos de espera habituales incluyen:

Cuota del tenant agotada
Ninguna variante de acelerador coincidente disponible
Hay suficientes GPU totales, pero no suficientes en la topología requerida
La clase de tarjeta completa solicitada está agotada
Un nodo está bloqueado por motivos de salud operativa
Una carga de trabajo de mayor prioridad ha reservado la capacidad
Una comprobación de admisión está a la espera de aprovisionamiento de capacidad

Esta información modifica el comportamiento del operador. Si el problema es de cuota, añadir hardware no lo solucionará. Si el problema es la fragmentación, comprar más GPU quizá no sea necesario. Si el problema es una exclusión por salud, el flujo de reparación debe ser la prioridad. La transparencia en las colas pertenece al producto tanto como a las herramientas de depuración.

¿Cómo se deben recuperar los recursos?

Los recursos de GPU deben recuperarse de forma automática cuando la carga de trabajo termina, agota su tiempo o se suspende deliberadamente, ya que las asignaciones huérfanas resultan costosas. Un sistema completo debe conciliar el estado del planificador, el estado de los Pods, la asignación de dispositivos y los registros de medición.

Si un trabajo indica que ha terminado pero un recurso sigue asignado, la capacidad del grupo queda distorsionada. Si un Pod desaparece pero el sistema de tarificación sigue cobrando al proyecto, la factura es incorrecta. Si un nodo falla y el recurso nunca se retira de la capacidad disponible, el siguiente trabajo puede asignarse a un dispositivo fuera de servicio. La recuperación de recursos es, por tanto, una función tanto de planificación como de coherencia de datos.

¿Qué conviene construir primero?

Construye primero la base de datos real de recursos y después la política de planificación. Necesitas un descubrimiento fiable de dispositivos, estado de salud, relaciones entre nodos, clases de recursos y vinculaciones de cargas antes de que las colas complejas resulten fiables. A partir de ahí, añade cuotas, compartición, reglas de topología, preemption con conocimiento de checkpoints, medición y optimización.

Un ejemplo de plataforma que conecta estas capas es Sensaka.

Si tuviera que gestionar un clúster homogéneo y pequeño, mantendría el modelo simple y usaría la planificación nativa de GPU de Kubernetes con cuotas claras. Si tuviera que operar un clúster de IA heterogéneo, multitenant y con múltiples modelos, añadiría un grupo de recursos explícito, una capa de admisión de trabajos, planificación basada en el estado de salud y contabilidad de costes. La complejidad está justificada cuando evita que aceleradores escasos queden ociosos, fragmentados o asignados a la carga de trabajo equivocada.