KV Cache on KnightLi Blog

DeepSeek-V4 KV Cache explicado: por qué el contexto de 1M usa menos VRAM

Mon, 18 May 2026 18:38:26 +0800

El costo real de los modelos de contexto largo no suele estar en si aceptan un millón de tokens, sino en cuánta VRAM consume el KV Cache durante la inferencia.

Durante la decodificación Transformer, cada nuevo token generado necesita acceder a los estados Key y Value de los tokens anteriores. Cuanto más largo es el contexto, más grande es el KV Cache. Un KV Cache mayor presiona VRAM, ancho de banda de memoria, tiempo al primer token y throughput.

DeepSeek-V4 es interesante porque no solo reduce caché en la dimensión de cabezas de atención. Lleva la compresión a la dimensión de longitud de secuencia. Según el análisis de Hugging Face sobre DeepSeek-V4, en un escenario de 1M tokens, el KV Cache de DeepSeek-V4-Pro es alrededor del 10% del de DeepSeek-V3.2, y alrededor del 2% de una arquitectura GQA bf16 común.

Esa es la diferencia clave: DeepSeek-V4 no solo guarda cada entrada KV en un formato más pequeño. Reduce la cantidad de entradas KV que deben conservarse y buscarse en una historia larga.

Varias generaciones de optimización de KV Cache

La optimización de KV Cache ha seguido varias rutas.

La primera es MHA tradicional, Multi-Head Attention. Cada cabeza Query suele tener sus propias cabezas Key/Value. La estructura es directa, pero en contextos largos la caché crece linealmente con la longitud de secuencia, generando mucha presión de VRAM.

La segunda es GQA, Grouped Query Attention. Varias cabezas Query comparten menos cabezas Key/Value. Muchos modelos modernos como LLaMA, Mistral y Qwen usan ideas similares. Reduce mucho el número de cabezas KV y hoy es una optimización común para contexto largo.

La tercera es MLA, Multi-head Latent Attention. DeepSeek-V2 y DeepSeek-V3 usan esta ruta, comprimiendo Key/Value en representaciones latentes de bajo rango y reduciendo aún más la caché en la dimensión de cabezas.

La cuarta es la atención comprimida híbrida de DeepSeek-V4. Se centra en la longitud de secuencia: no solo reduce cuánto KV guarda cada token, sino que comprime múltiples tokens históricos en menos entradas KV y las recupera mediante atención dispersa o densa.

En términos simples:

MHA: cada cabeza recuerda por separado.
GQA: varias cabezas Query comparten memoria.
MLA: la representación KV de cada token se comprime en un vector latente.
DeepSeek-V4: muchos tokens históricos se agregan en menos bloques de memoria comprimida.

Cambio clave: de comprimir cabezas a comprimir secuencia

GQA y MLA optimizan principalmente cuánto KV guarda cada token. Funciona bien, pero cuando el contexto llega a 1M tokens, el número de tokens se vuelve el problema principal.

DeepSeek-V4 comprime el contexto antiguo en bloques. El modelo no necesita preservar KV completo para cada token lejano. En su lugar, varios tokens forman entradas comprimidas.

Es parecido a leer un libro muy largo: recuerdas con detalle las páginas recientes, mientras que los capítulos anteriores quedan como resúmenes, temas y pistas importantes. La atención de DeepSeek-V4 sigue una división similar: conservar detalle cerca y usar representación comprimida lejos.

CSA: compresión 4x más recuperación dispersa

CSA significa Compressed Sparse Attention. Es el mecanismo de compresión de largo alcance de grano más fino.

En CSA, el modelo comprime tokens vecinos en menos entradas KV. La documentación de Hugging Face Transformers da una razón de compresión por defecto m=4, es decir, aproximadamente cada cuatro tokens forman una entrada comprimida.

No es un promedio simple. CSA usa un pool de compresión aprendido y ventanas solapadas para preservar información útil. Después de comprimir, la consulta no atiende a todos los bloques comprimidos directamente. Primero usa Lightning Indexer para puntuarlos, selecciona los bloques top-k más relevantes y luego realiza la atención principal.

Esto aporta dos beneficios:

El número de entradas KV históricas disminuye.
Cada consulta mira solo un subconjunto relevante de bloques comprimidos.

CSA encaja con contextos lejanos donde todavía importan detalles: bases de código, documentos largos e historiales de llamadas a herramientas.

HCA: compresión 128x más atención densa

HCA significa Heavily Compressed Attention, y es más agresivo.

