¿Qué es el KV cache en los modelos de lenguaje?

Es la memoria donde se guardan las Keys y Values ya calculados de los tokens anteriores en cada capa de atención, para no tener que recalcularlos en cada nuevo token generado, lo que acelera mucho la fase de generación token a token.

¿Por qué la primera respuesta de un chatbot tarda más que el resto del texto?

Porque antes de generar necesita completar la fase de 'prefill', donde calcula el KV cache inicial de todo el prompt. Una vez construida esa caché, la fase de 'decode' genera tokens mucho más rápido reutilizando ese historial.

¿Cuánta memoria puede consumir el KV cache?

Crece linealmente con el contexto: un modelo tipo 7B con 8.192 tokens de contexto puede rondar los 4 GB de caché por conversación, y ese consumo se duplica al doblar el contexto y se multiplica por cada conversación simultánea.

¿Cómo reducen las empresas el consumo de memoria del KV cache en producción?

Con técnicas como MQA/GQA para reducir el número de cabezas KV, cuantización de la caché a formatos más compactos como FP8, gestión con paginación de memoria, atención con ventana deslizante, y estrategias de RAG o resúmenes para no arrastrar contexto innecesario.

KV Cache en Transformers: el truco que hace que tu chatbot responda rápido (y por qué cuesta memoria)

INTELIGENCIA ARTIFICIAL · TRANSFORMERS · RENDIMIENTO

⏱️ 11–15 min de lectura Qué guarda el KV caching, qué acelera de verdad y por qué las ventanas largas se comen la VRAM

La idea

Guardar Keys y Values ya calculados para no “releer” toda la conversación token a token.

El efecto

Después del primer token, el modelo puede ir mucho más fluido porque evita recomputación redundante.

El precio

La memoria crece lineal con el contexto: más tokens, más capas, más VRAM por conversación.

¿Te suena esto? La primera respuesta tarda… y luego el texto empieza a salir “a chorro”.

Ese cambio de ritmo no es magia: suele ser KV cache haciendo su trabajo. Pero el truco tiene una cara B muy real: si quieres chats con contexto largo y muchos usuarios a la vez, la caché se convierte en uno de los mayores consumidores de memoria del sistema.

Si alguna vez has tenido que elegir entre “más contexto” o “más concurrencia”, estás en el terreno donde la arquitectura importa. De hecho, este tema encaja perfecto con la decisión de modelo en nube vs local: el KV cache es literalmente una conversación sobre hardware y límites.

1. Por qué un chatbot “sin caché” sería desesperante

Los modelos tipo GPT generan texto de forma autorregresiva: predicen el siguiente token, lo añaden a la secuencia, y repiten. El detalle importante es este: cada nuevo token depende de todos los anteriores (por la atención causal).

Si no existiera KV cache, en cada paso el modelo tendría que volver a calcular, para toda la secuencia, un montón de cosas que ya sabía del paso anterior. Es como escribir un mensaje mirando el historial… pero releyendo todo el chat desde el principio en cada palabra. No solo suena ridículo: es caro.

Diagrama de atención causal mostrando Query, Key y Value por token

La atención causal usa el Query del token actual contra las Keys y Values de los tokens anteriores. Lo importante: lo “anterior” no cambia cuando generas lo “nuevo”.

2. Qué guarda exactamente el KV cache

En cada capa de atención, el modelo proyecta los estados ocultos para obtener tres cosas: Q (Query), K (Key) y V (Value). Durante la generación, para calcular el siguiente token necesitas:

El Query del token nuevo (el que estás generando ahora).
Todas las Keys y Values de los tokens anteriores (el contexto completo).

Aquí está el “truco”: las Keys y Values de los tokens pasados no cambian. Así que en lugar de recomputarlas una y otra vez, se guardan en memoria como tensores por capa (y, según arquitectura, por cabeza o por grupo de cabezas).

Una forma práctica de imaginarlo: el KV cache es el “historial en bruto” que cada capa necesita para atender al pasado sin tener que reconstruirlo. Y eso es lo que hace que la generación token a token sea viable a baja latencia.

3. Prefill vs decode: dónde acelera (y dónde no)

En la práctica, la inferencia de un chatbot tiene dos fases muy distintas:

Prefill

El modelo “ingiere” tu prompt y calcula el KV cache inicial. Aquí suele vivir gran parte del tiempo hasta el primer token (TTFT).

Decode

El modelo genera tokens uno a uno, leyendo Keys/Values desde caché y añadiendo los del token nuevo.

KV cache brilla especialmente en decode. Si vas a generar 200 tokens, no quieres recalcular 200 veces el pasado completo. Pero ojo con una confusión típica: la primera respuesta no “sale gratis”. El modelo necesita construir la caché de entrada (prefill) antes de poder aprovecharla.

En chats de varias rondas, hay otro matiz: si mantienes sesión, puedes reutilizar parte del KV cache de la conversación previa. Si no (o si el sistema reempaqueta todo el historial en cada llamada), entonces cada turno vuelve a pagar prefill completo. Esto es justo el tipo de detalle que separa un chatbot “correcto” de uno que se siente instantáneo.

4. Cuánta memoria consume: la fórmula que te cambia la perspectiva

El KV cache no crece con el número de parámetros del modelo, sino con cuánto contexto estás sosteniendo. Aproximación útil (para modelos decoder-only):

