Una tarjeta de título generada que dice Recursive Flint 40B-A2.5B, con paneles que indican 39,8 mil millones de parámetros en total y alrededor de 2,5 mil millones activos por token, un contexto de 262.144 tokens que comparten el prompt y la salida, pesos Apache 2.0 publicados por primera vez el 21 de octubre de 2026, cuantización NVFP4 a menos de 0,7 puntos del modelo de 16 bits, y más de 125 tokens por segundo en un MacBook Pro con M4 Pro. Un pie de página señala que cada resultado de benchmark y cada cifra de rendimiento mostrados son reportados por Recursive y no han sido reproducidos de forma independiente, y que los tamaños de archivo se midieron a partir de los repositorios publicados en Hugging Face.
Guides & Insights

Recursive Flint 40B-A2.5B: un modelo de programación diseñado para ser rápido ante todo

Autor

Alistair Wren

Fecha de publicación

Últimos modelos · 20Ver todos los modelos →
Benchmarks: Artificial Analysis · actualizado a diario
Volver a todas las publicaciones

El número que decide si Recursive Flint 40B-A2.5B merece tu espacio en disco no es 54,9 %. Es 2,5. El primer modelo de codificación de pesos abiertos de Recursive tiene 39.800 millones de parámetros y activa aproximadamente 2.500 millones de ellos por cada token que escribe, y casi todas las demás decisiones del lanzamiento —la disposición de atención, la receta de cuantización, el kernel Metal personalizado, el motor de inferencia— derivan de esa única proporción. Flint se lanzó el 21 de octubre de 2026 bajo Apache 2.0, lo que lo convierte en un modelo de un día de antigüedad en el momento de escribir esto y dentro de la ventana en la que un lanzamiento todavía es noticia y no historia. Como una tabla de benchmarks de un día es una promesa más que una medición, llevamos el registro de producción por separado: el AI Incident Archive registra cómo han resistido las afirmaciones de modelos y proveedores una vez que atienden tráfico real.

La versión breve para quien esté decidiendo ahora mismo: es un modelo disperso de mezcla de expertos diseñado para ser lo más rápido de su categoría en un portátil, publica tres puntuaciones de programación agéntica que están todas reportadas por el proveedor y no han sido reproducidas, y es el primer modelo de una empresa cuyo propósito declarado es automatizar la investigación que construye modelos. Los tres hechos importan, y el tercero es el que seguirá siendo interesante dentro de un año.

Lo que realmente se envió

Cuatro repositorios, no uno. El principal RecursiveSI/flint aloja el checkpoint BF16, la configuración, el tokenizador, la plantilla de chat y un kit de servicio SGLang, y se creó el 21 de octubre de 2026 a las 14:20 UTC. Junto a él hay tres variantes cuantizadas, todas con fecha de esa misma tarde: una compilación int4 en safetensors, un GGUF int4 y un GGUF NVFP4. Todos los tamaños siguientes se midieron a partir de los listados de archivos de los propios repositorios, en lugar de citarse del anuncio.

• Referencia BF16: 79,59 GB en 37 archivos, en 15 fragmentos de safetensors de aproximadamente 5,37 GB cada uno. Este es el artefacto de ajuste fino y el que no querrás descargar para inferencia.

• NVFP4 GGUF — 22,86 GB en un solo archivo, la compilación de inferencia completa más pequeña publicada.

• Int4 GGUF — 25,99 GB, una cuantización q4_1 que es más grande que el archivo NVFP4, lo que invierte el orden de los nombres y vale la pena saberlo antes de elegir por nombre de archivo.

• safetensors Int4 — 22,58GB, para runtimes que prefieren pesos fragmentados en lugar de un único GGUF.

La licencia es Apache 2.0, y la model card añade la distinción de que los términos de la API alojada y las prácticas de datos son independientes de la licencia de los pesos: la separación habitual, expresada con claridad en lugar de quedar enterrada.

A screenshot of the Recursive Flint model card on Hugging Face, showing the repository name RecursiveSI/flint, the apache-2.0 licence label, the Recursive Flint heading, the description of a mixture-of-experts coding model with 39.8 billion total parameters and approximately 2.5 billion active per token covering codebase investigation, bug fixing, feature work and tests, the sentence quoting release evaluation scores of 54.9 percent on Terminal-Bench 2.1, 89.7 percent on SWE-bench Pro v2 and 74.2 percent on SWE-bench Verified, the list of what the repository contains including the BF16 checkpoint and an SGLang serving kit, and the evaluation protocol paragraph naming temperature 1.0, top-p 0.95, top-k 20, the Terminus 2 and mini-swe-agent harnesses, average pass@1 over at least five attempts, and the note that Terminal-Bench counts solutions obtained through web retrieval as unsuccessful.