La documentación de Transformers da una razón por defecto m'=128. HCA comprime un tramo mucho más largo de contexto en una sola entrada comprimida. Como la secuencia resultante ya es muy corta, no necesita recuperación dispersa top-k como CSA. La consulta puede hacer atención densa sobre todas las entradas HCA comprimidas.

HCA se parece más a un resumen global. No intenta conservar todos los detalles. Cubre una historia muy larga a costo muy bajo, ayudando al modelo a mantener conciencia de contexto global, temas de largo alcance e información lejana.

Si CSA es “notas comprimidas consultables”, HCA es más bien un “índice global y resumen”.

Ventana deslizante: el contexto reciente conserva detalle

DeepSeek-V4 no comprime todo.

Además de CSA y HCA, mantiene una rama de ventana deslizante para el contexto reciente sin comprimir. La documentación de Transformers indica que los attention blocks de DeepSeek-V4 concatenan ramas comprimidas de largo alcance con K/V de ventana deslizante.

Esto importa. Al generar el siguiente token, el contexto más cercano suele ser el más importante: nombres de variables, firmas de funciones, la frase actual, resultados recientes de herramientas o la última instrucción del usuario. Si se comprimiera demasiado, la calidad de salida caería.

La idea de DeepSeek-V4 es:

Cerca: conservar detalles sin comprimir.
Medio y largo alcance: usar CSA para compresión consultable.
Más lejos: usar HCA para resumen global muy comprimido.

Pila híbrida de capas: distintas capas usan distinta atención

DeepSeek-V4 no usa el mismo mecanismo de atención en todas las capas.

El artículo de Hugging Face sobre DeepSeek-V4 señala que la estructura de 61 capas de V4-Pro usa HCA en las dos primeras capas, alterna CSA y HCA después, y usa una sliding-window MTP block al final. La documentación de Transformers también describe V4-Pro como dos capas HCA bootstrap seguidas por capas alternas CSA/HCA.

Esto muestra que DeepSeek-V4 trata la atención como un sistema por capas. Algunas capas favorecen compresión global, otras recuperación dispersa, y otras conservan ventanas locales.

Es más complejo que usar un solo tipo de atención en todas partes, pero se ajusta mejor a contextos extremos de 1M tokens.

FP8 y FP4 reducen aún más el costo de caché

El ahorro de DeepSeek-V4 no viene solo de la razón de compresión.

El artículo de Hugging Face indica que la mayoría de entradas KV en V4 usan almacenamiento FP8, las dimensiones relacionadas con RoPE permanecen en BF16, y el Lightning Indexer de CSA usa FP4. La combinación de compresión, baja precisión y recuperación dispersa produce un uso muy bajo de KV Cache.

Esto recuerda algo importante: no basta mirar el número de longitud de contexto. La viabilidad de despliegue depende de VRAM, presión de ancho de banda, latencia y calidad de implementación bajo contexto largo.

Diferencias con otros modelos

Frente a MHA tradicional, DeepSeek-V4 ya no mantiene memoria de atención completa para cada token en una historia larga, así que la presión de caché cae mucho.

Frente a GQA, DeepSeek-V4 no solo reduce el número de cabezas KV. También reduce el número de entradas KV para historia larga. GQA sigue acumulando caché linealmente con la longitud de secuencia; V4 comprime el contexto lejano en bloques.

Frente al MLA de DeepSeek-V3, V4 extiende la optimización desde “hacer más compacta la representación de cada token” hacia “comprimir también la cantidad de entradas históricas”. MLA ya reduce mucho el costo KV por token, pero en contexto de millones de tokens la longitud de secuencia sigue siendo un cuello de botella.

Frente a atención dispersa ordinaria, CSA primero comprime y luego recupera de forma dispersa sobre una secuencia comprimida más corta. HCA va más lejos: con compresión 128x, incluso la atención densa resulta barata.

Qué significa para agentes y tareas largas

Los workflows de agentes consumen mucho contexto. Leen archivos, llaman herramientas, reciben resultados, generan planes, corrigen planes y vuelven a llamar herramientas. Cuanto más largo es el contexto, más probable es que KV Cache sea el cuello de botella.

El diseño de caché de DeepSeek-V4 puede ayudar en varias formas:

Manejar bases de código largas, documentos extensos e historiales de herramientas de muchas rondas.
Reducir presión sobre tiempo al primer token y throughput causada por KV Cache.
Ejecutar contextos más largos o más solicitudes concurrentes con el mismo hardware.
Acercar el contexto de un millón de tokens a un despliegue práctico, no solo a un número de benchmark.

