Cómo funciona el TTFT
Una medición de TTFT necesita dos marcas de tiempo:
TTFT = hora del primer resultado − hora de inicio de la solicitud
La fórmula es sencilla. La elección de las marcas de tiempo no lo es.
Un TTFT observado por el cliente comienza cuando el cliente envía la solicitud y termina cuando recibe el primer token con contenido o el primer fragmento transmitido. Ese intervalo puede incluir:
- El envío de la solicitud al servicio.
- La autenticación, el enrutamiento y la puesta en cola.
- La conversión del prompt en tokens.
- El procesamiento completo del prompt, una etapa llamada prefill.
- La selección del primer token de salida.
- La conversión y el envío de esa salida de vuelta al cliente.
Durante el prefill, el modelo procesa la entrada y prepara la información de atención almacenada que reutilizará al generar los tokens posteriores. Los prompts más largos normalmente requieren más trabajo de prefill. Un servicio ocupado puede añadir tiempo de espera en la cola antes de que comience ese trabajo.
Un TTFT medido a nivel del motor puede utilizar límites más acotados. Por ejemplo, la métrica del servidor de vLLM comienza cuando la solicitud llega al frontend, actualmente cuando empieza la tokenización. Por lo tanto, no incluye la ruta de red del cliente ni el trabajo realizado por una aplicación anterior.
Por eso, el TTFT no es un número universalmente comparable. La documentación de evaluación comparativa de NVIDIA lo define desde el envío de la consulta hasta la recepción del primer token. El glosario de Google Cloud lo describe desde que el modelo recibe el prompt hasta que produce el primer token. Ambas convenciones son útiles, pero miden partes diferentes de la solicitud.
Ejemplo práctico
Supón que una solicitud transmitida tiene esta cronología:
- 0 ms: El cliente envía el prompt e inicia el cronómetro.
- 40 ms: El servicio recibe la solicitud.
- 110 ms: Termina la espera en la cola y comienza el procesamiento.
- 350 ms: Termina el procesamiento del prompt y se genera el primer token.
- 390 ms: El cliente recibe el primer fragmento con contenido.
El TTFT observado por el cliente es de 390 ms.
Una medición del servidor que comienza cuando llega la solicitud y termina cuando se genera el token es de 310 ms: 350 ms menos 40 ms.
La diferencia de 80 ms se debe al alcance de la medición. No indica que ninguno de los dos cronómetros sea inexacto.
El mismo ejemplo también muestra por qué no debes interpretar el TTFT como la latencia total. La generación continúa después de los 390 ms. Los intervalos entre los tokens posteriores y el tiempo hasta el token final son mediciones independientes.
Cuándo y por qué importa el TTFT
El TTFT es más importante cuando la salida puede utilizarse en cuanto comienza. Las interfaces de chat, los asistentes de programación y los sistemas de texto en tiempo real pueden mostrar avances después de que llega el primer contenido. Un TTFT más corto reduce la pausa silenciosa antes de recibir esa respuesta.
Por sí solo, importa menos cuando la aplicación debe esperar la respuesta completa. Por ejemplo, un trabajo de resumen por lotes puede interesarse más por el tiempo total de finalización o por el rendimiento general.
Usa el TTFT para investigar el inicio de una solicitud. Un valor alto puede indicar un prompt largo, una oportunidad perdida de usar la caché de prompts, espera en la cola debido a la carga, un trabajador en frío, sobrecarga del frontend o distancia de red. El TTFT por sí solo no puede decirte qué etapa es responsable. Combínalo con trazas o con mediciones independientes de la cola, el prefill y la red.
Al comparar sistemas, mantén constante la carga de trabajo. Usa la misma distribución de longitudes de prompt, el mismo estado de la caché, la misma concurrencia, el mismo comportamiento de transmisión, la misma ubicación del cliente y los mismos eventos de inicio y finalización. Informa de una distribución, como la mediana y los percentiles de cola, en lugar de una solicitud inusualmente rápida. La metodología de evaluación comparativa de MLCommons utiliza escenarios definidos y trata por separado el TTFT de la fase del prompt y la medición de la fase de generación por este motivo.
Ideas erróneas comunes
Un TTFT bajo no significa que la respuesta completa sea rápida. Un sistema puede comenzar rápidamente y después generar despacio. Otro puede comenzar despacio y producir rápidamente el resto de la salida.
La transmisión no reduce automáticamente el tiempo de cálculo del modelo. Permite que el cliente observe parte de la salida antes de que se complete la respuesta. El almacenamiento en búfer de un servidor, proxy o cliente puede hacer que el TTFT observado sea más largo incluso cuando el modelo genera su primer token al mismo tiempo.
El primer fragmento no siempre contiene un solo token. Los protocolos de transmisión pueden agrupar varios tokens en un solo evento. Los eventos vacíos o los metadatos no deberían detener el cronómetro si el objetivo es medir cuándo aparece una salida utilizable.
No existe un TTFT «bueno» independiente del contexto. La longitud del prompt, la carga, el hardware, el almacenamiento en caché, la ruta de red y los límites de la medición cambian el resultado. Un objetivo debería especificar la carga de trabajo y el percentil al que se aplica.
Qué leer después
Lee ¿Qué es la latencia de inferencia? para situar el TTFT dentro de la cronología completa de una solicitud. Lee ¿Qué son los tokens por segundo? para conocer la tasa de generación después de que llega el primer token. Para comparar la espera inicial con la velocidad de generación y la capacidad del sistema, consulta Latencia frente a TTFT frente a tokens por segundo frente a rendimiento.