DeepSeek-V4.1-Flash: qué trae de nuevo y qué cambió con la versión 1017

Cuando un agente de programación trabaja en un proyecto, casi todo lo que el modelo hace es leer: el código, los resultados de cada comando, el historial de lo ocurrido. La respuesta nueva en cada paso suele ser corta. Ese desbalance entre mucha entrada y poca salida es el problema que DeepSeek dice atacar con DeepSeek-V4.1-Flash. Es un modelo publicado el 10 de septiembre de 2026 y actualizado el 17 de octubre con una versión llamada 1017.

Aquí repaso las novedades del informe técnico (51 páginas) con analogías antes de las cifras, y después cuento qué se sabe, según fuentes oficiales, de la actualización 1017. No necesitas conocimientos previos: cada término se define cuando aparece.

Una advertencia sobre las cifras: todas las puntuaciones de este artículo las publica DeepSeek en su informe y en sus fichas de Hugging Face, no un evaluador independiente. Son afirmaciones de DeepSeek, el laboratorio que desarrolla el modelo. Cuando digo “según el informe”, es eso: lo que el informe afirma, nada más.

En corto

• Qué es: un LLM multimodal (entiende texto e imágenes y responde con texto) de tipo Mixture of Experts, con 552B de parámetros en su estructura principal y contexto de hasta un millón de tokens.
• Idea central: que el modelo “pese” menos en memoria al trabajar con textos largos. Su caché KV ocupa unos 890 bytes por token, cerca de 1/4 de la de V4-Flash, y la parte que se guarda en disco baja a cerca de 1/8.
• Cálculo repartido: 8B de parámetros activos al leer la entrada (prefill) y 16B al generar (decode).
• Resultados: según el informe, en agentes de programación y de oficina iguala o supera a modelos cerrados en varias pruebas; en las más duras, como Terminal-Bench 4.0, queda por debajo del mejor modelo cerrado de la tabla.
• Licencia: pesos abiertos con licencia MIT.
• Versión 1017: actualización menor del 17 de octubre de 2026, con nota oficial en la documentación de la API y ficha propia en Hugging Face.

Por qué la memoria es el cuello de botella

Para generar cada palabra nueva, un modelo de lenguaje consulta todo lo anterior. Para no recalcularlo cada vez, guarda resúmenes internos de cada token ya leído. Esa libreta de apuntes es la caché KV (de “key-value”, clave-valor). El mecanismo detrás está explicado en el artículo sobre Attention Is All You Need y la arquitectura Transformer.

La libreta crece con cada token. En una conversación corta es insignificante. En un agente que lleva cientos de miles de tokens de contexto, ocupa mucho. Y ocupa lugar en tres sitios, según el informe:

• HBM: la memoria de la tarjeta gráfica (GPU). Es rapidísima y escasa.
• SSD y memoria del servidor: donde se guardan cachés para reutilizarlas si vuelve a llegar el mismo inicio de texto. Así no hay que releerlo.
• Ancho de banda: la velocidad para mover esos datos de un sitio a otro.

Para el informe, esas tres exigencias (cálculo, almacenamiento y transferencia) son el cuello de botella principal para seguir bajando el costo de desplegar modelos. Además lo conecta con los agentes: cada vez que un agente llama a una herramienta, hay que volver a procesar contexto. Si la caché no está disponible, se paga de nuevo.

Los números clave, en una tabla

Tabla 1: Cifras principales de DeepSeek-V4.1-Flash según el informe técnico

Dato	Cifra del informe
Parámetros de la estructura principal	552B
Parámetros de Engram (memoria adicional)	196B
Parámetros activos por token	8B en prefill, 16B en decode
Contexto máximo	1 millón de tokens
Caché KV global por token	890 bytes (cerca de 1/4 de V4-Flash)
Caché KV persistente	cerca de 1/8 de V4-Flash
Reducción de caché global vs. V4-Flash y V1	unas 4 veces y 437 veces
Datos de preentrenamiento	45T tokens
Capas	40 (20 de codificador y 20 de decodificador)

Cómo leerla: “parámetros” son los números internos que el modelo ajustó al entrenarse. Ver parámetros de un modelo. La caché por token se compara con la de V4-Flash, el modelo anterior de DeepSeek, y con V1, el primero de la familia. Que el informe diga “unas 4 veces” y “437 veces” es una comparación entre generaciones de DeepSeek, no contra modelos de otras empresas.