La arquitectura es un argumento sobre el ancho de banda de memoria.

En un portátil, decodificar un token no es principalmente un problema de cómputo. Es un problema de mover los pesos desde la memoria a las unidades aritméticas con la suficiente rapidez, y por eso un modelo denso de 40 mil millones de parámetros es lento por bueno que sea el chip: cada token lee todos los pesos. La respuesta de Flint es leer casi ninguno de ellos.

• Esparsidad — 256 expertos enrutados por capa MoE, con 6 seleccionados por token, más un experto compartido siempre activo. De las 49 capas, 2 son densas y 47 son MoE, por lo que todas excepto las dos primeras realizan trabajo condicional.

• Parámetros activos: 39,8B en total, aproximadamente 2,5B activos por token contando la cabeza de salida, que es de donde proviene la designación «40B-A2.5B». El cuerpo activo por sí solo es de unos 2,2B.

• Atención — 35 capas de ventana deslizante con una ventana de 513 tokens (el token actual más los 512 anteriores) intercaladas con 14 capas de atención completa. Solo 32 cabezas de consulta y 4 cabezas de clave-valor, con una dimensión de cabeza de 128, para que la caché KV se mantenga lo bastante pequeña como para hacer prácticas las sesiones largas de agentes.

• Codificación posicional: embeddings rotatorios en las capas de ventana deslizante y ninguno en absoluto en las capas de atención completa, una elección que la tarjeta del modelo indica sin explicar. La RMSNorm QK por cabeza y los sumideros de atención aprendidos por cabeza están haciendo el trabajo de estabilidad que normalmente comparte la codificación posicional.

• Contexto — 262.144 tokens documentados, y la ficha del modelo especifica explícitamente que esto abarca el prompt y la salida generada en conjunto. El anuncio promociona "hasta 512k" y luego recomienda mantenerse dentro de 256k para programación. Ambas afirmaciones provienen del mismo proveedor, con un párrafo de diferencia.

El detalle interesante es cómo se eligió la forma. Recursive dice que su Eureka Machine —un bucle de investigación automatizado que propone ideas, las implementa, las prueba y combina lo que funciona— partió de una línea base de 35 mil millones de parámetros con 3 mil millones activos y buscó entre configuraciones de expertos y anchuras. La configuración 40B/2.5B resultante estaba, según la propia formulación del anuncio, "proyectada para ofrecer la mejor combinación de velocidad y rendimiento de programación entre las configuraciones que probó nuestra Eureka Machine". Proyectada, no demostrada mediante una comparativa directa de modelos terminados. Es una forma normal de elegir una arquitectura cuando las ejecuciones de entrenamiento son caras, y también es una afirmación que un checkpoint posterior podría contradecir silenciosamente.

Las tres puntuaciones y las notas al pie que las acompañan.

Flint obtiene un 54,9 % en Terminal-Bench 2.1, un 89,7 % en SWE-bench Pro v2 y un 74,2 % en SWE-bench Verified. Esas cifras aparecen en la ficha del modelo como evaluaciones de lanzamiento, y ningún tercero ha publicado una medición de este modelo: el índice de modelos de Artificial Analysis, el árbitro independiente habitual para un lanzamiento como este, no tiene ninguna entrada de Flint a fecha de 22 de octubre. Así que todo lo que sigue es Recursive midiendo a Recursive.

Lo que el proveedor sí revela sobre su propia metodología es más de lo que la mayoría de las publicaciones de lanzamiento ofrecen voluntariamente, y cambia cómo deberían interpretarse las cifras:

• Terminal-Bench 2.1 — ejecutado con el arnés Terminus 2, con acceso a internet habilitado, y las soluciones obtenidas mediante recuperación web se contaron como fallos. Ese último ajuste es una desventaja deliberada, y la ficha del modelo señala que las puntuaciones publicadas por otros desarrolladores pueden no aplicarlo, lo que hace que una comparación equivalente con cifras de terceros sea más difícil, no más fácil.

