A medida que las organizaciones llevan la IA a producción, Kubernetes se está convirtiendo en un hogar habitual para los servicios que la rodean. Pero una aplicación puede estar en ejecución mientras los usuarios siguen esperando respuestas. Esa diferencia cambia la forma en que los equipos de plataforma investigan el rendimiento, asignan las GPU y planifican un servicio fiable.
Ilustración editorial: La empresa y el incidente de este artículo son ficticios. Las explicaciones técnicas y las estadísticas del sector están respaldadas por las fuentes enlazadas.
Todo está en ejecución, pero los empleados esperan
El nuevo asistente de IA de la empresa parecía un éxito. Los empleados podían hacer preguntas sobre políticas internas y documentos técnicos en lugar de buscar en varios sitios web. El piloto devolvía respuestas útiles en cuestión de segundos. Sus desarrolladores empaquetaron el software en contenedores y lo desplegaron en la plataforma de Kubernetes que la empresa ya tenía.
Después, el asistente se puso a disposición de miles de empleados. Algunas respuestas llegaban rápido. Otras tardaban tanto que la gente se rendía.
Los ingenieros de operaciones inspeccionaron el clúster. Los nodos estaban disponibles, los contenedores de la aplicación estaban en ejecución y Kubernetes había mantenido el número esperado de copias. Aun así, el servicio parecía averiado.
Añadir otro servidor de aplicaciones parecía la respuesta obvia. Pero eso costaría dinero sin responder a una pregunta más importante: ¿en qué estaba gastando su tiempo cada solicitud?
El problema refleja un cambio más amplio. En su Encuesta anual Cloud Native 2025, publicada en enero de 2026, la CNCF informó de que el 82 % de los usuarios de contenedores encuestados utilizaban Kubernetes en producción.
En otra pregunta de la encuesta, respondida por 213 organizaciones que alojan cargas de trabajo de IA, el 66 % usaba Kubernetes para una parte o la totalidad de sus cargas de trabajo de inferencia. Esas cifras describen grupos de encuestados distintos, no a todas las empresas del mundo. La CNCF también presentó un bloque temático dedicado, AI Inference + Agentic, en la KubeCon North America 2026.
La IA está entrando en una infraestructura que los equipos de plataforma ya conocen. El misterio es por qué las herramientas conocidas no siempre cuentan toda la historia.
Seguir una sola pregunta a través del sistema
Los ingenieros eligen una solicitud que sufrió retraso: un empleado ha preguntado qué cambió en la política de reembolso de gastos de viaje.
Primero, el asistente comprueba el permiso del empleado para ver la política. Busca en los documentos de la empresa, selecciona los pasajes pertinentes y envía la pregunta y el texto de apoyo a un modelo de lenguaje. El modelo genera una respuesta. Buscar información de apoyo antes de la generación se conoce habitualmente como generación aumentada por recuperación (RAG, retrieval-augmented generation). Usar un modelo ya entrenado para producir una respuesta es inferencia (inference).
Kubernetes puede operar el software que hay detrás de esos pasos. Un contenedor (container) empaqueta una aplicación y sus dependencias de software.
Kubernetes planifica los contenedores en Pods, las unidades que coloca en máquinas de trabajo llamadas nodos (nodes). Puede mantener el número de copias solicitado y sustituir los Pods que fallan cuando hay recursos adecuados disponibles. La descripción general oficial de Kubernetes explica el modelo de orquestación.
Pero el asistente no funciona como un único servicio indivisible. Su solicitud pasa por varias etapas:
| Etapa de la solicitud | Trabajo que se realiza | Posible retraso |
|---|---|---|
| Identidad | Comprobar el acceso del empleado | Respuesta del servicio de identidad |
| Recuperación | Buscar en los documentos de políticas indexados | Latencia de la búsqueda o del almacenamiento |
| Inferencia | Generar una respuesta con el modelo de lenguaje | Espera de capacidad del modelo y tiempo de generación |
| Devolución | Entregar la respuesta a la aplicación | Retraso de la red o de la aplicación |
En nuestra investigación ilustrativa, los servicios de identidad y de recuperación responden con rapidez. Las solicitudes se acumulan en la inferencia.
La API de la aplicación acepta preguntas más rápido de lo que el modelo puede completarlas, lo que crea una cola (queue). Más Pods de la API solo alimentarían la misma cola más deprisa. Los ingenieros han localizado el cuello de botella. Ahora necesitan entender el recurso que hay detrás.
Una CPU disponible no es una GPU disponible
Los servicios web corrientes suelen depender sobre todo de una CPU, el procesador de uso general que ejecuta el código de la aplicación, y de la memoria para los datos activos. Los modelos de lenguaje grandes usan con frecuencia GPU, procesadores adecuados para muchas operaciones matemáticas en paralelo. Las GPU también necesitan suficiente memoria dedicada para alojar los datos del modelo y atender las solicitudes. No todos los servicios de IA necesitan su propia GPU: los modelos más pequeños pueden ejecutarse en CPU, y muchas aplicaciones llaman en su lugar a un modelo alojado.
Nuestra empresa decidió alojar un modelo que funciona con GPU. Imagina que tiene cuatro GPU adecuadas y que las cuatro ya están asignadas a cargas de trabajo de servicio de modelos. Puede que Kubernetes tenga CPU y memoria libres para otro Pod de la API, pero una réplica adicional del modelo necesita una GPU adecuada. La réplica puede quedarse sin planificar aunque el clúster parezca tener capacidad de cómputo ordinaria de sobra.
Kubernetes conoce las GPU a través de complementos de dispositivo (device plugins) y puede usar la asignación dinámica de recursos (DRA, Dynamic Resource Allocation) para que las cargas de trabajo soliciten características de los dispositivos mediante reclamaciones de recursos (resource claims). DRA es estable desde Kubernetes 1.35.
Lo decisivo es que la documentación de DRA indica que el planificador no puede aplicar la apropiación (preemption) a un Pod existente que use recursos de DRA para ceder ese dispositivo a un Pod de mayor prioridad. El Pod urgente puede quedarse pendiente hasta que el dispositivo se libere. Es posible compartir dispositivos en configuraciones compatibles. El ejemplo de las cuatro GPU es solo una ilustración simplificada, no una regla universal de una carga de trabajo por GPU.
Este es el punto en el que falla el viejo instinto de escalado del equipo: crear más copias del software no puede fabricar un acelerador escaso.
Lo que cambió la investigación
| Suposición anterior | Evidencia de la solicitud |
|---|---|
| Los contenedores están saludables, así que el asistente está saludable | Los usuarios siguen esperando la inferencia del modelo |
| Más réplicas de la API resolverán el retraso | La API no es el componente limitado |
| Si la CPU del servidor está ociosa, hay capacidad | Puede que la memoria o los dispositivos GPU adecuados ya estén asignados |
| La prioridad garantiza capacidad inmediata para la recuperación | La planificación con DRA tiene una limitación documentada de la apropiación (preemption) |
Los ingenieros ya no necesitan otra explicación del fallo. Necesitan elegir una intervención y poner a prueba sus consecuencias.
Corregir la capacidad, la visibilidad y la recuperación
Empieza por la demanda de inferencia, no por el uso de CPU de la API. El equipo mide las solicitudes que esperan al modelo, las solicitudes que se están procesando en ese momento, la latencia de respuesta y el rendimiento (throughput) del servicio de modelos. KServe es una plataforma de código abierto para servir modelos en Kubernetes. Su documentación sobre el escalado automático de la inferencia generativa muestra cómo KEDA (Kubernetes Event-driven Autoscaling, escalado automático de Kubernetes basado en eventos) puede escalar las réplicas de inferencia con métricas del servicio de modelos, incluidos los recuentos de solicitudes del motor de inferencia vLLM, siempre que esté configurada la infraestructura de métricas necesaria.
Ese escalado puede solicitar más réplicas, pero no puede garantizar la disponibilidad de GPU. El equipo debe decidir qué da el mejor resultado: reservar aceleradores, mejorar el procesamiento por lotes (batching, agrupar solicitudes para que el modelo atienda varias a la vez), reducir las llamadas innecesarias al modelo o cambiar el tamaño del modelo. Cuando hay varias réplicas, nuestro artículo sobre el balanceo de carga de la inferencia de IA (en inglés) explica cómo el enrutamiento puede tener en cuenta el trabajo en caché y el cómputo ocupado.
Sigue la solicitud completa. Una traza (trace) distribuida registra por dónde pasó una solicitud y cuánto tiempo consumió cada una de sus etapas. OpenTelemetry, que se graduó como proyecto de la CNCF el 21 de mayo de 2026, ofrece herramientas de observabilidad (observability) independientes de los proveedores. Sus convenciones semánticas de GenAI, los nombres de campo acordados para este tipo de telemetría, siguen evolucionando para las invocaciones de modelos, el uso de tokens y la ejecución de herramientas.
Un token es una unidad de texto que un modelo consume o genera. El recuento de tokens puede ayudar a explicar la demanda de procesamiento y el costo. El trazado puede distinguir el tiempo que se pasa esperando del tiempo que se dedica a generar una respuesta. Nuestro artículo sobre cómo hacerse cargo del canal (pipeline) de telemetría explica qué estandariza OpenTelemetry y cuándo vale la pena ejecutar un Collector como capa adicional.
Mantén el contenido sensible fuera de la telemetría innecesaria. Las instrucciones (prompts) de los empleados, el texto de las políticas recuperado y las respuestas generadas podrían contener información privada. La documentación de atributos GenAI de OpenTelemetry identifica el contenido potencialmente sensible. Los ingenieros deberían capturar la latencia y los recuentos sin almacenar indiscriminadamente las instrucciones completas, y aplicar controles de acceso, filtrado y retención a cualquier contenido que sí necesiten.
Prueba el servicio, no solo el reinicio. Si falla un nodo de inferencia, Kubernetes puede planificar un Pod de reemplazo. Ese Pod sigue necesitando un acelerador adecuado y los archivos del modelo. La aplicación también necesita sus dependencias de búsqueda e identidad. Una prueba de recuperación útil mide cuándo los empleados pueden volver a obtener una respuesta correcta y autorizada.
Y si un agente de IA puede modificar registros, la aplicación de destino debe autorizar cada acción para el usuario real: que un modelo decida llamar a una herramienta no equivale a tener permiso para realizar la operación. Los controles de seguridad de Kubernetes ayudan a proteger las cargas de trabajo, pero no sustituyen a la autorización de negocio.
Estas respuestas resuelven problemas distintos. El escalado aborda la capacidad limitada, el trazado explica el rendimiento, los controles de privacidad protegen la evidencia, y la recuperación y la autorización protegen el propio servicio.
Si operar el modelo o comprar la inferencia
El equipo puede seguir alojando la inferencia en Kubernetes u operar su aplicación en Kubernetes mientras usa una API de modelos gestionada. Ninguna de las dos es la respuesta universal.
| Opción | Inferencia autoalojada | API de modelos gestionada |
|---|---|---|
| Hardware | El equipo gestiona la capacidad y el uso de los aceleradores | El proveedor gestiona la infraestructura de servicio |
| Escalado | Requiere planificación, métricas del servicio de modelos y capacidad de reserva | Requiere gestionar cuotas, concurrencia y límites del proveedor |
| Control | Más control sobre el entorno de ejecución y el despliegue del modelo | Limitado a los modelos y funciones que admite el proveedor |
| Economía | Tiempo de hardware, ingeniería, operaciones y almacenamiento | Cargos por uso, compromisos de consumo y costos de integración |
| Riesgo | Carga del modelo, recuperación del clúster y de los aceleradores | Red, disponibilidad del servicio y acuerdos de tratamiento de datos |
Para una empresa que sirve muchos modelos con un volumen sostenido, gestionar la inferencia puede valer la pena. Un equipo más pequeño que opera un solo asistente podría evitarse un trabajo considerable con GPU usando un servicio gestionado. Si mantiene la inferencia en Kubernetes, los grupos de nodos dedicados a GPU (node pools, es decir, grupos de máquinas de trabajo con GPU) o los clústeres separados pueden ser adecuados cuando el aislamiento, la capacidad o la fiabilidad lo justifiquen. Un equipo que aloja un modelo por su cuenta también debe elegir un motor para servirlo, y nuestra guía para elegir un motor de inferencia de IA explica qué comparar.
La empresa de nuestro ejemplo ya puede comparar las opciones a partir de la demanda de solicitudes medida, los objetivos de servicio, el esfuerzo operativo y los requisitos de datos. Eso es más útil que decidir que todos los componentes de IA deben vivir en un clúster de Kubernetes solo porque el resto de la aplicación lo hace.
Hasta dónde necesita profundizar un equipo depende de su función. La mayoría de los equipos de plataforma y de aplicaciones solo necesitan reconocer este patrón y medir dónde espera una solicitud, lo que basta para plantear pronto la pregunta correcta. Los equipos que alojan modelos por su cuenta necesitan más profundidad en la planificación de aceleradores y el servicio de modelos, y la documentación de Kubernetes y KServe enlazada más abajo está escrita para ellos.
Kubernetes sigue siendo una base sólida: planifica servicios, ayuda a mantener la disponibilidad y ofrece a los equipos controles operativos conocidos. La IA añade restricciones de recursos y responsabilidades de aplicación que esos controles no pueden resolver por sí solos.
La habilidad importante para los equipos de plataforma no es tratar la IA como un mundo completamente nuevo. Es saber dónde terminan las prácticas conocidas de Kubernetes y dónde debe empezar la ingeniería del servicio de modelos.
Para profundizar
- CNCF Annual Cloud Native Survey 2025: CNCF, enero de 2026. Cifras de adopción, poblaciones encuestadas y límites.
- KubeCon North America 2026 AI Inference + Agentic track: CNCF, agosto de 2026. Las prioridades emergentes de infraestructura del evento.
- Kubernetes GPU scheduling: guía oficial sobre los complementos de dispositivo.
- Kubernetes Dynamic Resource Allocation: estado estable, reclamaciones de dispositivos y límites de la apropiación.
- KServe generative-inference autoscaling: KServe. Escalado del servicio de modelos y métricas de KEDA.
- OpenTelemetry graduation: 21 de mayo de 2026. Hito del proyecto.
- OpenTelemetry GenAI semantic conventions: telemetría en evolución de modelos, agentes y herramientas.
- OpenTelemetry GenAI attributes: detalles de instrumentación sensibles a la privacidad.