DeepSeek V4 reduce su KV cache un 90% en ventanas de un millón de tokens, pero la compresión agresiva tiene un costo
La guerra de la eficiencia en IA china sigue escalando. DeepSeek acaba de publicar las notas de lanzamiento de su nuevo modelo V4, y los números que aparecen ahí son difíciles de ignorar: el modelo requiere apenas el 27% de los FLOPs de inferencia por token único y solo el 10% del KV cache en comparación con su predecesor directo, el DeepSeek V3.2. Todo esto al operar con una ventana de contexto de un millón de tokens.
Qué significa reducir el KV cache un 90%
Para entender el impacto real de esta cifra, hay que recordar cómo funciona la inferencia en modelos de lenguaje. El proceso se divide en dos fases: prefill y decode. Durante el prefill, el modelo procesa el prompt inicial; en el decode, genera la respuesta token por token. El problema es que la fase de decode necesita mantener en memoria el contexto completo de la conversación mediante el llamado KV cache, o caché de clave-valor. A medida que crece el número de tokens en contexto, ese caché crece con él, y a un millón de tokens, la presión sobre la memoria es enorme. Un modelo que logra operar con el 10% de ese requerimiento puede procesar muchas más solicitudes simultáneas o, dicho de otra forma, requiere mucha menos memoria por petición.
La otra cara de la moneda: fallos del tipo “aguja en un pajar”
La compresión agresiva del KV cache no viene gratis. Según detalla el propio análisis de la fuente, reducir drásticamente la memoria disponible para almacenar el contexto obliga al modelo a realizar compromisos: puede perder detalles específicos enterrados en contextos muy largos. A esto se le llama fallo del tipo “needle in a haystack” —aguja en un pajar— y puede traducirse en respuestas imprecisas cuando la información clave está “oculta” dentro de un texto extenso. Todo apunta a que el rendimiento de V4 dependerá mucho del tipo de tarea y la distribución del contenido dentro del contexto.
“Una reducción agresiva del KV cache no es solo un hito de software; tiene implicaciones masivas para la cadena de suministro de memoria real.”
El mecanismo detrás de la magia: MLA
La arquitectura responsable de estas ganancias es el sistema Multi-Head Latent Attention (MLA), que DeepSeek ya había introducido en modelos anteriores. En lugar de almacenar los tensores de clave y valor completos por cada token, MLA los proyecta en una representación latente de bajo rango que luego se expande al momento del cómputo. Es ese ciclo de comprimir y expandir el que permite reducir el peso en memoria sin (teóricamente) perder capacidad de razonamiento. En la práctica, según se filtró en el análisis de la fuente, el 27% de FLOPs solo se traduce en mejora de rendimiento si hay suficiente memoria disponible en la GPU para sostener los cálculos.
Por qué importa más allá de los benchmarks
Hay una cadena de efectos que va desde los centros de datos hasta el consumidor final. El mercado de HBM —la memoria de alto ancho de banda que alimentan las GPU de IA— lleva meses en un superciclo de demanda que ha generado escasez y presión de precios que se filtra hasta los módulos de memoria y SSDs para PC. Si los modelos de lenguaje logran extraer más rendimiento por gigabyte de HBM mediante técnicas de compresión como las de DeepSeek V4, la presión sobre ese mercado podría empezar a ceder. Habrá que ver si la reducción es lo suficientemente amplia como para impactar de forma tangible en el mercado de consumo, pero la dirección es la correcta.
Fuente: WCCFTech
