Contexto de un millón de tokens con una décima parte de la caché KV: la apuesta de eficiencia de DeepSeek-V4

Lo caro de un millón de tokens de contexto nunca han sido realmente los tokens. Es la memoria que ocupan. Cada token de la ventana reside en la caché KV, y esa caché crece con la secuencia; por eso, servir contextos largos ha tenido un precio tan alto. La vista previa de V4 de DeepSeek apunta directamente a esa curva de coste.

Dos modelos, un millón de tokens

DeepSeek publicó la serie V4 como una vista previa técnica, con checkpoints en Hugging Face. La oferta incluye dos modelos de mezcla de expertos (MoE). DeepSeek-V4-Pro cuenta con 1,6 billones de parámetros y 49 mil millones activos por token. DeepSeek-V4-Flash es la opción más ligera: 284 mil millones de parámetros, 13 mil millones activos. Ambos soportan una ventana de contexto de un millón de tokens.

La afirmación de eficiencia

Las cifras de eficiencia son el titular real. Con un millón de tokens de contexto, según el documento, DeepSeek-V4-Pro necesita solo el 27% de los FLOPs de inferencia de un solo token y el 10% de la caché KV en comparación con DeepSeek-V3.2. Menos FLOPs significa generación más rápida. Una décima parte de la caché KV significa que el mismo presupuesto de memoria da cabida a unas diez veces más sesiones concurrentes de contexto largo, antes de que intervenga cualquier otro cuello de botella. Esa aritmética es lo que hace creíble la afirmación del documento de «soportar de forma rutinaria contextos de un millón de tokens».

Cómo lo consigue la arquitectura

Tres cambios arquitectónicos cargan con el peso. El primero es un diseño de atención híbrida que reparte el trabajo entre Compressed Sparse Attention (CSA) y Heavily Compressed Attention (HCA). La atención dispersa mantiene al alcance los tokens lejanos que realmente se necesitan; la vía muy comprimida mantiene bajo control la huella de memoria de todo lo demás. El segundo son las Manifold-Constrained Hyper-Connections (mHC), una mejora de las conexiones residuales convencionales. El tercero es el optimizador Muon, al que el documento atribuye una convergencia más rápida y una mayor estabilidad del entrenamiento. Ambos modelos se preentrenaron con más de 32 billones de tokens y luego pasaron por un extenso pipeline de post-entrenamiento destinado a desbloquear y ampliar sus capacidades.

Pro-Max y la carrera de los pesos abiertos

DeepSeek también describe V4-Pro-Max, el modo de máximo esfuerzo de razonamiento del modelo Pro. El documento afirma que «redefine el estado del arte de los modelos abiertos» y que supera a sus predecesores en las tareas principales. La vista previa no incluye tablas de benchmarks, así que esa afirmación no tiene cifras públicas que la respalden más allá de las cifras de eficiencia. Hay que leerla como una declaración pendiente de verificación cuando aparezcan resultados independientes.

El momento llega en pleno tramo concurrido de los pesos abiertos. Nuestra cobertura de Gemma 4 de Google DeepMind, un modelo MoE de 26 mil millones de parámetros orientado a razonar sobre codebases completos y transcripciones de varias horas, muestra la misma carrera hacia el contexto largo en los modelos de pesos abiertos. Los modelos densos más pequeños de Gemma ofrecen ventanas de 256.000 tokens. DeepSeek promete un millón completo en ambas variantes de V4. La diferencia importa sobre todo en el caso de uso que señala el documento: tareas de horizonte largo que antes obligaban a los desarrolladores a recurrir a pipelines de chunking y recuperación, que añaden latencia y complejidad por encima de lo que el modelo pueda hacer.

Lo que aún queda por demostrar

La vista previa funciona también como prueba de si el mercado considera la eficiencia una característica de primer nivel. Los checkpoints están disponibles para que cualquiera los ejecute, y la división en dos modelos da a DeepSeek un nivel Pro para trabajos pesados y un nivel Flash cuyo número de parámetros activos apunta a un coste de servicio más bajo. El documento no posiciona explícitamente el modelo Flash, así que trátese eso como una lectura, no como una especificación. Para los desarrolladores que sirven cargas de trabajo de contexto largo, la pregunta práctica es más simple: si las cifras del 27% y el 10% se mantienen fuera del documento, el coste de retener un millón de tokens deja de ser el motivo para construir en torno a la recuperación en lugar del contexto.

Nada de esto resuelve si el modelo es bueno. La eficiencia es la mitad de la ecuación, y una buena calidad de contexto largo nunca fue solo un problema de memoria. La vista previa ofrece a los críticos un objetivo claro: ejecuciones independientes de la configuración de un millón de tokens, la configuración exacta para la que se construyó la arquitectura, con las cifras de coste contrastadas con V3.2. Mientras esas ejecuciones no existan, la serie plantea un argumento sólido sobre hacia dónde se dirigen los costes del contexto largo, respaldado por un modelo que la gente puede descargar de verdad.