Para tener una idea de la escala: 890 bytes por token, multiplicado por un millón de tokens, da unos 890 MB de caché global (cuenta propia a partir de la cifra del informe, sin contar otras partes de la memoria).

Expertos que se turnan: qué es un Mixture of Experts

Piensa en una clínica con 384 especialistas. Cuando llega un paciente, la recepción no lo manda con todos: elige a los 6 especialistas que mejor encajan con su caso. Además, hay un médico general que atiende a todos los pacientes, sin excepción. La clínica tiene una capacidad enorme, pero cada consulta solo ocupa a 7 de sus 385 médicos.

Un Mixture of Experts (MoE) funciona igual:

• El paciente: cada token.
• La recepción: el enrutador, una pieza pequeña que decide qué expertos atienden cada token.
• Los especialistas: los expertos enrutados.
• El médico general: el experto compartido.

Según el informe, cada capa de DeepSeek-V4.1-Flash tiene 1 experto compartido y 384 enrutados, y por cada token se activan 6 de los enrutados.

Por eso las cifras de parámetros tienen dos lecturas. Los 552B son el tamaño total de la estructura. Los 8B o 16B son lo que trabaja de verdad para cada token. El costo de cálculo depende de lo segundo. La memoria necesaria para tener el modelo cargado depende de lo primero.

Leer con la mitad del modelo: el Causal Encoder-Decoder

Esta es la novedad que explica el 8B contra 16B. Las dos fases de una respuesta son:

• Prefill: el modelo lee de una vez todo el texto de entrada.
• Decode: el modelo genera la respuesta, token a token.

Son fases distintas, y se explican con más detalle en la entrada prefill y decode del glosario. En un agente, el prefill es lo caro, porque cada paso agrega al contexto salidas de herramientas, archivos y mensajes, y esa lectura se repite si la caché falla.

El informe propone la arquitectura Causal Encoder-Decoder (CED), inspirada en un trabajo anterior llamado YoCo. Piensa en un edificio de 40 pisos dividido en dos mitades. Los 20 pisos de abajo (el codificador) leen y entienden el texto. Los 20 de arriba (el decodificador) no repiten esa lectura: reciben las notas globales que salieron del piso 20 y se dedican a redactar la respuesta. Así, al leer una entrada larga solo se recorre la mitad de abajo. Eso es lo que el informe resume como 8B activos en prefill. El trabajo de prefill baja casi a la mitad, y el rendimiento se mantiene comparable al de la base, según el informe.

Una libreta más pequeña: CSA2 y la caché en FP4

CSA2: compartir apuntes entre capas

El modelo anterior ya comprimía su contexto. V4.1-Flash va más lejos con Compressed Sparse Attention 2 (CSA2). Tiene tres ideas que se entienden con una oficina:

• Compresión: en vez de guardar una nota por cada token, se guarda una nota por cada pequeño grupo de tokens. El informe usa una razón de compresión de 2 en el codificador y de 1 (sin comprimir) en el decodificador.
• Selección: al responder, no se consulta toda la libreta, sino solo las 512 notas más relevantes (el “top-k” de 512 del informe), elegidas por un índice ligero.
• Reutilización entre capas: en lugar de que cada capa guarde su propia copia de las notas, muchas reutilizan las de una capa anterior. El informe define tres modos por capa: Full (calcula todo), Reindex (reutiliza las notas pero vuelve a elegir cuáles mirar) y Reuse (reutiliza también la selección). La mayoría de las capas operan en modo Reuse.

Es como si en lugar de que cada empleado archive su propia copia del expediente, varios consultaran la misma y solo los primeros de cada grupo hicieran el trabajo de buscar.

FP4: apuntes con menos bits

La segunda palanca es la precisión. Cada número de la caché se guarda con cierto número de bits. Menos bits significan menos espacio y algo menos de exactitud, como guardar una foto en menor resolución. A eso se le llama cuantización. Según el informe, V4.1-Flash guarda su caché principal en FP4 (4 bits), lo que casi reduce a la mitad el espacio frente al formato FP8 de V4. El modelo se entrenó con esa precisión en mente, y el informe reporta solo una degradación marginal. La parte de ventana deslizante, más sensible, se mantiene en FP8.

Sumadas, CSA2 y FP4 llevan la caché global a esos 890 bytes por token, cerca de 1/4 de V4-Flash.

