DeepSeek V4.1 Flash: API barata, pesos abiertos enormes

DeepSeek V4.1 Flash combina precios bajos de API con un modelo de pesos abiertos enorme. Lanzado el 10 de septiembre de 2026, activa 8.000 millones de parámetros al procesar la entrada y 16.000 millones al generar la salida, pero solo su estructura principal contiene 552.000 millones de parámetros. La mejora está en cuánto trabajo realiza el modelo en cada fase, no en una descarga pequeña para tu portátil. [1] [2]

¿Qué significa realmente «8B activos»?

El número de parámetros activos describe la parte del modelo utilizada para un token, no todo el modelo que debe almacenarse. V4.1 Flash es un modelo de mezcla de expertos, que selecciona partes de su red para realizar el cálculo. El nuevo diseño de DeepSeek también separa el procesamiento de la entrada y la generación de la salida, con un número distinto de parámetros activos en cada fase. [2]

Procesar la entrada suele llamarse prefill: el modelo lee el prompt antes de responder. Generar la salida es decode: produce tokens en secuencia. El informe técnico de DeepSeek describe una arquitectura de codificador-decodificador causal con 20 capas en cada parte. Declara 8B parámetros activos en prefill y 16B en decode; aquí B significa mil millones. [2]

Por eso, promediar ambas cifras y hablar de «un modelo de 12B» sería engañoso. Un prompt largo con una respuesta corta reparte el trabajo de forma distinta que un prompt breve seguido de un parche extenso. La arquitectura asigna cálculos diferentes a esas fases, pero ninguna convierte el modelo completo en una descarga de tamaño doméstico.

El desglose del almacenamiento lo deja claro. DeepSeek declara una estructura principal de 552B más unos 196B de memoria condicional Engram, un componente de consulta. La configuración de despliegue del proyecto vLLM también cuenta el modelo de borrador DSpark y otros tensores. El paquete completo de Hugging Face aparece actualmente con 763B parámetros. Las cifras cuentan partes diferentes del mismo lanzamiento. [2] [3]

La discusión del lanzamiento en r/LocalLLaMA, el 10 de septiembre, combinó entusiasmo con preguntas sobre arquitectura y despliegue. Esa es la tensión útil: el modelo puede calcular de forma selectiva y seguir siendo enorme a la hora de alojarlo. [5]

¿Por qué importa reducir la caché de contexto?

Una caché menor reduce uno de los costes de memoria de las conversaciones largas. La caché KV guarda información de atención de los tokens ya procesados para reutilizarla durante la generación. Esa memoria es distinta de la necesaria para almacenar los pesos del modelo.

El informe de DeepSeek sitúa la memoria KV global en 890 bytes por token, aproximadamente una cuarta parte de V4 Flash. Por separado, el anuncio afirma que la caché KV necesita una cuarta parte de la memoria de alto ancho de banda y una octava parte del almacenamiento SSD para la caché KV, respecto a la generación anterior. Son medidas relacionadas, no descripciones intercambiables de toda la memoria del modelo. [1] [2]

Esto importa a los agentes de programación porque una tarea puede acumular código del repositorio, resultados de herramientas y cambios sucesivos. Una caché menor abarata mantener ese contexto. No demuestra que el modelo recuerde correctamente cada dependencia o elija un buen parche. La capacidad de contexto publicada ronda el millón de tokens; la configuración de despliegue concreta 1.048.576. [2] [3]

Lo interpretaría como una mejora de infraestructura. Hace más práctico servir ese contexto largo, mientras que la calidad de una tarea de programación extensa sigue siendo otra pregunta.

¿Las mejoras de programación están verificadas de forma independiente?

Esta comparación procede de la evaluación de DeepSeek, no de una prueba independiente de esta publicación. Su tabla del modelo ajustado para seguir instrucciones muestra mejoras claras frente a V4 Flash en varios benchmarks de agentes. La comparación útil es con esa versión anterior y sus condiciones declaradas, no con cifras de otro proveedor obtenidas de otra forma.

DeepSeek publica una subida del 54,4 % al 74,2 % en DeepSWE v1.1, una mejora de 19,8 puntos porcentuales. Su ficha especifica reasoning_effort=100, temperature=1.0 y top_p=0.95. Las evaluaciones de agentes de código usan DeepSeek Harness Minimal con un contexto de un millón de tokens; DeepSWE usa mini-SWE. Esas condiciones forman parte del significado de las cifras. [2]

Mi lectura es que el lanzamiento merece una nueva evaluación de programación. Mi comparación anterior de V4 Flash trata de la versión previa y no determina cómo se comporta V4.1. Repetiría tareas representativas con las mismas pruebas y criterios de revisión antes de trasladar al trabajo diario un veredicto negativo antiguo o una puntuación nueva.

¿Cuánto cuesta DeepSeek V4.1 Flash por API?

La tabla actual identifica el modelo como deepseek-flash y aplica tarifas diferentes en horas punta y valle. En la consulta del 14 de septiembre de 2026, la entrada sin caché costaba 0,15 dólares por millón de tokens en horas valle y 0,30 en punta; la salida, 0,60 y 1,20 respectivamente. La entrada en caché tiene una tarifa inferior propia. [4]

Las tarifas en horas punta duplican las de las horas valle. Comparar precios exige indicar la franja y el tipo de caché, no solo la cifra más baja. El coste total de una tarea también depende del razonamiento, los resultados de herramientas y los reintentos necesarios. Un precio bajo por token de salida resulta atractivo, pero yo mediría el coste de obtener un resultado que pueda revisarse.

¿Puedes ejecutar los pesos abiertos en local?

Los pesos están disponibles con licencia MIT, pero el despliegue documentado requiere servidores de gran capacidad. La configuración de vLLM describe un checkpoint de unos 511 GB y un presupuesto mínimo de memoria GPU de 614 GB. Sus ejemplos incluyen una bandeja GB200 NVL4 y un nodo de ocho GPU H200. Son requisitos de esa configuración, no un mínimo universal para cualquier implementación futura. [2] [3]

Por eso separaría la decisión de usar la API de la de alojar el modelo. Probar un conjunto fijo de tareas por API permite evaluar su utilidad. Alojar los pesos añade la necesidad de planificar el modelo, la memoria, el entorno de ejecución y la capacidad. Los pesos abiertos dan esa opción a los operadores, pero no eliminan el trabajo de operar el modelo.

Para un desarrollador individual, empezaría con una comparación acotada por API frente al modelo que ya hace el trabajo. En un equipo de infraestructura, partiría de la configuración de despliegue y mediría las longitudes reales de entrada y salida. La cifra de 8B se vuelve útil cuando sabes qué fase de tu trabajo describe.