DeepSeek-V4: contexto de 1M tokens para agentes | Keryc
DeepSeek-V4 llega con una promesa clara: permitir agentes que realmente aprovechen ventanas de contexto de hasta 1 millón de tokens sin romperse a mitad de tarea. ¿Suena a ciencia ficción? No tanto. El truco no es solo abrir una ventana gigante, sino bajar el costo por token para que cada pasada de inferencia sea viable en la práctica.
Qué hace diferente la arquitectura
La pregunta clave es simple: puede tu agente mantener una cadena larga de acciones y resultados sin quedarse sin memoria o sin tiempo de cómputo? DeepSeek-V4 ataca ese problema desde la base.
La novedad principal es dividir la atención en dos caminos que se alternan en las capas: Compressed Sparse Attention (CSA) y Heavily Compressed Attention (HCA). Cada uno tiene un objetivo distinto y juntos reducen tanto los FLOPs por token como el tamaño del KV cache.
CSA comprime la secuencia 4x usando un pooling gobernado por softmax y un sesgo posicional aprendido. Sobre esa secuencia ya comprimida corre un "lightning indexer" (ejecutado en FP4) que selecciona top-k bloques por query. Además hay una rama de ventana deslizante para los tokens más recientes.
HCA comprime muchísimo, 128x, y luego aplica atención densa sobre ese flujo comprimido. Al ser la secuencia comprimida muy corta, la atención densa resulta barata.
Alternar CSA y HCA evita desperdiciar capacidad. En la pila de 61 capas de V4-Pro, las capas 0 y 1 son HCA, las capas 2 a 60 alternan CSA y HCA, y el bloque final corre solo la ventana deslizante.
Para exprimir más memoria, la mayor parte de los KV se almacenan en FP8, con BF16 reservado para las dimensiones de RoPE. El indexer corre en FP4. Esas decisiones de cuantización, junto con las tasas de compresión, producen reducciones notables en el KV cache.
Resultado práctico: V4-Pro usa alrededor de 27% de los FLOPs por token frente a V3.2 y solo 10% del KV cache. V4-Flash baja aún más: 10% de FLOPs y 7% de KV cache. Comparado con una arquitectura establecida como grouped query attention de 8 cabezas en bfloat16, V4 puede requerir aproximadamente 2% de la memoria de cache.
Además de la atención, las capas feed-forward usan DeepSeekMoE y las conexiones residuales tradicionales se reemplazan por conexiones hiper-constrantes en la variedad (manifold-constrained hyper-connections, mHC). Es decir, no es solo atención comprimida: todo el diseño de la pila está pensado para contextos largos.
Decisiones post-entrenamiento e infraestructura para agentes
Eficiencia arquitectónica es necesario pero no suficiente para agentes. DeepSeek-V4 incorpora varias decisiones post-entrenamiento y de infraestructura pensadas para flujos de trabajo con herramientas.
Primero, la gestión de trazas de razonamiento cambia. En V3.2 se mantenían trazas entre rondas de llamadas a herramientas, pero se descartaban cuando llegaba un nuevo mensaje del usuario. Para tareas largas, eso obligaba a reconstruir estado. V4 preserva el contenido de razonamiento entre mensajes de usuario mientras haya llamadas a herramientas. Para conversaciones normales sin herramientas, el comportamiento anterior se mantiene y se vacía el razonamiento al inicio de cada turno.
Segundo, V4 introduce el token especial |DSML| y un formato de llamada a herramientas basado en XML. El motivo: el JSON-in-string que usan muchos tool-calls sufre errores de escape cuando el modelo genera comillas anidadas. El esquema XML separa claramente parámetros de texto sin procesar y parámetros estructurados, por ejemplo string="true" para strings pasar tal cual y string="false" para parámetros que se envían como JSON. Esto reduce errores con números, booleanos y estructuras anidadas.
Tercero, el comportamiento del agente fue afinado con RL en entornos reales. Para eso DeepSeek diseñó DSec, una plataforma en Rust que expone cuatro substratos de ejecución tras un SDK Python: llamadas a funciones, contenedores, microVMs (Firecracker) y VMs completas (QEMU). Algunas características clave de DSec:
Carga rápida de imágenes con almacenamiento por capas 3FS, para que los rollouts de RL no esperen arrancar contenedores.
Replay de trayectorias seguro ante preempciones, para continuar entrenamiento sin repetir llamadas a herramientas costosas.
API uniforme entre substratos, para reutilizar harnesses y cambiar entre ejecuciones ligeras y VMs completas.
Esas decisiones infra son lo que permite entrenar a los agentes en escenarios realistas a gran escala.
Rendimiento: ¿qué tan bien se comporta como agente?
Los números muestran que V4 no es un campeón absoluto en razonamiento general, pero sí se destaca en tareas agenticas y de uso de herramientas. Puntos relevantes:
Terminal Bench 2.0: V4-Pro-Max 67.9, por encima de GLM-5.1 (63.5) y K2.6 (66.7), detrás de GPT-5.4-xHigh (75.1) y Gemini-3.1-Pro (68.5).
SWE Verified: 80.6 resueltos, casi al nivel de Opus-4.6-Max (80.8) y Gemini-3.1-Pro (80.6).
MCPAtlas Public: 73.6, segundo lugar tras Opus-4.6-Max (73.8).
Toolathlon: 51.8, por encima de K2.6 (50.0), GLM-5.1 (40.7) y Gemini-3.1-Pro (48.8).
En un benchmark interno de R&D con 30 tareas de codificación (PyTorch, CUDA, Rust, C++), V4-Pro-Max alcanza 67% de pass rate; Sonnet 4.5 obtuvo 47% y Opus 4.5 70%.
Una encuesta interna a 85 desarrolladores que usaron V4-Pro reportó que 52% lo consideran listo para reemplazar su modelo principal y 39% se inclinaban hacia esa opción.
En recuperación de largo contexto, la métrica MRCR 8-needle se mantiene por encima de 0.82 hasta 256K tokens y permanece en 0.59 a 1M tokens. Eso es relevante si tu agente necesita buscar hechos antiguos en conversaciones muy largas.
Checkpoints, modos de razonamiento y recomendaciones de uso
Hay cuatro checkpoints disponibles en Hugging Face Hub. Las variantes instruct usan FP4 para los pesos MoE de los expertos y FP8 para lo demás. Los modelos base están en FP8 en todo.
Los modelos instruct soportan tres modos de razonamiento:
Non-think: respuesta rápida, sin cadena de pensamiento explícita.
Think High: razonamiento explícito en bloques <think> con esfuerzo moderado.
Think Max: máxima inversión de razonamiento, requiere al menos 384K tokens de contexto.
Parámetros recomendados: temperature=1.0, top_p=1.0 para todos los modos.
¿Qué significa esto para tu proyecto agentico?
Si estás construyendo agentes que encadenan muchas llamadas a herramientas, V4 cambia las reglas del juego porque baja el costo por token y mantiene trazas de razonamiento entre turnos con herramientas. En términos prácticos, podrás ejecutar sesiones de terminal con cientos de comandos, largos browse sessions o rutas de herramientas complejas sin que el modelo pierda el estado o se quede sin memoria.
Ahora bien, 1M de contexto es capacidad, no garantía de rendimiento. Lo que importa es cuánto cuesta procesar cada token a esa profundidad: aquí V4 reduce tanto los FLOPs como la memoria KV, y eso lo hace usable en hardware real.
La pregunta abierta es de integración: ¿adaptarán los ecosistemas de herramientas el token |DSML| y el esquema XML? ¿Se trasladarán estas ganancias intercaladas de pensamiento a marcos de agentes fuera del laboratorio? Si trabajas con pipelines de herramientas, valdría la pena prototipar la transición al formato XML de llamadas y probar la ventana larga en escenarios reales.