Ventana deslizante y el “repaso acotado” del disco

Además de la memoria global, el modelo lleva una atención local, de ventana deslizante (SWA): solo mira de cerca los últimos 128 tokens, como alguien que además de su libreta general tiene a mano lo último que se dijo en la conversación.

En el despliegue de V4, esa memoria local también se guardaba en disco para reanudar conversaciones. El informe indica que llegaba a ser casi la mitad de la caché persistente. En V4.1 se hizo lo contrario: no se guarda en disco. Se mantiene unos minutos en un fondo de memoria (el 10 % de la RAM de cada máquina) y, si se pierde, se reconstruye con una técnica llamada SWA Bounded Replay. Esta repasa solo los últimos 128 tokens en lugar de reconstruir exactamente toda la cadena. Es una reconstrucción aproximada. El informe dice que su efecto en la calidad es insignificante en las pruebas que hicieron. También reconoce que podría degradar el resultado en casos límite no probados.

Con esto, la parte persistente (la que vive en SSD o memoria del servidor) baja a cerca de 1/8 de la de V4-Flash. Las 72 horas de permanencia mínima garantizada de la parte global son un dato del informe. Describen cómo configuró DeepSeek su servicio.

Otras piezas, en una línea cada una

El informe agrega varias extensiones. Estas son las que se pueden explicar sin entrar en matemáticas:

• Engram (196B de parámetros): una memoria de consulta, parecida a un diccionario, que se añade al modelo para separar “recordar datos” de “razonar”. Se consulta por palabras y grupos de palabras, no se calcula con toda la red.
• Single-Pass mHC: un ajuste en la forma en que la información circula entre capas, para que se pueda ejecutar con menos movimiento de datos. El informe indica que, en el despliegue, reduce a la mitad el tráfico de memoria de esa operación.
• DSpark: decodificación especulativa. Un pequeño módulo propone un borrador de varias palabras a la vez y el modelo principal las verifica, como un asistente que adelanta el texto y el jefe solo corrige. Su propósito es generar más rápido.
• Visión integrada: el modelo procesa imágenes desde el preentrenamiento. Un codificador de visión propio acepta imágenes de hasta unos 1344 × 1344 píxeles.

Cómo se entrenó

• Preentrenamiento: 45T tokens de un corpus multimodal, con una proporción de 7 a 1 entre texto y datos multimodales. La atención dispersa se entrenó desde cero con secuencias de 64K tokens, y la longitud se extendió a 1M a los 34T tokens.
• Posentrenamiento: el informe afirma que no introduce algoritmos nuevos. Sigue el esquema habitual de ajuste supervisado, aprendizaje por refuerzo y destilación. Todo el trabajo nuevo está en los datos: tareas y entornos de agentes generados de forma automática a gran escala, incluyendo entornos de programación construidos a partir de repositorios públicos de GitHub. En la fase final de destilación participaron más de 40 modelos maestros.
• Esfuerzo de razonamiento: el modelo acepta una instrucción de “esfuerzo” de 1 a 100. En la API pública hay tres niveles: low (50), high (75) y max (100). Según el informe, subir el esfuerzo de 25 a 100 sube el promedio de ocho pruebas de razonamiento de 67,1 % a 76,3 %, y en Terminal-Bench 2.1 de 82,4 % a 90,6 %. Todo eso con unas 2,5 veces más tokens de salida. Las ganancias se concentran al principio: entre 60 y 80 se recupera la mayor parte de la precisión con menos de la mitad del presupuesto de tokens.

Cómo rinde: los benchmarks

Un benchmark es una prueba estándar para comparar modelos. Sus resultados solo dicen algo sobre esa prueba. Estas son las puntuaciones del informe, con el modelo en esfuerzo máximo (“Max”), frente a modelos abiertos y cerrados.

Tabla 2: V4.1-Flash frente a otros modelos, según la Tabla 3 del informe técnico

