DeepSeek reduce la caché de memoria del modelo a 890 bytes por token, frente a 3514

DeepSeek ha publicado en Hugging Face el modelo DeepSeek-V4.1-Flash, junto con un artículo en el que lo que más espacio ocupa no es la calidad de las respuestas, sino el coste de almacenar la memoria. Cuando un modelo de lenguaje lee un texto largo, guarda para cada token datos intermedios del mecanismo de atención.

Eso es la KV-cache. Sirve para no recalcularlo todo cada vez que se genera la siguiente palabra, y cuanto más largo es el contexto, más pesa. En V4.

1-Flash, la caché global en HBM (la memoria más rápida de la tarjeta gráfica) ocupa 890 bytes por token. En la anterior V4-Flash eran 3514. Para una sesión de un millón de tokens, eso equivale a unos 0,9 GB en lugar de 3,5 GB.

El modelo es multimodal y sigue una arquitectura MoE (mixture of experts): para cada token solo trabaja una parte de los expertos. Su núcleo principal tiene 552 000 millones de parámetros. Otros 196 000 millones residen en las tablas de memoria Engram. El contexto está pensado para 1M de tokens. El artículo cuenta con unos 500 autores. El código de entrenamiento no está disponible, pero los pesos sí se han publicado.

Tres técnicas que abaratan el servicio

La principal novedad arquitectónica es el esquema causal codificador-decodificador, abreviado CED. Casi todos los grandes modelos abiertos de primer nivel son decoder-only: una misma pila de capas lee la consulta y escribe la respuesta. Aquí la pila está dividida. En el prefill, cuando el modelo lee el prompt, hay 8000 millones de parámetros activos. En la decodificación, es decir, al generar la respuesta, son 16 000 millones. Es un pariente de la idea de YOCO, en la que la caché se calcula una vez y luego se reutiliza.

La segunda técnica es el mecanismo de atención CSA2. Toma la caché en formato FP4, es decir, almacena los números en solo cuatro bits, y la reutiliza entre capas. Antes, cada capa mantenía su propia copia.

La tercera es SWA Bounded Replay. La ventana deslizante de atención solo mira los últimos tokens, y su caché local había que escribirla antes en disco para poder retomar la sesión más tarde. Ahora ya no se escribe: al reanudar, se recalcula de nuevo un fragmento acotado. Se gasta cómputo, pero se descarga el disco.

Resumen del ahorro de memoria:

• caché en HBM: 890 bytes por token en lugar de 3514, es decir, casi 4 veces menos;
• caché persistente en SSD: aproximadamente 1/8 del volumen de V4-Flash;
• parámetros activos: 8000 millones en el prefill y 16 000 millones en la decodificación.

Qué han mostrado los benchmarks

Ahorrar no basta si el modelo se vuelve peor. Por eso los autores lo compararon con su predecesora y con el modelo cerrado Opus-5 en tareas de agente, en las que el modelo trabaja por sí mismo con código y terminal.

• DeepSWE v1.1 es un conjunto de tareas de ingeniería de software: el agente modifica el código para resolver un problema concreto. V4.1-Flash resuelve el 74,2%. V4-Flash obtuvo el 54,4% y Opus-5, el 74,0%.
• Terminal-Bench 2.1 reúne tareas en línea de comandos. El Pass@1, es decir, la proporción de tareas resueltas al primer intento, es del 90,6% en V4.1-Flash. En V4-Flash es del 82,7% y en Opus-5, del 89,1%.

El avance de casi 20 puntos porcentuales en DeepSWE es notable. En ambas pruebas, el modelo abierto superó al cerrado, aunque en DeepSWE la diferencia de 0,2 puntos entra dentro del ruido habitual.

Dónde siguen las dudas

El sentido práctico del trabajo es que las sesiones de agente de un millón de tokens ahora dependen del cómputo, y no del volumen de HBM o de SSD destinado a la caché. Una sesión larga de un agente que acumula durante semanas el historial de ediciones y los logs del terminal sale más barata. En una sola tarjeta se pueden mantener más sesiones de este tipo a la vez. Para las empresas que alojan sus propios modelos, supone un ahorro directo en hardware.

Con todo, hay reservas. Los autores no han presentado ablaciones por componente, es decir, no desactivaron las técnicas una a una, y no está claro cuál de las tres aporta el grueso del ahorro. Tampoco hay curvas de calidad de recuperación de información en el contexto con el millón completo de tokens. La «ventana de 1M» declarada está menos respaldada de lo que sería deseable. En las tareas científicas complejas de Terminal-Bench 4.0, el modelo queda claramente por detrás: 31,2% frente al 51,8% de Opus-5.

También resulta llamativo que V4.1-Flash parece ser la única entre los grandes modelos abiertos que se ha alejado del decoder-only puro. Antes, un enfoque así solo se veía en T5Gemma, con su arquitectura codificador-decodificador. Si mediciones independientes confirman la ventaja, otros laboratorios podrían adoptar la separación de la pila entre lectura y generación.