Red Hat Prescribe RPS, TTFT e ITL como SLOs Base para Modelos de Lenguaje en Producción

Los ingenieros de Red Hat, Legare Kerrison y Cedric Clyburn, dijeron a profesionales en la Arc of AI 2026 Conference que el error más persistente de la industria en despliegues de modelos de lenguaje en producción es tratar puntuaciones de leaderboards públicos como proxy para idoneidad en el mundo real — y que corregir esto requiere adoptar objetivos de nivel de servicio específicos de carga de trabajo (SLOs) anclados a tres métricas de infraestructura que la mayoría de los equipos aún no rastrean.

Kerrison y Clyburn mapearon la progresión de la industria año a año: 2023 fue el año de los LLMs base, 2024 perteneció a Retrieval Augmented Generation, 2025 al fine-tuning y agentes de IA, y 2026 es el año de evaluaciones de LLM — la disciplina que cierra la brecha entre "el modelo tiene buen benchmark" y "el modelo funciona de manera confiable en producción." La mayoría de los equipos de IA empresarial han diferido trabajo riguroso de evaluación, y esa deuda se está manifestando como latencia impredecible y regresiones de calidad.

El problema estructural central es un "triángulo de compensaciones" cuyos tres vértices son calidad del modelo (precisión), capacidad de respuesta (latencia) y costo. Optimizar dos cualesquiera degrada el tercero. Alta precisión más baja latencia significa alto costo de infraestructura. Bajo costo más alta precisión produce alta latencia. Bajo costo más baja latencia produce precisión degradada. Los equipos que seleccionan un modelo de un leaderboard de benchmark sin mapear su propia posición en ese triángulo están tomando una decisión arquitectónica sin los datos relevantes — los leaderboards utilizan criterios genéricos como codificación, matemáticas y escritura creativa que no representan los prompts específicos o distribuciones de datos de una organización específica.

La solución es evaluación impulsada por requisitos de aplicación, gobernada por SLOs con tres métricas centrales. Requests Per Second (RPS) mide el rendimiento y qué tan bien la pila de servicio escala bajo carga. Time to First Token (TTFT) — el intervalo entre enviar una solicitud y recibir el primer token generado — captura la latencia percibida por el usuario. Inter-Token Latency (ITL) mide la brecha entre cada token subsiguiente después del primero, indicando eficiencia del decodificador y suavidad de streaming. Kerrison y Clyburn proporcionaron objetivos concretos de SLO por tipo de carga de trabajo: un chatbot de comercio electrónico requiere TTFT en o por debajo de 200ms e ITL en o por debajo de 50ms en el percentil P99. Una aplicación basada en RAG, que consume más tokens de entrada y produce menos tokens de salida, tolera TTFT de hasta 300ms, ITL de hasta 100ms (si se transmite), y latencia de solicitud de extremo a extremo de hasta 3.000ms, todo en P99.

Para equipos de ingeniería de IA que construyen o auditan infraestructura, las implicaciones de hardware se derivan directamente. La inferencia de LLM se divide en dos fases con perfiles de recursos distintos: la fase Prefill, que procesa el prompt de entrada, es compute-bound; la fase Decode, que genera cada token subsiguiente, es memory-bound. Confundir los dos conduce a adquisición de hardware desajustada. Las técnicas de optimización — especulative decoding, prefix caching, session caching y generación estructurada — abordan fases específicas y patrones de carga de trabajo, no todos los cargas de trabajo por igual. Ejecutar inferencia localmente, donde el caso de uso lo permite, elimina la latencia de viaje de ida y vuelta en la nube y puede cambiar la posición del triángulo.

El equipo de Red Hat también trazó un límite definitorio nítido entre evaluación de modelo y benchmarking de modelo que tiene consecuencias operacionales. La evaluación de modelo es la evaluación del desempeño e idoneidad de un modelo específico en una carga de trabajo objetivo ejecutándose en hardware objetivo. El benchmarking de modelo es la comparación estandarizada contra conjuntos de datos predefinidos entre modelos. Confundir los dos — ejecutar un benchmark y llamarlo evaluación — es el mecanismo por el cual los equipos distribuyen modelos que puntúan bien públicamente pero se desempeñan mal en producción. La implicación para los pipelines CI/CD es que las ejecuciones de benchmark pertenecen a gates de selección, mientras que los suites de evaluación específicos de tareas pertenecen a verificaciones de regresión vinculadas a cada despliegue.

Los equipos de IA empresarial que aún no han definido SLOs a nivel de carga de trabajo están operando sin una señal confiable sobre si una nueva versión de modelo, actualización del motor de servicio o cambio de configuración de hardware es una mejora o una regresión. El marco de Kerrison y Clyburn no requiere reconstrucción de pipelines existentes — requiere instrumentarlos con las tres métricas que realmente gobiernan la experiencia del usuario y el costo. Los equipos que instrumenten primero estarán posicionados para tomar las decisiones de hardware y proveedor de modelo que un cambio en toda la industria hacia el rigor de evaluación forzará.