Pero la atención comprimida no es gratis. Comprimir tokens históricos en bloques implica elegir qué información se conserva. El modelo debe equilibrar ahorro de VRAM con retención de detalles recuperables. El rendimiento real depende de la tarea: navegación de código, documentos legales, QA largo y toolchains de agentes tienen necesidades distintas de recuperación de detalles.

No leas 2% como 2% de todo el costo

“KV Cache alrededor del 2% de GQA” puede malinterpretarse.

Se refiere principalmente al tamaño de memoria de KV Cache. No significa que el costo total de inferencia caiga al 2%, ni que todos los escenarios sean 50 veces más rápidos. La inferencia también incluye lectura de pesos, enrutamiento MoE, redes feed-forward, cómputo de atención, scheduling y comunicación.

El artículo de Hugging Face separa dos números: en contexto de 1M tokens, los FLOPs por token de DeepSeek-V4-Pro son 27% de DeepSeek-V3.2, mientras que KV Cache es 10%. Caché y cómputo son dimensiones distintas.

La afirmación más segura es: DeepSeek-V4 reduce mucho la presión de KV Cache en contexto ultralargo, mejorando la viabilidad de despliegue en escenarios de un millón de tokens. Latencia y throughput reales dependen de implementación, hardware, batching, cuantización y framework de inferencia.

Resumen

La mayor diferencia entre DeepSeek-V4 y otros modelos grandes es que mueve la optimización de KV Cache desde la dimensión de cabezas de atención hacia la dimensión de longitud de secuencia.

GQA guarda menos cabezas KV. MLA hace más compacta la representación KV de cada token. DeepSeek-V4 además agrega tokens lejanos en bloques comprimidos y combina CSA, HCA, ventanas deslizantes y almacenamiento de baja precisión, para que el contexto de un millón de tokens no quede bloqueado de inmediato por KV Cache.

No es un truco único. Es una arquitectura de inferencia para contexto largo: conservar detalles cerca, comprimir lo lejano, recuperar detalles cuando hacen falta y resumir globalmente cuando es posible.

Para desarrolladores y aplicaciones de agentes, el significado es directo: contexto largo no es solo aceptar más entrada. Debe poder ejecutarse, ser estable y tener costo aceptable. Eso es lo que DeepSeek-V4 cambia.

Referencias

Cómo ajustar llama.cpp con 8GB de VRAM: por qué 32K es más seguro y 64K necesita cuantización de KV Cache

Thu, 23 Apr 2026 12:13:04 +0800

Si 8GB de VRAM bastan para ejecutar LLMs locales con fluidez, especialmente con contextos largos, es una de las preguntas más comunes al usar llama.cpp.

Tres conclusiones clave:

Con 8GB de VRAM, contexto 32K suele ser el equilibrio más seguro
Si realmente quieres 64K, la cuantización de KV Cache suele ser esencial
En inferencia full-GPU, subir a ciegas el número de hilos CPU puede empeorar el rendimiento

1. Qué significan 32K, 64K y KV Cache

32K y 64K se refieren a longitud de contexto, es decir, cuántos tokens puede procesar el modelo a la vez. K significa miles: 32K son unos 32000 tokens, y 64K unos 64000 tokens. Cuanto más largo el contexto, más contenido previo puede ver el modelo.

KV Cache es una caché de resultados intermedios que el modelo mantiene para acelerar la generación autoregresiva. Una vez que el modelo leyó parte del contexto, no necesita recalcular todo desde cero cada vez. Guarda información intermedia y la reutiliza. K y V vienen de Key y Value en Transformers.

Estos términos aparecen juntos porque:

32K y 64K definen cuánto contenido quieres recordar
KV Cache determina cuánta VRAM extra hace falta para mantener esa memoria
cuanto más largo el contexto, más grande suele ser la KV Cache

Cuando la inferencia de contexto largo se ralentiza, el problema raíz suele ser que la caché creció hasta presionar el límite de VRAM.

2. Por qué 32K y 64K se comportan tan distinto

Usando unas 30000 letras chinas de The Three-Body Problem como stress test, la comparación entre 32K y 64K puede verse dramática: con tamaño de documento similar, 64K puede volverse mucho más lento.

La razón no es que el modelo empeore de repente. El problema real es tocar el límite de VRAM.

En 32K, pesos del modelo más caché quizá aún caben en 8GB, así que la mayoría del tráfico se queda en la memoria de la GPU. Al pasar a 64K, la caché crece, el uso total se acerca o supera el techo de VRAM, y parte de los datos se empuja a memoria compartida o del sistema.

