Prefix caching: same load, 3x faster

16,1 segundos a 5,2. El mismo modelo, la misma GPU, las mismas 10 peticiones al mismo contexto. Lo único que cambió: si el prefijo ya estaba en caché. Si sirves un agente, esto es probablemente la palanca más grande que tienes — y la más fácil de activar.

Qué es el prefix caching

Cuando varias peticiones comparten el mismo inicio (tu system prompt, las instrucciones del proyecto, un documento), el modelo recalcula ese prefijo en cada llamada: es el prefill, la fase que lee el prompt. El prefix caching guarda el estado de atención (la caché KV) de eso ya procesado y lo reutiliza cuando el prefijo coincide.

vLLM lo trae y se activa con una bandera:

vllm serve ./models/qwen3-coder-30b \
  --enable-prefix-caching \
  --kv-cache-dtype fp8

Los números (el mismo escenario, dos veces)

10 usuarios, 16K de contexto, misma máquina (L40S):

	Tiempo total	TTFT p50	tok/s p50	Throughput agregado
Contexto nuevo cada vez	16,1 s	9.652 ms	15,9	199 tok/s
Contexto ya procesado	5,2 s	3.773 ms	73,6	740 tok/s

3,1× más rápido en tiempo total
2,6× menos TTFT
4,6× más tokens por segundo por usuario
3,7× más throughput agregado

Y no hubo una sola petición fallida en ninguno de los dos casos.

Por qué esto domina en un agente

Un asistente de código no manda una pregunta suelta: manda el mismo contexto una y otra vez. Cada turno reenvía las instrucciones, los archivos abiertos y el historial. En nuestro uso real, la mayor parte del tráfico era relectura de contexto, no generación nueva: por cada token que el modelo escribía, leía decenas.

Ahí el prefix caching no es una optimización del 10%: es la diferencia entre pagar por releer todo cada vez y reutilizarlo. Y explica por qué el costo por token de un modelo propio puede ser tan bajo frente a una API que cobra cada token de entrada.

El matiz que casi nadie cuenta

El famoso "58-73 tok/s con 10 personas" es el caso de prefijo compartido. Con sesiones distintas (10 personas trabajando en cosas diferentes), el número baja a 15,9 tok/s p50. Ambos son reales, pero son escenarios distintos:

Prefijo compartido → varios turnos de la misma conversación, o muchos usuarios con el mismo system prompt. Cache-friendly.
Sesiones distintas → cada uno con su contexto único. Aquí manda la concurrencia y la memoria.

Si vas a dimensionar hardware, decide cuál de los dos es tu caso mayoritario. Confundirlos es la forma más rápida de comprar la GPU equivocada. → El error de mi propio benchmark

Cómo aprovecharlo (con lo que sabíamos y lo que faltó)

Actívalo. En vLLM es una bandera; en otros servidores, revisa si está en la configuración por defecto.
Ordena el prompt con el prefijo estable primero. System prompt e instrucciones al inicio; lo que cambia (la pregunta, el archivo que se edita) al final.
Evita el ruido al inicio. Un timestamp o un ID de sesión en la primera línea rompe la caché para todos. (Lo usamos en el benchmark justamente para eso, con --session-mode unique.)
Mide el hit rate. No lo medimos en esta prueba y es el número que falta: qué porcentaje de tokens vino de caché en uso normal.

Lo que me llevo

De todas las palancas de inferencia (cuantización, batching, paralelismo), el prefix caching es la que mejor relación esfuerzo/beneficio tiene en un workload agéntico: una bandera y ordenar el prompt. La trampa es la de siempre: el mejor caso se ve espectacular, y hay que saber cuándo es el caso real.

El resto de la cadena está en 48 KB por token y en la guía Inference Engineering.

¿Sabes cuál es tu hit rate de caché? Cuéntame en los comentarios: es el número que más gente no tiene medido.