• SWE-bench Pro v2 y SWE-bench Verified — ejecutados con mini-swe-agent y sin acceso a internet en absoluto, un entorno más difícil que el de los agentes que pueden buscar documentación durante la tarea.

• Intentos y tiempos de espera: pass@1 promedio en al menos cinco intentos, con tiempos de espera del agente de hasta cinco horas. Promediar cinco intentos es un protocolo razonable; unos tiempos de espera de cinco horas significan que estas son puntuaciones de un agente que estás dispuesto a dejar ejecutándose, no de un autocompletado.

• Muestreo — temperatura 1.0, top-p 0.95, top-k 20 en todas las evaluaciones, y el kit de servicio aplica esos valores predeterminados cuando una solicitud los omite.

La tabla de benchmarks de un proveedor también es una declaración sobre qué competidores eligió. El propio gráfico de Recursive compara Flint con Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer y Gemma 4 —modelos locales que encajan en hardware similar, que es el grupo de comparación honesto para un modelo de portátil y también un grupo seleccionado para hacer que el argumento de la dispersión se vea bien. La afirmación que se hace es limitada y defendible: Flint lidera los modelos MoE de menos de 50 mil millones de parámetros totales en programación agéntica, y rivaliza con modelos densos de entre 25 y 40 mil millones mientras se ejecuta mucho más rápido. No es una afirmación sobre modelos de programación de frontera, y Recursive no hace ninguna: el anuncio dice directamente que Flint «puede necesitar más orientación que los modelos de programación de código cerrado más grandes a los que estás acostumbrado».

Velocidad: contra qué se mide realmente el 2×

Recursive reporta más de 125 tokens por segundo en un MacBook Pro con M4 Pro y más de 150 tokens por segundo en un NVIDIA RTX Spark de 64 GB en contextos cortos, y lo describe como hasta el doble de rápido que modelos comparables y más de cinco veces más rápido que modelos densos de 25 a 40 mil millones de parámetros con puntuaciones de programación similares. La nota al pie de la metodología del gráfico de velocidad es la parte que vale la pena leer: promedio de tokens por segundo a lo largo de una sesión de 128.000 tokens, excluido el prefill, con un competidor medido a 124k en lugar de la longitud completa.

Excluir el prefill es una práctica estándar para el benchmarking de decodificación y sigue siendo relevante aquí, porque el prefill es exactamente donde un agente de programación pasa su tiempo cuando vuelca un repositorio en la ventana de contexto. Una cifra que solo mide la mitad de decodificación de una sesión de 128k favorecerá a cualquier modelo con activación dispersa, y todo el diseño de Flint se basa en la activación dispersa. Nada de eso hace que la cifra sea incorrecta. La convierte en una cifra de decodificación, y debería compararse con otras cifras de decodificación en lugar de con cuánto tarda tu agente en terminar una tarea.

A screenshot of Recursive's Introducing Flint announcement page, showing the breadcrumb Updates over Introducing Flint, the headline Introducing Flint, and the subtitle calling it a local model with the fastest inference and strongest coding performance in its class, built with automated research. Below it the opening paragraph introduces Recursive Flint as a mixture-of-experts model with 40 billion total parameters that activates just 2.5 billion per token, built from scratch in under four months. The next paragraph claims it leads mixture-of-experts models under 50 billion total parameters on SWE-Bench Pro v2, Terminal-Bench 2.1 and SWE-Bench Verified while running more than five times faster than dense models of 25 to 40 billion parameters, then a sentence states that with the optimized inference engine it generates more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB NVIDIA RTX Spark at short contexts, up to twice as fast as comparable models. The final paragraph describes the release as a practical test of Recursive's Eureka Machine, the automated research system that helped develop nearly every part of the model-building stack.

La receta de cuantización es la parte más transferible

La mayoría de los artículos sobre cuantización tratan sobre cuánta precisión se perdió. Este trata sobre una decisión que fue en dirección opuesta a la convención.

Recursive cuantizó la capa de salida —el lm_head— a 4 bits. Eso va contra la práctica común, y la razón es específica de los modelos dispersos: con solo 2500 millones de parámetros activos, la capa de salida representa una gran proporción de los pesos que se leen para cada token, así que dejarla en 16 bits limita la velocidad máxima a la que puede llegar el modelo. Recuperar la precisión exigió una etapa de destilación offline en la que el modelo cuantizado se entrena con sus propias respuestas premuestreadas de un coreset que descubrió por sí mismo, con el modelo de 16 bits como profesor — una configuración que, según Recursive, casi redujo a la mitad los pasos de entrenamiento frente a su línea base de entrenamiento consciente de la cuantización.

