DeepSeek V4: cómo un contexto de 1 millón de tokens cambia el juego para agentes

Resumen ejecutivo

DeepSeek lanzó V4 con dos checkpoints MoE disponibles en el Hub: DeepSeek-V4-Pro (1.6T parámetros totales, 49B activos) y DeepSeek-V4-Flash (284B totales, 13B activos). Ambos soportan una ventana de contexto de 1 millón de tokens. Aunque los resultados de benchmark son competitivos pero no de vanguardia absoluta, la verdadera innovación no está en registros de precisión, sino en cómo V4 hace viable el uso de contextos extremadamente largos para agentes que encadenan llamadas a herramientas y manejan sesiones prolongadas.

Para profesionales y tomadores de decisión en América Latina, esto significa que casos como automatización de soporte, asistentes que realizan búsquedas y ejecuciones largas, pipelines de análisis o sesiones de terminal interactivas pueden ejecutarse con menos interrupciones por limitaciones de memoria o costos de cómputo por token.

El problema del KV cache para agentes

Tener una ventana de 1M tokens es solo parte de la solución; lo que importa es el costo por cada paso de inferencia a esa profundidad. En actividades agenticas donde cada resultado de herramienta se anexa al contexto (por ejemplo, una búsqueda, un comando de terminal o el resultado de una API), cada token siguiente debe atender a todo lo previo, lo que incrementa dos cosas críticamente: los FLOPs por token y el tamaño del KV cache.

DeepSeek V4 reduce esos costos de manera sustancial: V4‑Pro usa aproximadamente 27% de los FLOPs por token comparado con DeepSeek V3.2 y consume el 10% del tamaño de KV cache. V4‑Flash baja aún más esos números, a cerca del 10% de los FLOPs y 7% del KV cache. Si se mide contra una arquitectura establecida de atención agrupada con 8 cabezas en bfloat16, V4 requeriría aproximadamente 2% del tamaño de cache. Eso facilita ejecutar sesiones largas sin que el KV cache llene la GPU o sin que la latencia de cada ronda aumente hasta interrumpir el flujo de trabajo.

Atención híbrida: CSA y HCA

La eficiencia de V4 proviene de dividir la atención en dos mecanismos y alternarlos entre capas:

• Compressed Sparse Attention (CSA): comprime las entradas KV por 4x en la dimensión de secuencia usando un pooling con gating softmax y un sesgo posicional aprendido. Un “lightning indexer” (operando en FP4 con un producto punto multi-cabeza puntuado por ReLU) selecciona top-k de esos bloques comprimidos por cada query. La selección es esparsa y se aplica sobre bloques que ya son cuatro veces más cortos, lo que reduce el espacio de búsqueda.

• Heavily Compressed Attention (HCA): aquí la compresión es de 128x y se elimina la selección esparsa; cada query atiende densamente a los bloques comprimidos. Al ser la secuencia comprimida muy corta, la atención densa es computacionalmente barata.

Ambos caminos mantienen una rama de ventana deslizante para manejar la parte más reciente e incompresible del contexto. Alternar CSA y HCA a lo largo de las capas evita desperdiciar capacidad en un único patrón de atención.

En la pila de 61 capas de V4‑Pro, las capas 0–1 son HCA, las 2–60 alternan CSA y HCA, y el bloque MTP final corre solo con la ventana deslizante. Además, la mayoría de las entradas KV se almacenan en FP8, solo las dimensiones RoPE usan BF16, y el indexer corre en FP4 — decisiones de almacenamiento que, junto con las tasas de compresión, explican las grandes ganancias en tamaño de cache.

Otros componentes arquitectónicos relevantes

• Feed‑forward: usa DeepSeekMoE (experto mixto), que ayuda a mantener eficiencia y capacidad.
• Conexiones residuales: sustituidas por “manifold‑constrained hyper‑connections” (mHC), un cambio de diseño que acompaña la nueva estrategia de atención.

