# Latencia y tokens por segundo: por qué importa en UX > La latencia de un LLM se mide con el tiempo hasta el primer token y los tokens por segundo. Qué la causa, cómo la percibe el usuario y cómo diseñar para ella. *Tags: ia, ux, rendimiento, diseno-con-ia* --- > [!info] Definición Rápida > La **latencia** de un LLM es el tiempo que tarda el modelo en procesar un prompt y generar la respuesta. En una interfaz de chat conviene separarla en dos medidas: el **tiempo hasta el primer token** (TTFT, por *time to first token*), que es la espera antes de ver la primera palabra, y la **velocidad de generación**, medida en tokens por segundo, que decide qué tan rápido se llena el resto del texto. ## ¿Qué miden el tiempo al primer token y los tokens por segundo? La documentación de Anthropic define la latencia como el tiempo que tarda el modelo en procesar un prompt y generar una salida, y señala que depende del tamaño del modelo, de la complejidad del prompt y de la infraestructura. Para medirla separa el TTFT, que corre desde que se envía el prompt hasta que se genera el primer token, de la latencia total. Un [[tokens|token]] es el fragmento de texto con el que trabaja el modelo, y la generación sale token a token. De ahí sale una cuenta que sirve para estimar cualquier respuesta: **tiempo total ≈ TTFT + (tokens de salida − 1) × tiempo entre tokens** El tiempo entre tokens (ITL, *inter-token latency*) es la inversa de los tokens por segundo: a 50 tokens por segundo, cada token tarda 20 milisegundos. Ojo: "TPOT" (tiempo por token de salida) se usa a veces como sinónimo de ITL y a veces no, así que revisa cómo define cada fuente su medición antes de comparar cifras. ## ¿Qué hace lenta una respuesta? Una petición pasa por dos fases. En la primera, llamada *prefill*, el modelo lee todo el prompt a la vez. En la segunda, *decode*, genera la respuesta un token detrás de otro. Cada fase tiene un cuello de botella distinto y por eso un síntoma distinto: | Qué ve la persona | Fase probable | Qué influye | Qué se puede hacer | |---|---|---|---| | Pantalla quieta antes de la primera palabra | Prefill (más cola y red) | Largo del prompt, contexto recuperado, carga del proveedor | Acortar el prompt, reutilizar el prefijo del prompt, mostrar feedback inmediato | | Texto que avanza con pausas | Decode | Tamaño del modelo, carga del proveedor | Modelo más pequeño, menos carga | | Espera total larga con respuesta extensa | Decode | Cantidad de tokens de salida | Pedir salidas más cortas, dividir la tarea | - **La salida pesa mucho más que la entrada.** OpenAI afirma en su guía de optimización que recortar un 50 % de los tokens de salida puede recortar cerca de un 50 % de la latencia, mientras que recortar un 50 % del prompt puede mejorarla solo entre 1 % y 5 %. - **Un prompt muy largo sí se nota en el TTFT.** NVIDIA midió Llama 3.1 70B en un sistema GH200 NVL32 con tamaño de lote 1: 472 ms al primer token con 32.768 tokens de entrada y unos 2,2 segundos con 122.880. Es una medición de laboratorio con hardware especializado: tus números serán otros, pero la tendencia (más contexto, más espera) se mantiene. Anthropic indica que el caché de prompts suele mejorar el TTFT en documentos largos. Un modelo de razonamiento añade otro factor: genera pasos intermedios antes de responder, así que el texto visible tarda más en llegar (ver [[modelos-de-razonamiento|modelos de razonamiento]]). ## ¿Cómo percibe el usuario la espera? Jakob Nielsen fijó tres límites de tiempo de respuesta en su libro *Usability Engineering* (1993), y Nielsen Norman Group los mantiene publicados con una actualización de 2014: - **0,1 segundos:** el límite para que la persona sienta que el sistema reacciona al instante. No hace falta más feedback que mostrar el resultado. - **1 segundo:** el límite para que el hilo de pensamiento no se interrumpa. Entre 0,1 y 1 s la demora se nota, pero no exige un aviso especial. - **10 segundos:** el límite para mantener la atención en el diálogo. Pasado ese punto, NN/g recomienda un indicador de porcentaje cuando se pueda medir y una forma claramente señalada de interrumpir la operación. Esas cifras son anteriores a los LLM y casi ninguna respuesta de un modelo cabe en 0,1 segundos. Por eso el diseño se apoya en la percepción: que algo se mueva pronto y que la persona sepa qué ocurre. ## ¿Qué puede hacer el diseño? Para bajar la espera percibida, sin cambiar el tiempo real: - **Streaming.** Mostrar el texto según se genera permite empezar a leer antes de que termine. OpenAI lo describe como la técnica más eficaz para reducir la espera percibida. Los detalles están en [[streaming-de-respuestas|streaming de respuestas]]. - **Feedback inmediato.** Al enviar, la interfaz responde en menos de 0,1 s con un estado que describa el paso real. Qué indicador usar según la duración se explica en [[estados-de-carga-en-ia|estados de carga en IA]]. - **Pasos visibles.** Si la tarea tiene etapas (leer, buscar, redactar), mostrarlas convierte una espera vacía en progreso. Ver [[progreso-de-tareas-largas|progreso de tareas largas]]. - **Cancelación.** Permitir detener una respuesta larga evita esperar algo que ya no se necesita. Ver [[interrumpir-y-redirigir|interrumpir y redirigir]]. Para bajar el tiempo real, con el equipo técnico: - **Salida y prompt más cortos.** Pide respuestas breves y quita contexto redundante del prompt. Anthropic aconseja limitar por párrafos u oraciones, porque el límite por número de palabras funciona peor con los tokens. `max_tokens` corta de golpe, incluso a mitad de frase. - **Modelo más rápido.** Elegir un modelo más pequeño es una de las vías más directas, siempre que la tarea lo permita (ver [[modelos-pequenos-vs-grandes|modelos pequeños vs. grandes]]). - **Menos llamadas o llamadas en paralelo.** OpenAI recomienda combinar pasos secuenciales en una sola petición y ejecutar en paralelo los pasos independientes. ## ¿Cómo se mide en la práctica? 1. Guarda una marca de tiempo al enviar la petición. 2. Guarda otra cuando llega el primer fragmento de texto visible. La diferencia es el TTFT. 3. Guarda otra al terminar. Divide el tiempo restante entre los tokens de salida menos uno para obtener el tiempo entre tokens. 4. Registra los tokens de entrada y de salida de cada petición, para saber qué fase pesa más. Mide sobre peticiones reales, no solo sobre ejemplos cortos, y mira los percentiles altos. Wikipedia explica que la latencia de cola (los percentiles 95, 99 o 99,9) importa porque los promedios y las medianas pueden engañar. ## ¿Cuándo NO conviene optimizar solo la velocidad? Cuando la velocidad se logra recortando calidad o contexto. Una respuesta rápida y equivocada es peor que una lenta y correcta, porque la persona gasta tiempo corrigiéndola. Anthropic recomienda lograr primero un prompt que funcione bien sin restricciones y aplicar después las estrategias de latencia, para saber cuál es el mejor resultado posible. ## Ejemplo Ejemplo ilustrativo: un asistente de redacción tarda 6 segundos en mostrar la primera palabra porque antes busca en los documentos de la marca, y después escribe 300 tokens en unos 6 segundos más. El equipo hace tres cambios: muestra en el primer instante el paso "Buscando en la guía de estilo", activa el streaming para que el texto aparezca desde el primer fragmento y pone un botón para detener. La suma de tiempos casi no cambia, pero la persona ve actividad dentro de la primera décima de segundo y empieza a leer a los 6 segundos en lugar de a los 12. ## Errores comunes - Medir solo la latencia total y olvidar el tiempo hasta el primer token. - Mostrar un spinner genérico durante 20 segundos. - Fiarse del promedio y no mirar los casos lentos. - Optimizar velocidad sin medir la calidad de la respuesta. - No permitir cancelar una generación larga. ## Fuentes - [Response Times: The 3 Important Limits, Nielsen Norman Group](https://www.nngroup.com/articles/response-times-3-important-limits/) - [Reducing latency, documentación de Claude (Anthropic)](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-latency) - [Latency optimization, guía de OpenAI](https://developers.openai.com/api/docs/guides/latency-optimization) - [Prompt caching, documentación de Claude (Anthropic)](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) - [Prefill vs decode: LLM inference phases explained, Redis](https://redis.io/blog/prefill-vs-decode/) - [Low Latency Inference Chapter 2: Blackwell is Coming, NVIDIA](https://developer.nvidia.com/blog/low-latency-inference-chapter-2-blackwell-is-coming-nvidia-gh200-nvl32-with-nvlink-switch-gives-signs-of-big-leap-in-time-to-first-token-performance) - [Latency (engineering), Wikipedia](https://en.wikipedia.org/wiki/Latency_(engineering)) --- Source: https://www.fernandoux.com/es/wiki/ia/latencia-en-llms/