KV cache (bytes) ≈ 2 × B × L × S × H_kv × d_head × bytes_por_elemento

B = batch (peticiones en paralelo), L = capas, S = tokens totales (prompt + historial + generado), H_kv = nº de cabezas “KV” (no siempre coincide con las de Query), d_head = dimensión por cabeza. El “2” es por guardar Key y Value.

Vamos con un ejemplo para que duela lo justo:

Un modelo tipo 7B con 32 capas, 32 cabezas y d_head ≈ 128, usando FP16/BF16 (2 bytes).
Con 8.192 tokens de contexto, el KV cache puede rondar ≈ 4 GB para una sola conversación.
Doblas a 16k tokens y, si todo lo demás se mantiene, te vas a ≈ 8 GB. Solo de caché.

¿Lo mejor (o lo peor)? Ese coste se multiplica por el batch y por la concurrencia. Si quieres servir muchas conversaciones simultáneas, el KV cache se vuelve el verdadero “devorador de VRAM”. Por eso, en producción, el rendimiento no es solo cuestión de FLOPs: también es una guerra de memoria y ancho de banda.

Esquema de cómo se reutilizan Key y Value desde KV cache y se añade el token nuevo

La mecánica esencial: el token nuevo calcula su Q y añade su K/V; el resto del pasado se lee desde caché.

5. Por qué las ventanas de contexto largas “cuestan tanto”

Cuando ves modelos con 128k o 1M de contexto, es fácil pensar: “genial, meto todo y ya”. Pero a nivel de inferencia eso cambia la economía del sistema:

Más contexto significa más KV cache por usuario. Aunque el modelo sea el mismo, el servidor ahora necesita sostener una estructura mucho más grande para que tu conversación siga siendo atendible token a token.

Se reduce la concurrencia efectiva. En la práctica, con la misma GPU, o atiendes menos sesiones a la vez, o recortas contexto, o aceptas más latencia. No hay milagros: solo trade-offs.

Y aparece el “arte” de decidir qué meter en el prompt. Aquí es donde RAG, resúmenes y estrategias de memoria cobran sentido, porque meter “todo” no solo puede empeorar la calidad, también encarece. Si quieres una visión clara para elegir arquitectura, te va a encajar el mapa de decisión de RAG vs fine-tuning vs agentes.

6. “Vale, ¿y cómo lo hacen en producción?”

Cuando un proveedor sirve miles de chats, no puede permitirse un KV cache infinito por sesión. Por eso verás combinaciones de técnicas (algunas invisibles para ti):

Reducir H_kv sin perder calidad: variantes como MQA/GQA hacen que haya menos “cabezas KV” que “cabezas de Query”. Resultado: misma idea de atención, menos memoria de caché.
Cuantizar la caché: guardar KV en FP8 o incluso formatos más compactos reduce memoria y ancho de banda. Es una de las palancas más directas para escalar contexto o usuarios.
Gestión inteligente del KV cache: en vez de una reserva monolítica, se usa paginación y pools de memoria para asignar, mover o evictar partes del contexto de forma controlada.
Atención con ventana deslizante: el modelo atiende con prioridad a lo más reciente (o a segmentos clave), limitando el crecimiento efectivo del KV cache.
“Memoria” a nivel aplicación: resumir, comprimir historial, o recuperar solo lo relevante (RAG) para no arrastrar ruido ni tokens inútiles.

Diagrama de pool fijo de KV cache mostrando cache hit, cache miss y recomputación

La imagen mental correcta: un pool de memoria para KV. Si hay “hit”, la atención reutiliza; si hay “miss” (por evicción o límites), toca recomputar y la latencia se dispara.

7. Checklist rápido si tu chatbot va lento (o se queda sin memoria)

Si el primer token tarda demasiado

Suele ser prefill: prompt grande, historial gigante o demasiados “documentos pegados”. Recorta, resume, o recupera solo lo relevante.

Si tu caso es chat multi-turn, revisa si estás reconstruyendo todo el contexto en cada turno o si realmente reutilizas sesión.

Si se cae con OOM (out of memory)

Casi siempre es KV cache (especialmente con contextos largos) o batch demasiado alto. Baja: contexto máximo, batch, o longitud de salida.

Si controlas el stack, mira opciones de cuantización de KV cache o arquitecturas con menos cabezas KV (GQA/MQA).

Si quieres irte a local y todo se vuelve “muy justo”

En móvil o equipos modestos, la memoria es la reina. Ahí cobra sentido apostar por modelos pequeños y eficientes y diseñar prompts con disciplina. Si te interesa ese enfoque, mira small language models en dispositivos.

8. La idea que te llevas

KV cache es uno de esos inventos que parecen “un detalle de implementación”… hasta que te das cuenta de que define la experiencia del usuario y el coste de servir el producto.

Acelera porque evita recomputar Keys y Values del pasado en cada token. Cuesta porque para conseguir esa velocidad tienes que pagar memoria por capa y por token. Y cuando subes el contexto, ese coste deja de ser una línea en una tabla: se convierte en el cuello de botella.

La próxima vez que alguien te diga “pongamos 128k de contexto y listo”, ya tienes la pregunta clave: ¿cuánta VRAM estamos dispuestos a pagar por conversación?