DeepSeek ha publicado V4.1 Flash: 552.000 millones de parámetros, un millón de tokens de contexto y pesos abiertos bajo licencia MIT. Ya está disponible en Helmcode desde ayer, en todos los planes, en infraestructura de la UE, sin retención de logs y sin ningún cambio en lo que pagas.
Sustituye a V4 Flash y conserva el mismo identificador de modelo.
Pero la cifra que mejor explica este lanzamiento no tiene que ver con su tamaño ni con sus parámetros activos. La más llamativa son sus 890 bytes de caché.
890 bytes dan para mucho
Es lo que ocupa la caché KV global de V4.1 Flash por cada token de contexto.
La caché KV es la memoria de trabajo que el modelo conserva sobre lo que ya ha leído para no tener que recalcularlo mientras genera. Puedes pensar en ella como sus "apuntes" sobre el prompt.
En V4 Flash eran unos 3,5 KB por token. En la primera generación de DeepSeek, cerca de 389 KB.
Son unas 437 veces menos que en V1 y aproximadamente una cuarta parte que en V4 Flash.
Lo interesante es que no han llegado ahí haciendo simplemente una cuantización más agresiva. DeepSeek ha cambiado la arquitectura.
Por qué importa eso ahora
Hace un par de años, reducir la KV cache habría parecido sobre todo un problema de infraestructura.
Con agentes empieza a ser también un problema de producto.
Un agente no hace una llamada y termina. Lee archivos, ejecuta código, llama herramientas, recibe resultados, falla, lee el error y continúa. Cuando llega al paso 80 puede estar generando unos cientos de tokens mientras recibe cientos de miles como input.
Y buena parte de ese input ya había aparecido en pasos anteriores.
Eso cambia la carga. El modelo pasa mucho tiempo leyendo y manteniendo contexto, no solo generando tokens nuevos.
Ahí importan dos cosas: cuánto cuesta procesar ese contexto y cuánto cuesta conservarlo para poder reutilizarlo.
V4.1 Flash toca las dos.
Seguro que has escuchado que ya tenemos modelos suficientemente inteligentes, que ahora hacen falta modelos más ligeros y más baratos. Bien, pues V4.1 Flash es justamente el deseo que habíamos pedido.
Qué ha cambiado DeepSeek
Hay cuatro decisiones que explican buena parte de la reducción.
Lee el contexto con medio modelo. V4.1 divide sus 40 capas en un causal encoder de 20 y un decoder de 20. El prefill activa 8B de parámetros por token; el decode, 16B. Para una carga que puede leer mucho más de lo que escribe, esa asimetría tiene bastante sentido.
Comparte la KV entre capas. Con CSA2, solo cuatro de las 40 capas construyen desde cero su KV global y su selección de contexto. Otras capas pueden reutilizar la memoria, o reutilizar además las posiciones que otra capa ya decidió mirar. Treinta de las 40 capas están en modo Reuse.
Baja la KV global de FP8 a FP4. No es una compresión aplicada al final: DeepSeek introduce estas condiciones durante post-training mediante Quantization-Aware Training. La memoria local de Sliding Window Attention, más sensible, se mantiene en FP8.
Deja de persistir la memoria local durante horas. La KV global sigue en almacenamiento persistente. El estado local de SWA pasa a DRAM del host y caduca en minutos. Si vuelve a hacer falta, el modelo reconstruye de forma acotada los últimos 128 tokens en lugar de recuperar toda la historia.
Juntas, estas decisiones dejan la KV global en 890 bytes por token y la caché persistente en torno a un octavo de la de V4 Flash.
Si quieres bajar hasta cómo funciona CED, qué diferencia hay entre Full, Reindex y Reuse, por qué FP4 aguanta o cómo funciona Bounded Replay, lo hemos desmontado en una pieza aparte: DeepSeek V4.1 Flash, la arquitectura construida para agentes .
Puedes decidir cuánto razona
V4.1 Flash trae una palanca habitual ya en los modelos cerrados, el esfuerzo de razonamiento.
En nuestro endpoint es el parámetro reasoning_effort y acepta cuatro valores, siempre como cadena de texto: low, medium, high y max. Si lo omites, el modelo razona con su comportamiento por defecto.
-d '{
"model": "deepseek-v4-flash",
"reasoning_effort": "high",
"messages": [...]
}'El razonamiento vuelve en message.reasoning_content y el recuento de tokens que ha consumido, en completion_tokens_details.reasoning_tokens. Así puedes medir lo que te está costando cada nivel en tu propia carga.
DeepSeek documenta que subir el esfuerzo mejora la precisión media sobre un conjunto de benchmark, y que el tramo intermedio recupera buena parte del máximo gastando bastante menos. Eso es una tendencia agregada. Prompt a prompt no tiene por qué ordenarse de menos a más: en nuestras pruebas, un mismo nivel produce mucho más razonamiento en unas tareas que en otras y el orden se invierte según el caso.
La recomendación práctica es la de siempre: fija el nivel por tipo de tarea, mídelo con tus propios prompts y no asumas que el máximo es siempre mejor. En una tarifa plana, bajar el esfuerzo no te cambia la factura. Te ahorra latencia y consumo de tu cuota mensual, que en un agente de cientos de pasos es exactamente lo que notas.
Qué pasa con el coste
DeepSeek bajó sus tarifas de API con el lanzamiento.
El output bajó un 9%. El input sin acierto de caché, un 32%. El input con acierto de caché, un 57%.
En Helmcode no pagas esas tarifas: V4.1 Flash cuenta contra la cuota mensual de tu plan igual que V4 Flash y el precio de la suscripción no cambia.
La eficiencia está cayendo mucho más rápido en input, y sobre todo en input cacheado, que en output. Es decir, lo que cuesta una tarea depende cada vez más de una variable que no controlas del todo: cuánto contexto se resuelve con aciertos de caché y cuánto hay que volver a procesar.
Y sobre eso se monta el problema real de estimar lo que gasta un agente. Un chat tiene un coste razonablemente predecible por conversación. Un agente, no. Depende de cuántas vueltas necesite para terminar, y eso varía con la tarea, con el estado del repositorio, con si la primera aproximación falla. La misma petición puede costar cuatro llamadas o cuarenta.
Por eso la tarifa plana encaja tan bien justo en esta carga. No te ahorra un porcentaje sobre una factura: te quita de encima la varianza. Puedes dejar corriendo un agente durante una hora sin que el coste de la tarea sea una incógnita hasta que termina.
Los benchmarks de DeepSeek V4.1 Flash
V4.1 Flash rinde bien en varios benchmarks agénticos y de software. Obtiene 90,6 en Terminal-Bench 2.1, 74,2 en DeepSWE, 54,8 en AutomationBench y 31,8 en Agents' Last Exam. En esos tests queda al nivel o por encima de los comparadores cerrados que DeepSeek publica.
Conviene saber de dónde salen esas cifras.
El 90,6 de Terminal-Bench se obtiene con DeepSeek Harness Minimal. Con Codex, el mismo checkpoint y la misma tarea dan 84,1. El 74,2 de DeepSWE sale con mini-SWE; con OpenCode, 65,5.
Casi nueve puntos sin cambiar el modelo.
Es un modelo que se comporta muy diferente en función del harness, las herramientas, la estrategia de contexto y la infraestructura que hay alrededor.
Es justo la idea que exploramos en DeepSeek Harness por dentro : same model, different agent.
V4.1 añade otra capa a esa historia. La arquitectura del modelo también empieza a cambiar alrededor de la forma en que esos agentes trabajan.
Tampoco gana en todas partes. En Terminal-Bench 4.0 obtiene 31,2 frente a 51,8 de Opus 5. En Humanity's Last Exam, 36,8 frente a 56,3. El propio reporte reconoce margen en tareas científicas agénticas y en multimodal.
El patrón encaja bastante bien con la arquitectura que han presentado: V4.1 Flash es especialmente interesante cuando el trabajo combina agentes, herramientas y mucho contexto. Eso no significa que sea automáticamente el mejor modelo para cualquier tarea difícil.
Entonces, ¿qué es V4.1 Flash?
Lo interesante no es resumirlo como un DeepSeek más rápido.
DeepSeek ha aumentado el backbone hasta 552B y, al mismo tiempo, ha reducido mucho la cantidad de modelo activa al leer y la memoria necesaria para sostener contexto.
Eso apunta a una dirección bastante clara: más capacidad total sin hacer que el coste de cada paso crezca en la misma proporción.
Durante mucho tiempo comparamos modelos preguntando cuánto sabían o cuánto costaba generar un millón de tokens.
Con agentes empieza a haber otra pregunta útil: cuánto cuesta mantener al modelo trabajando hasta que termina la tarea.
V4.1 Flash es uno de los diseños más explícitos hasta ahora alrededor de esa pregunta.
Ya está en Helmcode
V4.1 Flash está disponible en todos los planes, en infraestructura de la UE y sin retención de logs.
Sobre el identificador. deepseek-v4-flash apunta ahora a V4.1 Flash. Si ya lo usabas, estás recibiendo el modelo nuevo sin tocar la integración. Mantenemos el identificador porque DeepSeek ha retirado V4 Flash y ha renombrado el suyo a deepseek-flash, y preferimos que no tengas que cambiar código por un cambio de nomenclatura ajeno.
Dicho esto, es un modelo distinto detrás del mismo nombre. Si tienes prompts afinados o una batería de evals en producción, merece la pena volver a pasarla: los cambios de arquitectura de esta versión afectan a cómo se comporta con contextos largos.
curl https://api.helmcode.com/v1/chat/completions \
-H "Authorization: Bearer sk-your-key-here" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"reasoning_effort": "high",
"messages": [
{
"role": "user",
"content": "Explica RAG en una frase."
}
]
}'Necesitas una suscripción activa a Helmcode o a NaN y una key de tu Dashboard .
- La arquitectura completa con gráficos
- Qué incluyen los planes
- Todos los modelos que servimos
- El modelo abierto correcto para cada caso de uso
Si quieres dimensionarlo contra lo que pagas hoy por token, cuéntanos qué ejecutas y lo calculamos contigo.
