Cómo gestionar GPU y NPU multimarca en una plataforma

La forma más limpia de gestionar GPU y NPU de distintos fabricantes consiste en estructurar el problema por capas: descubrimiento físico, normalización del estado de salud, abstracción de recursos, planificación y telemetría de las cargas de trabajo. No conviene asumir que todos los aceleradores son idénticos. Lo adecuado es ofrecer a los usuarios un mecanismo estándar para solicitar capacidad, manteniendo visibles para la plataforma las discrepancias entre fabricantes y modelos.

Kubernetes facilita la exposición de dispositivos y su planificación, pero continúas necesitando controladores de fabricante, plugins de dispositivos o drivers DRA, control de firmware, recolección de métricas de salud y directrices operativas. La capa de gestión debe saber con precisión qué es cada tarjeta, si responde con salud y qué cargas de trabajo pueden ejecutarse realmente en ella.

¿Por qué es compleja la gestión de aceleradores multimarca?

Gestionar aceleradores de múltiples fabricantes resulta complejo porque los dispositivos difieren en mucho más que en su nombre comercial. Presentan controladores distintos, entornos de ejecución propios, diferente firmware, interfaces de monitoreo particulares, distintos tamaños de memoria, soporte desigual de precisión matemática, modelos de particionado dispares, requisitos topológicos específicos y compatibilidades variables con cada framework.

Incluso las métricas de salud carecen de uniformidad. Un fabricante puede exponer la temperatura de la memoria de forma directa; otro puede mostrar únicamente la temperatura general de la placa. La terminología para errores ECC varía. Las métricas de consumo energético proceden de interfaces heterogéneas. Los campos expuestos por el firmware cambian entre versiones.

Por ello, el primer error consiste en intentar resolver la heterogeneidad exclusivamente en la interfaz gráfica. Un panel único que liste todas las tarjetas resulta útil, pero no convierte los dispositivos en piezas operativamente intercambiables. Es indispensable contar con un modelo de datos común por debajo.

¿Qué debe contener el inventario común de aceleradores?

Un inventario de aceleradores verdaderamente útil debe identificar cada tarjeta física, su host asignado, sus capacidades técnicas, sus dependencias de software y su estado de salud.

Como mínimo, conviene registrar el fabricante, el modelo, el número de serie o identificador único de dispositivo, el nodo anfitrión, la ranura o bus PCIe, la capacidad de memoria, la versión de firmware, la relación de controladores compatibles, el estado de salud, la temperatura, la potencia eléctrica y el estado de asignación en los casos en que dichos valores estén disponibles.

Para la planificación, conviene añadir atributos operativos como si la tarjeta se asigna al completo o particionada, si pertenece a un dominio topológico concreto, si se encuentra reservada o si está catalogada como degradada.

Para la gobernanza, es preciso vincular la tarjeta con el servidor físico, el rack, el centro de datos, el responsable, el estado de mantenimiento y el histórico de cargas de trabajo ejecutadas.

En este punto es donde el monitoreo dentro y fuera de banda actúan de forma coordinada. La BMC aporta visibilidad sobre el estado del hardware a nivel de servidor. Las librerías de tiempo de ejecución o agentes de cada fabricante son necesarios para métricas de utilización y consumo de memoria en la tarjeta. Kubernetes proporciona la vinculación con las cargas de trabajo. El inventario de recursos debe unificar todas esas perspectivas.

¿Cómo expone Kubernetes las GPU y otros aceleradores?

Kubernetes expone el hardware especializado mediante integraciones de fabricante como los plugins de dispositivos (device plugins), y los clústeres más recientes pueden valerse además de la Asignación Dinámica de Recursos (DRA).

El marco de device plugins permite al fabricante anunciar dispositivos como recursos del nodo ante el kubelet. De este modo, Kubernetes puede programar un Pod que solicite ese recurso en un nodo con capacidad libre disponible. Este modelo es el más extendido para GPU.

La Asignación Dinámica de Recursos (DRA) introduce una forma más expresiva de solicitar dispositivos y definir sus propiedades. A partir de Kubernetes 1.35, la capacidad principal de DRA es estable y viene habilitada por defecto según la documentación oficial de Kubernetes. Para infraestructuras heterogéneas, esto permite que una carga de trabajo exprese requisitos más ricos que un simple recuento numérico de dispositivos genéricos.

