Ivan Nikitin, director ejecutivo y cofundador de Fortytwo: serie de entrevistas

Ivan Nikitin es director ejecutivo y cofundador de Fortytwo, donde desarrolla tecnología de inferencia en enjambre que reúne varios modelos de IA para razonar y evaluar el trabajo de los demás. Su trayectoria abarca los videojuegos, la IA conversacional, la IA generativa y los sistemas interactivos en Temporal y Sensorium. En 2011 cofundó Temporal junto con Vlad Larin, ahora cofundador y director de tecnología de Fortytwo. Allí adquirió experiencia con poblaciones de agentes en evolución y sistemas que combinan modelos especializados.

Fortytwo desarrolla infraestructura de IA que permite a los modelos colaborar durante la inferencia. Su producto Fortytwo Engine utiliza un Swarm Decoder para dirigir un proceso de razonamiento compartido a medida que avanza, con el objetivo de mejorar la precisión y reducir la generación innecesaria de tokens en tareas largas. La empresa ofrece a los desarrolladores una API a través de Fortytwo Engine y la implementación local mediante Fortytwo Harbor.

Antes de cofundar Fortytwo, pasó años desarrollando productos relacionados con la IA conversacional, la IA generativa y los sistemas interactivos en Sensorium y Temporal. ¿Cómo influyeron esas experiencias en su visión de las limitaciones de los modelos individuales de lenguaje de gran tamaño y, en última instancia, lo llevaron al enfoque basado en enjambres que sustenta Fortytwo?

Una parte importante de nuestro equipo, y yo incluido, llegó a la IA a través de los videojuegos. Los videojuegos han sido la cuna de la informática personal y de la IA moderna: son la razón de que exista la GPU, y los juegos fueron el primer campo de pruebas serio para el aprendizaje por refuerzo. Sus mundos nos ofrecieron un entorno práctico para crear agentes capaces de aprender, adaptarse y competir. En Temporal, que cofundé en 2011 junto con Vlad Larin, ahora cofundador y director de tecnología de Fortytwo, empezamos trabajando con inteligencia en evolución: poblaciones de agentes que competían bajo presión selectiva. Nos interesaba cómo una población podía lograr más que un agente individual, siempre que existiera un buen mecanismo para identificar sus contribuciones más valiosas y desarrollarlas. La selección y la evaluación se convirtieron en aspectos centrales de nuestra manera de entender la inteligencia.

Cuando aparecieron los modelos transformer, ampliamos nuestro trabajo a la IA conversacional y creamos una plataforma de personajes impulsados por IA capaces de mantener conversaciones abiertas, sin guion, con memoria y personalidad. Esto ocurrió un par de años antes de ChatGPT, y los modelos con los que trabajábamos tenían ventanas de contexto de apenas 512 a 1.024 tokens. No era viable esperar que un único modelo de lenguaje de aquella época pudiera satisfacer de forma fiable todos los requisitos de esa experiencia. Tuvimos que crear una cadena de procesamiento personalizada con modelos especializados, cada uno con una responsabilidad más acotada, y la lógica necesaria para combinar sus aportaciones. Clasificar y seleccionar respuestas se volvió esencial para que toda la experiencia funcionara. Así aprendimos cuánto podía lograrse al combinar modelos limitados en un sistema bien diseñado.

La otra lección fue la eficiencia. Aprendimos que era posible entrenar y servir modelos especializados de forma más eficiente para tareas bien definidas, lo que nos permitía lograr más con recursos de computación limitados. Pero ampliar la inferencia seguía siendo un reto: por un lado, estaban los límites de uso de las API y, por otro, el coste de alojar los modelos por cuenta propia a gran escala. Sin acceso a capacidad de computación de vanguardia, tuvimos que pensar cuidadosamente cómo aprovechar mejor los recursos disponibles. Fortytwo reunió esas lecciones en la visión de la inferencia en enjambre: varios modelos, o varias instancias de un mismo modelo, contribuyen al razonamiento y, al mismo tiempo, evalúan el trabajo de sus pares. El resultado es que el conjunto es más preciso que cualquiera de sus integrantes.

