Las cargas de IA no son solo prompts y modelos. También son contenedores, GPUs, colas, storage, secrets, routing, jobs batch, rollouts, dashboards y dominios de fallo. Kubernetes importa porque ofrece un plano de control compartido para ejecutar esa infraestructura compleja con reglas repetibles.
La encuesta anual Cloud Native 2025 de CNCF, publicada en enero de 2026, dice que Kubernetes se consolidó como el sistema operativo de facto para IA, con 82% de los usuarios de contenedores ejecutando Kubernetes en producción. Un post complementario de CNCF también informa que 66% de las organizaciones usan Kubernetes para hospedar cargas de IA generativa. Esas cifras muestran que la infraestructura de IA está pasando de experimentos a plataformas compartidas.
Eso no significa que todo proyecto de IA necesite Kubernetes desde el primer día. Un asistente local pequeño puede correr en una máquina. Una API simple puede vivir en un Worker o VM. Kubernetes se vuelve interesante cuando la carga necesita scheduling, aislamiento, GPUs, autoscaling, rollouts, ownership de varios equipos y observabilidad entre servicios.
Las cargas web tradicionales compiten sobre todo por CPU y memoria. Las cargas de IA suelen competir por aceleradores escasos. La documentación de Kubernetes explica que los proveedores de GPU exponen dispositivos mediante device plugins, y los pods solicitan recursos como nvidia.com/gpu. Eso vuelve las GPUs programables, pero no las vuelve baratas, infinitas ni automáticamente eficientes.
La plataforma debe responder preguntas prácticas: qué modelo recibe el nodo caro, qué jobs pueden esperar en cola, qué workloads pueden correr en CPU, qué modelos pueden escalar a cero y qué servicios necesitan capacidad caliente porque el cold start tarda demasiado. Platform engineering para IA es parte scheduling y parte economía de producto.
Un buen cluster de IA no trata todos los pods igual. La inferencia online quiere baja latencia y capacidad caliente predecible. Los embeddings batch toleran colas. Los entrenamientos pueden correr durante horas. La preparación de datos suele cargar CPU e IO. Los servicios de observabilidad y APIs no deberían ser expulsados porque un job de modelo consumió el cluster.
Para una implementación práctica, diseñaría una pequeña plataforma de IA en Kubernetes con tres carriles: servicio de inferencia online, worker de embeddings con cola y API de plataforma. El sistema tendría node pools separados, resource requests y limits, quotas por namespace, gestión de secrets, dashboards y gates de rollout.
El primer dashboard debería mostrar las señales aburridas que mantienen vivos los sistemas de IA: p95 de latencia, volumen de peticiones, utilización de GPU, profundidad de cola, versión del modelo, tasa de error, costo de compute o tokens, cold starts y estado de despliegue.
Las cargas de IA crean nuevas formas de fallo. Un rollout malo de modelo puede aumentar latencia sin tumbar pods. Una base vectorial puede devolver contexto antiguo. Un nodo GPU puede verse sano para Kubernetes mientras el model server está saturado. Un job batch puede perjudicar la inferencia online si las quotas son débiles. Una evaluación sin límite puede quemar el presupuesto mensual.
Kubernetes ofrece los bloques. Platform engineering convierte esos bloques en guardrails: namespaces, quotas, admission policies, estrategias de deploy, probes, autoscaling, priority classes y dashboards alineados con cómo falla realmente el producto de IA.
| Fallo | Síntoma | Control de plataforma |
|---|---|---|
| Falta de GPU | Pods de inferencia pendientes o jobs retrasados. | Node pools, quotas, priority classes y política de cola. |
| Rollout malo | Sube la latencia o baja la calidad tras el deploy. | Canary, métricas por versión y rollback automático. |
| Cola saturada | Embeddings se atrasan y los datos quedan antiguos. | Alertas de cola, autoscaling de workers y backpressure. |
| Costo fuera de control | Horas de GPU o inferencias se disparan. | Alertas de presupuesto, rate limits y costo por namespace. |
| Brecha de observabilidad | Pods verdes, pero experiencia degradada. | SLIs de latencia, saturación, versión de modelo y resultado de negocio. |
Kubernetes no es valioso para IA porque esté de moda. Es valioso cuando se convierte en la capa operacional común para workloads difíciles: serving, colas, GPUs, storage, rollouts, políticas y observabilidad. La victoria real no es correr un modelo en un pod. Es darle al sistema completo de IA un plano de control confiable.
Artículo sobre Kubernetes como sistema operativo para cargas de IA que cubre GPU scheduling, device plugins, platform engineering, model serving, node pools, workers con cola, observabilidad, autoscaling, dominios de fallo e infraestructura cloud native para IA.