Por qué la observabilidad de GPU en Kubernetes requiere ingeniería a medida

Ejecutar cargas de trabajo de IA en Kubernetes revela un marcado contraste entre la gestión de CPU y GPU. Mientras que el uso de CPU y memoria incluye métricas nativas por pod y atribución de costos, las GPUs compartidas no ofrecen ninguna de estas funcionalidades de forma predeterminada. A octubre de 2026, los ingenieros de plataforma deben reconstruir manualmente la visibilidad de su componente de infraestructura más caro.

Qué ocurrió

Durante años, los usuarios de Kubernetes han confiado en paneles de control estándar para rastrear el consumo de recursos. Estas herramientas comparan lo que un contenedor solicitó frente a lo que realmente usó, permitiendo a los equipos identificar desperdicios y asignar costos por namespace. Este modelo funciona sin problemas para CPU y memoria porque el kernel rastrea automáticamente el uso por contenedor. Sin embargo, este flujo de trabajo establecido se rompe completamente cuando se aplica a las Unidades de Procesamiento Gráfico (GPU).

Cuando las cargas de trabajo se trasladan a las GPUs, las suposiciones que se mantienen verdaderas para otros recursos ya no aplican. Los equipos de plataforma se ven obligados a reconstruir cada capa de visibilidad desde cero. Deben crear sus propias métricas, definir sus propios estándares de precisión e inventar reglas para dividir las facturas. Este esfuerzo manual es particularmente doloroso porque los costos de GPU representan el mayor gasto en los presupuestos de infraestructura de IA moderna.

Cómo funciona

El problema central radica en cómo se exponen las métricas de GPU. Herramientas como el exporter DCGM de NVIDIA reportan datos a nivel de dispositivo físico por defecto. Este enfoque funciona cuando un único pod posee toda una GPU. No obstante, cuando múltiples pods comparten una GPU mediante time-slicing o Multi-Process Service (MPS), el exporter asigna el mismo valor total de uso a cada pod. Si tres pods comparten una GPU, cada uno parece usar el 100% del dispositivo, resultando en una cifra de utilización total absurda del 300%. El driver expone solo un conjunto de contadores para toda la GPU, haciendo imposible distinguir el consumo individual de cada carga de trabajo.

El dimensionamiento correcto (rightsizing) también se vuelve complejo. A diferencia de las CPUs, que soportan millicores y sobrecompromiso (overcommitting), las GPUs suelen solicitarse como unidades enteras. El fraccionamiento ocurre por debajo del scheduler mediante time-slicing o particiones Multi-Instance GPU (MIG), lo que significa que las solicitudes de Kubernetes no se alinean perfectamente con el uso real. Además, las métricas de utilización de GPU son ambiguas. Una GPU puede mostrar un 100% de utilización mientras realiza un mínimo de cómputo, ya que los frameworks a menudo reservan la mayor parte de la memoria al inicio. El uso de memoria sigue siendo la métrica más fiable para la atribución, ya que el tiempo de cómputo es difícil de medir con precisión en entornos concurrentes.

Detalles clave

• El exporter DCGM de NVIDIA reporta a nivel de dispositivo, causando números de uso inflados cuando las GPUs se comparten entre múltiples pods.
• Las solicitudes de GPU en Kubernetes son recursos de número entero, lo que impide las estrategias de sobrecompromiso y ráfagas (bursting) comunes con las CPUs.
• La variable de entorno NVIDIA_VISIBLE_DEVICES puede permitir que los pods accedan a todas las GPUs en un nodo si el plugin de dispositivos no la sobrescribe correctamente.
• Las métricas de utilización de cómputo no son fiables para cargas de trabajo compartidas, ya que indican actividad en lugar de consumo proporcional de recursos.
• El uso de memoria es la señal más precisa para la atribución de costos, aunque no tiene en cuenta las rebanadas de memoria reservadas por el driver.
• Los proveedores de nube facturan los nodos GPU como partidas únicas, requiriendo una descomposición manual para asignar costos a modelos o equipos específicos.

Por qué importa

Para los desarrolladores de software, la falta de observabilidad nativa de GPU se traduce directamente en trabajo pesado de ingeniería y opacidad financiera. Los equipos no pueden simplemente adoptar sus manuales existentes de monitoreo de CPU. En cambio, deben invertir tiempo significativo construyendo herramientas personalizadas para rastrear el uso, aplicar salvaguardas y dividir costos. Esto desvía recursos del desarrollo de producto al mantenimiento de infraestructura. Sin datos precisos, las organizaciones corren el riesgo de sobreaprovisionar hardware costoso o de no repercutir los costos a los equipos correctos, llevando a ineficiencias presupuestarias.

La complejidad se extiende a las decisiones de arquitectura técnica. Diferentes paradigmas de compartición, como time-slicing, MPS y MIG, cambian las matemáticas subyacentes para la asignación de recursos. La Asignación Dinámica de Recursos (DRA) está madurando en Kubernetes, pero el ecosistema, incluidos los autoscalers, aún está alcanzándola. Los ingenieros deben entender qué modo de compartición usan sus nodos para interpretar las métricas correctamente. Malinterpretar estas señales puede llevar a decisiones de escalado incorrectas y cuellos de botella de rendimiento.

Qué puedes hacer

• Audita tu configuración actual de monitoreo de GPU para identificar si las métricas están infladas debido a que las GPUs son compartidas.
• Prioriza el uso de memoria como la métrica principal para la atribución de costos, entendiendo sus limitaciones respecto a la reserva del driver.
• Verifica que el plugin de dispositivos esté configurado correctamente para aislar el acceso a las GPUs y evitar fugas de visibilidad.
• Evalúa el impacto de los diferentes modos de compartición (time-slicing, MPS, MIG) en tus cálculos de asignación de recursos.
• Considera la adopción progresiva de Dynamic Resource Allocation (DRA) a medida que madure el soporte en el ecosistema de Kubernetes.
• Desarrolla scripts personalizados para descomponer las facturas de los proveedores de nube y asignar costos de GPU a equipos o modelos específicos.