Ivan Nikitin, CEO e cofundador da Fortytwo – Série de entrevistas

Ivan Nikitin é CEO e cofundador da Fortytwo, onde desenvolve uma tecnologia de inferência em enxame que reúne vários modelos de IA para raciocinar e avaliar o trabalho uns dos outros. Sua trajetória abrange jogos, IA conversacional, IA generativa e sistemas interativos na Temporal e na Sensorium. Em 2011, cofundou a Temporal com Vlad Larin, hoje cofundador e CTO da Fortytwo, adquirindo experiência com populações de agentes em evolução e sistemas que combinam modelos especializados.

Fortytwo desenvolve infraestrutura de IA que permite aos modelos colaborar durante a inferência. Seu Fortytwo Engine usa um Swarm Decoder para orientar um processo compartilhado de raciocínio à medida que ele se desenrola, com o objetivo de melhorar a precisão e reduzir a geração desnecessária de tokens em tarefas longas. A empresa oferece uma API para desenvolvedores por meio do Fortytwo Engine e implantação local por meio do Fortytwo Harbor.

Antes de cofundar a Fortytwo, você passou anos desenvolvendo produtos de IA conversacional, IA generativa e sistemas interativos na Sensorium e na Temporal. Como essas experiências moldaram sua visão sobre as limitações dos modelos individuais de linguagem de grande porte e, por fim, levaram à abordagem baseada em enxames por trás da Fortytwo?

Uma grande parte da nossa equipe, inclusive eu, chegou à IA por meio dos jogos. Os jogos foram o berço da computação pessoal e da IA moderna: são a razão da existência das GPUs, e os jogos foram o primeiro campo de teste sério para o aprendizado por reforço. Os mundos dos jogos nos proporcionaram um ambiente prático para desenvolver agentes capazes de aprender, se adaptar e competir. Na Temporal, que cofundiei em 2011 com Vlad Larin, hoje cofundador e CTO da Fortytwo, começamos trabalhando com inteligência em evolução: populações de agentes competindo sob pressão seletiva. Queríamos entender como uma população poderia alcançar mais do que um agente individual, desde que houvesse um bom mecanismo para identificar suas contribuições mais fortes e desenvolvê-las. A seleção e a avaliação se tornaram centrais para a forma como pensávamos sobre inteligência.

Quando surgiram os modelos transformer, ampliamos nosso trabalho para a IA conversacional e criamos uma plataforma de personagens baseados em IA capazes de manter conversas abertas, sem roteiro, com memória e personalidade. Isso aconteceu alguns anos antes do ChatGPT, e os modelos com que trabalhávamos tinham janelas de contexto de apenas 512 a 1.024 tokens. Era impensável esperar que um único modelo de linguagem daquela época atendesse de forma confiável a todos os diferentes requisitos dessa experiência. Tivemos de criar um fluxo de trabalho personalizado com modelos especializados, cada um com uma responsabilidade mais restrita, além da lógica necessária para combinar suas contribuições. Classificar e selecionar respostas se tornou essencial para fazer a experiência funcionar como um todo. Isso nos mostrou o quanto era possível alcançar ao combinar modelos limitados em um sistema bem projetado.

A outra lição foi a eficiência. Aprendemos que modelos especializados podiam ser treinados e disponibilizados com mais eficiência para tarefas bem definidas, permitindo-nos fazer mais com recursos computacionais limitados. Mas ampliar a inferência continuava sendo um desafio: de um lado, havia limites de uso das APIs; do outro, o custo de hospedar os modelos em infraestrutura própria em grande escala. Sem acesso à capacidade computacional de ponta, tivemos de pensar cuidadosamente em como aproveitar melhor os recursos disponíveis. A Fortytwo reuniu essas lições na proposta da inferência em enxame: vários modelos, ou várias instâncias do mesmo modelo, contribuem para o raciocínio enquanto avaliam o trabalho de seus pares. O resultado é um coletivo mais preciso do que qualquer um de seus integrantes.