Fortytwo Engine utiliza varios modelos de pesos abiertos para dirigir un único proceso de razonamiento y comprobar el trabajo de unos y otros mientras se genera la respuesta. ¿En qué se diferencia este enfoque de los sistemas multiagente convencionales, los conjuntos de modelos o la simple ejecución de varios modelos seguida de la selección de la mejor respuesta?

La diferencia clave es que la inferencia en enjambre está integrada directamente en el motor de inferencia que desarrollamos. Lo llamamos Swarm Decoder: varios modelos participantes dan forma continuamente a una única trayectoria de razonamiento mientras esta se genera. La evaluación y la dirección tienen lugar dentro de ese proceso, lo que permite que los modelos influyan en su rumbo antes de que la respuesta esté completa.

Las alternativas funcionan de otra manera. En los conjuntos de respuestas, los modelos generan respuestas independientes que después se clasifican, seleccionan o combinan. La arquitectura original de Fortytwo, implementada en 2025, clasificaba entre pares las respuestas ya completadas. Esto mejoró considerablemente la precisión, pero tuvo como coste una mayor latencia y más carga computacional. Muchos sistemas multiagente convencionales distribuyen el trabajo entre agentes y recurren a un orquestador y a mensajes en lenguaje natural para coordinar sus aportaciones. Esos intercambios pueden requerir llamadas de inferencia adicionales, repetir el contexto y tomar decisiones sobre qué información pasar de un agente a otro. En el Swarm Decoder no hay transferencias: los participantes trabajan sobre una única trayectoria y solo intercambian valoraciones sobre qué dirección es mejor.

El Swarm Decoder está diseñado para detectar supuestos débiles durante la generación, antes de invertir demasiado esfuerzo en desarrollarlos. El objetivo es reducir los errores, los retrocesos y la generación innecesaria; la eficiencia mejora cuando las comprobaciones evitan más trabajo del que añaden. Por eso tampoco hay penalización de latencia: la ejecución sigue una ruta más directa, de modo que Engine completa las tareas más rápido que el mismo modelo por sí solo y con menos tokens en total, contando todos los modelos participantes.

Has señalado que la desviación del modelo durante tareas prolongadas es un problema importante. ¿Qué provoca realmente esa desviación y cómo se manifiesta en aplicaciones prácticas como la ingeniería de software, la investigación o los agentes autónomos de IA?

La desviación se produce cuando el contexto de un modelo deja gradualmente de centrarse en la tarea. En una ejecución prolongada, el contexto se va llenando con las propias respuestas del modelo, los resultados de las herramientas, el contenido de los archivos y los intentos repetidos. La instrucción original ocupa una parte cada vez menor de aquello a lo que el modelo presta atención, y sus errores anteriores pasan a formar parte de la información a partir de la cual razona; así, los errores se acumulan en lugar de compensarse. Además, los modelos de razonamiento actuales se entrenan con aprendizaje por refuerzo para completar tareas, y aprenden atajos que parecen llevarlas a término: omitir la llamada a una herramienta, declarar que han tenido éxito o resumir en vez de comprobar. Lo llamamos pereza, y los modelos de frontera lo hacen tanto como los modelos de pesos abiertos. La causa de fondo es que un modelo por sí solo no tiene una verificación externa. Evalúa su propio trabajo, y los modelos no son buenos para reflexionar sobre sí mismos con precisión.

En ingeniería de software, se manifiesta cuando el agente corrige el error que describiste, pero incumple la restricción que mencionaste en el primer mensaje; escribe una prueba que se supera sin dificultad, o lee cuatro veces el mismo archivo porque ha perdido la cuenta de lo que ya averiguó. En investigación, se manifiesta en una ejecución prolongada que se aleja de la pregunta que planteaste y pasa a responder la que resulta más fácil, para luego ofrecer un resumen genérico. En los agentes autónomos, adopta la forma más costosa: desviaciones, llamadas repetidas a herramientas, retrocesos y un gasto de tokens varias veces superior al necesario para la tarea.

