DeepSeek ha llevado a 890 bytes por token el KV cache global de su nuevo DeepSeek-V4.1-Flash, frente a los 3.514 bytes de V4-Flash y los 389.120 bytes de su arquitectura V1 de 2023. La reducción, de unas 437 veces en menos de tres años según las cifras del propio fabricante, apunta directamente a uno de los problemas que aparecen al servir modelos de inteligencia artificial con contextos enormes: la cantidad de memoria necesaria para mantener activas muchas conversaciones simultáneamente.
Las claves del KV cache de DeepSeek-V4.1-Flash en 30 segundos
- DeepSeek-V4.1-Flash reduce su KV cache global hasta 890 bytes por token, unas 3,9 veces menos que V4-Flash.
- Frente a DeepSeek-V1, la reducción acumulada ronda las 437 veces.
- DeepSeek afirma que necesita una cuarta parte de HBM y una octava parte del almacenamiento SSD que V4-Flash para el cache.
- El ahorro importa especialmente en agentes con contextos largos y muchas peticiones concurrentes.
- La arquitectura combina reutilización del KV cache entre capas, atención dispersa y almacenamiento FP4.
El dato puede parecer pequeño comparado con los cientos de miles de millones de parámetros de los modelos actuales, pero se multiplica por la longitud del contexto y por el número de usuarios concurrentes. Con un millón de tokens, 890 bytes por token equivalen aproximadamente a 890 MB de KV cache global por secuencia, antes de considerar otros consumos de memoria del sistema.
Hay además una corrección importante respecto a una explicación habitual del problema: el tamaño del KV cache de un Transformer convencional no crece cuadráticamente con el número de tokens, sino aproximadamente de forma lineal con la longitud del contexto. Lo que históricamente presenta un coste cuadrático en la atención completa es el cálculo de las relaciones entre tokens durante el prefill. Son dos problemas relacionados, pero diferentes.
Qué es el KV cache y por qué puede devorar la memoria de una GPU
Cuando un modelo Transformer procesa una conversación calcula para las capas de atención unas representaciones conocidas como Key y Value (KV).
Sin cache, al generar el siguiente token tendría que volver a calcular repetidamente esas representaciones para todos los tokens anteriores. El KV cache conserva esos resultados para reutilizarlos durante la generación.
Es una optimización imprescindible para servir modelos de lenguaje con eficiencia, pero desplaza parte del problema hacia la memoria.
Un contexto largo permanece asociado a una cantidad considerable de información almacenada. Si el proveedor atiende simultáneamente cientos o miles de secuencias, el consumo se multiplica.
Por eso el problema no consiste únicamente en hacer que un modelo «quepa» en una GPU. En inferencia comercial también importa cuántas peticiones pueden mantenerse activas utilizando la misma infraestructura.
La evolución publicada por DeepSeek muestra hasta qué punto la compañía ha reducido este componente:
| Modelo | Fecha | KV cache global por token | Reducción frente al anterior |
|---|---|---|---|
| DeepSeek-V1 | 11/2023 | 389.120 bytes | — |
| DeepSeek-V3.2 | 12/2025 | 48.068 bytes | 8,1 veces |
| DeepSeek-V4-Flash | 04/2026 | 3.514 bytes | 13,7 veces |
| DeepSeek-V4.1-Flash | 09/2026 | 890 bytes | 3,9 veces |
El salto completo es considerable. Un millón de tokens utilizando los 389.120 bytes por token indicados para V1 supondría teóricamente unos 389 GB de KV global. Con V4.1-Flash, la misma multiplicación da aproximadamente 890 MB.
No significa que V4.1-Flash necesite solamente 890 MB para ejecutar un contexto de un millón de tokens. El modelo, estados internos, buffers, activaciones y otros componentes también consumen memoria. La comparación se refiere específicamente al KV cache global que DeepSeek mide en su arquitectura.
DeepSeek ha cambiado la arquitectura para reducir el cache
V4.1-Flash no consigue esa reducción únicamente almacenando los mismos datos con menos bits.
El modelo utiliza una nueva arquitectura Causal Encoder-Decoder (CED) dentro de un Mixture of Experts (MoE) de 552.000 millones de parámetros. Según DeepSeek, durante el procesamiento de la entrada activa alrededor de 8.000 millones de parámetros por token y durante la generación alrededor de 16.000 millones.
Uno de los cambios más relacionados con la memoria aparece en Compressed Sparse Attention 2 (CSA2).
En lugar de mantener de forma independiente toda la información KV que requeriría una arquitectura tradicional, DeepSeek comparte y reutiliza parte del cache entre capas. El sistema emplea distintos modos de atención denominados Full, Reindex y Reuse para evitar almacenar información redundante.
A ello se añade KV caching en FP4.
El formato de cuatro bits reduce la cantidad de memoria necesaria para representar determinados valores del cache. DeepSeek combina esta cuantización con la reutilización entre capas para alcanzar los 890 bytes por token anunciados.
La compañía asegura que el resultado frente a V4-Flash es:
| Recurso para KV cache | V4.1-Flash frente a V4-Flash |
|---|---|
| HBM | aproximadamente 1/4 |
| Almacenamiento SSD | aproximadamente 1/8 |
| KV global por token | 890 frente a 3.514 bytes |
La diferencia entre HBM y SSD tiene sentido porque no todo el cache tiene necesariamente que permanecer en la memoria de alta velocidad de las GPU.
DeepSeek utiliza además una técnica denominada SWA Bounded Replay que permite reconstruir determinados estados de Sliding Window Attention reproduciendo únicamente los tokens recientes necesarios. De esta forma evita mantener permanentemente esos estados en almacenamiento secundario.
Según el informe técnico, esa combinación reduce el KV cache persistente aproximadamente a una octava parte del utilizado por V4-Flash.
Los agentes de IA hacen que reutilizar el cache sea mucho más importante
Este tipo de optimización gana importancia con los agentes de IA.
Una conversación convencional puede consistir en unas pocas preguntas relativamente independientes. Un agente de programación, investigación o administración de sistemas funciona de otra manera.
Puede mantener durante decenas de minutos un historial que incluye código fuente, documentación, instrucciones, resultados de herramientas, errores, búsquedas y respuestas anteriores.
En cada nuevo paso buena parte del contexto ya había sido procesada.
Por ejemplo, un agente podría mantener cientos de miles de tokens y recibir como nueva información únicamente unas líneas con el resultado de ejecutar una prueba. Volver a procesar todo desde cero sería un desperdicio considerable.
El prefix caching permite conservar y reutilizar el trabajo asociado a la parte del contexto que permanece idéntica.
Los precios de Kimi K3 ofrecen un ejemplo comercial de cuánto puede valer esa diferencia. En Together AI, el modelo de Moonshot AI tiene actualmente estas tarifas:
| Kimi K3 en Together AI | Precio por millón de tokens |
|---|---|
| Entrada sin cache | 3,00 dólares |
| Entrada desde cache | 0,30 dólares |
| Salida | 15,00 dólares |
El token de entrada recuperado desde cache cuesta, por tanto, diez veces menos que uno que tiene que procesarse nuevamente.
Eso no significa que todos los proveedores necesiten necesariamente superar un 90 % de cache hit para que un servicio sea viable. La rentabilidad depende del modelo, precio, hardware, utilización, longitud del contexto y carga de trabajo.
Pero deja clara la economía que existe detrás de esta optimización.
Si un servicio con esas tarifas consiguiera un 96 % de aciertos de cache, el coste efectivo de la entrada se aproximaría a 0,41 dólares por millón de tokens, frente a los 3 dólares que costaría procesarlos todos como nuevos.
Un contexto de un millón de tokens cambia las necesidades de infraestructura
Kimi K3 sirve también para ilustrar el problema desde el lado de la memoria.
El modelo admite aproximadamente un millón de tokens de contexto y utiliza una arquitectura híbrida en la que 69 de sus 93 capas emplean Kimi Delta Attention (KDA), mientras 24 utilizan Multi-head Latent Attention (MLA).
Estimaciones realizadas a partir de su configuración sitúan el KV de las capas MLA alrededor de 13,5 KiB por token utilizando FP8. Un contexto cercano al millón de tokens puede rondar así los 14 GB solamente para esa parte del cache.
El número crece rápidamente con la concurrencia.
Mil secuencias de ese tamaño teórico llevarían la cifra al orden de 14 TB, sin contar los pesos del modelo, estados adicionales ni memoria necesaria para ejecutar la inferencia.
En la práctica, no todos los usuarios mantienen permanentemente un millón de tokens activos y los sistemas de inferencia aplican paginación, diferentes niveles de memoria, reutilización del cache y otras técnicas. Por eso multiplicar simplemente el contexto máximo por el número de usuarios representa un escenario extremo, no necesariamente la utilización real de un servicio.
Pero permite entender por qué los proveedores están dedicando tantos recursos a reducir el tamaño del KV.
La alternativa consiste en descargar parte del cache desde la memoria HBM hacia DRAM, NVMe u otros niveles de almacenamiento. Es más barato en capacidad, pero introduce transferencias y puede reducir el rendimiento si los datos tienen que moverse continuamente.
Por eso la capacidad y el ancho de banda de memoria se han convertido en variables tan importantes como la potencia de cálculo en los sistemas diseñados para inferencia de IA.
DeepSeek ha reducido 437 veces el KV por token desde 2023
La evolución de DeepSeek muestra también que la competencia entre modelos está empezando a trasladarse desde los parámetros y los resultados de benchmarks hacia la eficiencia de ejecución.
V4.1-Flash tiene 552.000 millones de parámetros totales, pero su arquitectura activa una fracción relativamente pequeña para cada token. Al mismo tiempo, DeepSeek ha trabajado específicamente sobre atención dispersa, reutilización entre capas, cuantización del KV y reconstrucción de estados.
El resultado anunciado es 890 bytes de KV cache global por token.
Frente a los 3.514 bytes de V4-Flash supone reducirlo aproximadamente un 74,7 %. Frente a los 48.068 bytes de V3.2, la reducción supera el 98 %. Y comparado con los 389.120 bytes de V1, el KV global por token es unas 437 veces menor.
La consecuencia puede ser más importante que simplemente ahorrar memoria.
Menos KV por usuario permite mantener más secuencias concurrentes dentro de la misma capacidad HBM, reducir transferencias hacia almacenamiento secundario y potencialmente aumentar el aprovechamiento de aceleradores que siguen siendo costosos.
DeepSeek vincula precisamente esta reducción con su capacidad para ofrecer V4.1-Flash a precios inferiores. La compañía ha lanzado el modelo el 10/09/2026 y afirma que necesita una cuarta parte de la HBM y una octava parte del SSD dedicado al cache respecto a V4-Flash.
Con agentes que pueden mantener contextos de cientos de miles o incluso un millón de tokens, el tamaño del KV cache empieza a convertirse en una especificación del modelo tan relevante para los operadores como el número de parámetros activos o los FLOPS necesarios para inferencia.
Y los 890 bytes por token de DeepSeek-V4.1-Flash muestran hasta qué punto todavía existe margen para rediseñar esa parte de la arquitectura.
