Kubernetes ya no es únicamente la capa que mantiene disponibles aplicaciones en contenedores. Se está convirtiendo en la infraestructura común sobre la que las empresas intentan operar inferencia de modelos, cargas con GPU, pipelines de machine learning y aplicaciones de IA generativa. La CNCF reportó que el 82% de los usuarios de contenedores ejecutaba Kubernetes en producción en su encuesta de 2025 —frente al 66% en 2023— y que el 66% de las organizaciones que hospedan modelos de IA generativa utiliza Kubernetes para administrar parte o toda su inferencia. Pero hay una señal de alerta: solo el 7% despliega modelos diariamente. El desafío, por tanto, ya no es demostrar que Kubernetes puede ejecutar IA, sino saber si la infraestructura empresarial puede hacerlo de forma continua, segura, observable y económicamente sostenible.
Kubernetes está emergiendo como una de las plataformas centrales para operacionalizar IA empresarial, especialmente inferencia. Sin embargo, tener un clúster Kubernetes en producción no significa tener una plataforma de IA lista para producción. La diferencia está en seis capacidades: aceleradores y capacidad, scheduling, distribución de modelos, serving y networking consciente de inferencia, observabilidad y autoscaling, y finalmente seguridad, gobierno y FinOps.
La tendencia tiene respaldo cuantitativo. La CNCF describe Kubernetes como el “de facto ‘operating system’ for AI” y reporta que el 82% de los usuarios de contenedores ya lo utiliza en producción. Entre las organizaciones que alojan modelos de IA generativa, el 66% ejecuta parte o toda la inferencia sobre Kubernetes. Al mismo tiempo, el 44% de las organizaciones encuestadas todavía no ejecuta cargas AI/ML sobre Kubernetes y solo el 7% afirma desplegar modelos diariamente. Es decir: la infraestructura cloud native ha madurado más rápido que muchas prácticas de operación de modelos.
El contexto empresarial vuelve esa brecha más importante. McKinsey reportó en agosto de 2026 que el 44% de los participantes de su encuesta ya veía la IA escalándose a nivel empresarial, frente al 38% un año antes. Sin embargo, uno de cada cinco afirmó que los costos operativos asociados a IA estaban limitando su uso y apenas cerca del 6% calificó como “AI high performer” bajo el criterio de impacto significativo en EBIT. La encuesta reunió 1.719 participantes en 97 países.
Gartner, por su parte, proyecta US$2,7 billones —trillion en nomenclatura anglosajona— de gasto mundial en IA durante 2026, un aumento interanual del 49,5%. Más relevante para la infraestructura: estima US$42.276 millones en IaaS optimizada para IA en 2026; dentro de ese segmento, la inferencia representaría US$23.300 millones frente a US$19.000 millones para entrenamiento, es decir, el 55% del gasto. La economía de la IA está pasando de “entrenar modelos” a mantener modelos ejecutándose permanentemente dentro de procesos empresariales.
Y ese cambio expone un problema conocido de cloud computing: el costo sin control. El State of the Cloud 2026 de Flexera, basado en más de 750 responsables y usuarios de cloud, encontró que administrar el gasto cloud sigue siendo un desafío principal para el 85% de los encuestados, mientras que el desperdicio estimado de IaaS y PaaS subió al 29%. El 73% opera entornos híbridos y el 53% identifica seguridad y cumplimiento como su principal reto para iniciativas de IA basadas en cloud.
La lectura estratégica es clara: Kubernetes puede convertirse en el plano operativo común de aplicaciones e IA, pero la empresa tiene que evolucionar de “administrar clústeres” a operar una plataforma de IA. Eso implica medir costo por modelo y por inferencia, utilizar métricas específicas de LLM, automatizar la capacidad GPU, introducir controles de gobernanza desde CI/CD y tratar el ciclo de vida del modelo como una cadena de suministro de software y datos, no como un artefacto aislado.
Kubernetes dejó de ser “solo contenedores”: la IA cambió la ecuación
Kubernetes nació y continúa definiéndose oficialmente como un motor de orquestación para automatizar el despliegue, escalamiento y administración de aplicaciones en contenedores. Lo nuevo no es esa función, sino el tipo de workload que está empezando a recibir. Entrenamiento distribuido, fine-tuning, batch inference, servidores de LLM, embeddings, rerankers, pipelines RAG, agentes y APIs de inferencia introducen patrones de consumo completamente diferentes a los de una aplicación web convencional.
Una aplicación web tradicional suele pedir CPU y memoria y escalar relativamente rápido. Un servicio de inferencia puede necesitar decenas o cientos de gigabytes de pesos, GPU escasa, afinidad topológica, un periodo considerable de inicialización, memoria dedicada al KV cache y métricas que Kubernetes no conoce de manera nativa, como tokens por segundo, time to first token o profundidad de la cola. AWS, por ejemplo, documenta explícitamente para inferencia en EKS métricas como request rate, token throughput, latencia y utilización del KV cache; Google recomienda configurar el autoscaling de LLM en GKE alrededor de métricas del servidor de inferencia y objetivos de rendimiento, no limitarlo a CPU.
Esto cambia incluso la definición de “utilización”. Una GPU al 95% puede significar eficiencia o puede esconder una cola creciendo hasta incumplir el SLO. Un clúster con CPU disponible puede estar completamente bloqueado porque no existe el tipo correcto de acelerador en la zona adecuada. Y diez réplicas de un modelo no garantizan diez veces más capacidad si el router distribuye tráfico sin considerar longitud del prompt, estado del KV cache o capacidad disponible en cada instancia. Es precisamente el tipo de problema que intenta abordar la Gateway API Inference Extension, proyecto del ecosistema Kubernetes orientado a estandarizar y optimizar el enrutamiento hacia workloads de inferencia generativa autoalojados.
La evolución de Kubernetes upstream durante 2026 muestra hasta qué punto estas cargas están influyendo en la plataforma. Al 19 de octubre de 2026, la rama más reciente es Kubernetes 1.37.1, publicada el 15 de septiembre. Kubernetes 1.37 llevó a beta el scale-to-zero del HorizontalPodAutoscaler para workloads con métricas externas u object metrics; avanzó Dynamic Resource Allocation para dispositivos especializados; y llevó a beta el gang scheduling, diseñado para admitir grupos de Pods bajo una estrategia “all-or-nothing”, particularmente relevante para entrenamiento distribuido y HPC.
También hay un detalle operativo urgente para plataformas autogestionadas: Kubernetes upstream marca el 27 de octubre de 2026 como fin de vida de la rama 1.34. Eso no significa que EKS, GKE o AKS necesariamente apliquen exactamente la misma ventana —cada servicio mantiene sus propias políticas—, pero sí refuerza una regla fundamental: una plataforma de IA no puede construirse sobre un clúster cuya estrategia de actualización ya está rezagada.
La administración de aceleradores también está cambiando. Dynamic Resource Allocation permite solicitar y compartir recursos asociados a dispositivos mediante ResourceClaim y DeviceClass; en Kubernetes 1.37, el soporte de DRA para extended resources alcanzó GA y otras integraciones con workloads continúan madurando. Esto apunta hacia una gestión de GPU y otros aceleradores más rica que el modelo histórico de recursos extendidos estáticos.
Los hyperscalers están siguiendo el mismo camino. AWS documenta NVIDIA GPU y AWS Trainium en EKS, con EKS Auto Mode o Karpenter para aprovisionamiento de nodos acelerados. Google publica guías específicas para autoscaling de inferencia LLM sobre GPU y TPU en GKE. Microsoft incorporó en AKS un add-on basado en KAITO para automatizar el aprovisionamiento de nodos GPU y el despliegue de modelos de IA.
No obstante, ninguna de estas capacidades convierte automáticamente al clúster en una plataforma de IA robusta. Kubernetes resuelve la orquestación; no sustituye la arquitectura.
La brecha puede verse en los propios datos de la CNCF. En su investigación de 2024, publicada en 2025, el 80% de las organizaciones reportaba Kubernetes en producción y el 77% había adoptado principios GitOps; sin embargo, el 48% aún no había desplegado AI/ML sobre Kubernetes. Entre quienes sí lo hacían, los usos estaban distribuidos entre batch jobs, experimentación, inferencia en tiempo real y preprocesamiento de datos.
Eso conduce a la pregunta relevante para un CIO o CTO: no “¿tenemos Kubernetes?”, sino “¿qué tan preparada está nuestra plataforma Kubernetes para comportarse como infraestructura de IA?”
La prueba real: las capacidades que deciden si su infraestructura está lista
Una evaluación seria debería separar la madurez del clúster de la madurez de la plataforma de IA.
| Dimensión | Infraestructura preparada | Señal de alerta |
|---|---|---|
| Compute y aceleradores | Pools separados para CPU/GPU; drivers automatizados; cuotas; capacidad bajo demanda y reservada; selección de GPU por perfil de modelo | GPU configuradas manualmente, un solo SKU, aceleradores permanentemente ociosos o frecuentes Pods Pending |
| Scheduling y capacidad | Autoscaling de Pods y nodos; prioridades; topology awareness; estrategia para jobs multi-GPU/multi-node | HPA solo con CPU; nodos GPU estáticos; entrenamiento distribuido que reserva parcialmente recursos |
| Modelos y artefactos | Registry/versionado; pesos separados de la imagen cuando conviene; caché; hashes; lineage; rollback | Imágenes de cientos de GB con pesos incrustados; descarga completa en cada arranque; versiones ambiguas |
| Serving y networking | API Gateway/Inference Gateway; rate limiting; canary; routing consciente del workload; aislamiento por tenant | Load balancing HTTP genérico para todo; ausencia de límites de tokens/concurrencia |
| Observabilidad y SLO | TTFT, TPOT, tokens/s, queue depth, errores, GPU/VRAM, KV cache, costo por servicio/modelo | “El Pod está verde” como único indicador de salud |
| Seguridad, gobierno y FinOps | RBAC, políticas de red, Pod Security, artefactos firmados, auditoría, inventario de modelos, controles de datos y costos | GPU compartidas sin política, modelos sin propietario, credenciales dentro de imágenes, costos agregados solo por clúster |
Compute no es solamente “tener GPU”. Kubernetes debe saber qué dispositivo necesita cada workload, qué nodos pueden proporcionarlo y qué capacidad debe mantenerse caliente. DRA avanza precisamente en esa dirección al incorporar clases y claims para recursos especializados. En workloads distribuidos, el gang scheduling evita que una parte del trabajo consuma aceleradores mientras el resto permanece esperando capacidad; la funcionalidad es beta en Kubernetes 1.37 y debe habilitarse explícitamente.
Autoscaling tampoco puede reducirse al HPA tradicional basado en CPU. Kubernetes 1.37 permite que HPA llegue a cero réplicas cuando utiliza una métrica de objeto o externa apropiada, lo que puede resultar especialmente útil para colas, workloads batch y ciertos endpoints de GPU. Sin embargo, scale-to-zero introduce un trade-off: ahorrar capacidad ociosa puede aumentar el tiempo de cold start. Por eso, un servicio interactivo crítico puede necesitar una réplica mínima “caliente”, mientras que un modelo interno de uso esporádico puede aceptar arrancar desde cero.
En LLM, además, la métrica de escalamiento debe reflejar la unidad de trabajo real. Google recomienda usar métricas adecuadas del servidor de inferencia para alinear hardware provisionado, tráfico y objetivos de rendimiento; AWS expone en su arquitectura de referencia request rate, token throughput, latencia y KV cache utilization. Azure documenta autoscaling de workloads GPU en AKS mediante métricas DCGM, Prometheus y KEDA.
Otra decisión importante ocurre por debajo de Kubernetes: el runtime de inferencia. El paper original de vLLM/PagedAttention reportó entre 2 y 4 veces más throughput que FasterTransformer y Orca con niveles comparables de latencia en sus experimentos de 2023, gracias en buena medida a una administración más eficiente del KV cache. Ese resultado no debe interpretarse como una garantía para todos los modelos o GPU, pero ilustra por qué optimizar únicamente el clúster puede dejar una enorme parte del rendimiento sin explotar.
KServe es una de las capas open source que pueden abstraer parte de esta complejidad. El proyecto proporciona recursos Kubernetes para serving predictivo y generativo, además de capacidades de autoscaling, networking, health checking, canary y A/B testing. No es obligatorio adoptar KServe: es un ejemplo de cómo una organización puede evitar que cada equipo de ML reconstruya su propio stack de serving.
La observabilidad necesita igualmente cambiar de vocabulario. Para APIs convencionales se habla de request rate, error rate y duration; para LLM hay que sumar time to first token (TTFT), time per output token (TPOT), throughput en tokens, utilización de GPU y VRAM, queue depth, KV cache, tiempo de carga del modelo, tasa de rechazo y costo por unidad de servicio. Las guías actuales de EKS y GKE utilizan explícitamente varias de estas señales para evaluar y escalar inferencia.
Finalmente, la infraestructura debe ser gobernable. Kubernetes define Pod Security Standards en niveles Privileged, Baseline y Restricted, y recomienda controles como políticas de red para aislar workloads. Para gobernanza específicamente relacionada con IA, el NIST AI Risk Management Framework y su perfil para IA generativa proporcionan una base voluntaria para incorporar consideraciones de confiabilidad y riesgo a lo largo del diseño, desarrollo, uso y evaluación de sistemas de IA.
La necesidad no es académica: Flexera encontró que seguridad y cumplimiento son el principal reto de las iniciativas de IA cloud para el 53% de sus encuestados; el 47% de las grandes empresas de la muestra ya estaba estableciendo responsables o equipos dedicados a gobierno de IA.
Dónde correr la IA: on-prem, nube pública, híbrida, gestionada o autogestionada
No existe una topología universalmente ganadora. La decisión depende del grado de utilización del acelerador, sensibilidad de los datos, elasticidad requerida, disponibilidad regional, habilidades del equipo, latencia y horizonte de inversión. El 73% de los participantes del State of the Cloud 2026 de Flexera reporta operar entornos híbridos, lo que refuerza que la elección real rara vez es simplemente “cloud versus datacenter”.
| Modelo de despliegue | Ventajas | Desventajas | Costo relativo* | Mejor encaje |
|---|---|---|---|---|
| On-prem + Kubernetes autogestionado | Máximo control de hardware, red, datos y versiones; buena previsibilidad con utilización sostenida | CAPEX elevado; procurement GPU; capacidad difícil de ampliar rápidamente; alta carga operativa | Alto inicial / medio a largo plazo si la utilización es muy alta | Datos soberanos, HPC estable, workloads 24/7 previsibles, entornos desconectados |
| Nube pública + Kubernetes gestionado — EKS, GKE, AKS | Elasticidad; acceso a múltiples aceleradores; integración con IAM, observabilidad y servicios cloud; menor trabajo sobre el control plane | GPU y egress pueden elevar OPEX; dependencia de cuotas/capacidad regional; servicios específicos del proveedor | Bajo inicial / medio-alto variable | Inferencia fluctuante, time-to-market, nuevos proyectos de IA, equipos pequeños de plataforma |
| Nube pública + Kubernetes autogestionado | Máximo control sobre componentes Kubernetes dentro del cloud | Se paga infraestructura cloud y además el costo humano de operar control plane, upgrades, HA y seguridad | Medio-alto | Casos excepcionales que requieren personalización upstream no disponible en servicio gestionado |
| Híbrido: on-prem + Kubernetes gestionado/cloud | Coloca datos/workloads donde tenga más sentido; permite burst hacia cloud; facilita soberanía + elasticidad | Networking, IAM, observabilidad, GitOps y gobierno se vuelven más complejos | Medio-alto, muy dependiente de conectividad y operación | Organizaciones grandes con datacenter existente, requisitos regulatorios y demanda variable |
| Multi-cloud Kubernetes | Mitiga dependencia extrema de un proveedor y puede acercar workloads a mercados/capacidad | Portabilidad real es menor de lo que parece cuando se utilizan GPU, storage, IAM y networking específicos; duplica competencias | Alto | Solo cuando existe una justificación empresarial explícita de resiliencia, regulación o acceso a capacidad |
*El costo es una estimación relativa de TCO, no una tarifa. Debe incluir control plane, aceleradores, CPU/RAM, almacenamiento, interconexión y egress, observabilidad, licencias, soporte, personas/on-call y, sobre todo, capacidad GPU ociosa. Los proveedores mantienen páginas oficiales de precios y las tarifas varían según región, contrato, compromisos y modalidad; Azure, por ejemplo, advierte explícitamente que sus precios publicados son estimaciones y pueden cambiar según contrato y tipo de cambio.
Gestionado versus autogestionado debería tratarse como una decisión distinta de “cloud versus on-prem”. En ausencia de una restricción que obligue a controlar el plano de control, un servicio Kubernetes gestionado suele ser el punto de partida más razonable para una empresa que quiere dedicar su capacidad de ingeniería a modelos, serving, seguridad y observabilidad, en lugar de etcd, HA del API server y lifecycle del control plane. Esta es una recomendación arquitectónica, no una regla universal.
Los tres principales proveedores ya añaden abstracciones dirigidas directamente a IA. AWS ofrece EKS Auto Mode/Karpenter para capacidad acelerada y documenta GPU NVIDIA y Trainium. GKE proporciona guías específicas de GPU, TPU, inferencia y autoscaling de LLM. AKS permite automatizar con KAITO el aprovisionamiento de nodos GPU y el servidor de inferencia. Por ello, la comparación de servicios gestionados en 2026 no debería quedarse en “cuánto cuesta el control plane”, sino medir tiempo para obtener GPU, opciones de acelerador, autoscaling, cold-start, cuotas, observabilidad, capacidad reservada/spot, networking de alto rendimiento y portabilidad del stack de serving.
El costo requiere una cautela adicional. Flexera estima que el desperdicio de IaaS/PaaS llegó al 29% en 2026, mientras McKinsey encuentra que el costo operativo de IA ya limita el uso en aproximadamente una de cada cinco organizaciones encuestadas. McKinsey resume el problema de forma directa: “The cost of AI is constraining usage in some organizations.”
Por eso, la pregunta financiera correcta no es “¿cuánto cuesta el clúster?”, sino:
¿cuánto cuesta una unidad útil de IA?
Para un sistema generativo puede ser costo por 1.000 o un millón de tokens, por conversación resuelta, por documento procesado o por transacción empresarial. Para visión puede ser costo por imagen; para batch scoring, costo por millón de registros. Ese cambio permite que FinOps deje de optimizar nodos aislados y empiece a optimizar resultados.
De modelo a producción: checklist técnico y arquitectura de referencia
El siguiente proceso parte de que no existe un presupuesto ni stack específico definido. Está pensado como una secuencia de controles que un equipo de plataforma puede adaptar a EKS, GKE, AKS, Kubernetes on-prem o entornos híbridos.
Checklist técnico de producción
Paso 1 — Defina primero el SLO, no la GPU. Determine el caso de uso, modelo, tamaño, contexto máximo, concurrencia esperada, throughput objetivo y latencia. Para LLM interactivos, defina objetivos de TTFT, TPOT, p95/p99 y tokens por segundo. Para batch, priorice throughput, deadline y costo. Las guías de inferencia de AWS y Google muestran precisamente que latencia, throughput y métricas del servidor son fundamentales para capacity planning y autoscaling.
Paso 2 — Construya una base Kubernetes actualizada y reproducible. Gestione clústeres, node pools, IAM y networking como código; establezca estrategia de upgrades; utilice múltiples zonas cuando el SLO lo requiera; configure quotas y límites. Si opera Kubernetes upstream, revise especialmente las ramas activamente soportadas: al 19 de octubre de 2026, 1.37.1 es el patch más reciente y upstream 1.34 termina soporte el 27 de octubre de 2026.
Paso 3 — Separe capacity pools por tipo de workload. No mezcle indiscriminadamente servicios generales con nodos GPU. Utilice labels, taints/tolerations, afinidad y clases de dispositivo. Automatice drivers y device plugins o DRA según la implementación soportada. Para workloads multi-GPU o multi-node, evalúe topología, interconexión y gang scheduling; para cargas de alta comunicación, la colocación de Pods puede ser tan relevante como la cantidad total de GPU.
Paso 4 — Trate modelo, runtime e imagen como artefactos versionados pero diferenciados. Registre el digest de la imagen, versión del modelo, tokenizer, configuración, prompt templates/adapters, datasets de evaluación y dependencias. Cuando resulte eficiente, mantenga pesos fuera de la imagen del servidor y distribuya/cachéelos explícitamente para reducir reconstrucciones y mejorar rollout. El problema del arranque de LLM ha motivado incluso sistemas de investigación como ServerlessLLM, orientados a reducir la latencia asociada al serverless inference de modelos grandes.
Paso 5 — Elija un serving runtime antes de diseñar el autoscaling. vLLM, NVIDIA Triton u otros servidores tienen características distintas de memoria, batching y métricas. KServe puede proporcionar una capa Kubernetes-native sobre distintos runtimes y estandarizar aspectos de deployment, health checking, autoscaling, canary y protocolos de inferencia.
Paso 6 — Automatice CI/CD y MLOps conjuntamente. Cada cambio debe ejecutar pruebas de software y de modelo: unitarias, seguridad, compatibilidad, calidad del modelo, regresión, performance y carga. Publique imágenes por digest, genere SBOM, escanee vulnerabilidades, firme artefactos y promueva manifests mediante GitOps. La CNCF encontró en su encuesta publicada en 2025 que el 77% había adoptado principios GitOps y el 60% utilizaba CI/CD para la mayoría o totalidad de sus aplicaciones.
Paso 7 — Haga el routing consciente de inferencia cuando el workload lo justifique. API Gateway continúa siendo útil para autenticación, TLS y cuotas, pero los LLM pueden beneficiarse de decisiones adicionales de routing. La Gateway API Inference Extension busca estandarizar precisamente el balanceo optimizado para modelos generativos self-hosted sobre Kubernetes.
Paso 8 — Escale Pods y nodos como un único sistema. HPA/KEDA debe responder a una señal vinculada a demanda —cola, concurrencia, requests o tokens—; el node autoscaler debe responder a la capacidad resultante. Scale-to-zero puede disminuir costos en workloads tolerantes al arranque en frío; para endpoints críticos, mantenga capacidad caliente. En Kubernetes 1.37, el HPA puede reducir a cero workloads compatibles mediante object/external metrics.
Paso 9 — Observe la IA, no únicamente Kubernetes. Recoja métricas de clúster y de negocio: GPU utilization, VRAM, potencia si está disponible, queue time, TTFT, TPOT, output tokens/s, requests/s, KV-cache utilization, model-loading time, errores, timeouts, throttling y costo por endpoint/modelo. Correlacione logs y traces con versión del modelo y deployment.
Paso 10 — Introduzca seguridad antes de la producción. Aplique least privilege con RBAC, Pod Security Standards apropiados, NetworkPolicy, secretos mediante un sistema gestionado/KMS, admission policies, scanning y firma de imágenes. Restrinja egress cuando corresponda y defina explícitamente qué workload puede utilizar qué aceleradores, datasets y credenciales. Kubernetes ofrece Pod Security Standards y controles de red como bloques base, pero la política empresarial debe completar la arquitectura.
Paso 11 — Añada gobernanza del modelo al pipeline. Cada modelo en producción debería tener propietario, versión, origen, licencia, propósito aprobado, datasets/evaluaciones relevantes, riesgos conocidos, reglas sobre datos sensibles y proceso de rollback. Para sistemas generativos, incorpore además evaluaciones de seguridad, calidad, prompt injection, salida sensible y uso no previsto según el contexto. El perfil GenAI del NIST AI RMF fue publicado precisamente para ayudar a identificar y gestionar riesgos específicos de IA generativa.
Paso 12 — Pruebe fallas y economía antes del go-live. Simule pérdida de un Pod, nodo GPU y zona; pruebe saturación de cola, agotamiento de capacidad y rollback. Ejecute load tests y obtenga una curva de costo/rendimiento, no un único benchmark. Defina el punto a partir del cual conviene mantener GPU caliente, reservar capacidad, usar spot/preemptible o escalar desde cero. AWS, por ejemplo, documenta arquitecturas EKS que combinan aprovisionamiento dinámico de GPU, capacidad Spot y On-Demand; la decisión concreta depende del SLO y tolerancia a interrupciones.
Qué deben hacer ahora CIO, CTO, DevOps y ML Engineers
Para el CIO, Kubernetes e IA deben convertirse en una decisión de plataforma, no en una colección de proyectos. El primer objetivo debería ser establecer ownership y economía: quién es responsable de la plataforma de IA, qué métricas de valor se usan, cómo se asignan costos y qué workloads pueden ejecutarse en infraestructura propia, cloud o servicios externos. La presión financiera ya está apareciendo: McKinsey encuentra que el 20% de los participantes limita alguna utilización de IA debido a costos operativos y Flexera sitúa la gestión del gasto cloud como reto para el 85% de su muestra.
La métrica ejecutiva que falta en muchas organizaciones es una unit economics de IA. El CIO debería poder responder cuánto cuesta una conversación, inferencia, documento, agente o millón de tokens y qué valor genera. McKinsey reportó que el 28% de sus encuestados ya asignaba más del 10% del presupuesto corporativo total de tecnologías de información y comunicaciones a IA, mientras que el 60% esperaba aumentar la inversión durante el año siguiente.
Para el CTO, la prioridad es impedir que cada equipo construya una plataforma de serving diferente. Conviene definir un “golden path” con runtime aprobado, registry, mecanismo de deployment, observabilidad, seguridad, autoscaling y gobernanza. Kubernetes puede servir como API común, mientras herramientas como KServe, Gateway API Inference Extension o componentes equivalentes abstraen funciones recurrentes.
También es responsabilidad del CTO decidir dónde aceptar dependencia del proveedor. Pretender una portabilidad absoluta puede generar una plataforma basada únicamente en el mínimo común denominador. La estrategia más pragmática suele consistir en mantener portables las interfaces críticas —Kubernetes API, imágenes OCI, GitOps, OpenTelemetry, métricas y contratos de serving— y aceptar optimizaciones específicas cuando generen una ventaja demostrable en costo o desempeño.
Para DevOps, SRE y Platform Engineering, el cambio principal es pasar de operar “Pods” a operar capacidad de inferencia. Un dashboard que muestra todos los Pods Running no dice si el usuario espera 20 segundos por el primer token. Las alertas deben integrar infraestructura y experiencia: TTFT, TPOT, throughput, queue depth, GPU/VRAM, errores y costo. AWS y Google ya incorporan este tipo de métricas en su documentación oficial para inferencia Kubernetes.
El equipo de plataforma también debería eliminar el aprovisionamiento manual de GPU, incorporar GitOps, automatizar upgrades, definir quotas por equipo/modelo, probar capacity shortage y establecer políticas para GPU compartida. DRA y el workload-aware scheduling de Kubernetes 1.37 muestran hacia dónde está evolucionando upstream, pero las funciones beta deben evaluarse y habilitarse según la política de riesgo y el soporte disponible en cada servicio gestionado.
Para los ML Engineers, producción comienza antes del kubectl apply. El modelo debe llegar acompañado por evaluación reproducible, versión, runtime, requerimientos de memoria, límites de contexto, benchmark de inferencia y criterios de rollback. También deberían probar batching, quantization, tensor/model parallelism y runtime bajo el tráfico real esperado antes de reclamar que la solución “necesita” determinado número de GPU.
La distinción resulta especialmente importante porque el rendimiento del servidor puede cambiar drásticamente la infraestructura necesaria. El benchmark original de PagedAttention/vLLM mostró mejoras de throughput de 2–4× bajo las condiciones analizadas: optimizar serving puede reducir más costo que simplemente añadir nodos.
Recomendación conjunta: cree un pequeño AI Platform Team transversal si la organización ya tiene varios modelos en producción. No necesita convertirse en una nueva burocracia. Su función debería ser proporcionar un camino estándar: infraestructura, serving, seguridad, observabilidad, GitOps, FinOps y gobernanza como capacidades reutilizables.
Una prueba sencilla para la dirección de TI es intentar responder estas preguntas sin convocar a cinco equipos diferentes:
| Pregunta | Una organización preparada debería conocer |
|---|---|
| ¿Cuánto cuesta este modelo? | Costo por inferencia/token/transacción y por ambiente |
| ¿Cuánta capacidad soporta? | QPS/tokens/s y curvas de saturación |
| ¿Qué ocurre si falla una GPU? | Failover, rescheduling y SLO esperado |
| ¿Qué versión está atendiendo tráfico? | Modelo, imagen y configuración exactos |
| ¿Quién puede desplegarlo? | Roles, policy-as-code y approval flow |
| ¿Qué datos puede consumir? | Clasificación, origen, residencia y controles |
| ¿Podemos volver atrás? | Rollback reproducible y probado |
| ¿Cómo sabemos que degradó? | SLO, calidad, drift, seguridad y costo |
La oportunidad es considerable, pero no justifica ignorar disciplina operativa. Gartner prevé que la inferencia ya superé al entrenamiento dentro del gasto de IaaS optimizada para IA en 2026; eso significa que la infraestructura deberá sobrevivir no a unas semanas de experimentación, sino a años de consumo continuo.
Fuentes y referencias
- Cloud Native Computing Foundation (CNCF) y Linux Foundation Research. (2026). CNCF Annual Cloud Native Survey: The Infrastructure of AI’s Future. Informe sobre la adopción de Kubernetes, las tecnologías cloud native y su papel en las cargas de trabajo de inteligencia artificial. Consultar informe completo.
- Cloud Native Computing Foundation (CNCF). (20 de enero de 2026). Kubernetes Fuels AI Growth; Organizational Culture Remains the Decisive Factor. Análisis de la evolución de Kubernetes como infraestructura para la IA y los desafíos de su adopción empresarial. Consultar publicación.
- Kubernetes. (s. f.). Schedule GPUs. Documentación oficial sobre la administración y asignación de GPU en clústeres de Kubernetes para cargas de trabajo que requieren procesamiento especializado. Consultar documentación.
- Kubernetes. (s. f.). Workloads. Documentación oficial sobre la ejecución, administración y escalabilidad de aplicaciones y cargas de trabajo en Kubernetes. Consultar documentación.