Benchmark (métrica)	Opus-5	GPT-5.6 Sol	K3	GLM-5.3	DS-V4-Pro	DS-V4-Flash	DS-V4.1-Flash
GPQA Diamond (Pass@1)	93,4	94,1	92,9	88,1	92,4	89,9	90,9
HLE (Pass@1)	56,3	44,5	43,5	42,0†	42,7†	37,8†	36,8 (39,1†)
Codeforces (rating)	-	-	-	-	3348	3289	3471
MathArena Apex (Pass@1)	-	-	65,6	-	65,3	58,6	65,6
Terminal-Bench 2.1 (Pass@1)	89,1	88,8	88,3	88,2	87,9	82,7	90,6
Terminal-Bench 3.0 (Pass@1)	43,3	34,4	17,7	28,3	11,8	7,6	30,0
Terminal-Bench 4.0 (Pass@1)	51,8	39,9	12,6	37,9	12,4	7,0	31,2
DeepSWE v1.1 (Resolved)	74,0	73,0	67,5	66,9	62,7	54,4	74,2
ProgramBench (Almost@1)	37,0	23,0	17,5	19,0	15,5	-	20,3
NL2Repo-Bench (Score)	75,3	56,8	58,0	58,0	61,5	54,2	65,4
CyberGym (Pass@1)	-	84,5	80,0	84,5	83,3	76,7	88,1
Automation-Bench (Pass@1)	50,3	45,8	46,7	48,8	43,2	37,7	54,8
Agents’ Last Exam (Pass@1)	28,6	26,7	27,6	28,5	25,7	25,2	31,8
HLE con herramientas (Pass@1)	63,6	-	59,8	62,5	60,0	51,5	63,9
Chartography con herramientas (Pass@1)	84,0	79,9	68,1	-	-	-	78,9
BabyVision con herramientas (Pass@1)	94,1	88,9	85,7	-	-	-	89,6
ZeroBench-main con herramientas (Pass@5)	52,0	53,0	41,0	-	-	-	49,0

Cómo leerla: cada fila es una prueba distinta, y más alto es mejor (Codeforces es un rating, no un porcentaje). † indica el subconjunto de HLE que solo tiene texto. Un guion significa que el informe no da cifra. Fíjate en dos cosas. Primero, la mejora frente a V4-Flash, su antecesor, es grande en agentes: DeepSWE v1.1 pasa de 54,4 a 74,2 y Terminal-Bench 2.1 de 82,7 a 90,6. Segundo, en las pruebas más difíciles (Terminal-Bench 3.0 y 4.0, HLE sin herramientas) queda por debajo de Opus-5, y en varias de las pruebas visuales también. El propio informe reconoce que sigue habiendo una brecha en tareas de agentes en ciencia que requieren conocimiento experto. También reconoce que la paridad en benchmarks no implica igualdad en tareas complejas y casos límite.

Sobre el modelo base (antes del posentrenamiento), el informe compara también con V4-Pro-Base, un modelo con 1,6T de parámetros en total y 49B activos.

Tabla 3: Modelos base, selección de la Tabla 1 del informe técnico

Benchmark (métrica)	V4-Flash Base	V4-Pro Base	V4.1-Flash Base
Parámetros activos	13B	49B	8B/16B
Parámetros de estructura	284B	1,6T	552B
MMLU-Pro (EM)	68,3	73,5	74,1
SuperGPQA (EM)	46,5	53,9	53,1
Simple-QA verified (EM)	30,1	55,2	42,3
HumanEval (Pass@1)	69,5	76,8	79,4
BigCodeBench (Pass@1)	56,8	59,2	60,6
LongBench-V2 (EM)	44,7	51,5	45,2
MMMU-Pro (EM, multimodal)	-	-	56,5
DocVQA (LLM-Judge, multimodal)	-	-	95,6

Cómo leerla: el informe destaca que V4.1-Flash-Base iguala o supera a V4-Pro-Base en muchas pruebas usando menos parámetros. La tabla también muestra lo contrario: en Simple-QA verified (recordar datos concretos) queda en 42,3 frente a 55,2, y en LongBench-V2 (contexto largo) en 45,2 frente a 51,5. Es consistente con una estructura más pequeña, y con que los autores dicen vigilar la recuperación de información en contextos largos.

El agente importa tanto como el modelo

Un agente es un modelo que decide pasos y usa herramientas, y el programa que lo envuelve (el “harness” o andamiaje) también influye. El informe mide el mismo modelo en ocho configuraciones:

Tabla 4: Mismo modelo, distintos andamiajes, según la Tabla 4 del informe técnico

