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.