Um cartão de título gerado com os dizeres Recursive Flint 40B-A2.5B, com painéis indicando 39,8 bilhões de parâmetros no total e cerca de 2,5 bilhões ativos por token, um contexto de 262.144 tokens compartilhado entre prompt e saída, pesos Apache 2.0 publicados pela primeira vez em 21 de outubro de 2026, quantização NVFP4 dentro de 0,7 ponto do modelo de 16 bits, e mais de 125 tokens por segundo em um MacBook Pro M4 Pro. Um rodapé observa que todos os números de benchmark e de vazão exibidos são informados pela Recursive e não foram reproduzidos de forma independente, e que os tamanhos dos arquivos foram medidos a partir dos repositórios publicados no Hugging Face.
Guides & Insights

Recursive Flint 40B-A2.5B: Um modelo de codificação criado para ser rápido em primeiro lugar

Autor

Alistair Wren

Data de publicação

Modelos mais recentes · 20Ver todos os modelos →
Benchmarks: Artificial Analysis · atualizado diariamente
Voltar para todas as publicações

O número que decide se Recursive Flint 40B-A2.5B vale o espaço no seu disco não é 54,9%. É 2,5. O primeiro modelo de codificação com pesos abertos da Recursive tem 39,8 bilhões de parâmetros e ativa aproximadamente 2,5 bilhões deles a cada token que escreve, e quase todas as outras decisões do lançamento — o layout de atenção, a receita de quantização, o kernel Metal personalizado, o motor de inferência — decorrem dessa única proporção. Flint foi lançado em 21 de outubro de 2026 sob a Apache 2.0, o que o deixa com um dia de vida no momento da escrita e dentro da janela em que um lançamento ainda é notícia, e não história. Como uma tabela de benchmark com um dia de vida é uma promessa, e não uma medição, mantemos o registro de produção separadamente: o AI Incident Archive registra como as alegações de modelos e provedores se sustentaram depois que passaram a atender tráfego real.

A versão curta para quem está decidindo agora: é um modelo esparso de mistura de especialistas criado para ser a coisa mais rápida da sua categoria de peso em um notebook, publica três pontuações de codificação agêntica que são todas relatadas pelo fornecedor e não reproduzidas, e é o primeiro modelo de uma empresa cujo propósito declarado é automatizar a pesquisa que constrói modelos. Todos esses três fatos importam, e o terceiro é o que ainda será interessante daqui a um ano.

O que realmente foi lançado

Quatro repositórios, não um. O repositório principal RecursiveSI/flint abriga o checkpoint BF16, a configuração, o tokenizer, o template de chat e um kit de serviço SGLang, e foi criado em 21 de outubro de 2026 às 14:20 UTC. Três variantes quantizadas ficam ao lado dele, todas marcadas na mesma tarde: uma versão int4 em safetensors, um GGUF int4 e um GGUF NVFP4. Todos os tamanhos abaixo foram medidos a partir das próprias listagens de arquivos dos repositórios, em vez de citados do anúncio.

• Referência BF16 — 79,59 GB em 37 arquivos, em 15 shards safetensors de aproximadamente 5,37 GB cada. Este é o artefato de ajuste fino e aquele que você não quer baixar para inferência.

• NVFP4 GGUF — 22,86 GB em um único arquivo, a menor compilação completa de inferência já publicada.

• Int4 GGUF — 25.99GB, uma quantização q4_1 que é maior do que o arquivo NVFP4, o que é o inverso da ordem de nomenclatura e vale a pena saber antes de escolher pelo nome do arquivo.

• Int4 safetensors — 22,58 GB, para runtimes que preferem pesos fragmentados em vez de um único GGUF.

A licença é Apache 2.0, com a ficha do modelo acrescentando a distinção de que os termos da API hospedada e as práticas de dados são separados da licença dos pesos — a separação habitual, declarada claramente em vez de ficar 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.

A arquitetura é um argumento sobre largura de banda de memória

Em um laptop, decodificar um token não é majoritariamente um problema de computação. É um problema de mover os pesos da memória para as unidades aritméticas rápido o suficiente, e é por isso que um modelo denso de 40 bilhões de parâmetros é lento não importa quão bom seja o chip: cada token lê todos os pesos. A resposta da Flint é ler quase nenhum deles.

• Esparsidade — 256 especialistas roteados por camada MoE, com 6 selecionados por token, além de um especialista compartilhado sempre ativo. Das 49 camadas, 2 são densas e 47 são MoE, então todas, exceto as duas primeiras, realizam trabalho condicional.

• Parâmetros ativos — 39,8B no total, aproximadamente 2,5B ativos por token contando a cabeça de saída, que é de onde vem a designação "40B-A2.5B". O corpo ativo sozinho é cerca de 2,2B.