El resultado publicado es que el modelo NVFP4 final obtiene una puntuación a menos de 0,7 puntos del modelo de 16 bits en el conjunto de pruebas comparativas. Esa es una afirmación del proveedor, y es el tipo de afirmación que es fácil de comprobar más adelante y costosa de falsificar, lo que la convierte en una afirmación útil para exigirles responsabilidad. La consecuencia práctica son los tamaños de archivo anteriores: una descarga de 22,86 GB que ejecuta un modelo de 39,8 mil millones de parámetros en una máquina con 48 GB de memoria unificada.

En Apple Silicon hay una segunda capa. Eureka Machine, de Recursive, produjo kernels especializados para proyecciones de baja precisión, operaciones de MoE, atención y procesamiento de prompts, incluido un megakernel de Metal que fusiona todo el forward pass de decodificación en un único dispatch en los chips M4 y M5. Fusionar el pase de decodificación es el tipo de optimización que solo compensa cuando se controlan a la vez la arquitectura del modelo, el formato de cuantización y el kernel, que es la verdadera tesis de este lanzamiento, más que cualquier cifra de benchmark concreta.

Cómo lo ejecutas y cuánto te cuesta cada camino

Hay dos historias de implementación distintas y no son intercambiables.

• GPU de servidor: el checkpoint BF16 se entrega con un kit de servicio SGLang destinado a una B300 o una H200 por réplica, expone un endpoint compatible con OpenAI en el puerto 30000 con el nombre de modelo flint, e incluye un cliente de ejemplo para razonamiento y llamadas a herramientas. Esta es la única vía compatible para los pesos de precisión completa; la ficha del modelo indica claramente que el código de modelado de Transformers aún no está incluido.

• Máquinas locales — llama.cpp, Ollama, Unsloth, LM Studio, vLLM y SGLang se mencionan todos como compatibles, lo cual es inusualmente amplio para un modelo del día de lanzamiento y marca la diferencia entre un checkpoint y un artefacto utilizable.

• El rec motor — el propio motor de inferencia de Recursive, instalado en ~/.local/bin, requiere un M4 Pro, M5 Pro o M5 Max con al menos 48 GB de memoria unificada y unos 30 GB de disco libre, y expone localmente una API compatible con OpenAI. Su README afirma un rendimiento en tokens de entre 1,4× y 2,6× el de llama.cpp en un M4 Pro con pesos de 4 bits, en prompts de entre 1.000 y 252.000 tokens con 1.024 tokens de salida, cinco ejecuciones por longitud de contexto y sin incluir el prefill. Está optimizado explícitamente para el uso en una sola sesión; si ejecutas varios agentes a la vez, la documentación te remite a otra opción.

Notas prácticas que deciden si una sesión va bien: la ventana de contexto se comparte entre el prompt y la salida, los problemas difíciles requieren un presupuesto de salida de al menos 32,768 tokens, incluido el razonamiento, y el reasoning_content devuelto debe conservarse en el historial de conversación, o el uso de herramientas multiturno se degrada. La propia guía de Recursive para tareas complejas consiste en dividir el trabajo en subtareas más pequeñas con instrucciones explícitas, un consejo honesto que también se lee como una descripción del techo del modelo.

¿Qué es lo que realmente no está demostrado?

Tres cosas, en orden descendente según cuánto deberían influir en una decisión.

La primera es la medición independiente. No existe ninguna. No una puntuación baja en una tabla de clasificación, ni una discutida: aún no existe ninguna evaluación de Flint por parte de terceros, y las únicas cifras que circulan son las del proveedor, producidas con las decisiones del proveedor sobre el arnés de pruebas y su ajuste para la recuperación web. La metodología se divulga lo suficientemente bien como para ser auditada, que es lo máximo que se puede pedir el primer día, pero que se divulgue no significa que esté verificada.