No obstante, Kubernetes sigue requiriendo controladores operativos e integraciones de fabricante funcionales. DRA dota al planificador y a la carga de trabajo de un contrato de recursos superior, pero un acelerador sin controladores adecuados permanece inaccesible.

¿Deben los usuarios solicitar un modelo de GPU específico de fabricante?

Los usuarios deberían solicitar recursos específicos de fabricante únicamente cuando la carga de trabajo dependa estrictamente de esa marca o arquitectura. Para la gran mayoría de los usuarios de una plataforma, el camino óptimo consiste en utilizar una especificación estándar.

Por ejemplo, una organización puede definir clases de recursos como:

Entrenamiento intensivo, 8 aceleradores completos de alta memoria
Entrenamiento estándar, 4 aceleradores completos
Inferencia dedicada, 1 acelerador completo
Inferencia compartida, acelerador particionado
Desarrollo, solo CPU

Estas clases constituyen ejemplos prácticos, no estándares universales. Quien desarrolla o entrena solicita la capacidad que requiere y la plataforma asigna esa petición al hardware que la satisfaga.

Si una carga de trabajo exige una versión exacta de CUDA, una arquitectura de modelo específica o un tamaño indispensable de memoria, ese requisito debe quedar explícito. La abstracción debe reducir la complejidad innecesaria sin enmascarar restricciones reales de compatibilidad.

¿Cómo decidir si dos modelos de acelerador pertenecen al mismo pool?

Dos modelos de acelerador solo deben convivir en el mismo pool lógico si las cargas de trabajo asignadas a dicho conjunto pueden ejecutarse de forma correcta y predecible en cualquiera de ellos.

Comprueba primero la compatibilidad de software. ¿Puede el mismo framework y modelo ejecutarse en ambos? ¿Están disponibles los controladores y librerías requeridos? ¿Exige la carga de trabajo un runtime propietario de un fabricante determinado?

Revisa a continuación la capacidad del hardware. La memoria representa a menudo una restricción estricta: un modelo que requiere más memoria de la que proporciona una tarjeta no puede ejecutarse en ella simplemente porque ambos equipos sean aceleradores.

La topología resulta determinante en el entrenamiento distribuido entre varias tarjetas, y las características del interconector pueden alterar radicalmente el rendimiento global del proceso.

Las diferencias de rendimiento condicionan el cumplimiento de SLO y el control de costes. Si dos modelos entregan un rendimiento muy dispar, tratarlos como un recurso indistinto distorsionará los tiempos de cola y las estimaciones de finalización de tareas.

La mejor abstracción suele mantener sencilla la interfaz de cara al usuario mientras preserva variantes de recursos bien definidas por debajo. Kueue, por ejemplo, admite objetos ResourceFlavor y cuotas capaces de representar diferentes modelos de GPU u otras variantes de recursos.

¿Cómo debe influir el estado de salud en la planificación?

La salud debe ser un criterio de entrada para la planificación, no solo una alarma disparada tras el inicio del trabajo. Una tarjeta puede hallarse técnicamente en línea y ser, al mismo tiempo, un pésimo destino para nuevas tareas. Algunos ejemplos incluyen aumento en los errores ECC, reinicios frecuentes, temperaturas altas persistentes, frecuencias de reloj degradadas o fallos intermitentes en los controladores.

Si la capa de gestión etiqueta una tarjeta como degradada, el planificador debe evitar asignarle cargas nuevas. La intervención concreta dependerá del nivel de riesgo. Una advertencia puede reducir la prioridad de asignación; una anomalía grave puede marcar el nodo como no planificable; un fallo confirmado puede motivar la migración de tareas, la recuperación mediante checkpoints y la apertura de una orden de reparación.

Este mecanismo sintetiza la necesidad de integrar la gestión de hardware con el planificador. Si el monitoreo físico reside en una herramienta aislada y la planificación en otra sin compartir el estado de salud, el planificador seguirá enviando trabajos a tarjetas que el equipo de operaciones ya sabe que no son fiables.

¿Cómo funcionan las cuotas en un pool heterogéneo?

Las cuotas deben regular tanto el volumen que un equipo puede consumir como las clases de recursos a las que tiene acceso. Un simple cupo de "10 GPUs" puede inducir a error si el entorno reúne modelos de aceleradores con prestaciones radicalmente diferentes.