En ese punto no colapsa el cómputo bruto, sino el ancho de banda.

Lo que parece “el contexto se duplicó y el rendimiento se hundió” suele ser que la ruta de datos salió de VRAM hacia memoria mucho más lenta.

3. Para 64K, la cuantización de KV Cache importa mucho

Para usuarios de 8GB de VRAM, una conclusión importante es que cuantizar KV Cache importa muchísimo.

Sin cambiar el modelo, cuantizar solo la caché reduce directamente el uso de memoria en contexto largo. Eso permite que parte de los datos que antes salían de VRAM vuelvan a caber. 64K seguirá siendo más pesado que 32K, pero es menos probable que caiga en la zona más lenta.

En simple:

32K es el rango predeterminado más práctico para 8GB
64K no es imposible
pero sin cuantización de caché, puede pasar de usable a difícil de usar

Prioridad habitual:

Revisar si la VRAM ya está cerca del techo
Decidir si activar cuantización de KV Cache
Solo después experimentar con ajustes de throughput

4. Baja utilización GPU no significa que esté inactiva

Este punto rompe la intuición.

Cuando Task Manager muestra 20% o 30% de GPU, mucha gente asume:

los parámetros están mal
el modelo no corre realmente en GPU
la GPU no se usa completa

Pero en inferencia llama.cpp, lo más probable es que el cuello de botella no sea cómputo del core, sino lecturas y escrituras de memoria.

Los cores GPU pueden terminar rápido un lote de cálculo y pasar el resto del tiempo esperando el siguiente lote de pesos o datos cacheados.

Por eso:

la utilización de cores no parece alta
pero la velocidad end-to-end no mejora

No es una GPU perezosa. Es una ruta de datos estrecha.

5. Aumentar parámetros de throughput ayuda solo si la VRAM aguanta

Si los cores GPU no están saturados, aumentar parámetros relacionados con throughput puede hacer que la GPU procese más datos a la vez y use mejor el paralelismo.

Puede mejorar velocidad, pero con una condición: debe quedar margen de VRAM.

Si ya estás en 64K, con una caché grande y VRAM casi agotada, subir esos parámetros puede terminar en:

crash
fallback a memoria compartida mucho más lenta

La secuencia más segura:

proteger primero el límite de VRAM
luego probar optimizaciones de throughput
tras cada cambio, revisar velocidad y estabilidad

6. Más hilos CPU no siempre son mejores

Es una trampa fácil.

Parece natural pensar que más hilos dan más velocidad. Pero si el modelo ya corre casi todo en GPU, forzar más hilos CPU puede empeorar claramente el rendimiento.

En inferencia full-GPU, la CPU es más scheduler y ayudante de preprocesamiento que motor principal. Demasiados hilos aumentan contención, overhead de scheduling y cambios de contexto, interrumpiendo el flujo de datos.

Resultado:

la CPU parece más ocupada
la velocidad general baja

En este setup, valores predeterminados o hilos más bajos suelen ser más fiables que maximizar todo.

7. Enfoque práctico para 8GB de VRAM

1. Trata 32K como objetivo predeterminado

Con una GPU de 8GB, no persigas 64K de inmediato. 32K suele equilibrar mejor velocidad, estabilidad y memoria.

2. Si quieres 64K, resuelve primero la caché

Confirma si KV Cache está cuantizada y si la VRAM ya está al límite.

3. No juzgues todo por utilización GPU

Baja utilización no implica ajustes incorrectos. Puede indicar que el cuello de botella es memoria.

4. Optimiza throughput sin cruzar el límite de VRAM

Estos parámetros pueden ayudar, pero solo con margen suficiente.

5. Sé conservador con hilos CPU

Si el modelo corre principalmente en GPU, más hilos CPU no son automáticamente mejores.

Conclusión

El valor de esta discusión no son solo números de benchmark, sino una verdad fácil de olvidar:

ajustar LLMs locales no consiste en poner cada valor al máximo. Consiste en entender si tu cuello de botella real es cómputo, capacidad de VRAM, ancho de banda de memoria o scheduling de CPU.

Para usuarios de 8GB, la estrategia más segura suele ser proteger primero el límite de VRAM y solo entonces decidir cuánto más empujar.

Si recuerdas una frase:

32K suele ser el rango de trabajo más estable para 8GB de VRAM; 64K es posible, pero solo si ya controlaste KV Cache y uso de VRAM.