El segundo es si un modelo de 2.500 millones de parámetros activos está a la altura del trabajo de horizonte largo para el que realmente sirven los agentes de programación. El protocolo del benchmark permite cinco intentos y tiempos de espera de cinco horas, lo que constituye un margen generoso; un modelo que necesita varios intentos y una correa larga puede registrar un buen pass@1 y, aun así, sentirse poco fiable en un editor. La propia advertencia de Recursive sobre que necesita más orientación que modelos cerrados más grandes apunta a lo mismo.

La tercera es la propia búsqueda de arquitectura. Una configuración proyectada como la mejor entre las que probó un sistema automatizado es una hipótesis sobre una ejecución de entrenamiento, no un resultado sobre un modelo terminado. Si la proyección de Eureka Machine era correcta, esta es una plantilla que otros equipos pequeños copiarán. Si era aproximadamente correcta, el siguiente checkpoint se mueve y la proporción cambia.

Dónde encaja esto si tu stack de agentes solo es parcialmente local

La razón por la que un modelo como Flint importa es que elimina una línea de una factura, no todas. La inferencia local se encarga del trabajo que puedes ejecutar en tu propia máquina y no hace nada por el trabajo que no puedes — el trabajo de contexto largo que no cabe, la ráfaga que supera a un solo portátil, la tarea en la que un modelo más grande simplemente es mejor. Eso deja a la mayoría de los equipos ejecutando dos sistemas.

OrcaRouter es la mitad alojada de ese arreglo y, para dejar claro el límite: no servimos Flint, y nada en este texto es una promoción de un checkpoint que alojemos nosotros. Flint es una descarga de Recursive, no un endpoint nuestro. Lo que hacemos es poner una única API delante de más de 200 modelos alojados al precio de lista del propio proveedor, sin ningún margen añadido, enrutar entre ellos con una cadena de fallback basada en configuración y conmutar automáticamente en caso de fallo cuando un proveedor empieza a fallar a mitad de una petición. Si quieres comparar lo que vale una ejecución local de Flint frente a un modelo de mezcla de expertos alojado de tamaño similar —Qwen3.6-35B-A3B y Gemma 4 26B-A4B se pueden invocar con esa misma clave—, la comparación cuesta una petición en lugar de un despliegue.

La lectura razonable

Flint es un lanzamiento real con un centro de gravedad específico e inusual. Recursive no lanzó el modelo de programación más potente que podría haber creado; lanzó el más rápido que pudo construir con un tamaño que cabe en un portátil, y luego publicó una pila de cuantización y kernels diseñada para que esa ventaja sobreviva al contacto con pesos de 4 bits. El 54,9 % en Terminal-Bench 2.1 y el 89,7 % en SWE-bench Pro v2 son cifras sólidas para un modelo disperso de 40 mil millones de parámetros y, por ahora, son solo las cifras del proveedor.

Lo que hace que valga la pena seguirlo en lugar de simplemente descargarlo es el método que hay detrás. Un equipo que afirma que un bucle automatizado de investigación eligió la arquitectura, la receta de cuantización y los kernels está haciendo una afirmación sobre un proceso, no sobre un modelo, y los procesos son verificables de una manera en que los benchmarks de lanzamiento no lo son: la siguiente versión o llega más rápido y mejor, o no llega. Flint es el primer dato de ese argumento, publicado bajo una licencia lo bastante permisiva como para que cualquiera pueda comprobar los pesos por sí mismo.

Si tienes 48 GB de memoria unificada y una máquina Apple Silicon, el coste de averiguarlo es una descarga de 22,86 GB y una tarde. Si no es así, lo honesto es esperar a la primera evaluación independiente, porque una tabla de benchmarks de un día de antigüedad es una promesa, no una medición.

A generated single-column scoreboard titled Recursive Flint 40B-A2.5B, listing parameters 39.8 billion total and about 2.5 billion active per token, architecture as a 256-expert mixture of experts selecting 6 per token across 47 MoE layers and 2 dense layers, context 262,144 tokens shared between prompt and output, published weights of 79.59 gigabytes in BF16 and 22.86 gigabytes as an NVFP4 GGUF, throughput of more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB RTX Spark, vendor-reported scores of 54.9 percent on Terminal-Bench 2.1, 89.7 percent on SWE-bench Pro v2 and 74.2 percent on SWE-bench Verified, independent score not available, licence Apache 2.0, and price zero for local use with no hosted endpoint from OrcaRouter. A footer states that the benchmarks and throughput are reported by Recursive and not independently reproduced, and that the file sizes were measured from the published repositories.