Una estrategia adecuada consiste en asignar cuotas por variante o especificación de recurso. Un equipo puede disponer de una cuota fija para tareas de entrenamiento intensivo y de una cuota independiente para inferencia. Otra alternativa es un modelo basado en créditos donde cada tipología de recurso consume una fracción distinta de un presupuesto común.

Kueue admite cuotas a nivel de clúster, variantes de recursos, préstamos, cesiones y reparto equitativo. Esto dota a los equipos de plataforma de herramientas nativas de Kubernetes para gobernar cargas de trabajo batch y de IA entre diferentes áreas.

Sea cual sea el esquema elegido, es fundamental que la tarificación y las definiciones de cuota estén alineadas. Si el planificador contabiliza un recurso bajo un criterio y el sistema de costes lo hace bajo otro, surgirán discrepancias continuas con los usuarios.

¿Cómo se combinan tarjetas completas, particiones y uso compartido?

La asignación de tarjeta completa, el particionado por hardware y el uso compartido por tiempo representan modelos operativos distintos y deben exponerse como tipos de recursos diferenciados.

La asignación de tarjeta completa brinda el aislamiento más limpio. Es la opción preferente para grandes tareas de entrenamiento o cargas con exigencias estrictas y predecibles de rendimiento.

El particionado por hardware, como Multi Instance GPU (MIG) de NVIDIA en equipos compatibles, divide una GPU física en instancias aisladas con recursos de computación y memoria dedicados.

El uso compartido por tiempo permite que múltiples cargas utilicen la misma GPU física de manera alterna. Puede elevar la utilización en tareas ligeras, pero su grado de aislamiento de rendimiento dista del ofrecido por el particionado hardware.

Conviene no etiquetar estas tres modalidades bajo la denominación genérica de "GPU compartida". Los usuarios necesitan saber qué garantías de rendimiento y aislamiento están adquiriendo. Los detalles técnicos de este esquema se profundizan en agrupación y planificación de recursos GPU en Kubernetes.

¿Cómo diseñar el monitoreo multimarca?

El monitoreo multimarca debe normalizar los conceptos comunes sin perder el detalle técnico propio de cada fabricante. Un esquema de salud estandarizado puede reunir estado, temperatura, potencia, uso de memoria, recuento de errores, porcentaje de utilización y versión de firmware, manteniendo bajo esa estructura los campos nativos originales del fabricante.

Ese nivel de detalle será imprescindible durante la resolución de averías. Un aviso normalizado de "advertencia" resulta muy práctico en un panel general, pero el ingeniero necesitará contrastar el sensor original, el código de error o el evento específico registrado por el fabricante.

La cadencia de recolección también requiere planificación. Los indicadores críticos de fallo justifican un sondeo frecuente o una recolección orientada a eventos, mientras que campos de inventario estables como los números de serie no lo necesitan.

Asimismo, el sistema debe alertar sobre los fallos en la recolección de datos. Si una actualización de controladores inutiliza un exportador de métricas, la plataforma debe reflejar que la fuente ha dejado de responder en lugar de reportar de forma engañosa el último valor almacenado.

¿Puede una sola plataforma gestionar recursos GPU y NPU a la vez?

Sí, una plataforma única puede gestionar ambos tipos de aceleradores si los aborda como recursos de cómputo gobernados mediante adaptadores específicos de fabricante bajo un modelo común. Esta capa común abarca identidad, salud, capacidad, asignación, vinculación con cargas de trabajo, cuotas y costes. La capa de adaptación gestiona controladores, API, telemetría y lógica de despliegue propia de cada marca, y esa separación es lo que permite escalar la infraestructura.

Pretender encajar a todos los fabricantes en una interfaz rígida suele generar sistemas frágiles. Un modelo basado en plugins o adaptadores facilita incorporar nuevas familias de aceleradores sin tener que rediseñar la plataforma por completo. Un ejemplo de solución basada en este esquema general es Sensaka.

Al construir un entorno de aceleración heterogéneo, conviene no comenzar por un proyecto centrado en crear una interfaz llamativa. Lo prioritario es disponer de un inventario fiable de tarjetas y de un modelo sólido de clasificación de recursos. Cuando la plataforma es capaz de determinar con certeza qué es cada tarjeta, si está sana, qué puede ejecutar y quién la está utilizando, la visión centralizada adquiere un verdadero valor operativo.