Caché KV vs caché de prompts: diferencias clave

Caché KV frente a caché de prompts: respuesta breve

La caché KV de un proveedor y la caché de prompts comparten una palabra, pero casi nada más. La caché KV es memoria de trabajo por solicitud. Se mantiene en la RAM o la VRAM de su servidor durante toda la vida de una solicitud y crece con la longitud del contexto y con el número de solicitudes simultáneas. La caché de prompts del proveedor es una función de facturación y latencia. El proveedor almacena un prefijo estable de su prompt en sus servidores y cobra una tarifa reducida cuando vuelve a enviarlo.

Una es memoria que compra como hardware. La otra es memoria que mantiene otra entidad y por la que le cobra un alquiler.

La diferencia práctica es más importante que la definición. Puede quedarse sin caché KV. Cuando ocurre, el modelo no se carga o se rechaza la solicitud. No puede quedarse sin caché de prompts. Sólo puede no obtener una coincidencia con ella y, en ese caso, paga silenciosamente el precio completo.

Qué contiene la caché KV y por qué existe

Un transformer que genera el token número 500 debe atender a los 499 tokens anteriores. Para cada uno de esos tokens, cada capa necesita un vector de clave y un vector de valor. Recalcularlos todos para cada token nuevo haría que la generación creciera con el cuadrado de la longitud, por lo que el runtime los conserva. Ese almacenamiento es la caché KV (caché de clave/valor).

Es un estado por solicitud porque se construye a partir de la secuencia exacta de tokens de esa solicitud. Dos usuarios que envíen prompts diferentes no pueden compartirla, salvo que el runtime use el almacenamiento en caché de prefijos, una función independiente que se describe más adelante.

El servicio se ejecuta en dos fases. Prefill lee el prompt completo y llena la caché, y está limitado por la capacidad de cómputo. Decode produce un token cada vez y lo añade a la caché, y está limitado por el ancho de banda de memoria. Por eso el procesamiento del prompt y la generación de tokens muestran velocidades diferentes cuando mide tokens por segundo en tu propio equipo.

¿Cuánta memoria usa la caché KV?

No busque una tabla del proveedor. El tamaño se calcula mediante una operación que puede repetir para cualquier modelo:

bytes per token = 2 * layers * kv_heads * head_dim * bytes per element

El 2 corresponde a la clave y al valor. Todos los demás números proceden de la config.json del modelo, publicada en su página de Hugging Face.

Tomemos Llama 3.1 8B. Su configuración indica num_hidden_layers 32 y num_key_value_heads 8. La hidden_size de 4096, distribuida entre 32 cabezas de atención, da una dimensión de cabeza de 128. En f16, cada elemento ocupa 2 bytes:

2 * 32 * 8 * 128 * 2 = 131072 bytes = 128 KiB per token

Multiplique este valor por el contexto solicitado y después por el número de solicitudes que ejecuta simultáneamente.

[
  {
    "label": "2k context",
    "one_request_gib": 0.25,
    "four_requests_gib": 1
  },
  {
    "label": "8k context",
    "one_request_gib": 1,
    "four_requests_gib": 4
  },
  {
    "label": "32k context",
    "one_request_gib": 4,
    "four_requests_gib": 16
  },
  {
    "label": "128k context",
    "one_request_gib": 16,
    "four_requests_gib": 64
  }
]

Con un contexto de 8k, la caché ocupa 1 GiB para una solicitud. Con 32k ocupa 4 GiB, un valor del mismo orden que los propios pesos de 4 bits. Con el contexto máximo de 128k del modelo, ocupa 16 GiB para una solicitud y 64 GiB si cuatro solicitudes lo llenan por completo. Los pesos no cambiaron. Sólo cambió la caché.

La atención de consultas agrupadas (GQA) influye mucho en ese valor. Llama 3.1 8B tiene 8 cabezas de clave/valor que atienden a 32 cabezas de consulta, por lo que cuatro cabezas de consulta comparten un par de clave/valor almacenado. Un modelo cuyo num_key_value_heads es igual a su num_attention_heads usa cuatro veces más caché con el mismo número de parámetros. Compruebe ese campo antes de asumir que servir dos modelos 8B tiene el mismo coste.

