Kubernetes se está convirtiendo en el substrato invisible de la inferencia IA

Lo que empezó como una pieza de infraestructura para microservicios web es hoy la pieza más estratégica de cualquier stack de IA serio. Kubernetes no fue diseñado pensando en GPUs ni en inferencia de modelos, pero la comunidad lo ha ido adaptando hasta convertirlo en el plano de control de facto para cargas de trabajo de IA a escala.

El cambio no es trivial. Orquestar contenedores de aplicaciones web y orquestar pods de inferencia con acceso a GPUs son problemas con características muy distintas: tiempos de arranque, afinidad de hardware, patrones de consumo de memoria, scheduling de lotes. Kubernetes ha tenido que evolucionar, y lo ha hecho a través de una capa de operadores y extensiones que en 2026 ya forman un ecosistema robusto.

Los operadores que están cambiando el juego

KEDA (Kubernetes Event-Driven Autoscaling) se ha convertido en la pieza estándar para escalar réplicas de inferencia basándose en métricas de cola: número de requests pendientes, latencia p95, tokens por segundo. El autoscaler nativo de Kubernetes basado en CPU no era suficiente para este tipo de cargas.

GPU Operator de NVIDIA automatiza todo lo que antes requería configuración manual: drivers, runtime de contenedor, exportador de métricas, time-slicing de GPUs. En clusters grandes, la diferencia entre gestionarlo a mano y usar el operador es de días de operaciones por semana.

Kueue resuelve el scheduling de batch jobs de entrenamiento: prioridades, cuotas por equipo, gestión de la cola cuando no hay recursos disponibles. Es el pilar de los sistemas de entrenamiento distribuido sobre Kubernetes.

# Ejemplo de NodePool con afinidad de GPU
apiVersion: karpenter.sh/v1
kind: NodePool
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-gpu-name
          operator: In
          values: ["h100", "a100"]

El problema del cold start

El talón de Aquiles de la inferencia sobre Kubernetes sigue siendo el tiempo de arranque. Cargar un modelo de 70B en una GPU puede tardar varios minutos, lo que hace que el autoscaling reactivo sea poco práctico para endpoints con baja latencia. Las soluciones actuales van desde mantener réplicas mínimas calientes hasta sistemas de precarga predictiva basados en patrones de tráfico histórico.

Knative Serving, combinado con técnicas de snapshot de memoria de GPU, está reduciendo esos tiempos en algunos entornos a menos de 30 segundos. Todavía lejos del ideal, pero la dirección es la correcta.