Si alguna vez has dimensionado un servidor para un LLM pensando solo en el tamaño del modelo y te has quedado corto de memoria en producción, casi seguro que el culpable es la caché KV. Es la variable menos intuitiva del cálculo de VRAM — y a menudo la más determinante.

Qué es la caché KV

Cuando un modelo genera texto token a token, para cada nuevo token necesita “recordar” la información de atención (las claves y valores, key y value, de ahí el nombre KV) de todos los tokens anteriores del contexto. En lugar de recalcular esa información en cada paso — algo computacionalmente carísimo — el motor de inferencia la guarda en memoria: eso es la caché KV.

Reutilizar las claves y valores evita recalcularlos en cada paso. Esto no hace constante el coste: atender a un contexto de 5.000 tokens sigue siendo más exigente que atender a uno de 500. La caché también crece con el contexto.

De qué depende el tamaño de la caché KV

A diferencia de los pesos del modelo, que son fijos una vez elegida la precisión, la caché KV es dinámica y depende de:

  1. La longitud del contexto (prompt + tokens generados). A más contexto, más caché.
  2. El número de peticiones concurrentes. Cada usuario activo mantiene su propia caché KV en paralelo — diez conversaciones simultáneas de 4K tokens consumen diez veces más caché que una sola.
  3. La arquitectura del modelo: número de capas, número de cabezas de atención y si usa técnicas de reducción como Grouped Query Attention (GQA) o Multi-Query Attention (MQA), que reducen significativamente el tamaño de la caché frente a la atención multi-cabeza tradicional (MHA).

Por qué sorprende tanto en producción

En pruebas con un solo usuario y contexto corto, la caché KV es un componente menor frente al peso del modelo. El problema aparece al escalar: en un entorno con varios solicitudes concurrentes y contextos largos (documentos completos, historiales de conversación extensos), la caché KV puede llegar a superar el tamaño de los propios pesos del modelo. Es la razón más común por la que un servidor que “funcionaba bien en pruebas” se queda sin memoria al pasar a producción.

Cómo mitigar su impacto

Existen varias estrategias, cada una con su propio compromiso:

  • Elegir modelos con GQA/MQA en lugar de atención multi-cabeza completa, cuando el caso de uso lo permita — reduce drásticamente la caché sin tocar la precisión de los pesos.
  • Cuantizar la propia caché KV (no solo los pesos), una técnica cada vez más soportada por los motores de inferencia modernos.
  • Limitar la ventana de contexto efectiva cuando no se necesita todo el histórico disponible.
  • Dimensionar por el peor caso realista de concurrencia, no por el promedio — un pico de uso sin margen de memoria provoca caídas de servicio, no solo lentitud.

Cómo incluir la caché KV en tu dimensionamiento

Este es exactamente el componente que hace que dos servidores con la misma GPU puedan comportarse de forma muy distinta según el modelo y el patrón de uso. Lo tratamos como parte del cálculo completo en nuestra guía de cuánta VRAM necesita un modelo LLM, y puedes estimarlo para tu escenario concreto — modelo, contexto y solicitudes concurrentes — en el Calculador LLM.