Por qué un modelo que funcionaba con 2k se niega a cargarse con 32k

El runtime reserva la caché KV cuando carga el modelo. La reserva tiene el tamaño correspondiente a la longitud de contexto configurada, no al prompt que se envía realmente. La ventana de contexto predeterminada de Ollama es de 4096 tokens. Si la aumenta a 32k, solicita 4 GiB de asignación adicional antes de que llegue un solo token.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

La misma configuración para cada sesión, desde el prompt interactivo:

ollama run llama3.1:8b
/set parameter num_ctx 32768

El fallo tiene un aspecto distinto en cada stack. vLLM comprueba los cálculos durante el arranque y se niega a ejecutarse:

ValueError: The model's max seq len (131072) is larger than the maximum number of tokens that can be stored in KV cache (78336). Try increasing `gpu_memory_utilization` or decreasing `max_model_len` when initializing the engine.

En una VPS que sólo usa CPU no se realiza esa comprobación, porque la asignación corresponde a la RAM del sistema. En su lugar, el kernel activa el asesino de procesos por falta de memoria y deja las pruebas en el búfer circular del kernel:

dmesg -T | grep -i "killed process"

Una línea que indique el nombre del proceso de serving significa que el sistema prometió más memoria de la disponible. La solución es usar un contexto más pequeño, no un archivo de swap más grande: una caché KV paginada en disco se lee con cada token generado, por lo que la generación se ralentiza hasta resultar inútil. La elección de un valor adecuado se explica en nuestra guía sobre num_ctx y la longitud de contexto en Ollama.

Qué efecto tiene la concurrencia en la cifra

Cada solicitud en curso lleva su propia caché KV. Este es el aspecto que más se omite en los planes de capacidad. Cuatro usuarios, cada uno con 32k de contexto, necesitan 16 GiB entre todos, además de los pesos.

Los runtimes difieren en lo estrictos que son con este aspecto. Ollama y llama.cpp reservan el contexto solicitado al cargar el modelo, por lo que la memoria queda comprometida aunque nadie la utilice. vLLM divide el pool en bloques de tamaño fijo y los asigna a medida que crece cada solicitud, por lo que una solicitud de 500 tokens ocupa sólo el espacio correspondiente a 500 tokens. En ambos casos, el pool es finito. Cuando se llena, las solicitudes nuevas quedan en cola en lugar de ejecutarse. El efecto de esa espera en los tiempos de respuesta se explica en cuántos usuarios simultáneos puede atender un LLM autoalojado.

Cuatro formas de reducir el tamaño de la caché KV

1. Reduzca la longitud del contexto. Es el factor con mayor impacto y normalmente el más económico. La mayoría de las cargas de trabajo de chat no se acercan nunca a 32k.
2. Cuantice la propia caché. El valor predeterminado de OLLAMA_KV_CACHE_TYPE en Ollama es f16 y acepta q8_0, que usa aproximadamente la mitad de memoria, y q4_0, que usa aproximadamente una cuarta parte. Los equivalentes en llama.cpp son -ctk q8_0 y -ctv q8_0.
3. Elija un modelo con menos cabezas key/value o menos capas. Consulte config.json antes de descargar 40 GB de pesos.
4. Atienda menos solicitudes a la vez y ponga el resto en cola.

En q4_0, la cifra de Llama 3.1 8B baja de 128 KiB por token a aproximadamente 32 KiB, por lo que un contexto de 32k cuesta cerca de 1 GiB en lugar de 4 GiB. Este ahorro tiene un coste. Las claves y los valores se almacenan con menor precisión, así que compare la salida con sus propios prompts antes de mantener esta configuración.

Qué ofrece realmente la caché de prompts del proveedor

La caché de prompts del proveedor es un producto diferente, con una unidad de facturación distinta. Se marca un prefijo estable, el proveedor lo almacena y las llamadas posteriores que repiten exactamente ese prefijo se facturan con una tarifa reducida en lugar del precio completo de entrada.

Multiplicadores publicados por Anthropic, a fecha de agosto de 2026: escribir en una caché de 5 minutos cuesta 1.25 veces el precio base de los tokens de entrada. Escribir en una caché de 1 hora cuesta 2 veces, y leer de la caché cuesta 0.1 veces. Si se coloca un prompt de sistema de 20,000 tokens detrás de esas cifras, el resultado es evidente.