• Atenção — 35 camadas de janela deslizante com uma janela de 513 tokens (o token atual mais os 512 anteriores), intercaladas com 14 camadas de atenção completa. Apenas 32 cabeças de consulta e 4 cabeças de chave-valor, com dimensão de cabeça 128, para que o cache KV permaneça pequeno o suficiente para tornar práticas sessões longas de agente.

• Codificação posicional — embeddings rotativos nas camadas de janela deslizante e nenhum nas camadas de atenção completa, uma escolha que o card do modelo afirma sem explicar. QK RMSNorm por cabeça e sinks de atenção aprendidos por cabeça estão fazendo o trabalho de estabilidade que a codificação posicional normalmente compartilha.

• Contexto — 262.144 tokens documentados, e o card do modelo é explícito ao afirmar que isso abrange o prompt e a saída gerada em conjunto. O anúncio divulga "até 512k" e depois recomenda permanecer dentro de 256k para programação. Ambas as afirmações são do mesmo fornecedor, separadas por um parágrafo.

O detalhe interessante é como o formato foi escolhido. A Recursive afirma que sua Eureka Machine — um loop automatizado de pesquisa que propõe ideias, as implementa, testa e combina o que funciona — começou de uma base de 35 bilhões de parâmetros com 3 bilhões ativos e explorou configurações e larguras de especialistas. A configuração 40B/2.5B resultante era, nas palavras do próprio anúncio, "projetada para oferecer a melhor combinação de velocidade e desempenho de codificação entre as configurações testadas pela nossa Eureka Machine". Projetada, não comprovada por uma comparação direta entre modelos finalizados. Essa é uma maneira normal de escolher uma arquitetura quando os treinamentos são caros, e também é uma afirmação que um checkpoint posterior poderia contradizer silenciosamente.

As três pontuações e as notas de rodapé que as acompanham

O Flint obtém 54,9% no Terminal-Bench 2.1, 89,7% no SWE-bench Pro v2 e 74,2% no SWE-bench Verified. Esses números aparecem na ficha do modelo como avaliações de lançamento, e nenhum terceiro publicou uma medição deste modelo — o índice de modelos da Artificial Analysis, o árbitro independente habitual para um lançamento como este, não tem nenhuma entrada do Flint até 22 de outubro. Portanto, tudo abaixo é a Recursive medindo a Recursive.

O que o fornecedor divulga sobre sua própria metodologia é mais do que a maioria dos posts de lançamento oferece voluntariamente, e isso muda a forma como os números devem ser lidos:

• Terminal-Bench 2.1 — executado com o harness Terminus 2, com acesso à internet habilitado, e soluções obtidas por meio de recuperação na web contabilizadas como falhas. Esse último ajuste é um handicap deliberado, e a ficha do modelo observa que as pontuações publicadas por outros desenvolvedores podem não aplicá-lo, o que torna mais difícil, e não mais fácil, uma comparação equivalente com números de terceiros.

• SWE-bench Pro v2 e SWE-bench Verified — executados com mini-swe-agent e sem acesso algum à internet, uma configuração mais difícil do que a de agentes que podem pesquisar documentação no meio da tarefa.

• Tentativas e timeouts — pass@1 médio em pelo menos cinco tentativas, com timeouts do agente de até cinco horas. A média de cinco tentativas é um protocolo razoável; timeouts de cinco horas significam que estas são pontuações de um agente que você está disposto a deixar em execução, não de um autocomplete.

• Amostragem — temperatura 1,0, top-p 0,95, top-k 20 em todas as avaliações, e o kit de serviço aplica esses padrões quando uma requisição os omite.

A tabela de benchmarks de um fornecedor também é uma declaração sobre quais pares ele escolheu. O próprio gráfico da Recursive compara o Flint com Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer e Gemma 4 — modelos locais que cabem em hardware semelhante, que é o grupo de pares honesto para um modelo de laptop e também um grupo selecionado para fazer o argumento de esparsidade parecer bom. A alegação feita é estreita e defensável: o Flint lidera modelos MoE com menos de 50 bilhões de parâmetros totais em codificação agêntica, e rivaliza com modelos densos de 25 a 40 bilhões enquanto roda muito mais rápido. Não é uma alegação sobre modelos de codificação de fronteira, e a Recursive não faz uma — o anúncio diz explicitamente que o Flint "pode precisar de mais orientação do que os modelos maiores de codificação de código fechado aos quais você está acostumado."

Velocidade: em relação ao que o 2× é realmente medido

