Avanzado 11 minOptimización

Cuantizar la caché KV: ahorrar VRAM (contexto largo contexte)

Tienes suficiente VRAM para cargar el modelo, pero en cuanto aumentas el contexto a 16k o 32k tokens, la memoria necesaria supera la capacidad disponible. La culpable es la caché KV: una memoria caché que crece linealmente con el contexto y que, con prompts largos, puede ocupar tanto como el propio modelo. La cuantización de la caché KV la comprime en Q8 o Q4 para duplicar el contexto que admite la misma tarjeta. Aquí te explicamos cómo activarla en Ollama y llama.cpp, las mejoras expresadas en cifras y el impacto real en la calidad.

Por Mohamed Meguedmi·Actualización 2026-08-27·Probado en Windows, macOS y Linux

#¿Por qué el caché KV consume tu VRAM?

Cuando un LLM genera texto, no recalcula la atención sobre todo el prompt con cada nuevo token: mantiene en memoria los vectores de claves (K) y valores (V) de cada token ya visto. Es el KV cache, y es lo que hace que la generación sea rápida. El problema: esta memoria crece linealmente con la longitud del contexto. Si duplicas el contexto, duplicas el KV cache.

Con un prompt corto de unos cientos de tokens, es insignificante. Pero en cuanto se utiliza RAG con documentos grandes, se resumen transcripciones o se usan agentes con memoria larga, el contexto se dispara, y la caché KV también. En un 70B con 32k de contexto, puede superar los 10 GB por sí sola, además de los ~40 GB del modelo. A menudo es esta caché, y no el modelo, la que provoca el error de falta de memoria en los prompts largos.

i
Modelo frente a caché KV: dos componentes distintos del consumo de memoria
La VRAM se divide en tres partes: los pesos del modelo (fijos, dependen del tamaño y de la cuantización), la caché KV (variable, depende del contexto) y un pequeño consumo adicional. Cuantizar el modelo (Q4_K_M) reduce el primer componente. Cuantizar la caché KV reduce el segundo. Son dos formas independientes de reducir el consumo de memoria.

#¿Cuánto pesa tu caché KV?

El kit de IA Local

Tu ChatGPT privado y gratuito en tu máquina en 1 hora — LM Studio, Ollama, Open WebUI, tus documentos, sin nube.

  • Espacio en línea de por vida
  • PDF + archivos
  • Reembolsado 30 j
El kit de IA Local →o todos los kits de por vida — 49 € →

El tamaño del caché KV depende de cuatro factores: el número de capas del modelo, la dimensión de atención, la longitud de contexto y la precisión de almacenamiento. En FP16 (por defecto), la fórmula aproximada es: 2 (K y V) × capas × dim_kv × contexto × 2 bytes. En la práctica, recuerda estos órdenes de magnitud en FP16 con un contexto de 32k tokens:

7-9B (por ejemplo, Qwen 3.5 9B, Granite 4.2 8B)
≈ 2 a 4 GB de caché KV a 32k, según la arquitectura (GQA ayuda mucho).
14B
≈ 4 a 6 GB a 32k tokens.
32B
≈ 8 a 10 GB con 32k tokens.
70B
≈ 10 a 16 GB para 32k tokens — a menudo el factor limitante.
i
GQA cambia la situación
Los modelos recientes usan Grouped-Query Attention (GQA), que comparte las cabezas K/V entre varias cabezas de consulta. Resultado: su caché KV ya es mucho más ligera que la de los modelos antiguos con Multi-Head Attention. Qwen 3.5, Gemma 4 y Granite 4.2 se benefician de ello. Esto no elimina la necesidad de cuantizar en contextos muy largos, pero eleva el umbral a partir del cual resulta necesario.

#Lo que cambia con la cuantización de la caché KV

La idea es la misma que para los pesos del modelo: en lugar de almacenar cada valor de la caché en 16 bits (FP16), se almacena en 8 bits (Q8_0) o 4 bits (Q4_0). Así, la memoria de la caché se divide por 2 (Q8) o por 4 (Q4). Como la caché KV puede representar una gran parte de la VRAM en contextos largos, el ahorro es directo: con la misma cantidad de VRAM, se puede duplicar aproximadamente la longitud de contexto que se puede manejar en Q8.