Andamiaje	DeepSWE v1.1 (Resolved)	Terminal-Bench v2.1 (Pass@1)
Claude Code	69,8	88,0
Codex	65,6	84,1
OpenCode	65,5	85,0
Pi	66,2	86,1
mini-SWE	74,2	90,3
DeepSeek Harness (Minimal)	72,6	90,6
DeepSeek Harness (Standard)	70,5	85,8
DeepSeek Harness (PTC)	67,6	85,8

Cómo leerla: el esfuerzo de razonamiento es el máximo (100) en todas las filas, y el modelo y la configuración de muestreo son los mismos. Solo cambia el programa que lo rodea. La diferencia llega a casi 9 puntos en DeepSWE (65,5 frente a 74,2). Lección práctica: una cifra de un benchmark depende del andamiaje con que se midió. La tuya puede ser distinta con tu herramienta.

La actualización 1017

Aquí hay que separar lo que se puede verificar de lo que no.

Lo que existe y es oficial:

• Una nota en la documentación de la API de DeepSeek, titulada “DeepSeek-V4.1-Flash-1017: Wish-Driven Programming Made Real”, con fecha de lanzamiento 17 de octubre de 2026. Dice que el modelo ofrece “stronger benchmark performance, faster task completion, and shorter outputs than the previous version” y lo describe como una mejora en rendimiento y costo a la vez. También dice que está optimizado para DeepSeek Harness, CodeBuddy de Tencent, WorkBuddy y otros, y recomienda actualizar a DeepSeek Harness v0.2.1-rc.1 o posterior.
• Una ficha propia en Hugging Face (DeepSeek-V4.1-Flash-1017), creada el 17 de octubre de 2026, con licencia MIT. La describe como “a minor update to DeepSeek-V4.1-Flash” que mejora el razonamiento, la programación, las tareas de agentes y los benchmarks visuales, y que reduce el tiempo de ejecución y la longitud de la salida.
• En la API, según la documentación, el nombre deepseek-flash pasa a servirse con este modelo y “la forma de llamarlo no cambia”. Los nombres antiguos deepseek-v4-flash y deepseek-v4-flash-vision-exp siguen aceptándose, pero se atienden con el mismo modelo.

Es decir: sí hay información oficial, y no solo un número de versión. Lo que no hay es un nuevo informe técnico: la ficha enlaza el mismo informe de V4.1-Flash, que es anterior a la 1017 y no la describe.

Tabla 5: 1017 frente a V4.1-Flash, según la ficha de Hugging Face de DeepSeek

Benchmark	V4.1-Flash-1017	V4.1-Flash
HLE sin herramientas	42,6 (44,0†)	36,8 (39,1†)
Terminal-Bench 4.0	42,3	31,2
DeepSWE v1.1	77,0	74,2
ProgramBench	29,1	20,3
NL2Repo-Bench	68,2	65,4
Automation-Bench v1.0.6	60,5	54,8
Agents’ Last Exam	35,4	31,8
Apex Bench v1.1	72,1	64,6
Chartography (con herramientas)	83,0	78,9
BabyVision (con herramientas)	92,5	89,6
ZeroBench-main (con herramientas)	51,0	49,0

Cómo leerla: la columna de V4.1-Flash coincide con las cifras del informe (por ejemplo, 31,2 en Terminal-Bench 4.0 y 74,2 en DeepSWE). La de 1017 es lo que DeepSeek publica para la nueva versión. Según esa ficha, la nueva versión supera a la anterior en las once pruebas listadas. La ficha usa el arnés de Claude Code en Terminal-Bench 4.0 y el de Mini-SWE-V2 en DeepSWE. Sigue siendo una medición del propio DeepSeek.

La ficha no detalla qué cambió en el entrenamiento. La nota de la API dice solo que se usó aprendizaje por refuerzo “con autorretroalimentación” para mejorar el desarrollo de proyectos completos. Da cuatro ejemplos:

• un modelado 3D de la Ciudad Prohibida
• un juego de carreras web
• una recreación de Portal 2 en Godot
• una escena 3D de la evolución desde la prehistoria hasta la era moderna

Un detalle de la misma nota, aunque no es del modelo. Las APIs de búsqueda y de lectura de páginas de DeepSeek pasan a estar abiertas a todos, a 0,75 dólares por cada 1.000 llamadas por endpoint. Las llamadas hechas a través de herramientas del lado del servidor en DeepSeek Harness, Claude Code y Codex son gratuitas por ahora. El cobro empieza el 31 de octubre de 2026 a las 16:00 UTC.

