¿Cómo logra DeepSeek V4.1 Flash reducir 8 veces la caché KV con CED?

DeepSeek ha colocado una idea bastante técnica en el centro de su nuevo V4.1 Flash: hacer que una inteligencia artificial pueda trabajar con cantidades enormes de contexto sin arrastrar una caché gigantesca detrás de cada palabra. Su nueva arquitectura Causal Encoder-Decoder (CED) cambia precisamente la manera en que el modelo almacena la información necesaria para seguir generando texto. Y el resultado no es menor: la caché KV persistente puede reducirse aproximadamente ocho veces frente al anterior DeepSeek-V4-Flash.

Hay, eso sí, un matiz importante. No toda la caché se reduce ocho veces. El diseño completo deja la caché KV global en unos 890 bytes por token, alrededor de una cuarta parte de la generación anterior, mientras que el almacenamiento persistente —el que puede terminar ocupando SSD en grandes despliegues— cae hasta aproximadamente un octavo. Esa diferencia parece un detalle para ingenieros; en centros de datos que procesan millones de tokens, deja de serlo enseguida.

Qué es DeepSeek-V4.1-Flash y por qué importa su arquitectura

DeepSeek presentó V4.1-Flash como el modelo más pequeño de su nueva familia arquitectónica. “Pequeño”, claro, necesita comillas mentales: hablamos de un modelo Mixture-of-Experts, o MoE, con 552.000 millones de parámetros en su backbone y capacidad para manejar contextos de hasta un millón de tokens.

La filosofía MoE permite que semejante montaña de parámetros no tenga que entrar completa en funcionamiento para procesar cada token. En lugar de encender toda la ciudad cada vez que alguien pulsa un interruptor, el sistema activa solo los barrios necesarios.

V4.1-Flash lleva esa idea bastante más lejos. Durante la fase de prefill, cuando el modelo lee y procesa el contexto proporcionado por el usuario, quedan activos aproximadamente 8.000 millones de parámetros por token. Durante la generación de la respuesta, o decode, la cifra sube a unos 16.000 millones.

Eso no significa que DeepSeek haya convertido mágicamente un modelo de 552.000 millones de parámetros en uno de 8.000 millones. El modelo completo sigue ahí. Lo que cambia es la cantidad de arquitectura activada para cada parte del proceso.

Y ahí entra CED.

Cómo funciona CED: leer primero, reutilizar después

Los grandes modelos de lenguaje convencionales suelen estar construidos como una larga sucesión de capas de decodificador. Cuando reciben un texto, cada capa genera sus propias representaciones de keys y values, las famosas K y V que terminan almacenadas en la KV cache.

Esa caché funciona como una memoria de trabajo. Cuando el modelo está escribiendo el token número 20.001 de una conversación, no necesita recalcular desde cero los 20.000 anteriores: conserva información relevante sobre ellos y la reutiliza.

El problema aparece cuando el contexto empieza a engordar. Diez mil tokens. Cien mil. Un millón. La caché también crece y necesita memoria de alta velocidad, almacenamiento, movimiento de datos entre dispositivos y, por supuesto, electricidad. El elefante no está tanto en calcular una frase como en recordar todo lo que había sobre la mesa antes de escribirla.

CED cambia esa mecánica. DeepSeek divide su Transformer de 40 capas en 20 capas de codificador causal y 20 capas de decodificador. En vez de obligar a las capas del decodificador a construir independientemente toda su información KV a partir de sus propios estados ocultos, la caché global del decodificador se proyecta desde los estados ocultos finales del codificador.

Dicho de manera menos académica: la primera mitad del modelo organiza el contexto y deja preparada una representación común; la segunda puede consultar esa información sin tener que fabricar una copia completa de la memoria desde cero en cada piso del edificio.

Esta división permite que la fase inicial de lectura resulte especialmente barata. Para procesar un prompt largo, el modelo puede concentrar buena parte del trabajo en el codificador causal y generar desde allí las representaciones que necesitará después el decodificador. De ahí salen los 8B de parámetros activos por token durante el prefill.

Cuando comienza a generar texto, la situación cambia. El decodificador entra plenamente en juego y la activación asciende a 16B por token. Sigue siendo una porción pequeña respecto al tamaño total del modelo, pero suficiente para mantener una red mucho más profunda durante la producción de la respuesta.

Esta asimetría tiene bastante sentido para los agentes de IA, una de las cargas de trabajo que DeepSeek tiene claramente en el punto de mira. Un agente puede tragarse documentos, código fuente, historiales de ejecución, instrucciones y resultados de herramientas antes de devolver apenas unas líneas. Mucha lectura; relativamente poca escritura.

En ese escenario, reducir el coste de procesar la entrada es oro.

La caché KV no cae ocho veces por una sola técnica

Sería cómodo atribuir toda la mejora a CED, pero sería incorrecto. DeepSeek combina varias técnicas de compresión y reutilización para reducir la memoria necesaria.

Una de ellas es Compressed Sparse Attention 2 (CSA2). En lugar de que todas las capas examinen todo el contexto con la misma intensidad, el sistema distribuye diferentes funciones entre las capas. Algunas realizan una atención completa; otras vuelven a indexar la información relevante y otras reutilizan resultados calculados previamente.

La idea recuerda a buscar un libro en una biblioteca inmensa. No hace falta que cada bibliotecario recorra los cien kilómetros de estanterías: uno delimita la sección, otro acota la balda y los siguientes trabajan ya sobre ese pequeño conjunto de candidatos.

DeepSeek emplea además un indexador jerárquico disperso. Las capas posteriores no necesitan volver a explorar todo el contexto, sino que trabajan sobre candidatos seleccionados previamente. El coste de esas búsquedas deja así de crecer de manera tan agresiva cuando se amplía la longitud del contexto.