A Recursive relata mais de 125 tokens por segundo em um MacBook Pro M4 Pro e mais de 150 tokens por segundo em um NVIDIA RTX Spark de 64GB em contextos curtos, descrevendo isso como até duas vezes mais rápido que modelos comparáveis e mais de cinco vezes mais rápido que modelos densos de 25 a 40 bilhões de parâmetros com pontuações de codificação semelhantes. A nota de rodapé sobre metodologia no gráfico de velocidade é a parte que vale a pena ler: média de tokens por segundo ao longo de uma sessão de 128.000 tokens, excluindo o prefill, com um concorrente medido em 124k em vez do comprimento total.

A exclusão do prefill é prática padrão para benchmarking de decode e continua importando aqui, porque o prefill é exatamente onde um agente de codificação passa seu tempo quando despeja um repositório na janela de contexto. Um número que mede apenas a metade de decode de uma sessão de 128k vai favorecer qualquer modelo com ativação esparsa, e todo o design do Flint é ativação esparsa. Nada disso torna o número errado. Torna-o um número de decode, e ele deveria ser comparado a outros números de decode, em vez de a quanto tempo seu agente leva para concluir uma tarefa.

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.

A receita de quantização é a parte mais transferível

A maioria dos textos sobre quantização trata de quanta precisão foi perdida. Este trata de uma decisão que seguiu o caminho oposto ao da convenção.

A Recursive quantizou a camada de saída — o lm_head — para 4 bits. Isso vai contra a prática comum, e o motivo é específico para modelos esparsos: com apenas 2,5 bilhões de parâmetros ativos, a camada de saída representa uma grande parcela dos pesos lidos para cada token, então deixá-la em 16 bits limita a velocidade máxima possível do modelo. Recuperar a acurácia exigiu uma etapa de destilação offline na qual o modelo quantizado treina com suas próprias respostas pré-amostradas de um coreset que ele mesmo descobriu, tendo o modelo de 16 bits como professor — uma configuração que a Recursive diz ter quase reduzido pela metade os passos de treinamento em relação à sua linha de base de treinamento ciente de quantização.

O resultado publicado é que o modelo NVFP4 final fica a menos de 0,7 ponto do modelo de 16 bits em toda a suíte de benchmarks. Essa é uma alegação do fornecedor, e é o tipo de alegação que é fácil de verificar depois e caro de falsear, o que a torna útil para cobrar deles. A consequência prática são os tamanhos de arquivo acima: um download de 22,86 GB que executa um modelo de 39,8 bilhões de parâmetros em uma máquina com 48 GB de memória unificada.

No Apple Silicon, há uma segunda camada nisso. A Eureka Machine da Recursive produziu kernels especializados para projeções de baixa precisão, operações de MoE, atenção e processamento de prompt, incluindo um megakernel Metal que funde toda a passagem forward de decodificação em um único dispatch nos chips M4 e M5. Fundir a passagem de decodificação é o tipo de otimização que só compensa quando você controla a arquitetura do modelo, o formato de quantização e o kernel em conjunto — o que é a tese real deste lançamento, mais do que qualquer número isolado de benchmark.

Como você o executa, e quanto cada caminho custa a você.

Existem duas histórias de implantação distintas e elas não são intercambiáveis.

• GPUs de servidor — o checkpoint BF16 vem com um kit de serviço SGLang que tem como alvo uma B300 ou uma H200 por réplica, expõe um endpoint compatível com OpenAI na porta 30000 com o nome de modelo flint, e inclui um cliente de exemplo para raciocínio e chamadas de ferramentas. Este é o único caminho suportado para os pesos de precisão total; o cartão do modelo afirma claramente que o código de modelagem do Transformers ainda não está incluído.

• Máquinas locais — llama.cpp, Ollama, Unsloth, LM Studio, vLLM e SGLang são todos indicados como suportados, o que é incomumente amplo para um modelo no dia de lançamento e é a diferença entre um checkpoint e um artefato utilizável.

• O rec engine — o mecanismo de inferência próprio da Recursive, instalado em ~/.local/bin, exige um M4 Pro, M5 Pro ou M5 Max com pelo menos 48 GB de memória unificada e cerca de 30 GB de disco livre, e expõe localmente uma API compatível com OpenAI. O README dele afirma throughput de tokens de 1,4× a 2,6× o do llama.cpp em um M4 Pro com pesos de 4 bits, em prompts de 1.000 a 252.000 tokens com 1.024 tokens de saída, cinco execuções por comprimento de contexto, excluindo o prefill. Ele é explicitamente otimizado para uso em sessão única — execute vários agentes ao mesmo tempo e a documentação indica outro caminho.