[
  {
    "label": "No caching, every call",
    "billed_token_equivalents": "20,000"
  },
  {
    "label": "First call, 5 minute cache write",
    "billed_token_equivalents": "25,000"
  },
  {
    "label": "First call, 1 hour cache write",
    "billed_token_equivalents": "40,000"
  },
  {
    "label": "Every later call, cache hit",
    "billed_token_equivalents": "2,000"
  }
]

Léalo como una operación aritmética. La prima de escritura de la caché de 5 minutos equivale a 5,000 tokens en la primera llamada: 25,000 frente a 20,000 por enviarlo sin caché. Cada llamada posterior dentro de la ventana factura 2,000 en lugar de 20,000, lo que supone un ahorro de 18,000. Por tanto, la caché de 5 minutos resulta rentable a partir de la segunda llamada.

La caché de 1 hora es una apuesta diferente. Factura 40,000 al escribir, con una prima de 20,000 tokens equivalentes, por lo que necesita dos aciertos dentro de esa hora para resultar rentable. Esto depende del patrón de tráfico, no del modelo. El cálculo completo, incluido cómo elegir la ventana, se encuentra en las cuentas del punto de equilibrio para la caché de prompts de Claude.

Dos detalles determinan si se utiliza la caché. Primero, un prefijo inferior a la longitud mínima del modelo no se almacena en caché de forma silenciosa: a fecha de agosto de 2026, el mínimo documentado es de 512 tokens para Claude Opus 5 y 1,024 tokens para Claude Sonnet 5. Una solicitud más corta se procesa normalmente y no devuelve ningún error. Segundo, la duración se mide desde el inicio de la solicitud que escribe o lee la entrada, y cada lectura la prolonga sin coste adicional. Por tanto, un endpoint con mucha actividad puede mantener activa indefinidamente una caché de 5 minutos. Un endpoint al que se llama una vez cada diez minutos paga la prima de escritura en cada ocasión y nunca obtiene lecturas de la caché.

Compruebe la respuesta en lugar de darla por supuesta. El objeto usage informa de cache_creation_input_tokens y cache_read_input_tokens. Un recuento de lecturas igual a cero en todas las llamadas significa que está pagando escrituras sin obtener ningún beneficio.

Cuando se encuentran las dos cachés

Un prompt de sistema largo es el punto de encuentro, y se cobra por ambos lados al mismo tiempo.

En el servidor local, un prompt de sistema de 20,000 tokens ocupa aproximadamente 2.4 GiB de caché KV en un servidor Llama 3.1 8B con f16. Además, ocupa ese espacio por separado para cada solicitud simultánea que lo incluya. En el proveedor remoto, ese mismo prefijo genera una escritura de caché y, en cada llamada posterior, cuesta 0.1 veces el precio de entrada. El coste local aumenta con el número de usuarios. El coste remoto aumenta con el tráfico y se restablece durante los periodos de inactividad.

Existe una función local que se parece a la caché de prompts del proveedor y que se confunde constantemente con ella: la caché de prefijos. La documentación de vLLM describe la caché automática de prefijos como el almacenamiento en caché de «la caché KV de las consultas existentes, para que una consulta nueva pueda reutilizarla directamente si comparte el mismo prefijo con una de las consultas existentes». El servidor llama.cpp mantiene una caché de prompt por slot de forma predeterminada, y --cache-reuse N establece el tamaño mínimo del bloque que intentará reutilizar.

La caché de prefijos ahorra procesamiento de prefill. El prompt de sistema de 20,000 tokens se procesa una vez en lugar de hacerlo en cada solicitud, lo que reduce notablemente el tiempo hasta el primer token. En vLLM, los bloques compartidos se reutilizan en lugar de duplicarse, por lo que también mejora el uso de memoria. Lo que nunca hace es reducir la caché que debe mantenerse para los tokens activos en ese momento. Mantener los pesos cargados entre solicitudes es un mecanismo relacionado, pero independiente, que se explica en mantener un modelo de Ollama cargado entre solicitudes.

Qué medir en su propio equipo

Cargue el modelo con el contexto de destino y lea los valores reales en lugar de confiar en la estimación.

ollama ps
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
free -g

