Kubernetes y el costo oculto de los modelos de IA: cómo ajustar recursos sin arriesgar producción

Introducción

En mayo de 2025, un equipo de infraestructura en Mercado Libre reportó un aumento del 312% en el costo mensual de un cluster de Kubernetes dedicado a inferencia de modelos de lenguaje. El detonante no fue un burst de tráfico, sino un simple cambio en los parámetros de los Horizontal Pod Autoscalers (HPA): al escalar automáticamente frente a picos de latencia, los pods mantuvieron asignaciones de CPU y memoria sobredimensionadas incluso después de que la carga bajara. El resultado: $28.000 USD extra en la factura de AWS en un solo mes, según datos internos filtrados al equipo de FinOps.

El caso no es aislado. Según el CloudBolt Research Report de marzo de 2026, el 89% de las organizaciones con cargas de trabajo de IA en cloud priorizan el rightsizing en Kubernetes como estrategia para controlar costos. Sin embargo, solo el 27% confía en automatizar ajustes de CPU y memoria en producción. La paradoja es clara: los mismos equipos que despliegan múltiples veces al día mediante CI/CD desconfían cuando se trata de delegar el ajuste de recursos a una máquina. ¿Por qué esta brecha entre la urgencia y la acción?

Qué ocurrió

El problema tiene raíces técnicas y organizacionales. Desde lo técnico, los modelos de IA —especialmente los basados en transformers como Llama 3 o Mistral— no siguen patrones de consumo lineales. Un pod que en pruebas consume 1.5 vCPU y 4 GB de RAM puede dispararse a 8 vCPU y 16 GB durante la inferencia en batch, pero nunca libera esos recursos por completo. Los mecanismos tradicionales de Kubernetes, como el HPA o el Vertical Pod Autoscaler (VPA), están diseñados para aplicaciones stateless con patrones predecibles, no para workloads con comportamientos esporádicos y costos variables.

Desde lo organizacional, el desafío es cultural. En una encuesta de StormForge a 1.200 ingenieros de Kubernetes en mayo de 2025, el 71% respondió que exige revisión humana antes de aplicar ajustes de recursos, incluso cuando los datos históricos muestran que la optimización manual escala mal en entornos dinámicos. La desconfianza no es infundada: un error en los límites de un pod puede llevar a:

• OOMKilled (Out Of Memory Killed) en pods críticos.
• CPU throttling no detectado, degradando el rendimiento de modelos de IA en un 40% según pruebas internas de CloudBolt.
• Rollbacks fallidos cuando los ajustes automáticos generan inestabilidad en clusters con node pools heterogéneos.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para DevOps

El costo oculto de los modelos de IA en Kubernetes se manifiesta en tres dimensiones:

1. Facturación inflada: Un pod de inferencia de Llama 3-8B en EKS con 4 vCPU y 16 GB cuesta $3.200 USD/mes en instancias g4dn.xlarge. Si el pod solo usa el 20% de esos recursos en promedio, la organización paga $2.560 USD adicionales por sobreaprovisionamiento. En clusters con decenas de pods, esto escala a cientos de miles de dólares anuales.

1. Degradación del SLA: Los ajustes manuales de recursos introducen latencia en el escalado. Según datos de StormForge, un equipo que aplica rightsizing manualmente tarda 3.7 horas en detectar y corregir un pod sobreaprovisionado, frente a 12 minutos con automatización. Durante ese tiempo, el cluster opera con recursos ociosos que impactan en costos y rendimiento.

1. Inconsistencia entre entornos: Los modelos de IA se desarrollan en notebooks con 4 GB de RAM, pero se despliegan en producción con 16 GB «por si acaso». Esta brecha —llamada environment drift— es responsable del 68% de los incidentes reportados en equipos de SRE según el State of Kubernetes 2025 de Red Hat.

Para Infraestructura y Cloud

El rightsizing automatizado no es solo un problema de costos, sino de eficiencia de infraestructura. En AWS, por ejemplo, las instancias G5 (GPU A10G) tienen un costo de $1.200 USD/mes en on-demand. Si un pod de inferencia solo usa el 30% de la GPU, la organización está desperdiciando $840 USD/mes por instancia. Con spot instances, el desperdicio es menor, pero el riesgo de preemption aumenta.

Además, los clusters sobreaprovisionados saturan los node pools:

• En un cluster de 50 nodos con pods sobreaprovisionados, la capacidad útil cae un 22% por fragmentación de recursos (datos de Datadog).
• Los autoscalers verticales (VPA) pueden generar thrashing en nodos cuando ajustan recursos dinámicamente, llevando a evictions no planificadas.

Para Seguridad

El rightsizing mal aplicado introduce riesgos de seguridad indirectos:

• Exposición de datos: Los pods con memoria excesiva pueden dumppear heap en archivos temporales, exponiendo datos sensibles si el cluster no tiene políticas de tmpfs configuradas.
• Ataques de resource exhaustion: Un atacante puede saturar un pod con requests altos de CPU para degradar el rendimiento de modelos críticos (ej: sistemas de fraud detection).
• Incumplimiento de licencias: Algunas licencias de software (ej: NVIDIA AI Enterprise) limitan el uso de GPUs por nodo. Un pod sobreaprovisionado puede violar los términos y generar multas.

