Recursive abre o Flint, modelo de código local com 40 bilhões de parâmetros

A Recursive anunciou o Flint, um modelo aberto de mistura de especialistas (MoE) voltado a programação com agentes e execução local. Segundo a empresa, o modelo reúne 40 bilhões de parâmetros totais, ativa 2,5 bilhões por token e foi projetado para rodar em hardware pessoal sem enviar o código a um servidor remoto. A proposta é relevante porque combina licença Apache 2.0, janela de contexto de até 512 mil tokens e uma aposta explícita em desempenho local — mas os números de benchmark e velocidade ainda são resultados divulgados pela própria desenvolvedora.

Resumo: o que a Recursive está lançando

• Flint é um modelo MoE para programação e uso com agentes, com 40 bilhões de parâmetros totais e 2,5 bilhões ativos por token.
• Os pesos estão disponíveis no Hugging Face sob a licença Apache 2.0, que permite reutilização ampla sob suas condições.
• A Recursive afirma que o modelo supera outros MoEs com menos de 50 bilhões de parâmetros em benchmarks de programação com agentes, como SWE-Bench Pro v2, Terminal-Bench 2.1 e SWE-Bench Verified.
• O anúncio informa mais de 125 tokens por segundo em um MacBook Pro com M4 Pro e mais de 150 tokens por segundo em uma NVIDIA RTX Spark de 64 GB, em contextos curtos.
• A empresa recomenda manter tarefas de programação dentro de 256 mil tokens, embora o limite máximo de contexto informado seja de 512 mil.

O que diferencia um MoE de 40 bilhões com 2,5 bilhões ativos

Modelos de mistura de especialistas dividem parte do cálculo entre vários blocos especializados. Em vez de executar todos os parâmetros a cada token, um mecanismo de roteamento seleciona apenas uma parcela deles. No caso do Flint, a Recursive diz que o modelo tem 40 bilhões de parâmetros armazenados, mas aciona 2,5 bilhões em cada etapa de geração.

Essa diferença importa para quem pretende rodar um assistente de código localmente. O tamanho total continua influenciando memória, distribuição e formatos de quantização; já a quantidade de parâmetros ativos afeta diretamente quanto trabalho precisa ser feito durante a geração. A promessa do MoE, portanto, não é tornar um modelo grande “leve” sem custo, e sim concentrar o cálculo de cada token em uma fração do modelo.

A Recursive posiciona o Flint como uma alternativa para tarefas agentivas de programação: percorrer um repositório, propor mudanças, executar testes e iterar sobre falhas. A empresa afirma que o modelo pode ser usado com llama.cpp, Ollama, Unsloth, LM Studio, vLLM e SGLang. Também lançou o rec, mecanismo de inferência próprio otimizado para Flint em chips M4 Pro e M5 Pro/Max.

Desempenho: o que os números divulgados realmente medem

A Recursive relata liderança entre MoEs abaixo de 50 bilhões de parâmetros em SWE-Bench Pro v2, Terminal-Bench 2.1 e SWE-Bench Verified, além de resultados em LiveCodeBench v6, IFBench e IFEval. A comparação agregada publicada pela empresa combina esses testes e mede velocidade média ao longo de uma sessão com 128 mil tokens; o prefill ficou fora da métrica de velocidade.

Há detalhes metodológicos importantes. Para LiveCodeBench v6, IFBench e IFEval, a empresa informa média de pass@1 em cinco tentativas. Nos testes agentivos, afirma ter permitido até cinco horas de execução por tentativa, com pelo menos cinco tentativas. Em Terminal-Bench 2.1, usou Terminus 2 em XML e acesso à internet, mas soluções obtidas por recuperação foram contadas como falha. Já os testes SWE-Bench foram executados com mini-swe-agent e sem internet.

Essas condições não invalidam os resultados, mas impedem uma leitura simplista de que “X tokens por segundo” ou “liderança em benchmark” se transfere automaticamente para todo fluxo de desenvolvimento. O desempenho de um agente depende do hardware, da quantização, do contexto, das ferramentas, da latência de disco, dos testes do projeto e do conjunto de instruções. A validação independente por terceiros ainda será necessária para transformar o anúncio em uma referência comparável entre ambientes.

O papel da quantização e dos kernels no lançamento

A Recursive atribui parte do desempenho à otimização do caminho completo de inferência, não apenas à arquitetura MoE. A empresa diz ter pesquisado receitas de quantização e aplicado 4 bits também à camada de saída, conhecida como lm_head. Segundo o anúncio, essa decisão é relevante porque, em um modelo com poucos parâmetros ativos, a camada de saída representa uma parcela significativa dos pesos lidos a cada token.