O Fortytwo Engine usa vários modelos de pesos abertos para orientar um único processo de raciocínio e verificar uns aos outros enquanto a resposta é gerada. Em que essa abordagem difere dos sistemas multiagentes convencionais, dos conjuntos de modelos ou simplesmente de executar vários modelos e selecionar a melhor resposta depois?

A principal diferença é que a inferência em enxame está integrada diretamente ao mecanismo de inferência que desenvolvemos. Nós o chamamos de Swarm Decoder: vários modelos participantes moldam continuamente uma única trajetória de raciocínio à medida que ela é gerada. A avaliação e a orientação ocorrem dentro desse processo, permitindo que os modelos influenciem sua direção antes de a resposta ser concluída.

As alternativas funcionam de outra forma. Em um conjunto de modelos no nível das respostas, os modelos geram respostas separadas, que depois são classificadas, selecionadas ou combinadas. A arquitetura original da Fortytwo, implementada em 2025, usava a classificação por pares de respostas concluídas. Isso melhorou substancialmente a precisão das respostas, mas aumentou a latência e a sobrecarga computacional. Muitos sistemas multiagentes convencionais dividem o trabalho entre agentes e usam um orquestrador e mensagens em linguagem natural para coordenar suas contribuições. Essas transferências podem exigir chamadas adicionais de inferência, repetição de contexto e decisões sobre quais informações passar de um agente a outro. No Swarm Decoder, não há transferências: os participantes trabalham em uma única trajetória e a única coisa que trocam é uma avaliação sobre qual direção é melhor.

O Swarm Decoder foi projetado para detectar suposições frágeis durante a geração, antes que se invista muito esforço em desenvolvê-las. O objetivo é reduzir erros, retrocessos e geração desnecessária; o ganho de eficiência ocorre quando essa verificação evita mais trabalho do que acrescenta. Por isso, também não há penalidade de latência: a execução segue um caminho mais direto, de modo que o Engine conclui as tarefas mais rapidamente do que o mesmo modelo funcionando sozinho e com menos tokens no total, contando todos os modelos participantes.

Você destacou a deriva dos modelos durante tarefas prolongadas como um problema importante. O que causa essa deriva, de fato, e como ela se manifesta em aplicações práticas, como engenharia de software, pesquisa ou agentes de IA autônomos?

A deriva ocorre quando o contexto de um modelo, aos poucos, deixa de se concentrar na tarefa. Em uma execução longa, o contexto se enche com as próprias respostas do modelo, resultados de ferramentas, conteúdo de arquivos e novas tentativas. A instrução original passa a representar uma parcela cada vez menor daquilo a que o modelo presta atenção, e os erros que ele cometeu antes também passam a fazer parte das informações que usa para raciocinar; assim, os erros se acumulam em vez de se anularem. Além disso, os modelos de raciocínio atuais são treinados com aprendizado por reforço para concluir tarefas e aprendem atalhos que parecem levar à conclusão: pular a chamada de uma ferramenta, declarar que a tarefa foi concluída ou fazer um resumo em vez de verificar. Chamamos isso de preguiça, e os modelos de ponta fazem isso tanto quanto os modelos de pesos abertos. A causa fundamental é que um modelo isolado não tem uma verificação externa. Ele avalia o próprio trabalho, e os modelos não são bons em fazer uma autoavaliação precisa.

Na engenharia de software, isso aparece quando um agente corrige o erro que você descreveu, mas viola a restrição mencionada na primeira mensagem; escreve um teste que passa sem esforço; ou lê o mesmo arquivo quatro vezes porque perdeu o controle do que já aprendeu. Na pesquisa, é uma execução longa que se afasta da pergunta feita e passa a responder à pergunta mais fácil, retornando com um resumo genérico. Nos agentes autônomos, é a versão dispendiosa: desvios, chamadas repetidas a ferramentas, retornos a etapas anteriores e uma conta de tokens várias vezes maior do que o necessário para a tarefa.

