Latencia al servir LLM: primer token, tokens por segundo y dónde se va el tiempo

La forma más rápida de reducir la latencia de un LLM casi nunca es cambiar de GPU: es generar menos tokens. Con un tiempo hasta el primer token de 400 ms y 40 ms por token generado, una respuesta de 500 tokens tarda 20,4 segundos. La misma respuesta en 150 tokens tarda 6,4. Ningún ajuste del servidor te da una mejora de ese tamaño con tan poco trabajo.

Las dos fases de cada petición

Toda petición a un LLM pasa por dos fases con cuellos de botella distintos, y medirlas por separado es lo primero.

El prellenado (prefill) procesa todo el prompt de entrada de una vez. Es una operación intensiva en cálculo y paralela: la GPU procesa miles de tokens de entrada en el tiempo que tarda en generar unos pocos de salida. Determina el tiempo hasta el primer token (TTFT), que crece con la longitud del prompt.

La decodificación genera la salida token a token. Cada token exige leer todos los pesos del modelo desde memoria, así que el límite es el ancho de banda de memoria, no el cálculo. Determina la latencia entre tokens (ITL), bastante estable para un modelo y un hardware dados.

latencia_total ≈ TTFT + tokens_de_salida × latencia_entre_tokens

Prompt de 8.000 tokens, salida de 300 tokens
TTFT = 0,6 s, ITL = 35 ms
→ 0,6 + 300 × 0,035 = 11,1 s     (el 95% del tiempo es generación)

En la mayoría de aplicaciones conversacionales, la generación domina. En las que procesan documentos largos y devuelven una respuesta corta (clasificar, extraer un campo), domina el TTFT. Optimiza la fase que realmente pesa en tu caso.

Reducir el tiempo de generación

Limita la salida desde el prompt y desde el parámetro de máximo de tokens. Pedir «responde en un máximo de tres frases» o devolver JSON con campos concretos en lugar de prosa reduce los tokens generados de forma directa. Revisa también si el modelo repite la pregunta, añade introducciones o cierra con ofertas de ayuda adicional: cada una de esas frases cuesta latencia.

Usa un modelo más pequeño donde basta. Un modelo de 8B genera bastante más rápido que uno de 70B en el mismo hardware, porque hay menos pesos que leer por token. Muchas aplicaciones enrutan las tareas simples (clasificación, extracción, reformulación) a un modelo pequeño y reservan el grande para las que lo necesitan.

La decodificación especulativa usa un modelo pequeño que propone varios tokens y el modelo grande los verifica en una sola pasada. Cuando el borrador acierta, se aceptan varios tokens por paso. La ganancia depende de cuánto acierte el borrador en tu tipo de texto: es alta en código y texto predecible, menor en texto creativo, y añade el consumo de memoria del segundo modelo.

Y la cuantización: al reducir el tamaño de los pesos, reduce lo que hay que leer por token y acelera la generación de forma casi proporcional cuando el límite es el ancho de banda.

Reducir el tiempo hasta el primer token

La caché de prefijos evita recalcular la parte del prompt que se repite entre peticiones: instrucciones del sistema, definiciones de herramientas, ejemplos. Para aprovecharla, ordena el prompt de lo más estable a lo más variable: primero las instrucciones fijas, después los documentos recuperados y al final la pregunta del usuario. Si pones la fecha y hora actuales al principio del prompt del sistema, invalidas la caché en cada petición.

Los proveedores de API ofrecen caché de prompts (automática o con marcas explícitas, según el proveedor), que además abarata los tokens cacheados. En servidores propios, vLLM y SGLang implementan caché de prefijos automática.

Recortar el contexto ayuda en las dos fases. Pasar 20 fragmentos recuperados cuando 5 bastan multiplica el prellenado y llena la caché KV, que reduce cuántas peticiones caben en paralelo.

Lo que percibe el usuario

El streaming no reduce la latencia total, pero cambia la percibida: el usuario empieza a leer tras el TTFT en lugar de esperar a la respuesta completa. Para una interfaz de chat, un TTFT por debajo de un segundo con streaming suele sentirse más rápido que una respuesta completa en cinco segundos sin él.

El streaming no sirve cuando la salida no se puede usar parcialmente: un JSON que otro sistema procesa, o una respuesta que debes validar antes de mostrar. En esos casos, la única latencia que cuenta es la total.

Paraleliza las llamadas independientes. Si un flujo hace tres llamadas que no dependen entre sí (clasificar, extraer entidades, detectar idioma), lanzarlas a la vez convierte la suma de tres latencias en la máxima de las tres.

Servidores propios: rendimiento contra latencia

Los servidores de inferencia modernos agrupan peticiones de forma continua (continuous batching): en cada paso de decodificación procesan todas las secuencias activas a la vez, y las nuevas entran sin esperar a que terminen las demás. Eso multiplica el rendimiento total de la GPU, porque leer los pesos una vez sirve para todas las secuencias del lote.

El precio es la latencia individual. Con más secuencias por lote, cada paso tarda algo más y cada usuario ve menos tokens por segundo. En vLLM, el número máximo de secuencias simultáneas se controla con --max-num-seqs, y la memoria disponible para la caché KV con --gpu-memory-utilization y --max-model-len:

vllm serve mi-modelo \
  --max-model-len 16384 \
  --max-num-seqs 64 \
  --gpu-memory-utilization 0.90

Si tu prioridad es la latencia por usuario (un asistente interactivo), baja --max-num-seqs y acepta menos peticiones por GPU. Si es el rendimiento total (procesar un lote nocturno de documentos), súbelo. No existe un valor correcto sin saber cuál de las dos cosas te importa.

Errores frecuentes y limitaciones

Medir la media. La latencia de un LLM tiene colas largas: respuestas que generan muchos más tokens de lo habitual, picos de carga, reintentos. Mide los percentiles 50 y 95 de TTFT, ITL y latencia total, y fija los objetivos sobre el p95.

Probar con una sola petición. Un servidor que responde rápido a una petición puede degradarse mucho con 50 simultáneas. Haz pruebas de carga con la concurrencia y la distribución de longitudes de prompt reales, no con un prompt corto repetido.

Olvidar el tiempo fuera del modelo. Recuperación de documentos, reranking, llamadas a herramientas, validación y red suman. Instrumenta cada paso del flujo; a veces la búsqueda vectorial sin índice o un reranker en CPU tardan más que la generación.

Atribuir todo al proveedor. Las APIs públicas tienen variaciones de latencia que no controlas, pero el tamaño de tu prompt y de tu salida sí. Antes de cambiar de proveedor, revisa cuántos tokens de entrada y de salida tiene la petición típica.

Por dónde empezar

Registra para cada petición tokens de entrada, tokens de salida, TTFT y latencia total durante un día. Si la salida media supera lo que el usuario necesita leer, recorta el prompt de respuesta primero. Si el TTFT domina, reordena el prompt para aprovechar la caché de prefijos y reduce el contexto recuperado.