Flint es un modelo de código gratuito para portátil que acaba de publicar Recursive, una startup fundada el año pasado. Se distribuye bajo licencia Apache 2.0, se ejecuta en local y, según la empresa, se construyó en buena parte con ayuda de su sistema de investigación automatizado, llamado Eureka Machine. Para desarrolladores y empresas, la promesa es concreta: trabajar sin conexión, mantener el código en casa y no pagar por uso. La propia compañía admite un peaje: necesita más guía que los asistentes de pago.
Flint, un modelo de código gratuito para portátil: qué ha publicado Recursive
Recursive ha lanzado Flint como un modelo de generación de código con licencia Apache 2.0, una de las licencias abiertas más permisivas del sector. En la práctica, eso significa que una empresa puede descargarlo, usarlo y integrarlo en sus propios flujos de trabajo sin pagar por cada petición ni depender de una API externa. Según la compañía, el modelo está pensado para ejecutarse directamente en un ordenador portátil, sin necesidad de enviar el código a un servidor ajeno.
Los datos técnicos que ha dado Recursive son estos: Flint es un modelo MoE (mixture of experts) que activa 2.500 millones de sus 40.000 millones de parámetros en cada paso. En las pruebas de la propia empresa, genera unos 131 tokens por segundo en un MacBook Pro con chip M4 Pro. Los modelos similares con los que lo compara se quedan entre 58 y 69 tokens por segundo. Son cifras de la propia Recursive, no de una evaluación independiente, y conviene leerlas con esa cautela.
El otro dato llamativo es el origen. Recursive afirma que Flint se desarrolló en gran parte con Eureka Machine, su sistema de investigación automatizado. La empresa no es la primera en usar IA para acelerar el desarrollo de IA, pero sí presenta este modelo como un caso práctico de ese enfoque. Es una afirmación de la compañía, y por ahora no hay detalles verificables sobre qué parte del trabajo hizo la máquina y cuál las personas.
Implicaciones técnicas de un modelo de código gratuito para portátil
La arquitectura MoE explica buena parte de la velocidad que reclama Recursive. En un modelo de este tipo, solo una fracción de los parámetros trabaja para generar cada token. En Flint son 2.500 millones activos de un total de 40.000 millones, es decir, un porcentaje pequeño. Eso reduce el cálculo necesario por token y, por tanto, permite una generación más rápida en hardware modesto. Es la razón por la que un portátil puede dar 131 tokens por segundo donde otros modelos de tamaño comparable no pasan de 69.
Hay un matiz que todo equipo técnico debería comprobar antes de entusiasmarse. Que se activen pocos parámetros no significa que el modelo entero deje de ocupar memoria: los 40.000 millones siguen existiendo. La información de Recursive no detalla los requisitos de memoria, así que cualquier equipo que quiera probarlo debe verificar qué versión descarga y si su máquina la soporta con holgura. Una cifra de velocidad sin ese dato es una medición incompleta.
La segunda implicación tiene que ver con la calidad. Recursive reconoce que Flint requiere más guía que los asistentes de pago. Traducido: instrucciones más precisas, más contexto aportado por el usuario y más revisión del resultado. Un asistente comercial suele tolerar peticiones vagas mejor que un modelo local ligero. Esa diferencia es el precio real de la gratuidad y de la privacidad, y la empresa tiene el mérito de no ocultarla.
Por último, está el argumento de la licencia. Apache 2.0 permite uso comercial, modificación y redistribución, con unas condiciones mínimas. Para un departamento legal, eso simplifica mucho la decisión frente a licencias con restricciones de uso. No elimina la necesidad de revisar el texto completo, pero despeja uno de los frenos habituales a la hora de adoptar un modelo abierto en una empresa.
Como pueden aplicar esto las empresas hoy
Lo más sensato es tratar a Flint como un experimento acotado, no como un reemplazo inmediato del asistente de pago que ya use el equipo. Un modelo de código gratuito para portátil tiene sentido sobre todo en tres situaciones: código que no debe salir de la empresa por contrato o por política interna, trabajo sin conexión y equipos que quieren eliminar el coste variable por uso.
Un plan razonable sería este. Primero, elegir a dos o tres desarrolladores y una tarea repetitiva, como generar tests, documentar funciones o refactorizar módulos pequeños. Segundo, medir en sus propios equipos la velocidad real y la memoria que consume, sin fiarse solo de las cifras de Recursive. Tercero, comparar la calidad del resultado con el asistente actual y anotar cuánto tiempo extra cuesta guiar al modelo. Si ese tiempo extra se come el ahorro, la cuenta no sale, por muy gratuita que sea la licencia.
Conviene evitar dos errores. El primero es suponer que gratis significa sin coste: el tiempo de revisión y la formación del equipo en cómo pedir las cosas también cuestan. El segundo es dar por buenas las comparativas de velocidad del fabricante. Para una PYME con pocos desarrolladores, la ventaja más tangible probablemente sea la privacidad del código y la previsibilidad del gasto, no la rapidez bruta.
Analisis Blixel
Lo más interesante de este lanzamiento no es la velocidad, sino la honestidad del trade-off. Una empresa que admite que su modelo exige más guía que los asistentes de pago está diciendo algo que el sector suele callar: la IA local no es una versión barata de la IA en la nube, es otra herramienta con otras reglas. Quien la adopte esperando lo mismo por cero euros se llevará una decepción. Quien la adopte sabiendo que cambia coste por esfuerzo de supervisión puede salir ganando.
Sobre la parte de Eureka Machine, prudencia. Que un modelo se haya construido en gran parte con IA es un titular atractivo, pero hoy es una afirmación de la empresa sin desglose. No es motivo para descartarlo, pero tampoco para tomarlo como prueba de que la investigación automatizada ya funciona a escala. Lo que sí es verificable es que Flint se puede descargar, probar y medir.
Mi posición es clara: un modelo de código gratuito para portátil merece una prueba seria en cualquier equipo que maneje código sensible o quiera controlar su factura. No merece una migración masiva basada en una tabla de benchmarks publicada por quien vende el producto. Haced la prueba con vuestro propio código, en vuestras propias máquinas y con una métrica simple: cuánto tiempo ahorra una tarea real una vez descontada la revisión. Si el resultado es positivo, tendréis una herramienta útil y sin dependencia de terceros. Si no, habréis gastado una tarde y sabréis con datos por qué no.
Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.