GPUs en Kubernetes: visibilidad y costes bajo control

Si gestionas una plataforma Kubernetes, probablemente ya tengas un panel de Grafana para ver el consumo de recursos. Con CPU y memoria, el kernel te lo da hecho: pides cuatro núcleos, usas la mitad y lo ves claro. Pero cuando llegan las GPUs, casi nada de esa visibilidad viene regalada. Todo lo que dabas por sentado en CPU y memoria, en GPU hay que construirlo: tus propias métricas, tu propia precisión y tus reglas para repartir la factura. Y duele más porque la GPU es la línea más cara del presupuesto.

El problema de la visibilidad: cada pod parece usar toda la GPU

Con CPU y memoria, el kernel ya rastrea el uso por contenedor, así que obtener un número por pod es gratis. En GPU no. La herramienta habitual, el exportador DCGM de NVIDIA, informa a nivel de dispositivo físico. Esto va bien cuando un pod tiene una GPU para él solo, pero en cuanto compartes GPU entre pods con time-slicing o MPS, DCGM da el mismo valor a todos los pods que la comparten. Si tres pods comparten una GPU, los tres parecen usar el 100%, y al sumar obtienes un 300% de una GPU que no existe. El driver expone un único conjunto de contadores para toda la GPU, así que DCGM no puede distinguir qué carga consumió qué. Los números se dibujan bien en un gráfico, pero los equipos construyen paneles y informes sobre valores totalmente erróneos y difíciles de detectar.

Ajuste de recursos: no hay milicores ni sobrecompromiso

En CPU estamos acostumbrados a milicores, sobrecompromiso, ráfagas, límites que solo throttlean o que provocan OOM kill. En GPU, casi nada de eso aplica. Una GPU se solicita como recurso de número entero: nvidia.com/gpu: 1. Pides GPUs completas, la solicitud y el límite deben coincidir, y no hay sobrecompromiso en el planificador. La compartición fraccionaria que necesitas para inferencia ocurre por debajo del planificador mediante time-slicing o MIG, y las peticiones de Kubernetes no encajan bien. Así que la premisa básica de ajuste (comparar lo solicitado con lo usado y reclamar la diferencia) apenas existe para GPUs al principio. Tienes que calcular qué parte de la capacidad de la GPU recibió una carga antes de poder hablar de desperdicio.

Barreras de seguridad: el peligro de NVIDIA_VISIBLE_DEVICES

El runtime de contenedores de NVIDIA mira una variable de entorno llamada NVIDIA_VISIBLE_DEVICES, y las imágenes base de CUDA la traen configurada para todas las GPUs. En un entorno normal, el plugin de dispositivo la sobrescribe e inyecta solo las GPUs asignadas al pod. Pero si nada la sobrescribe o el runtime está configurado para respetar la variable del contenedor, un pod puede ver y acaparar todas las GPUs de la máquina, sin importar lo que Kubernetes crea que asignó. Lo que el planificador registró como asignado y lo que realmente se ejecutó en el hardware pueden divergir significativamente. Para obtener el número real, hay que mirar a nivel de proceso y compararlo con lo que Kubernetes cree que hizo.

Definición de utilización: no te fíes del número grande

Cuando un gráfico de CPU dice 80%, sabes lo que ves. La utilización de GPU es más difusa. La métrica habitual indica que un kernel se ejecutó en la GPU durante una fracción de la ventana de muestreo, pero no cuánto cómputo o ancho de banda de memoria se quemó. Puedes ver GPUs al 100% de utilización mientras el cómputo apenas hace nada. Y a menudo lo que se agota primero es la memoria, porque frameworks como vLLM acaparan la mayor parte de la GPU al arrancar, necesiten o no. Conviene determinar pronto qué señal importa para tus cargas: ocupación de cómputo, huella de memoria, ancho de banda o potencia. Si te fías del titular, puedes sacar conclusiones equivocadas.

Atribución: factura por memoria, no por cómputo

La librería NVML de NVIDIA dice, por proceso en una GPU, cuánta memoria retiene, y puedes rastrear cada proceso hasta el pod y el equipo propietario. Los números son fiables, con un asterisco: no sumarán el total de la tarjeta, porque el driver reserva una porción de memoria para sí mismo que no pertenece a ninguna carga. El cómputo es donde se desmorona, y merece la pena entender por qué. Imagina una cocina compartida: la memoria es el espacio de trabajo, ves dónde están los ingredientes. El cómputo es el fogón y todos se turnan en ráfagas de milisegundos. Lo que NVIDIA da no es "cuánto tiempo de fogón tuvo cada cocinero", sino una bandera que se comprueba muchas veces por segundo preguntando "¿estaba este cocinero haciendo algo ahora?". Si dos personas trabajan, ambas banderas dicen sí casi todo el tiempo, así que tienes dos trabajos que parecen 90% ocupados, lo cual es cierto pero no dice nada sobre quién hizo más. Esa medición sirve en un escenario donde la GPU se turna estrictamente entre trabajos uno a uno, donde el modo de contabilidad de DCGM o el muestreo por PID de nvidia-smi puede aproximar la cuota de cada trabajo. Se rompe cuando los trabajos se ejecutan genuinamente en paralelo, que es justo lo que se elige para mejorar la utilización. Si dos equipos comparten GPU, nada disponible hoy dirá cuál quemó el 70% y cuál el 30%. La decisión práctica es facturar por memoria, donde los datos aguantan, y tratar el cómputo como una señal para impulsar el chargeback. La equidad mediante precisión entre equipos importa cuando quieres repartir costes de forma justa.

Qué significa para tu pyme y qué recomendamos

Si estás empezando con IA local o cargas GPU en Kubernetes, no subestimes la complejidad de la visibilidad y el control de costes. En ForgeNEX recomendamos:

• Empieza simple: si tu equipo es pequeño, valora alternativas gestionadas como Amazon ECS, que ya autorrepara GPUs e instancias, antes de montar un clúster Kubernetes con GPUs compartidas.
• Define tu estrategia de atribución desde el día uno: factura por memoria, que es medible, y usa el cómputo solo como indicador.
• Configura barreras de seguridad: revisa que NVIDIA_VISIBLE_DEVICES no exponga GPUs no asignadas. Un pod no debería ver más GPUs de las que Kubernetes le dio.
• Elige bien tus métricas: no te quedes con el número grande de utilización; mira ocupación de cómputo, memoria, ancho de banda o potencia según tu carga.
• Planifica el reparto de costes: la GPU es la línea más cara; sin datos fiables, el chargeback interno será injusto y generará conflictos.

Si necesitas ayuda para montar una plataforma de IA en Kubernetes con visibilidad y control de costes, en ForgeNEX podemos ayudarte. También te puede interesar nuestro artículo sobre IA local para empresas: cuándo compensa y cómo empezar.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.