Las herramientas de supervisión de CPU y memoria no se trasladan a las unidades de procesamiento gráfico GPU en Kubernetes con la misma facilidad. Aunque la plataforma suele proporcionar métricas de uso a nivel de contenedor o Pod, cuando comparten una GPU los equipos de plataformas necesitan construir por sí mismos la mayor parte de las capas de visibilidad, asignación y facturación, desde la recopilación de datos hasta la determinación de la parte del costo correspondiente a cada equipo.
La importancia del problema se debe a que la GPU suele representar la partida más cara de la factura de infraestructura. El análisis señala que el costo operativo no se limita al precio del nodo, sino que también incluye el tiempo de ingeniería necesario para compensar las brechas de medición, verificar la precisión de las cifras y evitar que las cargas superen lo que Kubernetes les asignó.
¿Por qué no bastan las métricas habituales?
La herramienta NVIDIA DCGM exporter, con la que comienzan muchos operadores, proporciona por defecto datos a nivel del dispositivo físico. Cuando un Pod posee una unidad GPU completa, esto puede ser suficiente, pero la situación cambia al utilizar time-slicing o MPS para compartir el dispositivo. En ese caso, puede aparecer el mismo valor para cada Pod que utiliza una GPU, dando la impresión de que tres cargas consumieron el 300% de una unidad que en realidad no existe.
El problema es que los gráficos pueden parecer correctos aunque los datos subyacentes no sean válidos para la atribución. Por ello, los equipos pueden construir informes y paneles de seguimiento completos sobre cifras que en realidad no distinguen entre los consumidores.
¿Qué cambia en la práctica para los equipos de plataformas?
La GPU también difiere de la CPU en el modelo de asignación de recursos. En Kubernetes, la GPU suele aparecer como un recurso entero, como nvidia.com/gpu: 1, y el planificador no permite gestionar partes fraccionarias de la manera habitual con los procesadores. La compartición real ocurre por debajo del nivel del planificador mediante time-slicing, MPS o MIG, lo que hace más compleja la comparación entre lo que solicitó la carga y lo que utilizó.
Los equipos también necesitan controles independientes para asegurarse de que lo que Kubernetes registró como asignado coincide con aquello a lo que la aplicación puede acceder realmente. La variable de entorno NVIDIA_VISIBLE_DEVICES puede hacer que el contenedor vea todas las unidades GPU del nodo, aunque el planificador solo le haya asignado una, si una configuración adecuada no impide este comportamiento.
Además, la frase «uso de GPU del 80%» no necesariamente tiene un único significado. Puede medir únicamente la existencia de un núcleo activo durante parte de la ventana de muestreo, sin aclarar el consumo de capacidad de cálculo o el ancho de banda de la memoria. En algunos marcos de trabajo, como vLLM, puede reservarse la mayor parte de la memoria de la GPU al iniciarse, lo que convierte la memoria o el ancho de banda en indicadores más importantes que la cifra general de uso.
Facturación: la memoria es más fácil de atribuir que el cómputo
La biblioteca NVIDIA NVML puede mostrar cuánta memoria mantiene cada process y luego vincular el proceso con el Pod y el equipo responsable, con la salvedad de que la suma de los valores no equivaldrá a toda la memoria de la tarjeta porque una parte la reserva el controlador para sí mismo.
La atribución del tiempo de cómputo entre cargas que se ejecutan en paralelo tiene una precisión limitada. Pueden aparecer dos cargas como activas al 90% cada una, sin que las métricas aclaren cuál consumió el 70% de la capacidad y cuál consumió el 30%. Por ello, el análisis plantea utilizar la memoria de la GPU como base práctica para la facturación interna y tratar la medición del cómputo como un indicador operativo, no como una referencia precisa para cobrar.
La elección del modelo de compartición cambia los cálculos
Compartir una GPU no implica un único modelo. El time-slicing se turna en el dispositivo sin aislamiento, MPS permite ejecutar al mismo tiempo núcleos de procesos diferentes, mientras que MIG divide el hardware en partes fijas. Sin embargo, los servicios en la nube pueden cobrar por la GPU física completa incluso cuando se utiliza solo una parte de ella, y las tarjetas de las categorías A100 y H100 pueden dividirse en un máximo de siete instancias, según el artículo.
Dynamic Resource Allocation (DRA) apunta a convertirse en el camino futuro para la gestión de recursos, pero todavía se encuentra en una etapa de madurez, y las herramientas que lo rodean, incluidas las herramientas de escalado como Karpenter, siguen este desarrollo.
¿Por qué importa esta noticia?
En AWS, el precio de la GPU compatible con MIG más barata de la categoría A100 ronda los 22 dólares por hora, o aproximadamente 14 dólares al utilizar precios spot, frente a unos 5 dólares por hora de una instancia comparable basada únicamente en CPU, según el artículo. Por tanto, un error en la atribución del uso no constituye un pequeño problema contable, sino que puede afectar directamente las decisiones sobre capacidad, costos y equidad en la distribución de la carga entre los equipos.
La conclusión editorial es que ejecutar GPU en Kubernetes todavía requiere un modelo operativo diferente del modelo de CPU y memoria. Los equipos de plataformas deben determinar qué puede medirse con precisión, establecer reglas claras para distribuir los costos y evitar basar decisiones contables en un indicador general de GPU que no describa el consumo real. Al mismo tiempo, la fuente señala que la madurez de DRA y la partición del hardware podrían reducir gradualmente la brecha, pero el momento en que ocurrirá y los límites de las herramientas actuales siguen siendo preguntas abiertas.