Prueba propia: una turbina en 3D generada con la API

Las tablas de arriba las publica el laboratorio de DeepSeek. Para ver al modelo trabajar en algo concreto, le pedí a DeepSeek por la API una tarea de programación visual: una animación 3D de un motor de avión con un corte parcial que deje ver cómo funciona por dentro. Escribí la consigna una sola vez y publico el resultado tal como salió, sin retoques.

Cómo se hizo:

• Modelo: usé deepseek-flash, que según la documentación de la API ya sirve la versión 1017.
• Razonamiento: activado, con esfuerzo high.
• Fecha: 26 de octubre de 2026 por la noche, hora de Colombia (ya 27 en hora UTC).
• Intentos: lo corrí una sola vez, sin reintentos ni correcciones.

La consigna (prompt) completa fue esta:

Crea una animación 3D interactiva de un motor turbofan (motor a reacción de avión) con un corte parcial que deje ver su funcionamiento interno.

Requisitos:
- Un único archivo HTML autocontenido. Usa Three.js 0.169.0 desde https://cdn.jsdelivr.net/npm/three@0.169.0/ con un import map (módulo `three` y `three/addons/`). No cargues ningún otro recurso externo: ni imágenes, ni fuentes, ni modelos.
- Construye la geometría con primitivas de Three.js. Incluye, en orden de adelante hacia atrás: el ventilador (fan) con sus álabes, el compresor de baja y de alta presión (varias etapas de álabes), la cámara de combustión, la turbina de alta y de baja presión, el eje central y la tobera de salida, todo dentro de una carcasa (nacelle).
- Corte parcial: quita un cuarto de la carcasa y de las piezas estáticas para que se vea el interior, como en un modelo de museo.
- Animación: las piezas giratorias rotan alrededor del eje; el ventilador y la turbina de baja presión giran juntos más lento, y el compresor y la turbina de alta presión giran juntos más rápido. Representa el flujo de aire con partículas que entran por el ventilador, se dividen entre el flujo de derivación (bypass) y el núcleo, cambian de color al pasar por la cámara de combustión y salen por la tobera.
- Controles: OrbitControls para girar y hacer zoom; un botón para pausar o reanudar; un botón para alternar entre vista con corte y vista completa; y un botón de "despiece" que separa las secciones a lo largo del eje con una transición suave y las vuelve a unir.
- Etiquetas en español sobre cada sección (Ventilador, Compresor, Cámara de combustión, Turbina, Tobera) que sigan a la pieza al girar la cámara.
- Fondo oscuro, iluminación que destaque el metal, y que se adapte al tamaño de la ventana (también en un celular).
- Rendimiento razonable: que funcione fluido en una laptop común.