FP4 y los 890 bytes por token

A esa reorganización se suma otro recurso: almacenar la KV principal con precisión FP4.

Reducir la precisión significa, simplificando bastante, representar determinados números utilizando menos bits. Se pierde parte del detalle matemático, pero se consigue que la misma información ocupe mucho menos espacio. La ingeniería consiste en encontrar el punto donde la memoria ahorrada compense sobradamente la pérdida de precisión sin degradar de manera significativa el funcionamiento del modelo.

Combinando estas técnicas, DeepSeek sitúa la caché KV global en 890 bytes por token. Es aproximadamente una cuarta parte de la utilizada por DeepSeek-V4-Flash.

Con un contexto cercano al millón de tokens, cada byte empieza a contar. Y mucho.

De dónde sale entonces la reducción de ocho veces

La cifra más llamativa aparece con SWA Bounded Replay, una técnica diseñada para evitar que determinados estados de la atención de ventana deslizante tengan que conservarse permanentemente en almacenamiento.

SWA significa Sliding Window Attention. Este tipo de atención trabaja principalmente con una ventana reciente de tokens en lugar de consultar siempre todo el historial. El inconveniente es que un sistema puede terminar manteniendo datos intermedios para reutilizarlos después.

DeepSeek adopta otra solución: cuando necesita estados de esa ventana que ya no conserva, reproduce únicamente los tokens recientes necesarios para reconstruirlos.

Es una especie de memoria selectiva. En vez de guardar todos los fotogramas de una película por si algún día interesa revisar veinte segundos, se conserva lo imprescindible para reconstruir ese fragmento cuando haga falta.

Así puede prescindirse de almacenar permanentemente buena parte de esa KV en SSD. La caché KV persistente queda aproximadamente en un octavo de la necesaria en DeepSeek-V4-Flash.

Por eso ambas cifras pueden ser correctas al mismo tiempo: cuatro veces menos caché global y ocho veces menos almacenamiento persistente. Mezclarlas sería fácil. También engañoso.

Durante años, la conversación alrededor de los grandes modelos de IA estuvo dominada por el número de parámetros. Más parecía equivaler a mejor. La realidad es bastante menos vistosa y bastante más industrial: importa cuánto cuesta ejecutar esos parámetros, cuántos usuarios pueden compartir una infraestructura y qué ocurre cuando cada solicitud incluye cientos de miles de tokens.

La KV cache se ha convertido en uno de los grandes cuellos de botella de la inferencia con contextos largos. No basta con disponer de GPUs rápidas. Hace falta memoria HBM suficiente, ancho de banda para mover los datos y, en ciertos sistemas, almacenamiento capaz de conservar cachés entre peticiones.

DeepSeek sitúa las necesidades de HBM para la KV cache de V4.1-Flash en aproximadamente una cuarta parte de las de V4-Flash, mientras que el almacenamiento SSD persistente queda en torno a una octava parte.

Ese ahorro tiene una consecuencia bastante terrenal: permite atender más trabajo con la misma infraestructura. Para una API de consumo masivo o un sistema de agentes que consulta repositorios enteros de código, bases documentales o historiales interminables, la diferencia puede traducirse en mayor rendimiento y menor coste por petición.

No es una característica que luzca demasiado en una captura de pantalla. En una factura de servidores, probablemente sí.

Un modelo multimodal pensado para contextos enormes

V4.1-Flash tampoco se limita al texto. DeepSeek lo ha desarrollado como un modelo multimodal nativo, capaz de procesar texto e imágenes dentro de la misma arquitectura.

Su ventana de contexto alcanza un millón de tokens, una escala especialmente interesante para sistemas que necesitan mantener grandes cantidades de documentación disponibles durante una tarea prolongada. No significa que meter un millón de tokens indiscriminadamente sea siempre buena idea; contexto y conocimiento no son sinónimos. Pero técnicamente amplía mucho el terreno de juego.

El modelo incorpora también una memoria condicional denominada Engram, con 196.000 millones de parámetros adicionales consultados de forma dispersa mediante búsquedas basadas en tokens. A ello se une DSpark, un sistema de decodificación especulativa destinado a acelerar la generación proponiendo varios tokens candidatos antes de verificarlos.

Son piezas distintas de una misma obsesión: que el modelo no desperdicie cálculo ni memoria donde no hace falta.

DeepSeek ha puesto V4.1-Flash a disposición de su API bajo el identificador deepseek-flash y ha publicado los pesos del modelo, lo que permite que el diseño pueda ser examinado e integrado por la comunidad técnica. La arquitectura cuenta además con soporte en herramientas de inferencia como vLLM.

El verdadero avance está en gastar menos para recordar más

DeepSeek-V4.1-Flash refleja un cambio interesante en la carrera de la inteligencia artificial. El progreso ya no consiste únicamente en fabricar modelos más grandes. También pasa por conseguir que la memoria, el cálculo y el almacenamiento trabajen con bastante menos desperdicio.

CED convierte el procesamiento de entrada y la generación en dos problemas arquitectónicos parcialmente distintos: 8B de parámetros activos para leer y 16B para escribir. CSA2 limita cuánto contexto necesita inspeccionar cada capa. FP4 comprime la representación de la caché. SWA Bounded Replay evita guardar información que puede reconstruirse con poco trabajo.

El resultado es más sobrio que el habitual récord de parámetros, pero quizá más relevante para la siguiente etapa de la IA: una caché KV global cercana a 890 bytes por token, aproximadamente cuatro veces menor que la de V4-Flash, y una caché persistente reducida hasta alrededor de una octava parte.

En sistemas que viven de leer millones de tokens una y otra vez, recordar mejor puede terminar siendo más valioso que pensar con más músculo.