¿Por qué puede aumentar el rendimiento y llegar más tarde el primer token? Una lista de validación para las actualizaciones de inferencia de IA

Ilustración conceptual: la espera inicial, el ritmo de la salida en streaming y el rendimiento agregado describen distintos aspectos de un servicio. No representa datos medidos.

Un servidor puede producir más tokens por segundo mientras la ventana de chat tarda más en mostrar alguna respuesta. Antes de aprobar una actualización de inferencia, conviene plantear una pregunta práctica: ¿qué parte de la espera del usuario queremos reducir?

Dos formas de ir «más rápido» en un mismo balance

La PR #60140 de vLLM, integrada el 6 de octubre, presenta resultados de GLM-5.3 tras cambiar a una caché KV en FP8. Con TP4, 8.000 tokens de entrada, 1.000 tokens de salida y 1, 4 o 16 solicitudes simultáneas, la tabla muestra mejoras de rendimiento de entre el 2,3 % y el 5,5 %. Sin embargo, la mediana del tiempo hasta el primer token (TTFT) aumentó entre un 6,9 % y un 11,1 %. La mediana de la latencia total disminuyó entre un 3,1 % y un 6,3 %: la respuesta empezaba más tarde, pero terminaba antes. Fuente: PR #60140

Estos resultados fueron publicados por un colaborador; no los hemos reproducido. Tampoco incluyen una serie de pruebas que cubra entradas más largas. Un parche posterior limitó ese comportamiento predeterminado a NVIDIA SM100. Aplicar estas conclusiones a todos los despliegues de GLM iría más allá de la evidencia disponible. Fuente: PR #60281

Separar las distintas partes de la espera

Los usuarios esperan primero la salida inicial, después más contenido y, por último, la respuesta completa. El rendimiento del servidor, o throughput, mide la producción agregada; el TTFT mide la espera inicial; la latencia entre tokens (ITL) describe los intervalos entre salidas sucesivas en streaming; el tiempo total abarca toda la solicitud. El TTFT de vLLM medido en el servidor incluye el procesamiento de la entrada, por lo que no mide únicamente el tiempo de cálculo de la GPU. También conviene observar en el cliente los tiempos añadidos por la red, la pasarela y la visualización. Fuente: diseño de las métricas

La planificación de la ejecución exige tomar decisiones con ventajas e inconvenientes. El prefill por bloques («chunked prefill») de vLLM divide las entradas largas y programa su procesamiento junto con las solicitudes que ya están generando una salida. Según la documentación, los presupuestos de tokens por lote más pequeños favorecen la ITL, mientras que los más grandes favorecen el TTFT. Esta es una explicación general de cómo pueden divergir las métricas de latencia. La PR anterior no demuestra que este mecanismo sea la causa del empeoramiento del TTFT con aquel cambio a FP8. Fuente: guía de optimización

La caché también ahorra trabajo en una fase concreta. La caché de prefijos reutiliza los cálculos de un prefijo de entrada compartido, lo que ayuda en el procesamiento inicial de la entrada («prefill») sin reducir directamente el trabajo de decodificación («decode») que genera nuevos tokens. Por eso, las preguntas repetidas sobre un mismo documento largo pueden beneficiarse de forma distinta a las cargas de trabajo dominadas por respuestas largas. Fuente: caché de prefijos y sus límites

Definir los criterios de validación antes de actualizar

El siguiente plan de pruebas es nuestra propuesta, no una serie de experimentos ya realizados.

1. Mantener estables las condiciones de comparación. Registrar la GPU, la versión del modelo, el commit del framework de inferencia, la cuantización, el paralelismo, la decodificación especulativa y los parámetros de muestreo. Cambiar únicamente el elemento que se evalúa en cada ocasión para poder identificar de dónde procede una mejora.

2. Construir una matriz pequeña. Elegir tres tipos de tareas reales: conversaciones cortas, respuestas cortas sobre documentos largos y salidas largas. Probar cada uno con prefijos nuevos y reutilizables, bajo una carga baja, habitual y cercana a la capacidad máxima. El resultado son 18 celdas. Las entradas deben permanecer dentro del rango admitido por el modelo, y los niveles de carga deben elegirse a partir del tráfico propio.

3. Añadir un pico de tráfico. Registrar la tasa real de llegada, la concurrencia real, la espera en cola y las solicitudes fallidas. Una prueba con concurrencia fija y una llegada repentina de usuarios ejercen presiones distintas; un limitador también puede trasladar la espera al cliente. La herramienta de benchmark de vLLM separa la tasa de solicitudes de la concurrencia máxima y ofrece métricas de la cola del cliente. Fuente: parámetros del benchmark

4. Conservar el balance completo de cada celda. Registrar, como mínimo, los p50/p95/p99 del TTFT, la ITL y la latencia total, además del rendimiento, los aciertos de caché, las interrupciones por preempción, los tiempos de espera agotados y la tasa de error. Repetir las pruebas de forma independiente e indicar los métodos de calentamiento y los tamaños de muestra. Interpretar los percentiles extremos con especial cautela cuando las muestras sean pequeñas. Los cambios de cuantización también requieren una comprobación separada de la calidad en las tareas: la velocidad no demuestra la corrección.

5. Fijar los umbrales antes de comparar las mejoras. Un asistente interactivo puede dar prioridad a la primera salida y a las pausas del streaming; un proceso por lotes offline puede priorizar el volumen completado. Los umbrales concretos deben derivarse de los requisitos del producto. Contar las solicitudes completadas con éxito que, además, cumplen los objetivos de latencia proporciona una medida más útil de la capacidad del servicio. vLLM admite umbrales de rendimiento útil («goodput») para el TTFT, el tiempo por token de salida y la latencia de extremo a extremo. Fuente: opción goodput

Relacionar el resultado con la experiencia del usuario

Un informe de validación útil debería responder a una pregunta concreta: «Con nuestro tráfico y nuestros requisitos de calidad, ¿cuántas solicitudes más podemos completar por hora y cuánto tendrán que esperar los usuarios que reciban el servicio más lento?»

Un mayor rendimiento es bienvenido. Examinarlo junto con los tiempos de espera, la calidad y los fallos permite ver exactamente qué mejora una actualización.

Fuentes verificadas el 19 de octubre de 2026. Este análisis técnico se basa en benchmarks públicos de colaboradores y en la documentación oficial. La matriz de pruebas es nuestra propuesta; no hemos realizado pruebas independientes de rendimiento ni de calidad. Las páginas «latest» de la documentación pueden cambiar. Comprueba la versión que realmente despliegas.