FP16
Precisión de referencia, sin pérdida, pero la que más recursos consume. La opción predeterminada.
Q8_0
La mitad de memoria, con una pérdida de calidad casi indetectable en la mayoría de los modelos. El mejor equilibrio.
Q4_0
Una cuarta parte de la memoria, pero con una pérdida de calidad medible que varía según el modelo. Reservar para los casos en los que la VRAM sea realmente el factor limitante.
!
Requisito previo: Flash Attention
La cuantización de la caché KV exige que Flash Attention esté activo. Sin él, llama.cpp y Ollama se niegan a aplicar un tipo de caché distinto de FP16 o dan un error. Es coherente: Flash Attention y la caché cuantizada trabajan juntos para reducir la huella de memoria de la atención.

#Activar la cuantización KV en Ollama

Ollama permite configurar la cuantización de la caché KV mediante dos variables de entorno del demonio. Hay que activar Flash Attention y luego elegir el tipo de caché. Estas variables se configuran en el servicio Ollama, no al ejecutar ollama run.

  1. 01
    Activar Flash Attention
    Configura OLLAMA_FLASH_ATTENTION=1 en el entorno del demonio. Es el requisito previo para cualquier caché que no sea FP16.
  2. 02
    Elegir el tipo de caché
    Establece OLLAMA_KV_CACHE_TYPE en el valor deseado: f16 (predeterminado), q8_0 (recomendado) o q4_0 (agresivo).
  3. 03
    Reiniciar el daemon
    Las variables de entorno solo se leen al iniciar el servicio. Reinicia Ollama para que tengan efecto.
  4. 04
    Verificar la mejora
    Carga un modelo con un contexto amplio y monitorea la VRAM con nvidia-smi o ollama ps. Debes poder aumentar num_ctx a un valor más alto que antes.
Terminal — Linux (systemd)
# Éditer l'unité systemd du service
sudo systemctl edit ollama