Podemos cuantificarlo. Ejecutamos Qwen 3.8 27B en 450 tareas de DeepSWE, trabajo real de ingeniería de software con uso de herramientas y contextos prolongados, tanto de forma independiente como a través de Fortytwo Engine. Por sí solo, el modelo promedió 16,3 millones de tokens por ejecución, 7.400 millones en total. A través de Engine, el mismo modelo promedió 12,3 millones de tokens por ejecución, 5.600 millones en total: un 24,7 % menos. Además, resolvió más tareas: un 47,8 % frente a un 42,2 %. El modelo no cambió en absoluto. Los cuatro millones de tokens por ejecución que se ahorraron eran desviación: volver a leer, repetir intentos y retroceder, algo que un modelo por sí solo tiene que hacer porque nadie detecta sus pasos en falso mientras los da. El enjambre los detecta, así que no tiene que pagar ese coste.

Antes, Fortytwo hacía que los modelos evaluaran las respuestas completas de los demás, mientras que la arquitectura actual les permite influir en el proceso de razonamiento mientras este se genera. ¿Qué aprendieron del enfoque anterior y por qué resulta más eficaz orientar el proceso en tiempo real?

La arquitectura de 2025 demostró que podemos alcanzar capacidades propias de los modelos de frontera mediante el escalado horizontal: incorporando más modelos participantes, en lugar de perseguir el más grande. Un enjambre de modelos de pesos abiertos que clasificaba las respuestas completas de los demás superó hasta en 17 puntos porcentuales al mejor modelo individual del enjambre, y fue más robusto en situaciones en las que un solo modelo no lo es: ante instrucciones imprecisas, instrucciones inyectadas y una mayoría de respuestas incorrectas.

Lo que esa arquitectura no podía hacer era intervenir. Clasificar respuestas completas funciona para una sola pregunta, pero las ejecuciones de agentes constan de cientos de pasos, con llamadas a herramientas entre ellos, y los errores decisivos se producen al principio y se acumulan. Si se evalúa al final, todos los modelos ya han pagado el coste total de los tokens, y el evaluador solo puede elegir entre trayectorias que ya han divergido. Además, el coste del enjambre aumentaba con el número de modelos, algo aceptable para una pregunta difícil, pero inadecuado para un agente de programación.

La orientación en tiempo real resuelve ambos problemas. La clasificación continua aplica una presión selectiva durante toda la ejecución, de modo que se corrige un paso en falso allí donde se produce, antes de que se propague. El enjambre nunca se conforma con un intento poco riguroso, porque uno así queda por debajo de otro más cuidadoso en la clasificación. Por eso, ahora el mismo mecanismo nos permite alcanzar a la vez una mayor precisión y usar menos tokens.

En las pruebas con Qwen 3.8 27B, Fortytwo informa de que usó un 24,7 % menos de tokens en 450 ejecuciones de DeepSWE y mejoró los resultados en seis pruebas de referencia. ¿Qué ocurre dentro del enjambre para que pueda mejorar el rendimiento y, al mismo tiempo, reducir el consumo de tokens?

La verificación del enjambre tiene un coste pequeño y fijo; el trabajo de recuperación que evita aumenta con la duración de la tarea, porque cada paso en falso que no se corrige pone en riesgo todo lo que se construye a partir de él. Por eso, cuanto más larga es la tarea, más se puede ahorrar. DeepSWE se sitúa en el extremo de las tareas más largas de ese espectro, lo que explica que el ahorro alcance casi una cuarta parte del total de tokens.

