Un clúster de Kubernetes puede funcionar sin problemas aparentes, pero el servicio de inteligencia artificial (IA) alojado sobre él puede fallar en satisfacer a sus usuarios. Por ejemplo, un modelo puede responder rápidamente con la primera palabra (token) y luego demorarse excesivamente en completar la respuesta. También puede entregar resultados rápidos pero incorrectos o poco útiles. Además, una GPU trabajando al máximo no garantiza que el servicio esté funcionando óptimamente, dejando al equipo de operaciones sin información clave sobre problemas reales. El verdadero desafío operativo radica en conectar el comportamiento del servicio de IA con las condiciones del entorno subyacente, que incluye Kubernetes, GPUs, capacidad computacional, almacenamiento y red, evitando analizar cada capa por separado.
Por ello, es imprescindible medir exhaustivamente un servicio de inferencia antes de su puesta en producción y luego comparar el rendimiento en vivo con esa línea base. En el cuarto artículo de la serie patrocinada por HPE sobre IA y Kubernetes, The New Stack entrevista a expertos como Marius Bogoevici (Senior Principal Product Manager en HPE Morpheus Software), Mahesh Ramachandran (Vicepresidente de Gestión de Producto en HPE OpsRamp Software) y Karthik Subramanian (Principal Product Manager en HPE Morpheus Software) para entender cómo abordar estos retos.
Comenzar con la experiencia y establecer una referencia
Para servicios conversacionales basados en IA, Bogoevici recomienda medir múltiples parámetros clave como el tiempo hasta el primer token que genera el modelo, el tiempo por cada token siguiente, la fiabilidad, la capacidad, la eficiencia de recursos, el coste y la calidad de las respuestas. La combinación de métricas dependerá de la experiencia que se quiera ofrecer. Un primer token rápido puede enmascarar una generación posterior lenta, mientras que una respuesta rápida puede ser inexacta o poco útil. 
«Un primer token rápido puede ocultar una generación lenta a continuación; una respuesta completa rápida puede seguir siendo inexacta o poco útil.»
El tiempo hasta el primer token y el tiempo hasta la respuesta completa responden a preguntas distintas. La latencia entre tokens y el tiempo por token ayudan a comprender la velocidad de generación tras la llegada del primer token. Los equipos deben documentar dónde miden cada intervalo y comparar resultados bajo carga sostenida y picos de demanda, estableciendo objetivos específicos para cada tipo de carga y experiencia de usuario.
Ramachandran complementa esta visión recomendando a los equipos perfilar el sistema de inferencia antes de que sea utilizado por los clientes. Es vital probar con distintas longitudes de preguntas y contextos, volúmenes de salida y niveles de tráfico representativos. Registrar la tasa de tokens procesados, latencias y niveles de servicio bajo estas condiciones crea una referencia para detectar cambios en producción y planificar capacidad.
Relacionar estas métricas de carga con el rendimiento de la infraestructura permite distinguir entre un aumento en la demanda de inferencia y problemas de competencia por recursos, facilitando una mejor gestión de capacidad. «Debéis perfilar el servicio antes de su lanzamiento», indica Ramachandran.
La calidad requiere su propia evaluación. Bogoevici aconseja verificar si el servicio proporciona respuestas adecuadas o si genera «alucinaciones» (errores o invenciones de información). La telemetría de la plataforma puede indicar que la petición fue atendida, pero especialistas en datos y dominios concretos necesitan pruebas específicas y criterios de aceptación para valorar las respuestas.
El eBook reciente Kubernetes en 2027: Construyendo plataformas para IA, autonomía y escalabilidad advierte sobre la necesidad de valorar la calidad de las salidas junto con el rendimiento para actualizar esos parámetros tras cambios en el modelo, los prompts o el sistema de inferencia.
Cuando la GPU está al 100% pero el servicio es lento
El uso elevado de GPU es un indicador útil, pero no identifica el cuello de botella. Bogoevici ejemplifica una falsa sensación de éxito: «Nuestras GPUs están al 100%, por tanto todo va bien». Esto no dice mucho sobre el rendimiento real del servicio. Ramachandran aconseja verificar si los pods de inferencia se escalan según métricas adecuadas para la carga, si las solicitudes llegan al modelo correcto y si los componentes asociados están disponibles justo a tiempo. Cambios en la mezcla de modelos utilizados pueden alterar percepción de latencias y capacidad, incluso con la GPU aparentemente a pleno rendimiento.
«Nuestras GPUs están al 100%, por lo que estamos funcionando bien.»
Subramanian subraya que el rendimiento también depende de la configuración de red, tiempos de respuesta de bases de datos o bases de datos vectoriales y plantea otra duda fundamental: «¿La partición de GPU asignada es demasiado pequeña para atender ese modelo?» Estas hipótesis requieren correlacionar métricas con las solicitudes y ventanas temporales para diagnosticar correctamente cada caso.
El Horizontal Pod Autoscaler de Kubernetes permite usar métricas personalizadas o externas, por lo que no es necesario reemplazarlo si la utilización de CPU no es un buen indicador para inferencia. Sin embargo, es esencial proveer, testear y validar la canalización de métricas, los límites de escalado y la capacidad disponible en aceleradores. La política de escalado no puede generar capacidad de GPU instantáneamente.
Contribuciones de HPE Morpheus y OpsRamp
HPE presenta HPE Morpheus Software como una plataforma para la provisión automática y gobernanza en entornos híbridos. Sus versiones Advanced y Enterprise incluyen el Servicio Kubernetes de HPE (HKS), que extiende el modelo operativo para infraestructuras híbridas y en la nube pública. Los equipos de plataforma pueden usar catálogos, plantillas, controles de acceso y procesos de aprobación para gestionar entornos, ofreciendo un autoservicio gobernado uniforme y reduciendo herramientas separadas y tareas manuales. No obstante, estas funcionalidades no incluyen por sí solas la evaluación de modelos o la calidad de sus respuestas.
Por su parte, HPE OpsRamp Software aporta observabilidad y monitorización completa a infraestructuras híbridas multivendedor, con mapas de servicio, correlación de eventos asistida por IA y automatización operativa para comprender dependencias e ir de la detección a la resolución. Ramachandran lo describe como el motor de observabilidad que complementa al motor de provisión Morpheus dentro de la estrategia global de operaciones cloud de HPE.
La solución conjunta de HPE, que incluye Morpheus, OpsRamp y runtimes, puede medir tasas de tokens procesados en entornos de modelos y en cargas de trabajo específicas. HPE está ampliando la observabilidad para conectar actividad del modelo y agente, volúmenes y tasas de tokens, latencias y tiempo hasta el primer token con telemetrías de infraestructura. Esto facilita investigar si las lentitudes provienen de la aplicación, la capa de servicio del modelo o la infraestructura, además de apoyar la planificación de capacidad y la asignación de costes.
Para aplicaciones agenticas, HPE planea mejorar la observabilidad incorporando trazas, llamadas a herramientas, errores y señales de calidad además de telemetrías de Kubernetes, CPU, GPU, memoria, almacenamiento y red. Están previstas instrumentaciones ligeras basadas en eBPF y OpenTelemetry para profundizar la visibilidad minimizando la sobrecarga. Estas señales facilitan el análisis pero no sustituyen evaluación específica de respuestas o controles de seguridad.
Como se explica en artículos anteriores, lograr telemetría integral depende de agentes, integraciones, permisos e instrumentación aplicativa. Para un servicio de inferencia, es clave conectar las métricas que los usuarios perciben con datos del modelo, eventos Kubernetes y telemetrías de red, bases de datos y aceleradores, detectando posibles huecos en visibilidad especialmente si hay modelos o servicios externos involucrados.
Diseñar rutas y programación específicas para IA
Mirando hacia 2027, Ramachandran aconseja considerar la autoescalabilidad, enrutamiento y programación del modelo como decisiones de diseño conscientes para cargas de IA. Menciona el encaminamiento de solicitudes basado en contenido, la co-programación de componentes relacionados y la provisión desagregada como áreas de evaluación según la arquitectura concreta. No son funciones automáticas de Kubernetes o productos HPE, sino tópicos para análisis a medida.
La propuesta experimental Gateway API incluye filtros pre-routing y el enrutador Body-Based de la extensión de Inferencia, que extrae el nombre del modelo del cuerpo de la solicitud para usarlo en el ruteo. Esto requiere implementar y configurar soluciones compatibles, y medir con modelos, tráfico y hardware propios la ganancia en latencia o eficiencia.
Proteger la telemetría y consensuar la puesta en marcha
La observabilidad en inferencia plantea retos en el manejo de datos. Bogoevici alerta que prompts, respuestas y documentos recuperados pueden quedar registrados en logs y trazas, preguntándose «¿Qué información se captura realmente y dónde se almacena?». Los equipos deben decidir qué recopilar, dónde, durante cuánto tiempo y quién puede acceder a estos datos. Recalca que los prompts son datos sensibles que requieren protección, incluso si se usan para depurar.
Ramachandran prevé que la operativa y la seguridad converjan conforme los agentes de IA generen nuevos eventos y registros de acceso. OpsRamp ya se prepara para interpretar telemetrías desde la perspectiva de la seguridad, aunque la actividad específica de agentes pueda necesitar instrumentación adicional. Seguimos necesitando diseñar y probar controles y respuestas ante incidentes adecuadas.
Antes del lanzamiento, Ramachandran recomienda que negocio y TI acuerden el valor esperado del servicio, incluyendo un volumen de inferencias plausible vinculado a objetivos de negocio, afirmando: «Debe existir un valor empresarial medible.»
«El objetivo no es solo tener GPUs ocupadas, sino servicios de IA confiables con rendimiento y uso de recursos ajustados a las necesidades del negocio.»
Subramanian enfatiza que esta responsabilidad no puede recaer en una sola persona. Administradores de plataforma, equipos de aprendizaje automático, ciencia de datos y seguridad deben colaborar planificando también para fallos o ataques. Es imprescindible sumar al propietario del negocio, probar cargas representativas, casos de fallo y documentar capacidad, calidad, costes y evidencias de recuperación que respalden la decisión de lanzamiento.
El lanzamiento debe basarse en evidencia de que el servicio cumple objetivos acordados y que los equipos saben qué medir y cómo actuar si el servicio falla. Posteriormente, la comparación continua del comportamiento del servicio de IA con las condiciones de infraestructura permite detectar regresiones, solucionar problemas en capas y ajustar capacidad según la demanda. No basta con que las GPUs estén ocupadas; el verdadero propósito es ofrecer servicios IA confiables, eficientes y alineados con el negocio.
