vLLM enseña a los nodos decode a devolver la KV-cache y reduce el TTFT hasta 3,3 veces

El equipo de vLLM ha añadido al inference desagregado la transferencia bidireccional de KV-cache. Los nodos prefill ahora pueden recoger de los nodos decode la caché ya calculada de los turnos anteriores de la conversación, de modo que no tienen que recalcular todo el contexto en cada turno. En prompts largos de varios turnos, el tiempo hasta el primer token (TTFT) se reduce hasta 3,3 veces.

Dónde se perdía el tiempo

En el esquema de disaggregated serving, las fases prefill y decode se ejecutan en pools de GPU distintos. Prefill procesa el prompt y construye la KV-cache; después se la entrega a un nodo decode, que genera la respuesta token a token. La separación tiene lógica: prefill está limitado por cómputo, decode por memoria y ancho de banda, y cada pool puede ajustarse a su propia carga.

Sin embargo, la transferencia de la caché era unidireccional, de prefill a decode. Por eso, a partir del segundo turno aparecía trabajo redundante. El cliente envía todo el historial de la conversación más el nuevo mensaje. La caché de ese historial ya está en el nodo decode, pero el nodo prefill no lo sabe y lo calcula todo de nuevo.

En un chat convencional es tolerable. Para los agentes, no. Un ciclo agéntico consta de decenas de pasos: llamada a una herramienta, respuesta, razonamiento, nueva llamada. El contexto crece hasta decenas de miles de tokens, mientras que la parte nueva en cada paso es pequeña. Se paga el coste completo de prefill por algo que ya se había calculado un minuto antes.

Cómo funciona el canal inverso

La idea es sencilla. Tras generar la respuesta, el nodo decode conserva la KV-cache tanto del prompt como de los tokens generados. Cuando llega el siguiente turno, el nodo prefill puede solicitarle el prefijo coincidente, recibirlo y calcular solo la parte final nueva. A partir de ahí todo sigue como antes: la caché completa se envía a decode.

En lugar de recalcular todo el historial, se transfieren por red tensores ya listos. La ganancia aparece donde enviar los datos por el interconnect resulta más barato que repetir el cálculo. Cuanto más largo es el prefijo común, mayor es esa diferencia.

Cifras clave del anuncio:

• aceleración del TTFT: hasta 3,3x;
• escenario: prompts largos de varios turnos;
• qué se ahorra: el cómputo de prefill repetido sobre el historial ya procesado;
• dirección de la transferencia: decode → prefill, además de prefill → decode;
• plataforma: vLLM en configuración con nodos prefill y decode desagregados.

El valor de 3,3x se presenta como límite superior. Es el mejor caso en diálogos largos, no un resultado medio garantizado. En una conversación corta con un prefijo pequeño, la diferencia será claramente más modesta.

Lo que queda fuera

La versión resumida del anuncio no incluye detalles de los que depende el efecto real: qué transporte y qué conector se utilizan, en qué hardware y con qué modelo se hicieron las mediciones, cómo cambia la carga de red y cómo afecta el esquema al throughput global. Es probable que estén en el texto completo del blog, y conviene leerlo antes de adoptar la función.

Hay además una cuestión de arquitectura. Para que el nodo decode pueda devolver la caché, tiene que retenerla, y la HBM de la GPU es limitada. Cuanto más duran las sesiones, mayor es la presión sobre la memoria y más importante resulta la política de expulsión. Si la caché ya se ha expulsado, no habrá mejora y prefill volverá al recálculo completo.

A quién le servirá en la práctica

En primer lugar, a los equipos que ya ejecutan vLLM en configuración desagregada y atienden a agentes, asistentes de programación u otras sesiones largas. Para ellos, el TTFT en los pasos tardíos del ciclo determina la velocidad que percibe el usuario del producto.

Antes de adoptarlo, conviene comprobar con el tráfico propio:

• qué proporción del prefijo se repite entre turnos y cómo crece a lo largo de la sesión;
• si el ancho de banda del interconnect entre nodos prefill y decode es suficiente;
• cuánto tiempo conservan los nodos decode la caché y con qué frecuencia se expulsa antes del siguiente turno;
• cómo cambian el p95/p99 del TTFT, y no solo el mejor resultado.

Si los prefijos son largos y las sesiones caben en la ventana de retención de la caché, el efecto puede acercarse al declarado. Si los diálogos son cortos o dispersos, el beneficio será menor y la complejidad añadida del esquema puede no compensar.