Para recuperar qualidade após a quantização, a companhia descreve uma etapa de destilação offline: a versão quantizada é treinada com respostas previamente amostradas da versão de 16 bits, que atua como professora. A Recursive afirma que o modelo NVFP4 final ficou a até 0,7 ponto da versão de 16 bits no conjunto de benchmarks divulgado. A informação é específica da avaliação interna da empresa e não equivale, por si só, a uma garantia para todos os tipos de código.

O anúncio também menciona kernels especializados para projeções de baixa precisão, operações MoE, atenção e processamento de prompt. Em chips M4 e M5, a empresa afirma ter produzido um megakernel Metal que funde toda a passagem de decodificação. É esse tipo de trabalho de engenharia que explica por que dois modelos de porte parecido podem apresentar experiências locais muito diferentes.

Privacidade local é vantagem prática, não dispensa governança

Para equipes brasileiras, executar um modelo no próprio equipamento pode reduzir a exposição de trechos de código, documentos internos e chaves que seriam enviados a uma API externa. Também elimina cobrança por token em usos recorrentes e permite trabalhar offline. Isso pode ser útil em protótipos, revisão de código, testes de agentes em repositórios isolados e ambientes com requisitos de confidencialidade.

Por outro lado, execução local não resolve automaticamente segurança, licença de dependências, qualidade do código ou conformidade. Um modelo pode sugerir mudanças inseguras, interpretar mal requisitos, expor segredos em logs locais ou falhar ao entender convenções de um projeto. O uso responsável ainda exige controle de acesso, revisão humana, testes automatizados e separação entre ambientes de desenvolvimento e produção.

Como o Flint foi desenvolvido com pesquisa automatizada

A Recursive afirma que construiu o Flint em menos de quatro meses com uma equipe pequena de pessoas e agentes. O elemento central é o Eureka Machine, sistema que a empresa descreve como um ciclo automatizado de pesquisa: propor ideias, implementá-las, testá-las e usar os resultados para definir as próximas tentativas.

Segundo a companhia, o sistema participou de escolhas de arquitetura, dados, receitas de treinamento, infraestrutura, quantização e inferência. A tese é que melhorias em diferentes camadas se acumulam: uma arquitetura que ativa menos parâmetros pode abrir espaço para otimizações de kernels, que por sua vez tornam uma determinada quantização mais prática. É uma narrativa tecnicamente plausível, mas a extensão da contribuição autônoma do sistema não foi auditada de forma independente no anúncio.

Limitações e perguntas que permanecem abertas

• A Recursive não apresenta no comunicado um conjunto independente de reproduções dos benchmarks nem todos os detalhes necessários para comparar cada configuração com concorrentes.
• Os números de velocidade são declarados para hardware e condições específicas; memória disponível, contexto e formato de pesos alteram fortemente o resultado.
• A própria empresa alerta que tarefas complexas devem ser divididas em subtarefas e receber instruções explícitas; isso indica que o modelo pode requerer mais orientação que modelos fechados maiores.
• Uma licença aberta facilita adoção, mas não substitui avaliação de segurança, custo de hardware e verificação das obrigações da Apache 2.0 para cada produto.

Análise do NoticIA: a competição local passa a ser também de sistemas

Na análise do NoticIA, o ponto mais interessante do Flint não é somente a contagem de parâmetros. O lançamento reforça que a competição em modelos de código locais está migrando para o sistema inteiro: roteamento MoE, quantização, kernels, motor de inferência e integração com ferramentas. Um modelo com boa capacidade, mas lento ou difícil de executar, tende a perder espaço no fluxo diário de um desenvolvedor.

A abertura dos pesos sob Apache 2.0 amplia a chance de experimentação por startups, consultorias e times internos no Brasil. Porém, o anúncio não deve ser lido como substituição automática de modelos hospedados: organizações precisam medir qualidade no próprio código, comparar custo total de hardware e operação, e definir onde dados sensíveis podem circular. A melhor métrica não será o placar isolado de um benchmark, mas a taxa de mudanças corretas que passam por revisão e testes em um ambiente real.

Conclusão

O Recursive Flint chega como um candidato relevante para agentes de programação executados localmente: combina MoE de 40 bilhões de parâmetros, 2,5 bilhões ativos por token, pesos abertos e otimizações específicas para Apple Silicon e NVIDIA RTX Spark. As alegações de desempenho são promissoras, mas vêm da própria desenvolvedora e exigem reprodução independente. Para quem trabalha com código sensível ou quer reduzir dependência de APIs, o próximo passo é testar o modelo em tarefas reais, com limites de contexto, revisão humana e critérios de qualidade definidos antes de colocá-lo no centro do fluxo de desenvolvimento.