Introducción
Un equipo de plataforma provisiona 16 GPUs A100 para un cluster de inferencia de LLMs. El dashboards muestra 34% de utilization del acelerador. La respuesta instintiva: escalar más GPUs. Pero el problema real está tres capas antes: el CPU que tokeniza prompts no alcanza a alimentar el pipeline, el NVMe donde viven los pesos del modelo tiene IOPS saturados, y la red entre el pod de preprocessing y el pod de inferencia introduce 12 ms de latencia por salto. Agregar GPUs en ese escenario no mueve la aguja. La infraestructura de IA no es un cluster de aceleradores con servicios de soporte alrededor. Es un sistema interconectado de cómputo, memoria, almacenamiento y red donde cada etapa impone restricciones distintas.
Qué ocurrió
Kasia Hilborne, de Vultr, publicó en el blog de la CNCF (4 de septiembre de 2026) un análisis sobre por qué el platform engineering de IA es, en esencia, un problema de infraestructura heterogénea. El argumento central: las conversaciones sobre infraestructura de IA arrancan por los GPUs porque son el componente más caro y visible, pero un workload de producción atraviesa múltiples etapas que dependen de recursos radicalmente distintos.
El pipeline simplificado que describe el artículo —Data → CPU preprocessing → GPU inference → CPU post-processing → application— ilustra que el GPU ejecuta la operación más intensiva en cómputo, pero el rendimiento end-to-end queda determinado por el eslabón más débil en toda la cadena. Si el preprocessing no entrega batches a la velocidad que el acelerador consume, la GPU queda idle. Si el storage no sirve artefactos de modelo (pesos de 70 GB para un LLaMA-3-70B, por ejemplo) en el tiempo de arranque del pod, el cold start se dispara. La publicación posiciona a Kubernetes como la capa de orquestación común que permite modelar esta heterogeneidad, y destaca Dynamic Resource Allocation (DRA, GA desde Kubernetes 1.32) como el mecanismo declarativo para solicitar dispositivos especializados dentro del mismo resource model que el resto de la aplicación.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma, este cambio de paradigma tiene consecuencias operativas concretas. Primero: el capacity planning deja de ser un ejercicio unidimensional. No alcanza con calcular cuántas GPUs necesita un workload; hay que dimensionar CPU cores para tokenización y retrieval, ancho de banda de red entre stages, y throughput de I/O para carga de modelos. Un equipo que sobredimensiona GPUs y subdimensiona la red entre pods de preprocessing e inferencia paga por capacidad ociosa del acelerador.
Segundo: la observabilidad tradicional se queda corta. Un métrica como DCGM_FI_DEV_GPU_UTIL en Prometheus dice qué porcentaje del tiempo el SM (Streaming Multiprocessor) estuvo activo. No dice si ese 34% refleja baja demanda o si el GPU está bloqueado esperando el próximo batch desde un pod de preprocessing en otro nodo. Sin correlación entre telemetría de infraestructura y telemetría de aplicación, los equipos diagnostican síntomas en el acelerador cuando la causa raíz está en el CPU, en el storage o en el scheduling.
Tercero: en entornos multi-tenant donde comparten un pool de GPUs con workloads de CPU intensivo, la falta de aislamiento de recursos no-GPU (memoria de sistema, ancho de banda de red, IOPS de disco) genera noisy neighbors que degradan el throughput de inferencia sin que ningún alerta de GPU lo registre.
Detalles técnicos
DRA (Dynamic Resource Allocation) reemplaza el modelo estático de nvidia.com/gpu: 1 en los resources.limits del pod por un esquema declarativo basado en ResourceClaim y ResourceSlice. En Kubernetes 1.32+, un workload puede especificar requisitos de dispositivo sin atarse a un vendor o a una topology fija:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: gpu-inference-claim
spec:
resources:
– name: gpu
device:
requests:
– name: accelerator
kind: DeviceClass
name: nvidia-a100-40g
—
apiVersion: v1
kind: Pod
metadata:
name: llm-inference
spec:
resourceClaims:
– name: gpu
resourceClaimName: gpu-inference-claim
containers:
– name: inference-server
image: vllm/vllm-openai:v0.6.3
resources:
requests:
cpu: «8»
memory: «64Gi»
limits:
cpu: «16»
memory: «128Gi»
El punto relevante no es la sintaxis de DRA en sí, sino la dirección: cómputo especializado y recursos clásicos (CPU, memoria) coexisten en un mismo modelo declarativo. Esto habilita que un scheduler como Kueue o Volcano tome decisiones de colocación considerando la topología completa del workload, no solo la disponibilidad de GPUs.
En el plano de red, Cilium (proyecto CNCF) permite aplicar políticas de identificador a nivel de workload que respeten la separación entre stages del pipeline. Un CiliumNetworkPolicy puede restringir que el pod de preprocessing solo comunique con el pod de inferencia por un puerto específico, y medir la latencia entre ambos con hubble sin instrumentar el código de aplicación.
Qué deberían hacer los administradores y equipos técnicos
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: pipeline-isolation
spec:
endpointSelector:
matchLabels:
stage: inference
ingress:
– fromEndpoints:
– matchLabels:
stage: preprocessing
toPorts:
– ports:
– port: «8000»
protocol: TCP
Conclusión
La infraestructura de IA en producción no se diseña comprando GPUs y esperando que el resto se resuelva solo. Es un problema de ingeniería de plataforma donde cada etapa del pipeline impone requisitos distintos de cómputo, memoria, I/O y red. Kubernetes ofrece el control plane común; DRA expande cómo los dispositivos especializados participan de ese modelo. Pero la decisión conceptual —optimizar el sistema completo en vez de un componente aislado— es lo que separa una plataforma que entrega throughput predecible de una que quema presupuesto en aceleradores ociosos mientras un cuello de botella de 8 vCPUs limita toda la cadena.
Fuentes
- https://www.cncf.io/blog/2026/09/04/cpu-gpu-why-ai-platform-engineering-is-a-heterogeneous-infrastructure-problem/