La frase suena potente: DeepSeek V4 usaría un 98% menos de memoria. Pero, leída con cuidado, la evidencia pública apunta a algo más concreto y bastante distinto: compresión de la caché KV en inferencia de contexto largo, no una reducción garantizada del 98% en toda la VRAM necesaria para desplegar el modelo.
Para un equipo que está calculando costes de GPU, concurrencia o capacidad de servicio, la diferencia no es menor. La caché KV puede ser uno de los grandes cuellos de botella cuando un modelo trabaja con ventanas de contexto enormes, pero no es toda la memoria de la tarjeta gráfica.
La conclusión más prudente
La forma más segura de describir DeepSeek V4 hoy sería esta:
DeepSeek V4 introduce cambios como Hybrid Attention, Compressed Sparse Attention (CSA) y Heavily Compressed Attention (HCA) para reducir de forma importante la presión de la caché KV y el coste de atención en contextos largos. Pero las fuentes públicas disponibles no bastan para afirmar que la VRAM total baje un 98% [
13][
14].
Ese matiz importa porque muchas lecturas rápidas mezclan tres cosas diferentes: memoria de caché KV, memoria total de inferencia y memoria total de despliegue. No son lo mismo.
Qué confirma realmente la documentación
La página oficial de noticias de la API de DeepSeek lista el lanzamiento de DeepSeek-V4 Preview el 24 de abril de 2026 [5]. La model card de DeepSeek V4 indica que la familia incluye DeepSeek-V4-Pro y DeepSeek-V4-Flash, y describe V4 como una serie de modelos de lenguaje Mixture-of-Experts (MoE) que conserva el marco DeepSeekMoE y la estrategia Multi-Token Prediction (MTP), además de introducir cambios como Hybrid Attention Architecture [
14].
La parte relevante para la memoria aparece en el tratamiento de la atención en contextos largos. Un artículo técnico de NVIDIA explica que Compressed Sparse Attention (CSA) usa compresión dinámica de secuencias para comprimir entradas KV y reducir la huella de memoria de la caché KV; después aplica DeepSeek Sparse Attention (DSA) para hacer más dispersas las matrices de atención y reducir coste computacional. Heavily Compressed Attention (HCA) va más allá al consolidar entradas KV de varios grupos de tokens en una sola entrada comprimida, lo que reduce aún más el tamaño de la caché KV [13].
Dicho de otra manera: hay respaldo para afirmar que V4 optimiza la caché KV y el coste de atención en contextos largos. No hay el mismo respaldo para convertir eso en una promesa general de que toda la VRAM del sistema se reduce en la misma proporción.
98%, 90% y 9,5x: tres números que no conviene mezclar
El número 98% aparece de forma directa en una publicación de LinkedIn generada por un usuario, cuyo título afirma que DeepSeek Sparse Attention reduce la memoria KV un 98% en escenarios reales de servicio [21]. Ese tipo de contenido puede servir como pista para investigar, pero no debería tratarse como especificación oficial de DeepSeek.
El dato de terceros más fácil de contrastar es otro: 10% de caché KV. Wccftech informó de que, frente a DeepSeek V3.2, DeepSeek V4 requeriría solo el 27% de los FLOPs de inferencia de un solo token y el 10% de la caché key-value (KV) [20]. Si se lee literalmente, ese 10% equivale a una reducción aproximada del 90% en caché KV. Pero la comparación es con DeepSeek V3.2 y no implica que todos los tamaños de contexto, lotes, motores de serving, configuraciones de hardware o despliegues completos reduzcan su VRAM total en un 90% [
20].
También hay titulares que hablan de 9,5x menos requisitos de memoria [3]. Incluso con la conversión más directa, 1/9,5 supone que queda alrededor del 10,5% de la necesidad original, es decir, una reducción cercana al 89,5%. Sigue sin ser 98%, y además habría que comprobar si el titular se refiere a caché KV, a un caso específico de contexto largo o a una configuración de despliegue completa [
3].
| Afirmación | Estado de la evidencia | Lectura más precisa |
|---|---|---|
| La VRAM total baja un 98% | No aparece respaldada como especificación oficial en las fuentes revisadas | No debería usarse como dato de compras o marketing [ |
| La caché KV se comprime de forma importante | Sí hay soporte técnico | CSA y HCA comprimen entradas KV en contextos largos [ |
| V4 usa el 10% de la caché KV de V3.2 | Es una cifra citada por terceros | Equivale a cerca de un 90% menos de caché KV, no de VRAM total [ |
| 9,5x menos memoria | Aparece en titulares de terceros | Aproximadamente un 89,5% menos, pero falta precisar el alcance [ |
Por qué la caché KV no es toda la VRAM
En un modelo de lenguaje, la caché KV almacena información de tokens anteriores para no recalcular ciertas partes de la atención en cada paso. Cuanto más largo es el contexto, más relevante se vuelve. Hugging Face explica que, en cargas de trabajo agentic de larga duración, los resultados de herramientas se van añadiendo al contexto y cada token posterior debe operar con un historial cada vez mayor; ahí importan especialmente dos métricas: los FLOPs de inferencia de un solo token y el tamaño de la caché KV, ambas crecientes con la longitud de secuencia [17].
La versión en GitHub del texto de Hugging Face describe fallos típicos de estas tareas largas: la traza supera el presupuesto de contexto, la caché KV llena la GPU o las rondas de llamadas a herramientas degradan el rendimiento a mitad de una tarea extensa [22].
Pero un despliegue completo no vive solo de la caché KV. La VRAM también se consume en pesos compartidos, pesos de expertos en modelos MoE, activaciones, sobrecarga del framework y otros elementos del stack. De hecho, incluso la publicación de LinkedIn que populariza el 98% separa shared weights, expert weights, activations, KV cache y framework overhead [21]. Esa separación es precisamente la razón por la que no se puede convertir una mejora en caché KV en una reducción automática e idéntica de toda la memoria de GPU.
CSA y HCA son ingeniería de eficiencia, no una cifra mágica
Lo interesante de DeepSeek V4 no es un eslogan, sino el tipo de problema que intenta resolver: hacer más viable la inferencia con contextos muy largos, incluso de escala millonaria. NVIDIA describe CSA y HCA como mecanismos para comprimir entradas KV, hacer más dispersas las matrices de atención y consolidar varios conjuntos de tokens en entradas comprimidas, reduciendo tanto el tamaño de la caché KV como el coste computacional asociado [13].
El informe técnico de DeepSeek V4 también menciona optimizaciones de infraestructura para entrenamiento e inferencia, como un kernel fusionado único para módulos MoE diseñado para solapar cómputo, comunicación y acceso a memoria [2]. Son mejoras relevantes de ingeniería. Pero no son, por sí mismas, una prueba de que el despliegue completo necesite un 98% menos de VRAM.
Cómo evaluar DeepSeek V4 en la práctica
Si estás valorando DeepSeek V4 para documentos largos, conversaciones extensas o agentes que encadenan herramientas, la pregunta útil no es si el titular del 98% es llamativo. La pregunta es si tu cuello de botella real está en la caché KV.
Las fuentes disponibles sí respaldan que V4 introduce optimizaciones importantes para la caché KV y la atención en contextos largos [13][
20][
22]. Lo que no respaldan con la misma claridad es usar «98% menos memoria» como dato para presupuestos de GPU, planificación de capacidad o promesas comerciales [
21].
La recomendación práctica es medir con tu propio caso: longitud de contexto, batch size, concurrencia, motor de serving y hardware concreto. Si tu carga está limitada sobre todo por caché KV, las técnicas de compresión de V4 pueden ser muy valiosas. Si el límite está en pesos del modelo, activaciones, sobrecarga del framework o estrategia de concurrencia, una reducción de la caché KV no se traducirá automáticamente en el mismo ahorro de VRAM total [13][
21][
22].