Devuelve solo el archivo HTML completo dentro de un bloque de código ```html.

Three.js es una biblioteca de JavaScript para dibujar escenas 3D en el navegador.

Tabla 6: Consumo de la prueba

Dato	Valor
Tokens de entrada (la consigna)	593
Tokens de salida, en total	51.995
De ellos, razonamiento	43.023
De ellos, la respuesta (el código)	8.972
Tiempo hasta recibir la respuesta completa	unos 226 segundos
Costo, según el saldo de la cuenta	unos 0,06 dólares (de 3,32 a 3,26)
Resultado	un archivo HTML de unos 25 KB, 790 líneas

Cómo leerla: el dato que más llama la atención es el reparto de la salida. El 83 % de los tokens que generó el modelo fue razonamiento interno, que no se ve en el resultado pero sí se paga y se espera. Es como contratar a un consultor por horas y descubrir que casi todo el tiempo lo gastó pensando. Solo unos 9.000 tokens fueron el código final.

Sobre las mediciones:

• Tiempo: se tomó del momento en que se guardaron los archivos de la respuesta, unos segundos después de recibirla. Por eso es aproximado.
• Costo: sale de la diferencia del saldo de la cuenta, que la API muestra con dos decimales. Con ese redondeo, el valor exacto puede estar entre 0,05 y 0,07 dólares.
• Velocidad: a ese ritmo, el modelo generó unos 230 tokens por segundo.

Si no se ve bien en la página, puedes abrir la turbina a pantalla completa. Puedes girarla con el ratón o el dedo, acercarte, pausar la animación, alternar entre la vista con corte y la completa, y separar las piezas con el botón de despiece.

El resultado me pareció muy bueno. Cumple los puntos de la consigna:

• Las piezas: ventilador, compresores, cámara de combustión, turbinas, eje y tobera, dentro de la carcasa.
• El corte: se puede alternar entre la vista con corte y la vista completa.
• El giro: dos velocidades de rotación, una para las piezas de baja presión y otra para las de alta.
• El aire: partículas que muestran el flujo de aire.
• Los controles y las etiquetas: los tres botones pedidos y etiquetas en español que siguen a cada pieza.

El único recurso externo que carga es Three.js desde jsDelivr, como pedía la consigna.

Un detalle técnico que muestra que no es perfecto: la página impide hacer zoom con los dedos en el celular (user-scalable=no), una práctica que las pautas de accesibilidad desaconsejan.

Es una sola ejecución, así que sirve como muestra y no como medición. Con otra consigna, otro nivel de esfuerzo u otro intento, el resultado y el consumo cambian.

Qué significa para ti

• Si usas agentes de programación o de oficina: lo relevante no es un benchmark suelto sino el costo del contexto. DeepSeek dice que los cargos por caché acertada son una parte grande del gasto de los agentes y que comprimir la caché los reduce. Eso lo afirma la propia empresa, así que compara el costo real de tu flujo, no el de la tabla de precios. Hay una pista útil en las cifras del propio informe: los niveles de esfuerzo intermedios dan buena relación entre calidad y costo. Reserva el máximo para lo difícil.
• Si usas la API: el modelo se llama deepseek-flash. En la nota de lanzamiento de V4.1-Flash, DeepSeek indica que los precios fuera de hora punta son el 50 % de los de hora punta, y que deepseek-v4-pro se redirige a V4.1-Flash a precio de Flash hasta que salga una V4.1-Pro. Los precios cambian. Revisa la página de precios de la API antes de calcular costos.
• Si piensas en ejecutarlo tú: los pesos son abiertos con licencia MIT. La ficha incluye una carpeta con instrucciones de inferencia local y recomienda temperatura 1.0, top_p 1.0 y al menos 256K de max_tokens. La ficha no indica requisitos de hardware. Como referencia, los archivos de pesos de la versión 1017 suman unos 510 GB (48 archivos safetensors), así que no es un modelo para un portátil. Para un uso con pocos recursos, mira los modelos pequeños, como en Clasificar texto sucio a gran escala con modelos flash y JEV. Y para integrar un modelo en una aplicación, Ingeniería de prompts avanzada: API y modelos locales.
• Si evalúas modelos para un cliente: mide con tu propio caso. Los benchmarks los publica DeepSeek, el andamiaje cambia el resultado hasta casi 9 puntos, y el informe reconoce que pueden fallar casos límite de CSA2 y de la reconstrucción aproximada de SWA.

Tu primer paso

Toma una tarea real de tu trabajo que implique mucho contexto (por ejemplo, analizar un repositorio o un conjunto de documentos), ejecútala con deepseek-flash en dos niveles de esfuerzo (por ejemplo, medio y máximo) y anota calidad, tiempo y tokens consumidos. Con esas tres cifras sabrás si el nivel máximo se justifica para ti. Ninguna tabla del informe puede decírtelo.

Fuentes

Consultadas el 26 de octubre de 2026. Todas las cifras de rendimiento son publicadas por DeepSeek.

• DeepSeek-AI, DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression (informe técnico, 2026).
• Hugging Face, ficha del modelo DeepSeek-V4.1-Flash (licencia MIT; creada el 10 de septiembre de 2026).
• Hugging Face, ficha del modelo DeepSeek-V4.1-Flash-1017 (creada el 17 de octubre de 2026; tabla comparativa, nota de uso y licencia).
• DeepSeek API Docs, DeepSeek-V4.1-Flash-1017: Wish-Driven Programming Made Real (17 de octubre de 2026).
• DeepSeek API Docs, DeepSeek-V4.1-Flash: Smarter, Faster, More Efficient (10 de septiembre de 2026).
• DeepSeek API Docs, Models & Pricing (nombres de modelo y precios vigentes).
• Artículos relacionados en este blog:
  • Attention Is All You Need: el paper de los Transformers explicado
  • Clasificar texto sucio a gran escala: cómo armar un pipeline con JEV y un LLM verificador
  • Ingeniería de prompts avanzada: API y modelos locales