Detalles técnicos

Componentes afectados y versiones

El problema no es exclusivo de Kubernetes 1.28+, pero las herramientas modernas lo mitigan mejor:

Los modelos de IA generan desperdicio por:

1. Requests vs. Limits: Kubernetes asigna recursos basados en requests, pero los limits pueden ser arbitrarios. Un pod con requests: 2, limits: 8 puede usar 6 GB de RAM aunque solo necesite 1.5 GB.
2. Overhead de sidecars: En clusters con Istio o Linkerd, los sidecars consumen hasta 1 vCPU y 500 MB de RAM por pod. Si el pod principal usa 1.5 GB, el overhead puede representar 25% del consumo total.
3. Cold starts en modelos: Un pod de inferencia que tarda 8 segundos en warm-up puede mantenerse activo con recursos reservados para evitar el startup time, incluso cuando está inactivo.

Ejemplo de desperdicio en producción

En un cluster de EKS con 2.400 pods de modelos de IA (Llama 3-8B y Stable Diffusion), los equipos reportaron:

• 38% de pods con requests superiores al 150% del uso real (datos de KubeCost).
• 12% de pods con limits de CPU que nunca se alcanzan, pero reservan recursos.
• Costos evitables: $18.000 USD/mes con ajustes manuales vs. $5.200 USD/mes con automatización (reducción del 71%).

Qué deberían hacer los administradores y equipos técnicos

1. Auditar el estado actual del cluster

# Instalar Goldilocks para análisis de VPA
kubectl apply -f https://raw.githubusercontent.com/FairwindsOps/goldilocks/v4.6.0/deploy/goldilocks.yaml
# Generar informe de recomendaciones
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods | jq -r '.items[] | select(.metadata.labels.app=="ai-model") | .spec.containers[].resources'

• container_memory_working_set_bytes (uso real de memoria).
• container_cpu_usage_seconds_total (uso real de CPU).
• kube_pod_container_resource_requests{container!="POD",container!="istio-proxy"} (recursos reservados vs. usados).

2. Implementar herramientas de rightsizing automatizado

# Ejemplo de configuración para un pod de Llama 3-8B
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: llama-3-8b-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: llama-3-8b
  updatePolicy:
    updateMode: "Auto"  # Ajusta automáticamente requests/limits
  resourcePolicy:
    containerPolicies:
    - containerName: "llama-3-8b"
      minAllowed:
        cpu: "1"
        memory: "4Gi"
      maxAllowed:
        cpu: "4"
        memory: "16Gi"

3. Validar con canary deployments y rollback automatizado

1. Crear un namespace de pruebas:

kubectl create namespace ai-rightsizing-test
kubectl label namespace ai-rightsizing-test istio-injection=enabled

1. Desplegar un pod con ajustes automáticos en modo dry-run:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llama-3-8b-canary
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: llama-3-8b
        image: ghcr.io/meta-llama/llama-3-8b:latest
        resources:
          requests:
            cpu: "1"
            memory: "4Gi"
          limits:
            cpu: "2"
            memory: "8Gi"

1. Monitorear con Prometheus Alerts:

- alert: PodOOMKilled
  expr: increase(kube_pod_container_status_last_oom_kill_time_seconds[5m]) > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} fue OOMKilled en {{ $labels.namespace }}"

4. Ajustar políticas de node pools y scheduling

• Usar node affinity para separar workloads de IA:

nodeSelector:
  kubernetes.io/arch: amd64
  node.kubernetes.io/instance-type: "g5.xlarge"  # GPU dedicada

• Configurar pod disruption budgets (PDB):

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: llama-3-8b-pdb
spec:
  minAvailable: 90%
  selector:
    matchLabels:
      app: llama-3-8b

• Habilitar spot instances para pods sin estado:

# Ejemplo con Karpenter
kubectl patch deployment llama-3-8b -p '{"spec":{"template":{"spec":{"nodeSelector":{"karpenter.sh/capacity-type":"spot"}}}}'

5. Métricas de éxito y feedback loops

El rightsizing automatizado en Kubernetes no es un lujo, sino una necesidad financiera y operativa para equipos que escalan modelos de IA. La brecha de confianza —donde el 89% de las organizaciones prioriza la optimización pero solo el 27% la automatiza— se resuelve con tres pilares:

1. Datos reales (métricas de Prometheus, no guesstimates).
2. Herramientas nativas (VPA, Goldilocks, StormForge) configuradas para entornos de IA.
3. Procesos de validación (canary deployments, rollbacks automatizados, PDBs).

La trampa no está en la tecnología, sino en la mentalidad: los equipos que confían en la automatización para CI/CD deben aplicar esa misma lógica a los ajustes de recursos. Como advierte la COO de CloudBolt, «se necesita mucho tiempo para construir confianza en la automatización, pero un solo incidente de producción la destruye por completo». El costo de no actuar no es solo económico: es la diferencia entre un cluster que escala y uno que quema recursos —y facturas— a velocidad de GPU.