ollama ps muestra el modelo cargado, su tamaño y si se ejecuta en la GPU o en la CPU. Si esperaba que un modelo se alojara por completo en la GPU, pero aparece dividido entre la GPU y la CPU, significa que la caché KV expulsó parte del modelo de la GPU. La velocidad de generación disminuirá en consecuencia. nvidia-smi muestra el valor real de VRAM, y free -g cumple la misma función en un VPS que usa sólo la CPU. Aumente el contexto por pasos, vuelva a cargar el modelo y observe cómo cambia el valor. El cálculo y el valor mostrado deberían ser parecidos. Si no lo son, la diferencia suele deberse a los búferes de cálculo propios del entorno de ejecución, no a un error en la fórmula.

Si esos valores le llevan a considerar un hardware que preferiría no alquilar, la comparación con el pago por token se desarrolla en GPU VPS frente a tokens de API.

FAQ

¿La caché KV es lo mismo que el almacenamiento en caché de prompts?

No. La caché KV es memoria por solicitud dentro del proceso de servicio. Contiene los vectores de clave y valor de cada token del contexto actual. Se encuentra en la RAM o la VRAM y se libera cuando termina la solicitud. La caché de prompts del proveedor es una función de facturación. Almacena un prefijo estable del prompt en la infraestructura del proveedor y aplica una tarifa reducida cuando se vuelve a enviar. Quedarse sin caché KV impide cargar un modelo. No disponer de caché de prompts sólo aumenta la factura y el tiempo hasta el primer token.

¿Por qué mi modelo se carga con un contexto de 2k, pero falla con 32k?

Porque el runtime asigna toda la caché KV al cargar el modelo. El tamaño se basa en la longitud de contexto configurada, no en el prompt que se envía. Para Llama 3.1 8B en f16, la caché ocupa 128 KiB por token. Por tanto, un contexto de 2k consume 0.25 GiB y uno de 32k consume 4 GiB. Los pesos caben en ambos casos. Lo que falla es la reserva de memoria. vLLM lo informa mediante ValueError, que indica el número máximo de tokens que pudo almacenar, y sugiere aumentar gpu_memory_utilization o reducir max_model_len. En un equipo que sólo usa CPU, el kernel out-of-memory killer termina el proceso. Puede confirmarlo con dmesg -T | grep -i "killed process".

¿Cómo calculo el tamaño de la caché KV de mi modelo?

Multiplique 2 por el número de capas, el número de cabezales de clave/valor, la dimensión de cada cabezal y los bytes por elemento. El resultado es el número de bytes por token. Después, multiplíquelo por la longitud de contexto y por el número de solicitudes simultáneas. Consulte el número de capas y cabezales en el config.json del modelo. Use 2 bytes por elemento para f16 o bf16. Una caché q8_0 ocupa aproximadamente la mitad, y q4_0 aproximadamente una cuarta parte.

¿La caché de prompts reduce la memoria que necesita mi propio servidor?

La caché de prompts del proveedor no afecta al hardware, porque el almacenamiento se encuentra en el lado del proveedor. El equivalente local es la caché de prefijos, disponible tanto en vLLM como en el servidor llama.cpp. Reutiliza los vectores de clave y valor ya calculados para un prefijo compartido. Esto ahorra cálculo de prefill y reduce el tiempo hasta el primer token. En vLLM, los bloques compartidos se reutilizan en lugar de duplicarse, por lo que también mejora el uso de memoria. Ninguna de las dos funciones reduce la caché necesaria para los tokens que están en proceso. Por tanto, el cálculo de contexto y concurrencia sigue determinando el mínimo de memoria requerido.

¿Vale la pena almacenar en caché un prompt que sólo envío una vez?

No. Escribir en la caché cuesta más que enviar una entrada normal: 1.25 veces la tarifa base para la opción de 5 minutos en agosto de 2026. Por tanto, un prefijo que no se vuelva a enviar dentro de ese intervalo supone una pérdida directa. La caché resulta útil cuando se repite el mismo prefijo, por ejemplo, un prompt de sistema largo o un documento sobre el que hará varias preguntas. Compruebe cache_read_input_tokens en la respuesta de la API para confirmar que obtiene aciertos de caché en lugar de pagar por escrituras.