Notas práticas que determinam se uma sessão corre bem: a janela de contexto é partilhada entre o prompt e a saída, os problemas difíceis exigem um orçamento de saída de, pelo menos, 32.768 tokens, incluindo o raciocínio, e o reasoning_content devolvido tem de ser preservado no histórico da conversa, caso contrário o uso de ferramentas em vários turnos degrada-se. A própria orientação da Recursive para tarefas complexas é dividir o trabalho em subtarefas mais pequenas com instruções explícitas, o que é um conselho honesto que também se lê como uma descrição do limite do modelo.

O que é genuinamente não comprovado

Três coisas, em ordem decrescente do quanto elas deveriam influenciar uma decisão.

A primeira é a medição independente. Não existe nenhuma. Não uma pontuação baixa em um ranking, nem uma contestada — ainda não existe nenhuma avaliação de terceiros do Flint, e os únicos números em circulação são os do fornecedor, produzidos com as escolhas de harness do fornecedor e o ajuste do fornecedor para recuperação na web. A metodologia é divulgada de forma suficientemente detalhada para ser auditada, o que é o máximo que se pode pedir no primeiro dia, mas divulgada não é verificada.

A segunda é se um modelo de 2,5 bilhões de parâmetros ativos se sustenta no trabalho de horizonte longo para o qual os agentes de programação realmente existem. O protocolo do benchmark permite cinco tentativas e timeouts de cinco horas, o que é um envelope generoso; um modelo que precisa de várias tentativas e de uma coleira longa pode registrar um bom pass@1 enquanto parece pouco confiável em um editor. A própria ressalva da Recursive sobre precisar de mais orientação do que modelos fechados maiores aponta para a mesma coisa.

A terceira é a própria busca de arquitetura. Uma configuração projetada como a melhor entre as que um sistema automatizado testou é uma hipótese sobre uma execução de treinamento, não um resultado sobre um modelo finalizado. Se a projeção da Eureka Machine estava certa, este é um modelo que outras equipes pequenas copiarão. Se estava aproximadamente certa, o próximo checkpoint muda e a proporção muda.

Onde isto se encaixa se a sua stack de agentes for apenas parcialmente local

O motivo pelo qual um modelo como o Flint importa é que ele remove uma linha de uma fatura, não todas elas. A inferência local dá conta do trabalho que você consegue executar na sua própria máquina e não faz nada pelo trabalho que você não consegue — a tarefa de contexto longo que não cabe, o pico que ultrapassa um único laptop, a tarefa em que um modelo maior é simplesmente melhor. Isso deixa a maioria das equipes operando dois sistemas.

O OrcaRouter é a metade hospedada desse arranjo e, para deixar clara a fronteira: não servimos o Flint, e nada neste texto é uma propaganda de um checkpoint que hospedamos. O Flint é um download da Recursive, não um endpoint nosso. O que fazemos é colocar uma única API na frente de mais de 200 modelos hospedados pelo preço de tabela do próprio provedor, com sem nenhum acréscimo, rotear entre eles com uma cadeia de fallback baseada em configuração, e fazer failover automaticamente quando um provedor falha no meio de uma requisição. Se você quiser comparar quanto vale uma execução local do Flint contra um modelo hospedado de mistura de especialistas de porte semelhante — Qwen3.6-35B-A3B e Gemma 4 26B-A4B podem ambos ser chamados por meio dessa única chave —, a comparação custa uma requisição em vez de uma implantação.

A leitura razoável

Flint é um lançamento real, com um centro de gravidade específico e incomum. A Recursive não lançou o modelo de programação mais forte que poderia ter criado; lançou o mais rápido que conseguia construir em um tamanho que cabe em um laptop e, em seguida, publicou uma pilha de quantização e kernels projetada para fazer essa vantagem sobreviver ao contato com pesos de 4 bits. Os 54,9% no Terminal-Bench 2.1 e os 89,7% no SWE-bench Pro v2 são números fortes para um modelo esparso de 40 bilhões de parâmetros e, por enquanto, são apenas os números do fornecedor.

O que faz valer a pena acompanhar em vez de apenas baixar é o método por trás disso. Uma equipe que afirma que um ciclo automatizado de pesquisa escolheu a arquitetura, a receita de quantização e os kernels está fazendo uma afirmação sobre um processo, não sobre um modelo, e processos são testáveis de uma forma que benchmarks de lançamento não são: o próximo lançamento ou chega mais rápido e melhor, ou não. Flint é o primeiro ponto de dados nesse argumento, lançado sob uma licença permissiva o suficiente para que qualquer pessoa possa verificar os pesos por conta própria.

Se você tem 48 GB de memória unificada e uma máquina Apple Silicon, o custo de descobrir é um download de 22,86 GB e uma tarde. Se não tem, a posição honesta é esperar pela primeira avaliação independente, porque uma tabela de benchmarks de um dia atrás é uma promessa, não uma medição.

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.