Análisis técnico / Octubre 2026
Modelos open-weight en octubre de 2026: qué avances importan para los agentes
DeepSeek V4.1 Flash 1017, MiniMax, los modelos locales y la especialización apuntan a una misma pregunta: cuánto cuesta completar una tarea y qué hace falta para hacerlo bien.
Publicado el 26 de octubre de 2026 por QDivZero Team13 min de lectura
El 17 de octubre, DeepSeek actualizó V4.1 Flash con una promesa especialmente relevante para quienes utilizan agentes de programación: resolver mejor las tareas, en menos tiempo y con respuestas más cortas. La combinación merece atención. Cuando un modelo puede consultar archivos, ejecutar pruebas y corregir su trabajo, su utilidad depende de lo que consigue terminar y de los recursos que consume hasta llegar ahí.
Esa preocupación recorre varios de los lanzamientos de modelos open-weight de octubre de 2026. MiniMax incorpora técnicas para abaratar cada consulta. NVIDIA parte de un presupuesto de memoria para diseñar Bolt. Recursive y Liquid trabajan en agentes que puedan ejecutarse en equipos locales. Con Clef, Cloudflare lleva al ámbito de los pesos abiertos la propuesta que popularizó Jev: modelos especializados en decisiones concretas, como clasificar una solicitud o elegir una herramienta, cuyos resultados puede utilizar directamente el programa. Meta y Reflection, por su parte, amplían las opciones de gran escala disponibles para desarrollar aplicaciones propias.
¿Qué avances permiten completar más trabajo con los recursos disponibles? Esta revisión, cerrada el 26 de octubre, sigue esa pregunta. La lectura conjunta de los anuncios sugiere que la eficiencia está influyendo en qué se entrena, cómo se ejecuta y cómo se evalúa un modelo. Para entender el alcance del cambio hay que relacionar esas tres decisiones, porque una mejora en una de ellas puede quedar anulada por las otras.
DeepSeek V4.1 Flash 1017 pone el foco en terminar mejor las tareas
La novedad de DeepSeek V4.1 Flash 1017 es una actualización del 17 de octubre sobre la familia presentada en septiembre. DeepSeek atribuye sus avances en desarrollo de proyectos al aprendizaje por refuerzo con retroalimentación del propio modelo. El anuncio comunica mejoras en calidad, duración de las tareas y longitud de las respuestas. No ofrece un desglose experimental que permita atribuir cada mejora a una intervención concreta del entrenamiento.
La ficha de la versión 1017 permite observar qué cambia frente a la versión anterior en tres pruebas de programación:
Son resultados publicados por DeepSeek. Terminal-Bench se ejecuta con Claude Code y DeepSWE con Mini-SWE-V2, los programas que proporcionan las herramientas y organizan la interacción del modelo con el entorno. La mejora de 11,1 puntos en Terminal-Bench no representa una aceleración del 11,1 %. Describe un cambio en el resultado de esa evaluación.
La distinción importa porque el tiempo de un agente se reparte entre actividades muy diferentes. Puede estar leyendo código, generando un cambio, esperando a que termine una prueba o investigando por qué ha fallado. Si necesita menos intentos para conseguir una solución válida, puede ahorrar recursos aunque la velocidad de generación apenas cambie. Si escribe menos pero omite una comprobación necesaria, el ahorro aparente puede trasladarse a quien revisa su trabajo. Evaluar la eficiencia exige conservar un criterio de calidad.
Los modelos crecen mientras se reduce el trabajo por token
El nombre Flash puede resultar engañoso si se interpreta como una medida del tamaño. En estas familias identifica una propuesta de eficiencia, pero no una arquitectura común ni un requisito de hardware. Para entenderla conviene separar la capacidad almacenada en los pesos, los valores numéricos aprendidos durante el entrenamiento, de la parte que interviene en cada cálculo.
En una arquitectura Mixture-of-Experts, o MoE, algunas capas contienen varias redes llamadas expertos. Un mecanismo entrenado, el router, selecciona cuáles procesan cada token, una unidad que puede representar una palabra, un fragmento o un signo. Así se puede aumentar el número total de parámetros sin utilizar todos ellos para cada token. Los pesos de los expertos restantes deben seguir accesibles, y la atención y el movimiento de datos añaden trabajo que el recuento de parámetros activos no describe.
Dos publicaciones de mediados de mes muestran la escala alcanzada. Muse Spark Open, de Meta, apareció el 15 de octubre con unos 816B de parámetros totales y 42B activos por token. Reflection publicó Beam el 16, con 501B totales y 23B activos. La B significa mil millones. En Beam, la publicación incluye formatos BF16, FP8 y NVFP4 e integraciones para ejecutar el modelo y conectarlo a agentes. Esas piezas reducen parte del trabajo necesario para utilizarlo.
DeepSeek plantea otra forma de repartir el cálculo. Su arquitectura Causal Encoder-Decoder, presentada el 10 de septiembre, utiliza unos 8B de parámetros activos por token al procesar la entrada y 16B al generar la salida. Esta asimetría tiene sentido en aplicaciones que leen mucho más de lo que escriben. Un agente puede recibir miles de líneas de código y devolver una llamada breve a una herramienta. Reducir el coste de lectura puede ser tan relevante como acelerar la respuesta. Es un antecedente de la actualización 1017, no una innovación introducida en octubre.
La consecuencia práctica del acceso abierto también merece precisión. Poder descargar estos modelos permite elegir dónde ejecutarlos y conservar una versión para evaluarla o adaptarla según su licencia. Esa libertad no elimina los requisitos materiales. La documentación de Muse Spark Open sitúa los pesos BF16 en torno a 1,5 TB. Un modelo puede ser accesible para investigación y despliegues propios y, al mismo tiempo, requerir una infraestructura considerable.
MiniMax y NVIDIA incorporan el ahorro al diseño del modelo
Si el objetivo es ejecutar muchas consultas, la eficiencia debe prepararse antes de poner el modelo en producción. Esa es una de las coincidencias más interesantes entre MiniMax M3.1 Flash y Nemotron 3.5 Bolt, aunque sus técnicas y sus equipos de destino sean distintos.
MiniMax anunció M3.1 Flash el 19 de octubre con acceso mediante API. Al cierre de esta revisión, su repositorio oficial ya ofrecía los pesos. La ficha describe atención dispersa en todas las capas, cuantización durante el entrenamiento y un componente DSpark para decodificación especulativa. Estas decisiones buscan reducir cuánto se consulta, cuánto se almacena y cuánto trabajo secuencial exige generar una respuesta.
La atención dispersa selecciona qué posiciones del contexto consultar. La cuantización representa los valores con menos bits, y tenerla en cuenta durante el entrenamiento ayuda al modelo a adaptarse a esa menor precisión. La decodificación especulativa propone varios tokens y utiliza el modelo principal para verificarlos. Cuando acepta suficientes propuestas, puede avanzar varias posiciones en una comprobación. El trabajo sobre muestreo especulativo explica por qué el beneficio depende de la aceptación y del coste de proponer y verificar.
NVIDIA presentó Bolt el 15 de octubre con un objetivo de 24 GB de memoria. Comprime Super VL hasta unos 74B de parámetros totales y 9B activos, combina distintas precisiones y aplica destilación para recuperar calidad tras cuantizar. Los expertos utilizan IQ2_XXS, a 2,0625 bits por elemento. La cifra de 24 GB corresponde a la configuración que documenta NVIDIA.
La relación entre precisión y almacenamiento se puede estimar así:
representa el número de parámetros y los bits medios por parámetro. Con 74B de parámetros, BF16 requiere 148 GB decimales solo para los pesos. A cuatro bits serían 37 GB y a dos bits, 18,5 GB. Es una comparación teórica con precisión uniforme. Los formatos reales añaden metadatos, y Bolt combina precisiones.
Memoria que ocupan los pesos según su precisión
Estos lanzamientos sugieren una evolución en la forma de diseñar modelos: el presupuesto de ejecución puede orientar la arquitectura y el entrenamiento desde el principio. El resultado depende después de las rutinas de cálculo que soporten el formato y el hardware. Leer menos datos puede acelerar una generación limitada por el ancho de banda de memoria, pero convertirlos también cuesta. La reducción de tamaño y la ganancia de velocidad son magnitudes diferentes.
El contexto largo convierte la memoria en un recurso compartido
Al reducir el espacio ocupado por los pesos, aparece otra demanda que crece mientras el agente trabaja. Cada consulta puede incorporar instrucciones, archivos, errores y resultados de herramientas. Un modelo compartido por un equipo debe atender varios de esos historiales a la vez. Por eso, anunciar un millón de tokens de contexto deja pendiente una pregunta decisiva: cuántas sesiones pueden utilizarse simultáneamente con una latencia aceptable.
La caché KV conserva claves y valores de la atención para reutilizarlos al generar nuevos tokens. En una arquitectura convencional, su memoria puede aproximarse mediante:
El factor 2 cuenta claves y valores. representa las capas con caché, las cabezas KV, su dimensión y los bytes por elemento. La suma incluye los tokens de todas las secuencias activas. En GQA, varias cabezas de consulta comparten claves y valores, por lo que la cuenta utiliza las cabezas KV.
Con 64 capas, ocho cabezas KV, dimensión 128 y BF16, un millón de tokens ocuparía unos 244,14 GiB solo de caché. Cuatro secuencias independientes elevarían la cifra a unos 976,56 GiB. Es un ejemplo hipotético para atención convencional. No describe la memoria de DeepSeek ni de los demás modelos de esta revisión.
Cuánta memoria necesita la caché KV
64 × 8 × 128
Ejemplo hipotético de atención convencional: 64 capas, 8 cabezas KV, dimensión 128 y BF16. Las secuencias son independientes, sin compresión ni prefijos compartidos. No corresponde a los requisitos de un modelo concreto.
Precisamente, las arquitecturas recientes intentan modificar esa relación. El informe técnico de DeepSeek V4.1 Flash combina compresión, reutilización entre capas y menor precisión de la caché. Comunica aproximadamente una cuarta parte de la memoria de caché durante la ejecución respecto a V4 Flash, a igual longitud de secuencia. Ese resultado de septiembre ayuda a entender por qué la revisión de octubre puede apoyarse en una base pensada para historiales extensos.
El motor también influye. PagedAttention reduce el desperdicio de memoria al organizar la caché en bloques. Compartir prefijos permite reutilizar los bloques iniciales de solicitudes compatibles. Aun así, conviene decidir qué información merece conservarse. Resumir un historial puede omitir un detalle necesario, mientras que enviarlo completo ocupa recursos y puede añadir información irrelevante. Comparar ambas opciones con recuperación de información mediante RAG permite estudiar ese equilibrio con preguntas concretas.
Los agentes locales necesitan mantener el ritmo durante toda la sesión
El presupuesto se vuelve especialmente visible en un ordenador personal. El modelo comparte memoria con el editor, el navegador y las herramientas del proyecto. Una velocidad elevada al comienzo de la conversación puede ser poco representativa de una sesión en la que ya se han leído muchos archivos.
Recursive presenta Flint como un modelo de programación local acompañado de su propio motor de inferencia y versiones cuantizadas. Su ficha técnica indica 39,8B de parámetros totales, unos 2,5B activos y una combinación de 35 capas de atención de ventana limitada y 14 de atención completa. La configuración documenta 262.144 tokens. El anuncio menciona hasta 512K, pero recomienda mantenerse dentro de 256K para obtener mejores resultados.
La publicación conjunta de modelo y motor es significativa. La calidad de una experiencia local depende de cómo ambos aprovechan el equipo, mantienen el contexto y procesan llamadas a herramientas. Una prueba útil debe incluir la lectura inicial del repositorio y el crecimiento de la conversación, además de la velocidad con la que se generan tokens.
Liquid publicó LFM2.5-24B-A2B el 13 de octubre. Su ficha detalla 24B de parámetros totales, 2,45B activos y una arquitectura que combina convoluciones cortas con atención GQA. Liquid explica que aprovecha su velocidad de generación para producir razonamiento antes de la respuesta final.
Aquí aparece un contrapunto a la reducción de longitud que anuncia DeepSeek. Dedicar más cálculo al razonamiento puede compensar si aumenta la probabilidad de resolver bien una tarea. La eficiencia no prescribe una respuesta siempre breve. Exige encontrar cuánto esfuerzo merece cada problema. Esa decisión cambia entre extraer un dato, corregir una función y modificar varios módulos de una aplicación.
Parte del trabajo puede resolverse sin generar una respuesta de texto
Ajustar el esfuerzo de razonamiento conduce a otra posibilidad: reservar un mecanismo más específico para las decisiones acotadas. Clasificar una incidencia o elegir entre varias rutas de procesamiento no siempre requiere que un modelo redacte una explicación y que otro programa extraiga después la categoría elegida.
El interés reciente por esta categoría tiene un antecedente claro en Jev, presentado por TypeSafe el 15 de septiembre. Recibe información y preguntas, y devuelve decisiones estructuradas con probabilidades que el programa puede utilizar directamente. Jev se ofrece como servicio de TypeSafe y aparece aquí como antecedente de la tendencia, no como una publicación de pesos abiertos de octubre.
El 1 de octubre, Cloudflare presentó Clef y Clef-flash, basados respectivamente en Qwen3.8-27B y Qwen3.5-9B. Su anuncio reconoce el interés suscitado por Jev y lleva esa propuesta al ámbito de los modelos con pesos abiertos. Calculan las opciones admitidas por un esquema a partir de las representaciones internas del modelo. Su entrenamiento busca mejorar tanto el acierto como la calibración, es decir, la correspondencia entre la confianza expresada y la frecuencia real de aciertos.
El 7 de octubre, Liquid publicó d1-3B y el experimental d1-omni-600M. La documentación de d1-3B describe respuestas en una sola pasada a preguntas de sí o no, elecciones y escalas de valoración. Se evita generar una secuencia de texto de salida, aunque procesar la entrada sigue teniendo un coste.
La clasificación existe desde mucho antes de los LLM. El interés de estas propuestas reside en permitir que la aplicación formule preguntas y opciones sobre información diversa, aprovechando representaciones aprendidas por modelos de lenguaje o multimodales. En un sistema de soporte, por ejemplo, un componente puede clasificar la incidencia y otro preparar una respuesta o consultar una herramienta.
Esta división permite asignar a cada componente una función que pueda comprobarse. También introduce dependencias: una clasificación equivocada puede enviar la tarea por una ruta incorrecta antes de que intervenga el modelo principal. Las probabilidades necesitan validarse con datos del uso previsto, y las decisiones dudosas deben tener un tratamiento definido. La especialización puede ahorrar generación, pero su valor se decide en el resultado del proceso completo.
La prueba decisiva es cuánto cuesta obtener un resultado válido
Los avances anteriores actúan en lugares distintos. DeepSeek comunica mejoras al completar tareas. MiniMax y NVIDIA reducen exigencias de ejecución. Flint vincula el modelo con un motor local. Clef y d1 permiten distribuir funciones. Para compararlos de forma útil hace falta medir el trabajo que termina correctamente bajo un presupuesto definido.
La cuenta incluye los intentos fallidos y utiliza el mismo periodo para todos los costes. Si una tarifa de inferencia ya incluye la infraestructura, esa partida no se suma otra vez. En un despliegue propio, se atribuye el coste de la capacidad utilizada. Si ninguna tarea se resuelve correctamente, el cociente no ofrece un coste finito por resultado.
Coste por tarea correcta
Configuración A
100 €gasto total
Configuración B
120 €gasto total
menos por tarea correcta con B
El gasto aumenta un 20 % y las tareas resueltas, un 50 %.El ejemplo muestra por qué una configuración con mayor gasto total puede producir resultados válidos a menor coste. Para trasladarlo a programación, antes hay que definir qué significa resolver la tarea. La metodología de SWE-bench utiliza pruebas para verificar los cambios. En un proyecto propio también pueden importar las regresiones, la mantenibilidad y el tiempo de revisión humana. Un cambio que supera las pruebas disponibles todavía puede necesitar correcciones.
Las cifras publicadas por los fabricantes sirven para seleccionar qué probar, pero sus condiciones deben leerse juntas. DeepSeek utiliza Claude Code para Terminal-Bench 4.0. MiniMax indica Codex 0.149.1. Flint publica resultados de Terminal-Bench 2.1 con Terminus 2. El programa que organiza las herramientas, la versión de la prueba y el presupuesto de ejecución forman parte del resultado. No se puede deducir una clasificación homogénea copiando esas cifras en una columna.
Una evaluación propia debe registrar aciertos, consumo, duración e intervención humana, manteniendo las mismas tareas y reglas. Las herramientas de vLLM y SGLang ayudan a medir el servicio bajo carga. La distribución del modelo entre varios aceleradores añade comunicación entre dispositivos. Es posible mejorar el coste de una tarea aislada y empeorar la espera cuando varias personas utilizan el sistema a la vez.
La tendencia de octubre es diseñar alrededor del trabajo completo
La aportación más interesante del mes es la diversidad de formas de abordar un mismo problema. Los modelos abiertos permiten intervenir en el entrenamiento, en la precisión numérica, en el motor y en la organización de la aplicación. Los lanzamientos revisados muestran cómo esas decisiones pueden acercarse: entrenar para ejecutar mejor una tarea, servirla con menos memoria y reservar la generación de texto para los pasos que la necesitan.
Eso amplía el margen de decisión de quienes desarrollan agentes. Un equipo puede preferir un modelo local para ciertas tareas y uno compartido para trabajos más exigentes. Puede invertir el ahorro de memoria en atender más sesiones, o dedicar más razonamiento a un problema difícil. El criterio útil es qué combinación mejora los resultados dentro del tiempo, el presupuesto y la supervisión disponibles. Los anuncios permiten formular esas hipótesis. Su confirmación exige observar el uso real.
El acceso a los pesos hace posible fijar versiones y estudiar esas alternativas, pero sigue condicionado por la licencia y el software disponible. Tampoco todo anuncio supone una descarga inmediata. Kimi K3.1 Pro, anunciado el 23 de octubre, prometía publicar los pesos como tarde el 4 de noviembre. Al cierre de esta revisión seguía siendo una publicación pendiente.
En QDivZero hemos desarrollado un ejemplo de ese paso del modelo a una aplicación en la guía para desplegar DeepSeek V4.1 Flash 1017 y conectarlo a OpenCode. Explica cómo compartir el acceso con un equipo y comprobar la carga del servicio. Los despliegues de modelos y la API compatible con OpenAI permiten realizar esa integración. El caso concreta la pregunta que atraviesa este mes: qué hace falta para que una mejora del modelo se convierta en trabajo bien resuelto para quienes lo utilizan.