Podemos quantificar isso. Executamos o Qwen 3.8 27B em 450 tarefas do DeepSWE — trabalhos reais de engenharia de software, com uso de ferramentas e contextos longos — uma vez por conta própria e outra por meio do Fortytwo Engine. Por conta própria, o modelo usou, em média, 16,3 milhões de tokens por execução, 7,4 bilhões no total. Por meio do Engine, o mesmo modelo usou, em média, 12,3 milhões de tokens por execução, 5,6 bilhões no total: 24,7% menos. Além disso, resolveu mais tarefas: 47,8%, contra 42,2%. O modelo não mudou em nada. Os quatro milhões de tokens por execução que deixaram de ser usados correspondiam à deriva: releituras, novas tentativas e retornos a etapas anteriores — trabalho que um modelo isolado precisa fazer porque ninguém detecta seus desvios enquanto eles acontecem. O enxame os detecta, então não é preciso gastar tokens com isso.

Antes, a Fortytwo fazia os modelos avaliarem as respostas uns dos outros depois de concluídas; na arquitetura atual, eles podem influenciar o processo de raciocínio enquanto ele ainda está sendo gerado. O que vocês aprenderam com a abordagem anterior e por que a orientação em tempo real é mais eficaz?

A arquitetura de 2025 demonstrou que podemos alcançar recursos de nível de ponta por meio da escalabilidade horizontal — reunindo mais modelos participantes, em vez de buscar o maior deles. Um enxame de modelos de pesos abertos que classificava as respostas completas uns dos outros superou o melhor modelo individual do enxame em até 17 pontos percentuais e mostrou-se robusto de maneiras que um modelo isolado não consegue ser: diante de instruções ambíguas, instruções injetadas e de uma maioria de respostas erradas.

O que essa arquitetura não conseguia fazer era intervir. Classificar respostas concluídas funciona para uma única pergunta, mas as execuções de agentes têm centenas de etapas, com chamadas a ferramentas entre elas, e os erros decisivos acontecem cedo e se acumulam. Avaliar no final significa que todos os modelos já gastaram o custo total em tokens, e o avaliador só pode escolher entre trajetórias que já divergiram. Isso também significava que o custo do enxame aumentava com o número de modelos — algo aceitável para uma pergunta difícil, mas inadequado para um agente de programação.

A orientação em tempo real resolve os dois problemas. A classificação contínua aplica pressão seletiva durante toda a execução, corrigindo um desvio assim que ele surge, antes que se propague. O enxame não se contenta com uma tentativa preguiçosa, porque uma tentativa menos cuidadosa perde na classificação para outra mais cuidadosa. É por isso que o mesmo mecanismo agora nos proporciona maior precisão e reduz o número de tokens ao mesmo tempo.

Nos testes com o Qwen 3.8 27B, a Fortytwo informa que usou 24,7% menos tokens em 450 execuções do DeepSWE, ao mesmo tempo que melhorou os resultados em seis benchmarks. O que acontece dentro do enxame para que ele consiga melhorar o desempenho e, simultaneamente, reduzir o consumo de tokens?

A verificação feita pelo enxame tem um custo pequeno e fixo; o custo da recuperação que ela evita aumenta com a duração da tarefa, porque cada desvio não corrigido compromete tudo o que se constrói a partir dele. Portanto, quanto mais longa a tarefa, maior a economia possível. O DeepSWE está entre as tarefas mais longas, e é por isso que a economia chega a quase um quarto de todos os tokens.

