DeepSeek-V4.1-Flash reduce el KV-caché en HBM a 890 bytes por token, frente a 3514

DeepSeek ha presentado V4.1-Flash, un modelo MoE multimodal con contexto de 1M de tokens. Su tronco principal tiene 552B parámetros y otros 196B residen en las tablas de memoria Engram. El resultado principal atañe al despliegue: el KV-caché global en HBM se comprime hasta 890 bytes por token, mientras que el anterior DeepSeek-V4-Flash necesitaba 3514 bytes. El caché persistente en SSD se redujo a aproximadamente una octava parte de su volumen anterior. Para sesiones agénticas de un millón de tokens, esto elimina el principal cuello de botella: la memoria del caché deja de determinar cuántas sesiones aguanta un servidor.

Una publicación en el canal de Telegram gonzo_ML remite a un artículo con unos 500 autores (arXiv 2609.19969), a una reseña en Substack y a los pesos en Hugging Face. El código no está en acceso abierto; la ficha indica N/A.

Tres mecanismos de ahorro de memoria

El primer mecanismo es un esquema causal codificador-decodificador, CED. El modelo se aparta del habitual decoder-only: en el prefill, cuando lee un prompt largo, están activos 8B parámetros, y al generar la respuesta, 16B. El autor de la reseña señala que parece ser el único de los grandes modelos abiertos con esta arquitectura. Los análogos más cercanos son el encoder-decoder T5Gemma y el esquema decodificador-decodificador YOCO.

El segundo mecanismo es la atención CSA2. Reutiliza el caché en formato FP4 entre capas, de modo que cada capa no necesita guardar su propia copia. Aquí se logra la mayor parte de la compresión hasta 890 bytes por token.

El tercer mecanismo es el recálculo acotado de la ventana deslizante, SWA Bounded Replay. El caché local de la ventana deslizante ya no se escribe en disco; cuando hace falta, se restaura recalculando un tramo acotado. Esto quita parte de la carga al SSD y explica por qué el volumen del caché en disco cayó unas ocho veces.

Benchmarks: paridad con Opus-5 en tareas agénticas

En DeepSWE v1.1 (un conjunto de tareas de corrección de errores en repositorios reales), V4.1-Flash resuelve el 74,2 % de las tareas. V4-Flash obtiene el 54,4 % y Opus-5, el 74,0 %. En Terminal-Bench 2.1 (tareas de agente en línea de comandos), el modelo alcanza el 90,6 % Pass@1, es decir, resuelve la tarea al primer intento. V4-Flash logra aquí el 82,7 % y Opus-5, el 89,1 %.

Es decir, la actualización no solo abarató la inferencia, sino que mejoró la calidad en programación y escenarios de terminal. La mejora en DeepSWE es de unos 20 puntos porcentuales respecto a su predecesora. Para los desarrolladores que construyen ciclos agénticos largos, es un argumento notable a favor de un modelo abierto.

Lo que no hay en el artículo

Hay también limitaciones. El trabajo no incluye ablaciones por componente, así que no está claro cuánto aportan por separado CED, CSA2 y el recálculo de la ventana al ahorro de memoria y a la calidad. Tampoco hay curvas de calidad de recuperación para el contexto de 1M de tokens. Los 890 bytes por token declarados muestran el coste de almacenamiento, pero no demuestran que el modelo encuentre de forma fiable el fragmento correcto en toda la longitud.

En tareas científicas complejas el resultado es notablemente más modesto. En Terminal-Bench 4.0, V4.1-Flash obtiene un 31,2 % y Opus-5, un 51,8 %. La paridad con el sistema cerrado se confirma en Terminal-Bench 2.1 y DeepSWE v1.1, pero no en el más duro de los benchmarks citados.

La conclusión práctica para quienes despliegan modelos por su cuenta: según el artículo, con un contexto de un millón de tokens el límite pasa a ser el cómputo, no la HBM ni el SSD para el caché. Esto cambia el cálculo del coste de las sesiones agénticas largas. Pero mientras no se publiquen el código, las ablaciones y mediciones independientes de contexto largo, las cifras siguen siendo afirmaciones de los autores. Los pesos se pueden descargar y probar con tareas propias.