# Ajouter dans la section [Service] :
[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

# Recharger et redémarrer
sudo systemctl daemon-reload
sudo systemctl restart ollama
Terminal — lanzamiento manual
# Sur macOS ou pour un lancement direct du serveur
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve
PowerShell — Windows
# Poser les variables au niveau utilisateur puis redémarrer Ollama
setx OLLAMA_FLASH_ATTENTION 1
setx OLLAMA_KV_CACHE_TYPE q8_0

# Quitter Ollama depuis la barre des tâches et le relancer
→
Aumenta el contexto para aprovecharlo
Cuantizar la caché no sirve de nada si tu num_ctx sigue siendo bajo. Una vez activada la cuantización, aumenta la ventana de contexto del modelo (parámetro num_ctx en el Modelfile o en la llamada a la API) para convertir la VRAM ahorrada en contexto utilizable.

#Activar en llama.cpp

En la línea de comandos de llama.cpp, la cuantización de la caché KV se controla con dos opciones distintas para las claves (K) y los valores (V), además de la opción de Flash Attention. Se pueden cuantizar K y V de forma independiente, pero en la práctica se ponen al mismo nivel.

Terminal — llama-cli / llama-server
# -fa active Flash Attention (obligatoire)
# -ctk = type du cache des clés, -ctv = type du cache des valeurs
llama-server \
  -m modele.gguf \
  -c 32768 \
  -fa \
  -ctk q8_0 \
  -ctv q8_0 \
  -ngl 99
-fa
Activa Flash Attention. Sin esta bandera, -ctk/-ctv por debajo de f16 falla.
-ctk q8_0
Cuantiza la caché de claves a 8 bits. Valores posibles: f16, q8_0, q4_0, q4_1, q5_0, q5_1.
-ctv q8_0
Cuantiza la caché de valores. Mismo conjunto de valores que -ctk.
-c 32768
El tamaño de contexto al que apuntas. La cuantización te permite aumentarlo sin desbordar la memoria disponible.
→
Asimetría K/V posible
El caché de valores (V) soporta mejor la cuantización agresiva que el de claves (K), más sensible. Un equilibrio interesante cuando la VRAM es escasa: -ctk q8_0 -ctv q4_0. Ganas espacio en V sin perjudicar la precisión de las claves.

#Cuánto contexto se gana: cifras reales

La ganancia concreta depende de la proporción de tu presupuesto de VRAM que ocupa la caché KV. Si el modelo cabe con mucho margen, cuantizar la caché solo libera un poco de espacio. Si el modelo ya satura la VRAM, puede marcar la diferencia entre 8k y 24k de contexto. Estos son algunos órdenes de magnitud observados, manteniendo constante la VRAM:

FP16 → Q8_0
Cache dividido por 2. En la práctica, contexto soportable aproximadamente duplicado cuando el cache dominaba el presupuesto.
FP16 → Q4_0
Caché dividida por 4. Permite mantener un contexto hasta ~3-4 veces más largo, a costa de una pérdida de calidad medible.
Ejemplo de 14B en RTX 4080 de 16 GB
De ~16k de contexto en FP16 a ~32k+ en Q8_0, manteniendo el modelo y el resto dentro de los mismos 16 GB.
Ejemplo de 32B en RTX 4090 24GB
Pasar la caché a Q8_0 suele permitir trabajar con documentos RAG largos sin descargar parte del procesamiento en la CPU.
i
La mejora no se limita al ahorro de memoria
Una caché KV más pequeña también reduce las necesidades de ancho de banda de memoria por token. En contextos muy largos, a veces se observa un ligero aumento de la velocidad de generación en Q8, además del ahorro de VRAM. No cuentes con ello de forma sistemática, pero es una ventaja adicional frecuente.

#El impacto en la calidad según los modelos

Esa es la verdadera pregunta. Cuantizar la caché introduce ruido en la atención, y no todos los modelos reaccionan igual. La regla empírica que se desprende de las pruebas de la comunidad:

Q8_0 en el caché
Diferencia prácticamente indetectable en la gran mayoría de los modelos. Perplejidad y calidad percibida casi idénticas a las de FP16. Es el ajuste que conviene activar por defecto, casi sin pensarlo.
Q4_0 en el caché
Pérdida visible y variable. Algunos modelos la soportan muy bien; otros empiezan a divagar en contextos muy largos, a perder el hilo o a alucinar más. Probar en TU caso.
Modelos con GQA
Generalmente más resistentes a la cuantización de la caché, ya que su caché es compacta y está bien estructurada.
Tareas sensibles (código, cálculo, extracción estricta)
Más expuestas a la degradación con Q4. Mantente en Q8 para todo lo que requiera precisión factual.
!
Prueba antes de adoptar Q4
Nunca uses Q4 para la caché en producción sin haber comparado las respuestas con tus propios prompts largos. El ahorro de VRAM es tentador, pero una pérdida de fiabilidad en un RAG o un agente cuesta más que la VRAM ahorrada. Q8 es la opción predeterminada segura; Q4 es una optimización que debe validarse empíricamente.

#Solución de problemas

« flash attention required » o caché ignorado
Has olvidado -fa (llama.cpp) o OLLAMA_FLASH_ATTENTION=1 (Ollama). La caché cuantizada vuelve a FP16 sin avisar, o se genera un error.
No se observa ahorro de VRAM
Tu contexto es demasiado corto para que la caché ocupe una cantidad significativa de memoria. El ahorro solo se aprecia con prompts largos. Aumenta num_ctx / -c para comprobarlo.
Calidad que se degrada en prompts largos
Probablemente estés usando Q4 en un modelo que no lo tolera bien. Vuelve a configurar K en q8_0 (o incluso todo en q8_0) y prueba de nuevo.
Variables Ollama sin efecto
Solo se leen al arrancar el daemon. Reinicia el servicio después de configurarlas y verifica que el proceso ollama pueda verlas.
Sigue dando OOM pese a la cuantización
Es el propio modelo el que excede la memoria disponible, no la caché. Cuantiza también los pesos (Q4_K_M) o elige un modelo de menor tamaño.
Diagnósticos rápidos
# Vérifier ce qui tourne sur GPU et la VRAM consommée
ollama ps
nvidia-smi

# Confirmer que les variables sont bien vues par le daemon (Linux)
systemctl show ollama --property=Environment

#Para ir más allá

La cuantización de la caché KV es una de las opciones para manejar contextos grandes en local. Estas guías completan el panorama:

Flash Attention 2 en un LLM local: activar y medir la mejora de rendimiento
El requisito previo para la cuantización del KV cache, que además aporta por sí mismo mejoras en el uso de memoria y en la velocidad. Leer primero si Flash Attention aún no está activo en tu equipo.
Elegir tu cuantización (Q4, Q5, Q8, FP16)
Para cuantizar los pesos del modelo —el otro gran componente del consumo de VRAM—, como complemento a la cuantización de la caché.
Instalar Ollama: Windows, macOS y Linux
Si tu stack aún no está en marcha, con los requisitos de GPU para dimensionarlo adecuadamente.
¿Esta guía te ha ayudado?

¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.