A questão da precisão está relacionada à inteligência irregular. Os avanços dos modelos costumam ser desiguais: eles podem apresentar raciocínio em nível de doutorado em uma área e dizer disparates completos em outra, porque o ajuste fino, o aprendizado por reforço (RL) e outras etapas de pós-treinamento melhoram o modelo com base nos dados usados para treiná-lo, e esses ganhos diminuem à medida que as tarefas reais se afastam desses dados. O Swarm Decoder não altera o modelo. Ele melhora o próprio raciocínio de maneira consistente; por isso, os seis benchmarks não são seis áreas para as quais otimizamos o sistema, mas seis lugares em que medimos a mesma coisa. No geral, o modelo é mais inteligente e atento e, com outros modelos verificando cada etapa, parece dedicar muito mais esforço à sua tarefa. É também por isso que podemos cobrar pelo Engine a mesma tarifa por token do modelo-base: o cliente não está pagando por um orçamento maior, mas por um caminho mais curto até a resposta certa.

Os desenvolvedores de IA estão cada vez mais preocupados com os custos de inferência, à medida que os modelos de raciocínio geram cadeias de tokens mais longas. Você acha que melhorar a eficiência do próprio processo de raciocínio pode, em última análise, ser tão importante quanto tornar os modelos individuais menores, mais rápidos ou mais baratos?

Sim, e eu diria que essa já é a alavanca mais importante. Tornar os modelos menores, mais rápidos e mais baratos reduz o preço de um token. Mas ninguém compra tokens. As pessoas compram uma tarefa concluída e, na era dos agentes, o número de tokens por tarefa disparou: um modelo de raciocínio pode consumir milhões de tokens em uma tarefa real de programação, e uma grande parte deles é gasta refazendo etapas. Reduzir em 25% o número de tokens por tarefa vale exatamente o mesmo que um corte de 25% no preço, com a diferença de que esse ganho se soma a cada melhoria em hardware, quantização e kernels, e podemos aplicar essa abordagem a qualquer modelo de pesos abertos disponível no mercado.

O setor tem três alavancas. Modelos melhores, o que depende de treinamento e custa caro. Tokens mais baratos, o que depende de hardware e de servir os modelos, e cujos custos estão convergindo porque todos usam as mesmas GPUs. E menos tokens por tarefa, o que depende de como a inferência é executada e ainda é uma área quase inexplorada. Até agora, escalar significou criar modelos maiores e cadeias de pensamento mais longas, e ambos exigem que um único modelo faça tudo em uma só trajetória. Acreditamos que o próximo eixo é coletivo: vários modelos raciocinando em conjunto, com o julgamento distribuído entre eles, para que a própria trajetória seja mais curta e confiável. Esse é um tipo de escalabilidade diferente do aumento do número de parâmetros ou da computação no momento do teste, e é nele que estamos apostando. Pensamos nisso como pares acima de parâmetros.

O Fortytwo Engine é compatível com a API da OpenAI e executa modelos de pesos abertos. Qual foi a importância da compatibilidade com as pilhas de desenvolvimento de IA existentes, e com que facilidade os desenvolvedores podem migrar uma aplicação de uma API convencional de modelo único para uma arquitetura de enxame?

A compatibilidade é essencial. O ecossistema de agentes — agentes de programação, ambientes de execução, frameworks e ferramentas de avaliação — foi construído com base no padrão da API da OpenAI. Por isso, para os desenvolvedores que usam o Fortytwo Engine, a migração é como mudar de um provedor de inferência para outro: em um aplicativo, agente, ambiente de execução ou serviço compatível, normalmente basta alterar uma única configuração: o endpoint, a chave de API e a seleção do modelo.

O que muda é o comportamento, não a integração. A diferença aparece em execuções longas de agentes, nas quais o consumo de tokens e a precisão na primeira tentativa determinam o custo: com o Engine, o mesmo modelo conclui as tarefas mais rapidamente, usa menos tokens e acerta mais delas. Meu conselho é tratar a mudança como qualquer troca de modelo: execute a avaliação que você já usa com seu agente, compare o número de tokens por tarefa e a taxa de sucesso e mantenha a opção que apresentar o melhor resultado.

Obrigado pela ótima entrevista. Leitores que queiram conhecer a inferência por enxame e como a avaliação entre pares pode melhorar a eficiência do raciocínio devem visitar Fortytwo.