En cuanto a la precisión, el problema es que la inteligencia presenta un rendimiento desigual. Las mejoras de los modelos suelen ser irregulares: pueden alcanzar un razonamiento de nivel doctoral en un ámbito y producir disparates absolutos en otro, porque el ajuste fino, el aprendizaje por refuerzo (RL) y otros métodos de posentrenamiento mejoran el modelo con los datos con los que se entrenó, y las mejoras disminuyen a medida que las tareas reales se alejan de esos datos. Swarm Decoder no modifica el modelo. Mejora el razonamiento en sí de manera constante, así que las seis pruebas de referencia no son seis ámbitos para los que hayamos optimizado el sistema, sino seis lugares en los que medimos lo mismo. En conjunto, el modelo es más inteligente y presta más atención; además, al contar con compañeros que verifican cada paso, da la impresión de que dedica mucho más esfuerzo a tu tarea. Por eso también podemos ofrecer Engine al mismo precio por token que el modelo base: el cliente no paga por un presupuesto mayor, sino por una ruta más corta hasta la respuesta correcta.

Los desarrolladores de IA están cada vez más preocupados por los costos de inferencia, ya que los modelos de razonamiento generan cadenas de tokens más largas. ¿Crees que mejorar la eficiencia del propio proceso de razonamiento podría llegar a ser tan importante como hacer que los modelos individuales sean más pequeños, rápidos o económicos?

Sí, y diría que ya es la palanca más importante. Hacer que los modelos sean más pequeños, rápidos y económicos reduce el precio de cada token. Pero nadie compra tokens: compra una tarea terminada. Y, en la era de los agentes, la cantidad de tokens por tarea se ha disparado: un modelo de razonamiento que trabaja en una tarea real de programación consume millones de tokens, y una gran parte se destina a volver sobre sus pasos. Reducir en un 25 % los tokens por tarea vale exactamente lo mismo que una rebaja del 25 % en el precio, pero además se suma a cada mejora en hardware, cuantización y kernels, y podemos aplicar esto a cualquier modelo de pesos abiertos disponible en el mercado.

La industria cuenta con tres palancas. Mejores modelos, lo que implica entrenamiento y resulta caro. Tokens más baratos, lo que depende del hardware y la prestación del servicio, y cuyos costos están convergiendo porque todo el mundo tiene las mismas GPU. Y menos tokens por tarea, lo que depende de cómo se ejecuta la inferencia y apenas se ha explorado. Hasta ahora, escalar ha significado crear modelos más grandes y cadenas de pensamiento más largas, y ambas cosas exigen que un solo modelo lo haga todo en una única trayectoria. Creemos que el siguiente eje es colectivo: varios modelos que razonan juntos, con el juicio distribuido entre ellos, para que la trayectoria en sí sea más corta y fiable. Se trata de una forma de escalado distinta de aumentar los parámetros o la computación en tiempo de prueba, y es por la que apostamos. Lo concebimos como priorizar a los pares por encima de los parámetros.

Fortytwo Engine es compatible con la API de OpenAI y ejecuta modelos de pesos abiertos. ¿Qué importancia tuvo la compatibilidad con las pilas de desarrollo de IA existentes y con qué facilidad pueden los desarrolladores trasladar una aplicación de una API convencional de un solo modelo a una arquitectura de enjambre?

La compatibilidad es esencial. El ecosistema de agentes —agentes de programación, entornos de ejecución, marcos de trabajo y herramientas de evaluación— se basa en el formato de la API de OpenAI. Así que, para los desarrolladores que usan Fortytwo Engine, cambiar es como pasar de un proveedor de inferencia a otro: en una aplicación, un agente, un entorno de ejecución o un servicio compatible, normalmente basta con modificar una sola configuración: el punto de conexión, la clave de API y la selección del modelo.

Lo que cambia es el comportamiento, no la integración. La diferencia se nota en las ejecuciones largas de agentes, donde el consumo de tokens y la precisión en el primer intento determinan el costo: con el mismo modelo, a través de Fortytwo Engine, las tareas se completan más rápido, con menos tokens y con más aciertos. Mi consejo es tratarlo como cualquier cambio de modelo: ejecuta la evaluación que ya usas con tu agente, compara los tokens por tarea y la tasa de éxito, y quédate con la opción que dé mejores resultados.

Gracias por esta excelente entrevista. Los lectores que deseen explorar la inferencia mediante enjambres y cómo la evaluación entre pares puede mejorar la eficiencia del razonamiento pueden visitar Fortytwo.