Estos elementos suman una arquitectura pensada no solo para alcanzar 1M tokens de capacidad, sino para que cada token adicional sea barato en tiempo y memoria.

Cambios pensados para agentes

Tener atención eficiente es necesario, pero no suficiente. DeepSeek V4 incorpora tres decisiones post‑entrenamiento e infraestructurales enfocadas en flujos agenticos:

1. Interleaved thinking across tool calls: V3.2 conservaba trazas de razonamiento entre rondas de herramienta pero las descartaba cuando llegaba un nuevo mensaje del usuario, lo que quebraba tareas multi‑turno donde el agente ya había encadenado varios llamados. V4 preserva el contenido de razonamiento a través de límites de mensaje cuando la conversación incluye tool calls, permitiendo una cadena de pensamiento coherente y acumulativa en tareas de largo horizonte. Para conversaciones sin herramientas, el comportamiento anterior se mantiene (se descarta el razonamiento en cada nuevo mensaje) para evitar inflar el contexto innecesariamente.

2. Tool‑call schema con tokens dedicados: V4 introduce el token especial |DSML| y un formato de llamada a herramientas basado en XML. El uso de XML reduce fallas de escape que son comunes cuando se usan JSON incrustado en strings, especialmente con contenido anidado y comillas. El esquema también separa parámetros de tipo string (pasados tal cual) de parámetros estructurados (pasados como JSON), lo que busca robustecer la interoperabilidad entre modelo e infraestructura de herramientas.

3. Infraestructura de pruebas: la publicación menciona DSec, un sandbox pensado para rollouts de RL (reinforcement learning) y evaluaciones de agentes, y un conjunto de benchmarks de agente. Los números de benchmark son competitivos, aunque no SOTA; lo importante es que la arquitectura y las decisiones de post‑entrenamiento apuntan a estabilidad y eficiencia en escenarios reales de agentes.

Implicaciones prácticas para América Latina

Para empresas y gobiernos en la región, las mejoras de V4 permiten construir agentes que mantienen contexto operativo durante horas o cientos de comandos: asistentes para soporte técnico continuo, automatización de procesos legales o contables con múltiples pasos, bots de compra y atención que consultan y actúan en APIs externas, y asistentes para desarrollo que mantienen el historial de una sesión de coding y ejecución.

Además, la reducción en el KV cache y en FLOPs por token facilita desplegar estos agentes en infraestructuras on‑premise o en nubes con límites de memoria, una consideración importante en organizaciones que priorizan privacidad o que enfrentan costos de nube elevados.

Limitaciones y consideraciones

• Benchmarks: los resultados son sólidos pero no los mejores del mercado; la propuesta de valor de V4 es la robustez y eficiencia de contexto largo, no solo puntajes de benchmark.
• Complejidad: la arquitectura híbrida y el uso de distintos formatos numéricos (FP4, FP8, BF16) aumentan la complejidad de implementación en infraestructuras de producción.
• Estándares de integración: el nuevo esquema de llamadas a herramientas y el token |DSML| requieren adaptar pipelines y validaciones para aprovechar las ventajas sin introducir nuevos puntos de fallo.

Conclusión

DeepSeek V4 no compite solo en métricas tradicionales: su aportación clave es hacer práctico el uso de contextos de hasta 1 millón de tokens reduciendo el costo por token y el tamaño del KV cache mediante una atención híbrida CSA/HCA, compresión agresiva y optimizaciones de almacenamiento numérico. Para organizaciones latinoamericanas que desarrollan agentes o flujos largos—desde atención automatizada hasta asesores especializados—V4 representa una alternativa interesante para manejar sesiones extensas con menos interrupciones y mejores garantías operativas.

Los modelos están disponibles en el Hub; el siguiente paso para equipos interesados es evaluar pruebas de integración en entornos controlados (por ejemplo, DSec o entornos de RL) y adaptar esquemas de tool‑calling y manejo de contexto para aprovechar las capacidades de V4 en producción.