Flint — o primeiro modelo de programação com autoaperfeiçoamento recursivo?

Autoria: Sam Witteveen · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Flint - The First RSI Coding Model? · Canal: Sam Witteveen · 18:37 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA, Modelos locais e open source

Resumo

O vídeo apresenta Flint, um modelo MoE de programação com 40 bilhões de parâmetros totais e cerca de 2,5 bilhões ativos por token, que busca combinar velocidade e desempenho. O apresentador compara seus resultados com modelos como Qwen 3.8 27B e demonstra o modelo em tarefas de geração, revisão e uso de ferramentas. Também explica como a Recursive afirma ter usado a Eureka Machine, um sistema automatizado de pesquisa com agents, para ajudar a desenvolver a arquitetura, a quantização e os kernels do modelo. A avaliação final destaca o potencial de Flint para execução local rápida, mas ressalta limitações de desempenho, hardware e transparência sobre o sistema de pesquisa.

Pontos-chave

Flint é um modelo MoE com 40 bilhões de parâmetros no total, dos quais aproximadamente 2,5 bilhões ficam ativos por token.
A baixa quantidade de parâmetros ativos favorece a velocidade, enquanto o total de parâmetros determina se o modelo cabe na memória disponível.
No Mac apresentado pela Recursive, Flint chega a cerca de 130 tokens por segundo com seu engine; na demonstração do vídeo, a versão NVFP4 alcança aproximadamente 200 tokens por segundo.
Flint se aproxima de modelos densos em alguns benchmarks, mas fica atrás do Qwen 3.8 27B em resultados como Terminal-Bench, SWE-bench e LiveCodeBench.
O modelo está disponível em diferentes formatos e pode ser executado com ferramentas como Ollama, LM Studio, llama.cpp, vLLM e SGLang.
A Recursive recomenda dar orientações explícitas e dividir tarefas maiores em partes menores; a escolha do harness também pode afetar velocidade e resultados.
A Eureka Machine é descrita como um sistema que propõe ideias, escreve código, executa experimentos e seleciona os resultados mais promissores.
O apresentador destaca que avaliadores e verificadores podem ser explorados por sistemas otimizados para métricas, tornando a qualidade da avaliação essencial.
A demonstração mostra geração rápida e uso de ferramentas, mas também ressalta que a versão testada não conta com a otimização de megakernel feita para Apple Silicon.
O vídeo conclui que Flint pode ser interessante para quem tem hardware adequado e busca um modelo local rápido, embora modelos densos ainda possam oferecer melhor desempenho.

Capítulos

Início	Capítulo	Resumo
00:00	Flint: velocidade e arquitetura	O apresentador introduz Flint como uma alternativa MoE mais rápida a modelos densos e explica sua arquitetura, seus formatos e os primeiros resultados de benchmarks.
05:49	A Recursive e a Eureka Machine	O vídeo apresenta a equipe por trás da Recursive e descreve a Eureka Machine como um sistema de pesquisa automatizada que testa ideias em paralelo.
10:36	Como a Eureka Machine ajudou a desenvolver Flint	São discutidas as escolhas de arquitetura, quantização e kernels que a Recursive atribui ao sistema automatizado.
13:17	Demonstração e testes de Flint	O apresentador demonstra a geração de texto, a revisão de uma resposta e o uso de ferramentas, observando a velocidade e o comportamento do modelo.
16:33	Hardware, desempenho e limitações	O vídeo compara os requisitos para executar diferentes versões de Flint e comenta as limitações de otimização e a possível evolução da Eureka Machine.

Citações

Ele consegue chegar a 130 tokens por segundo. — 00:32

É um modelo que chega bem perto do desempenho do modelo denso, mas é um MoE e pode rodar muito, muito mais rápido. — 04:13

A parte difícil não era ter ideias, mas criar o avaliador. — 09:00

Vamos ter que ver se eles vão escalar para tentar criar um modelo de nível de fronteira. — 18:06

Conceitos e entidades

Flint (modelo): Modelo MoE de programação apresentado pela Recursive, com 40 bilhões de parâmetros totais e cerca de 2,5 bilhões ativos por token.
Recursive (empresa): Empresa que desenvolveu Flint e afirma ter usado um sistema automatizado de pesquisa para ajudar a criar o modelo.
Eureka Machine (ferramenta): Sistema de pesquisa automatizada da Recursive que propõe e testa ideias por meio de experimentos paralelos.
Mixture of Experts (MoE) (conceito): Arquitetura que ativa apenas um conjunto de experts para cada token, em vez de usar todos os parâmetros do modelo.
NVFP4 (conceito): Formato de quantização de quatro bits usado na versão de Flint demonstrada no vídeo.
Richard Socher (pessoa): Principal representante público da Recursive, citado como uma das figuras por trás da empresa e de suas ideias de pesquisa.
Qwen3.8 27B (modelo): Modelo denso usado como referência de desempenho e velocidade na comparação com Flint.
Pi (ferramenta): Ferramenta recomendada pela documentação da Recursive como harness para executar Flint.
llama.cpp (ferramenta): Uma das opções mencionadas para executar Flint.

Tradução completa (pt-BR)

00:00 Certo, então, no canal, já falei bastante sobre o modelo Qwen 3.8 27B. Analisamos variações dele e preciso dizer que ainda é um dos meus modelos favoritos. O problema, porém, para muita gente que usa esse modelo, é a velocidade. Como ele é um modelo denso, durante a decodificação é preciso percorrer todas as camadas. Em um MacBook Pro com M4, ele chega a cerca de 13 tokens por segundo. Acho que isso basta para conversar, mas é meio doloroso para qualquer coisa que você queira fazer com agents, quando há dezenas de chamadas e um loop em andamento,

00:32 e assim por diante. Então, neste vídeo, quero falar de um novo modelo que está tentando competir com esses modelos de programação de nível intermediário, mas usando uma abordagem MoE, em vez de um modelo denso. Este é o Flint rodando naquele mesmo MacBook de que falei antes; ele chega a 130 tokens por segundo. É cerca de 10 vezes mais rápido que o modelo denso Qwen, e em alguns benchmarks de programação está chegando bem perto do mesmo nível de desempenho. Em outros, porém, fica bem para trás. Vamos falar disso, mas preciso dizer, antes mesmo de fazermos isso, que essa nem é

01:04 a parte mais interessante. A empresa que criou o modelo, Recursive, diz que construiu o modelo inteiro do zero em menos de quatro meses, usando basicamente uma máquina bem pequena e um conjunto de agents. Eles fizeram isso com o sistema automatizado de pesquisa, que chamam de Eureka Machine, que ajudou a projetar a arquitetura, a quantização e até os kernels de GPU. Então, vamos investigar se o Flint é realmente bom e também o que querem dizer quando afirmam que uma IA ajudou a criá-lo. Certo, então, o que é o Flint?

01:35 É um modelo de mistura de especialistas com 40 bilhões de parâmetros no total, mas apenas cerca de 2,5 bilhões ficam ativos para cada token. Há 256 especialistas. O modelo escolhe seis deles por token, além de um especialista compartilhado que está sempre ativo. E isso é o que realmente importa para executar algo assim localmente em um laptop ou computador desktop. Sua velocidade é limitada principalmente pela largura de banda da memória. Então, quantos pesos é preciso ler para cada token?

02:06 É a quantidade de parâmetros ativos que realmente prevê a velocidade. A quantidade total, ou o número total de parâmetros, é o que determina se o modelo vai caber ou não. Então, acho que as duas perguntas a considerar são: primeiro, 2,5 bilhões de parâmetros ativos é pouco demais? E, além disso, 40 bilhões de parâmetros é demais para que muitas pessoas consigam colocar o modelo na GPU? Há também outras coisas interessantes na arquitetura deste modelo. A maioria das camadas, 35 delas… usa o que se chama atenção de janela

02:40 deslizante, com cerca de 500 tokens. E apenas 14 das camadas totais usam um sistema de atenção completa. Isso torna o contexto longo bem mais barato. A documentação diz que, de fábrica, o modelo pode lidar com um contexto de 262K e até 65K tokens de saída. Outra coisa interessante é que o raciocínio está sempre ativado. Uma das coisas legais aqui é que esta é uma licença Apache 2 totalmente aberta. Não há restrições de acesso. Eles lançaram quatro repos oficiais no Hugging Face.

03:10 Há uma versão bfloat16, uma versão INT4, uma versão quantizada GGUF padrão e uma versão NVFP4, que é a que vou mostrar principalmente aqui. Agora, se dermos uma olhada rápida nos benchmarks em comparação com outros modelos de mistura de especialistas da mesma categoria, como o Qwen 3.6 35B — um modelo que muita gente queria ver atualizado para o 3.8, mas essa atualização nunca veio. Esse é o modelo de mistura de especialistas mais próximo do 27B e

03:41 de outros modelos MoE open source, como o Laguna XS. O Flint está na liderança em praticamente tudo e está basicamente empatado com o Qwen 3.6 no LiveCodeBench. Em seguimento de instruções, parece superar todos os rivais. Quando o comparamos diretamente com o Qwen 3.8 27B, ele perde, certo? No Terminal-Bench, fica em 55 contra 73, e também fica atrás nos resultados do SWE-bench e do LiveCodeBench. Então, não é que este seja o melhor modelo de programação que existe.

04:13 O ponto é que este modelo chega bem perto do desempenho do modelo denso, mas é um MoE e pode rodar muito, muito mais rápido. E, sinceramente, este gráfico é um argumento melhor do que qualquer um dos benchmarks. Dá para ver que as pontuações mais altas ficam por aqui e a maior velocidade, por aqui. E, olhando para isso, o Flint está isolado ali, bem à frente. Certo, se você quiser executar o modelo, há várias maneiras de fazer isso. Ele já está disponível no Ollama. Também está no LM Studio e no llama.cpp. Há suporte no vLLM e no SGLang se você quiser disponibilizá-lo como serviço adequadamente.

04:46 A própria Recursive criou seu próprio mecanismo, chamado rec, e é daí que vem a velocidade de 130 tokens por segundo. Mas, pelo que parece, no momento ele só pode ser instalado em um Mac, certo? E, ainda por cima, em um Mac bem potente. Infelizmente, não tenho um desses. Então, as imagens do Mac que vocês viram são, na verdade, do próprio vídeo de lançamento da Recursive. Vou mostrar principalmente a versão NVFP4 rodando em uma RTX PRO 6000. Agora, se quiser tentar executar o modelo você mesmo, o blog da Recursive diz que o Flint talvez precise de mais orientação do que os modelos de programação fechados maiores. Então,

05:18 acho que a ideia é que, com apenas 2,5 bilhões de parâmetros ativos, você divida as tarefas maiores em partes menores, com instruções explícitas. Outro ponto importante é o harness. A documentação recomenda o Pi em vez do OpenCode. Eles citam relatos de que o Pi é cerca de uma vez e meia mais rápido com workflows. E preciso dizer que estamos chegando a um ponto em que testar um modelo depende tanto do harness que você está usando quanto do próprio modelo. Certo, então vamos falar um

05:49 pouco sobre quem está por trás disso e por que um laboratório recém-criado lançaria um pequeno modelo local de programação como seu primeiro produto. Certo, a principal figura pública da Recursive é Richard Socher e, se você já trabalhou com NLP, provavelmente sabe quem ele é. Há cerca de 10 anos, ele dava muitos dos cursos mais interessantes em Stanford. Depois, foi chefe de IA na Salesforce, após a empresa comprar sua startup. Nos últimos anos, tem trabalhado em uma startup chamada You.com, tentando competir com o Google na busca. Richard sempre foi uma das

06:21 pessoas do deep learning com ideias realmente interessantes. Ele foi um dos autores do artigo original sobre ImageNet. Também criou coisas como os embeddings GloVe. E o interessante é que, se voltarmos à tese de doutorado dele em Stanford, de 2014, o título era “Recursive Deep Learning for NLP and Computer Vision”. Então, ele já vinha trabalhando com muitas dessas ideias de autoaperfeiçoamento recursivo e com toda essa noção de aprendizado contínuo, de fazer os modelos melhorarem, e assim por diante. Recentemente, ele basicamente

06:52 publicou um livro com muitas dessas ideias, chamado “The Eureka Machine”. Na verdade, acho que saiu em setembro. Tenho lido o livro nas últimas semanas e, como já disse, Richard Socher tem muitas ideias boas e interessantes. Agora, ele reuniu uma equipe de oito cofundadores de vários lugares, como Google, OpenAI, DeepMind, Meta e outros. Há ali muitas pessoas realmente impressionantes, que vêm trabalhando em várias ideias originais há bastante tempo, não apenas em LLMs.

07:23 Então, há Tim Rocktäschel, que veio do Google DeepMind, onde liderava a equipe de Open-Endedness, responsável pelo Genie, que vocês provavelmente conhecem como o grande modelo de mundo do Google. Você fornece uma única imagem, até mesmo um esboço simples, e ele pode transformá-la em um jogo. Dá para fazer várias coisas diferentes com ele. E, na verdade, toda a equipe tem um currículo realmente impressionante, certo? Todos vêm trabalhando em ideias muito interessantes. Acho que isso ficou evidente quando, em maio, saíram do stealth, tendo captado US$ 650

07:55 milhões, com uma avaliação de US$ 4,65 bilhões. A equipe ainda tem apenas cerca de 30 pessoas, ou menos. E é preciso pensar que os investidores não estavam exatamente apostando em nenhum produto específico. Eles estavam apostando em uma equipe e em um sistema para, basicamente, fazer esses modelos melhorarem a si mesmos e conseguir criar esse ciclo de autoaperfeiçoamento recursivo. E isso nos leva à Eureka Machine. Então, o nome é usado para duas coisas. Primeiro, para a grande visão apresentada no livro de Socher; e, segundo, para o

08:27 sistema real em execução dentro da Recursive. Então, vamos nos concentrar no sistema real. É um ciclo. Um agent propõe uma ideia para testar. Ele escreve o código, desafia a si mesmo, executa vários experimentos, treina algo ou faz o benchmark de algo. E então os vencedores se tornam uma espécie de degraus para a rodada seguinte. E o interessante é que ele executa muitas dessas ideias em paralelo, certo? Então, há muitos caminhos de pesquisa acontecendo em paralelo, e depois ele combina apenas os mais promissores. E, para ser sincero, isso é um território meio familiar para quem já olhou

09:00 para a pesquisa sobre abertura de possibilidades: é uma linha de trabalho bem parecida, mas ampliada com muito mais dinheiro e muito mais poder computacional. E o que eles dizem — e acho que realmente esclarece muita coisa sobre isso — é que a parte difícil não era ter as ideias, mas criar o avaliador. O desafio é que, à medida que a busca ficou mais forte, os candidatos à avaliação começaram a explorar a avaliação. Coisas como armazenar resultados em cache e explorar o tempo de execução. E a única maneira

09:30 de se sair bem nisso é continuar fortalecendo também o avaliador. É bem parecido com coisas como GANs, se você se lembra dos velhos tempos das GANs, quando havia um discriminador e um gerador. O próprio Socher disse que a equipe encontrou muitos bugs no próprio harness de testes enquanto construía isso. E acho que há lições aqui que se aplicam a qualquer pessoa que execute ciclos de agent ou faça RL. Seu avaliador ou verificador é, na verdade, uma espécie de superfície de ataque e, quanto melhor fica sua otimização, mais brechas ele vai encontrar nesses

10:04 tipos de recompensa. Então, dá para pensar nisso como um estagiário muito esperto, que vai encontrar um jeito de atingir qualquer métrica que você definir, independentemente de isso realmente levar ao objetivo final. Agora, em junho, eles estavam experimentando esse sistema em coisas como nanoGPT ou nanochat, basicamente tentando reduzir a loss. Mas Flint é realmente a primeira incursão deles na criação do próprio modelo, de um tamanho razoável e que as pessoas possam usar, entre outras coisas. Uma das críticas feitas aqui é que ainda não sabemos o que exatamente está executando isso.

10:36 Quais modelos, quantos agents, quanto poder computacional, entre outras coisas. Será que, por exemplo, estão apenas usando um modelo de ponta de uma das grandes empresas para otimizar os próprios modelos? Certo. Então, quando analisamos especificamente o Flint, a Recursive diz que o sistema era composto por três partes principais. A primeira é a busca por arquiteturas. E começou com um modelo com 35 bilhões de parâmetros no total, 3 bilhões ativos. Basicamente, algo bem parecido com o modelo Qwen 3.6B. Depois, exploraram diferentes configurações e larguras de experts e chegaram a 40 bilhões

11:07 no total, com 2,5 bilhões ativos. Então, o menor número de parâmetros ativos é basicamente o que nos dá o ganho de velocidade aqui. E vou mencionar algo que já comentei em outros vídeos: parece ser uma coincidência que o tamanho ideal para os parâmetros ativos seja cerca de 5% ou 6% do total de parâmetros. E, embora isso possa mudar em tamanhos realmente grandes, os modelos MoE que analisei e que tendem a se sair muito bem seguem essa fórmula. Já os que chegam a 10% de parâmetros ativos realmente não parecem se sair tão bem.

11:41 A segunda coisa que fizeram, que foi realmente interessante, foi a camada de saída. A camada de saída obviamente vai usar muitos parâmetros, porque você vai fazer uma previsão em que aplica softmax sobre todos os tokens possíveis. E, curiosamente, o Flint optou por um tokenizer de cerca de 150 mil tokens, e só essa camada de saída tem cerca de 300 milhões desses parâmetros. Isso dá aproximadamente um oitavo de todos os parâmetros pelos quais cada token vai passar. A maioria dos modelos não quantiza essa camada, mas aqui eles a quantizaram

12:13 para 4 bits e, na verdade, recuperaram a precisão destilando a partir de uma versão do modelo de 16 bits. É aqui que eles implementam esse treinamento com quantização ciente. Isso pode ser uma das coisas principais que fazem a versão NVFP4 deles pontuar tão perto do modelo de precisão total, o que é meio impressionante. A terceira coisa que fizeram foi incorporar toda a ideia de kernels. No Apple Silicon, o sistema deles escreveu um megakernel Metal de baixo nível,

12:44 que funde toda a etapa de decodificação em um único kernel, e isso acelera tudo porque há menos inicializações de kernel, menos acessos à memória e assim por diante. É realmente interessante que eles afirmem que o sistema Eureka Machine encontrou essas coisas e fez isso. Infelizmente, ainda não há nenhum artigo publicado sobre isso, então, na verdade, não temos muito em que nos basear. Mas seria muito interessante ver! Vamos passar para a demonstração e ver como o próprio modelo se sai. Certo, dá para ver que, ao abrir aqui, estou basicamente executando a versão NVFP4.

13:17 Eu mesmo rodei vários benchmarks com ele. Com certeza vejo algumas diferenças em relação aos resultados oficiais deles, tanto positivas quanto negativas. Mas isso também mostra como esses resultados podem mudar bastante quando você os executa. Se viermos aqui e fizermos alguns testes padrão, vocês vão ver que os tokens estão saindo muito rápido, e isso porque estou executando a versão NVFP4 aqui, certo? Dá para ver também, só olhando o raciocínio aqui. Vou deixar isso rodar.

13:49 Se olharmos o raciocínio aqui, ele é bem verboso. Ele passou por… Neste caso, basicamente fez uma avaliação. Não fez nada do que eu chamaria de raciocínio numerado aqui. Vamos em frente: executou a tarefa e passou. Se dermos algo um pouco mais difícil, veremos que, em vários desses casos, não temos o que eu chamaria de raciocínio numerado aqui. Se olharmos a saída, ela está sendo gerada bem rapidamente. Geralmente estou vendo algo em torno de 200 tokens por segundo. Se eu der algo mais livre, como isto, vamos ver

14:22 qual é a saída que estamos obtendo. E dá para ver que desta vez também dei a ele um system prompt. Há bastante raciocínio acontecendo aqui, e o raciocínio pode variar bastante neste modelo. Já vi, com esse tipo de coisa, que às vezes o raciocínio tem apenas algumas centenas de tokens. Às vezes, pode chegar aos milhares. Agora, vocês vão notar outra coisa aqui: estamos obtendo o raciocínio numerado. Dá para ver que temos o raciocínio numerado acontecendo. Temos coisas como decompor a solicitação, brainstorming inicial, estruturar o ensaio, redigir o conteúdo — um processo de raciocínio bem padrão e sólido

14:58 em torno disso. Certamente não é como o Neuralese que vimos em alguns dos modelos mais modernos, nos quais o raciocínio costuma ser abreviado. Mas aqui dá para ver que geramos quase 6 mil tokens. Estamos obtendo um pouco mais de 210 tokens por segundo, o que fica mais ou menos na média. Eu diria que geralmente vejo algo entre 200 e 212. Isso é bastante comum aqui. Agora, dá para ver que não houve muito prefill neste caso. Então, o que vou fazer é devolver a ele basicamente o mesmo ensaio e

15:29 e então pedir que ela basicamente dê uma nota. Então, na verdade, temos bastante pré-preenchimento acontecendo. Certo, estou pedindo: “Por favor, examine este ensaio, avalie e verifique a precisão dele.” Este é exatamente o texto que ela escreveu antes. Podemos ver que há bastante raciocínio na resposta, passando por tudo isso. E então temos a avaliação geral. É interessante que ela se dê uma nota de apenas cerca de 85% de precisão. Neste caso, se examinarmos o texto, ela fala sobre várias coisas que… que escreveu na primeira versão e que estão incorretas.

15:59 Em seguida, ela apresenta algumas revisões. Veja que o pré-preenchimento que fizemos aqui tinha mais de 2.000 tokens, e a velocidade de processamento dos tokens nessa etapa é super-rápida. E dá para ver que a velocidade de geração é quase exatamente a mesma que obtivemos antes. Quando pedimos que ela reescreva o texto, basicamente ela passa a fazer isso. Se olharmos para tarefas de agent, vocês verão que, pelos meus testes, ela parece ser muito boa no uso de ferramentas. Não há problemas nesse aspecto: ela consegue passar por várias etapas e executar tudo isso muito bem. E a principal vantagem disso é

16:33 simplesmente ser muito mais rápido, especialmente se você não tiver uma GPU muito rápida. Agora, a versão que estou usando aqui definitivamente não é tão otimizada quanto aquela para a qual eles criaram o megakernel no Mac. Isso parece ser algo bem singular que eles fizeram. Teria sido bom vê-los usar aquela Eureka Machine e aplicá-la aos kernels CUDA para melhorá-los também. Mas imagino que isso seja algo de bastante valor. Talvez eles não queiram revelar as otimizações de CUDA, assim como vimos

17:03 com ThinkingCap, em que muitas dessas empresas disponibilizam uma versão, mas cobram das empresas por outras versões, etc. Se você quer saber como isso vai funcionar na sua GPU e talvez o que poderia fazer com ele, preparei isto basicamente para mostrar diferentes GPUs e indicar se você conseguiria executá-lo ou não. Mesmo na RTX Pro com 96 gigabytes, ainda não consigo executar a versão completa em bfloat16. Provavelmente você vai precisar de uma H200 ou de várias GPUs para isso. Mas dá para executar a versão NVFP4 com bastante facilidade, sem falar em várias

17:36 das quantizações do Unsloth e outras quantizações disponíveis, que podem ser executadas em GPUs muito menores. Certo, então a que conclusão chegamos? Bem, se você tem um Mac Pro bem potente, com 48 gigabytes de memória, e quer um modelo de programação local e rápido, acho que vale muito a pena experimentar o Flint. Se você tem algo como um DGX Spark ou uma GPU maior, ainda vai ter um modelo de programação rápido de mistura de especialistas. Provavelmente não vai atingir aquele número chamativo de 130 tokens por segundo. Quanto à Eureka Machine em si, vamos ter que ver se eles vão escalar

18:06 para tentar criar um modelo de nível de fronteira. Adoraria vê-los enfrentar um modelo denso como o 27B e realmente superá-lo. E não se esqueçam de que o Qwen 4 está chegando, com várias ideias de Engrams e coisas do tipo, que eles pegaram do DeepSeek. Então, acho que vamos ver muitas outras ideias desse tipo de autoaperfeiçoamento recursivo começarem a ganhar força. Enfim, contem nos comentários o que vocês acham. Se experimentaram o Flint, como foi? Como ele tem se saído para vocês? Sei que muitos de vocês têm bastante interesse em modelos de mistura de especialistas, em vez de modelos densos

18:37 simplesmente porque são mais fáceis de executar, mas ainda parece que há uma perda considerável quando se escolhe essa opção, em vez de usar um modelo totalmente denso. Enfim, como sempre, se acharam o vídeo útil, cliquem em curtir e se inscrevam. A gente se fala no próximo vídeo. Até mais.

Transcrição original

[00:00] Okay, so on the channel, I’ve covered the Qwen 3.8 27B model quite a lot. We’ve looked at variations of it, and I gotta say, it’s still one of my favorite models. the problem, though, for a lot of people with that model is just speed. Because it’s a dense model, when you’re decoding, you’ve gotta go through all of the layers now on a MacBook Pro with an M4, it does about 13 tokens a second, and I guess that’s fine for chat, but it’s kind of painful for anything that you want to do with agents where you’ve got dozens of calls, you’ve got a loop going,

[00:32] et cetera So in this video, I want to talk about a new model that’s trying to take on these mid-level coding models, but do it from the point of an MoE rather than a dense model. So this is Flint running on that same MacBook that I was talking about before, it can hit 130 tokens a second. It’s roughly 10 times faster than the Qwen dense model And on some of the coding benchmarks it’s getting really close to the same kind of performance. On others though, it’s kind of well behind. So we’ll get into that but I gotta say before we even do that, That’s not

[01:04] even the most interesting part here. The company that made this, Recursive, say that they built the whole model from scratch in under four months With basically a very small machine and a set of agents and they did it with their automated research system, which they call the Eureka Machine, which helped design the architecture, the quantization, and even the GPU kernels So let’s dig into whether Flint is actually any good and also what do they mean when they actually say an AI helped build this? Okay, so what is Flint?

[01:35] It’s a mixture of experts model with 40 billion parameters in total, but only about two and a half billion active for each token. There are 256 experts. It picks six of them per token, and then there’s one shared expert that’s always on And this is the thing that really matters for running something like this locally on a laptop or on a desktop box. Your speed is mostly limited by your memory bandwidth. So how many weights do you have to read for every token?

[02:06] The active count here is really what predicts the speed. the total count or the number of parameters in total, is what decides whether it’s gonna fit at all So I guess the two questions really to think about here is one, is 2.5 billion parameters too small, to basically have for your active parameters? And then also is 40 billion parameters too big for many people to be able to fit this on their GPU? there are some other interesting things about the architecture of this model as well. So most of the layers, 35 of them… are using what’s called a sliding

[02:40] window attention of about 500 tokens And then only 14 of the total layers actually use a full attention system. So that keeps long context a lot cheaper. And they’re documenting that out of the box this can do 262K of context with up to 65K output tokens. Another interesting thing here is reasoning is always on now, one of the cool things here is that this is a fully Apache 2 open license. it’s not gated. They’ve released four official repos on Hugging Face.

[03:10] You’ve got a bfloat16 version. you’ve got an INT4 version. They’ve got a standard GGUF quantized version, and they’ve got an NVFP4 one which is what I’m gonna mostly show in here Now, if we just go for a quick look at the benchmarks against other mixture of experts models in its class, things like the Qwen 3.6 35B, which is a model that a lot of people wanted to see updated for the 3.8 and it just never came. That’s the mixture of experts model that’s sort of closest to the 27B and

[03:41] then other open MoEs like Laguna XS. Uh, Flint’s leading pretty much on everything, and it’s basically tied with Qwen 3.6 on LiveCodeBench On instruction following it seems to be beating out all of its rivals there when we compare it straight up against the Qwen 3.8 27B, it does lose, right? On Terminal-Bench, it’s 55 versus 73, and it’s behind both on SWE-bench numbers and the LiveCodeBench so it’s not that this is the best coding model out there.

[04:13] It’s that, this is a model that gets really close to the dense model performance, but is an MoE and can run much, much faster and honestly, this chart makes a better case than any of the benchmarks here. You can see sort of higher scores up here, more speed out here, and looking at this, Flint is sitting out all on its own over there All right, so if you want to run this, you’ve got a whole bunch of different ways you can do it. It’s already out in Ollama. It’s also in LM Studio and llama.cpp. and there’s vLLM and SGLang support if you want to serve it properly

[04:46] Recursive themselves have made their own engine called rec, and that’s where the 130 tokens a second is actually coming from But it seems at the moment that will only install on a Mac, right? and a pretty powerful Mac at that. Unfortunately, I don’t have one of those, So the Mac footage that you’ve been seeing is actually from Recursive’s own launch video I’m gonna mostly show the NVFP4 version running on an RTX PRO 6000 Now, if you want to try and run this yourself, Recursive’s own blog says that Flint may actually need more guidance than bigger closed coding models so

[05:18] I guess the goal there is when you’ve only got two and a half billion active parameters, break bigger jobs into smaller pieces with explicit instructions. another key thing is the harness. So their docs recommend Pi over OpenCode They refer to reports of Pi being about one and a half times faster with workflows and I gotta say we’re really getting into the point now where, testing a model comes down to as much about the harness that you’re using as just the model itself All right, so let’s talk a

[05:49] little bit about who’s behind it and why would a brand new lab ship a small local coding model as its very first product? All right, so the main public face of Recursive is Richard Socher and if you’ve worked in NLP at all, you probably know who he is. He used to basically teach a lot of the cool courses, at Stanford sort of 10 years ago he used to be the head of AI at Salesforce after they bought his startup. and for the past few years, he’s been working on a startup called You.com to try and take on Google at search Richard has always been one of the

[06:21] people in deep learning who’s had really interesting ideas he was one of the people on the original ImageNet paper. He also did things like GloVe embeddings And the interesting thing is that even if you go back to his 2014 Stanford PhD thesis, it was titled “Recursive Deep Learning for NLP and Computer Vision.” so he’s had a lot of the ideas Around recursive self-improvement and this whole idea of sort of continual learning, getting models to be better, et cetera just recently he basically

[06:52] published a book with a lot of these ideas called “The Eureka Machine.” In fact, I think it just came out in September. It’s something that I’ve been reading over the past few weeks, and like I said before, many things with Richard Socher, he has lots of good, interesting ideas now he pulled together a team of eight co-founders from a whole bunch of different places like Google, OpenAI, DeepMind, Meta, et cetera And there are a lot of seriously impressive people in there who’ve been working on a lot of original ideas for quite a while, not just on LLMs.

[07:23] so you’ve got Tim Rocktäschel in there who came from Google DeepMind, where he was leading the Open-Endedness team, which was the team behind Genie, what you’ve probably seen was Google’s big world model. You give it a single image and even a rough sketch, and it can then turn it into a game. It can do a whole bunch of different things, work with it and in fact the entire team here is really well pedigreed, right? They’ve all been working on really interesting ideas and I think that kind of shows when in May they came out of stealth, having raised $650

[07:55] million at a $4.65 billion valuation. The team is still only about 30 people or less. and you’ve got to think here that investors really weren’t sort of buying into any particular product. They were buying into a team and a system for how to basically make these models just improve themself, and be able to build that recursive self-improvement loop and that’s what brings us to the Eureka Machine. So the name gets used for two things. one being the big sort of vision from Socher’s book, and then two, the

[08:27] actual system running inside Recursive. So let’s focus on the real system. So it’s a loop. An agent proposes an idea to try. It writes the code, it challenges itself, it runs a bunch of experiments, it trains something or benchmarks something. And then winners become sort of stepping stones for the next round and the interesting thing is that it runs lots of these ideas in parallel, right? So there’s lots of these research paths going on in parallel, and then it combines just the most promising ones And to be honest, this is kind of familiar territory to anyone that sort of looked

[09:00] at the open-endedness research it’s a very similar sort of line of work, but scaled up with a lot more money, a lot more compute and the thing that they talk about which I think really does clarify a lot of things around this, is the hard part wasn’t coming up with the ideas, it was coming up with the judge And the challenge is as search got stronger, the candidates for judging sort of end up starting to be gaming the evaluation. So things like caching outputs, exploiting timing And the only way

[09:30] you can sort of do well out of that is to then keep getting your evaluator to be getting stronger as well. Very similar to things like GANs, if you remember the old days of GANs, where you had a discriminator and a generator Socher himself has said that the team, have found lots of bugs in their own test harness when they were building this And I think there are lessons here that apply to anyone running agent loops or doing RL. your evaluator or your verifier really is kind of like an attack surface and the better that your optimization gets, the more holes it will actually find in

[10:04] those kind of rewards so you can kind of think of this as like a really clever intern who will find a way to hit whatever metric you set whether or not that’s actually gonna lead to sort of the final goal Now, back in June, they were playing with this system on things like nanoGPT or nanochat, basically trying to get the loss down, there But Flint is really their first foray into actually making their own model which is a decent size and people can actually use, et cetera. One of the criticisms leveled here is that we still don’t know what’s actually running it.

[10:36] which models, how many agents, how much compute, et cetera Are they, for example, just using a frontier model from one of the big companies to optimize their own models? Alright. So when we actually look specifically at Flint, Recursive says the system here sort of consisted of three main parts. So the first is architecture search. and it started with a model with thirty-five billion total, three billion active, Basically something very similar to the Qwen 3.6B model they then explored different expert setups and widths and landed on 40 billion

[11:07] total with two and a half billion active So the fewer active parameters basically gives us the speed up here. And I will mention something that I’ve mentioned in other videos. it does seem to be kind of coincidence that the right size for your active parameters seems to be roughly around 5%, 6% of what your total parameters are and while that may change at really big sizes, MoE models that I’ve reviewed that have tended to do really well tend to stick to that formula, and ones where they go up to 10% active really don’t seem to do that well.

[11:41] The second thing that they did, which was really kind of interesting, was the output layer. So the output layer obviously is gonna use a lot of parameters because you’re gonna be making a prediction where you softmax over all the possible tokens and interestingly here, Flint has gone for a tokenizer of about 150,000 tokens and just that output layer alone is around sort of 300 million, of those parameters. It works out to be roughly an eighth of everything that you’re gonna put each token through now most models won’t quantize that, but here they did quantize

[12:13] that to four bits, and they actually recovered the accuracy by distilling from a 16-bit version of the model This is where they’re implementing that quantization-aware training This actually could be one of the key things that gets their NVFP4 version to score so close to The full precision model, which is kind of amazing there the third thing that they did was they actually sort of incorporated the whole idea of kernels in here. So on Apple Silicon, their system actually wrote a low-level Metal megakernel,

[12:44] which sort of fuses the whole decode pass into one kernel and that just speeds up everything because there are fewer kernel launches, fewer trips to memory, et cetera now, it’s really interesting that they’re claiming that their Eureka Machine system actually sort of found these things and did it. unfortunately, there is no published paper, for this at the moment, so Really, we don’t have a lot to go on, but it would be really interesting to see that! Let’s jump into the demo and have a look at how the model itself actually performs Okay, so you can see when I come in here, I’m basically running the NVFP4 one.

[13:17] I’ve run a bunch of the benchmarks on this myself. I definitely see, some differences, compared to, their official ones, both, positive and negative. but that also does sort of show how much, these things can actually, sort of change as you run them. if we come in here and just give it some sort of standard tests, you’ll see that we’re getting super fast, tokens out, and that’s because I’m running the NVFP4 version here, right? so you can see also just looking at the thinking in here, I’ll let that just run.

[13:49] if we look at the thinking in here, it’s quite verbose in the thinking. it has gone through… In this case, it’s basically just sort of done, an evaluation out. It hasn’t actually done any sort of what I would call numbered thinking in here. we go through, it ran the task and it passed If we give it something a little bit harder We’ll see for a number of these that we’re not getting what I would call numbered thinking in here. if we look at the output, this is basically generating, pretty quickly. I’m generally seeing sort of like around the 200 tokens per second. If I give it something that’s more sort of freeform like this, let’s see

[14:22] what the output, that we’re getting is And you can see here now this time I’ve basically given it a system prompt as well. we’re getting, quite a bit of thinking, going on here, and the thinking can vary quite a bit on this model. I’ve seen with these kind of things, sometimes the thinking is just for a few hundred, tokens. Sometimes it can be in the thousands. Now you’ll notice the other thing here is we’re getting the numbered thinking. So you can see here we’ve got the numbered thinking, going on. We’ve got like deconstruct the request, initial brainstorm, structuring the essay, drafting the content, really sort of a stock standard good, sort

[14:58] of thinking process, around this. certainly not like the Neuralese that we’ve seen from some of the more modern models, where they tend to sort of abbreviate the thinking down But here you can see that we’ve generated, almost 6,000 tokens. We’re getting a bit over 210 tokens, per second, which is kind of around the average. I would say I’m sort of seeing around, anything sort of 200, 212. That’s quite common here. Now, you can see that there wasn’t a lot of pre-fill in this one. So what I’ll do is I’ll basically give it the same essay back and

[15:29] then ask it to basically grade it. So we’ve actually got quite a lot of pre-fill going on Okay, so I’m asking it, “Please look at this essay and measure and check it for accuracy.” This is exactly the text that it wrote before. We can see coming out of it, we’ve got a fair bit of thinking in there, just going through that. and then we’ve got the overall assessment. it’s interesting that it only scores itself around 85% accurate. in this case, if we go through, it talks about different things that were… that it sort of wrote in the first one that are incorrect.

[15:59] It then goes through and gives some revisions for it. You see this one we had pre-fill was over 2,000 tokens, and the token speed there for the pre-fill is super fast. And you can see the generation speed is almost exactly what we had, before And when we ask it to rewrite it, it’s basically then going through and doing that. if we look at sort of agent tasks, you’ll see that, it seems to be very good at using tools, from my tests. there’s no issues around things like that it’s able to go through different steps, run all those things, quite well And the main advantage of this is

[16:33] just that it’s a lot faster, especially if you don’t have a very fast GPU. Now, the version I’m using here is definitely not as optimized as the one that they made the megakernel for on the Mac. that seems to be, a very unique thing that they’ve done. It would have been a nice thing to see them take that Eureka Machine and then point it at the, CUDA kernels and actually improve those as well. But I could imagine that that’s actually something that’s reasonably quite valuable They perhaps don’t want to give away the CUDA optimizations, Just like we’ve seen

[17:03] with ThinkingCap, where a lot of these companies are giving away one version, but then charging enterprises for other versions, et cetera If you’re looking to see where this will fit on your GPU and perhaps, what you could actually do with this, I put this together basically just showing different GPUs, and, will you be able to run this or not? even on the RTX Pro with 96 gigabytes, I still can’t run the full bfloat, 16 version in there. You’re gonna probably need like an H200 or you’re gonna need multiple GPUs, to do this. you can run the NVFP4 version though quite, easily not to mention a bunch

[17:36] of the, Unsloth quants and other quants that are out there, that you can run on much smaller GPUs Alright, so where does that leave us? Well, if you’ve got a pretty powerful, Mac Pro with 48 gigs of memory and you want a fast local, coding model, I think Flint is really well worth trying. if you’re on something like a DGX Spark or a bigger GPU, you’ll still get a fast mixture of experts coder. probably not gonna get that 130 tokens per second headline there Now for the Eureka Machine itself, We’re gonna have to see, do they scale up

[18:06] to try and do a frontier level model? I’d love to see them take on a dense model like the 27B and actually beat that and then don’t forget we’ve got Qwen 4 just around the corner with a whole bunch of Engrams ideas and stuff like that, which they took from DeepSeek So I do think we’re gonna see a lot more ideas of this recursive self-improvement stuff, starting to take off. Anyway, let me know in the comments what you think. If you’ve tried out Flint, how was it? How has it held up for you? I know many of you are really interested in the MoEs rather than a dense model

[18:37] just because it’s easier to run but it still does seem that you take quite a hit, when you do that as opposed to going for a fully dense model. anyway, as always, if you found the video useful, please click like and subscribe, and I will talk to you in the next video. Bye for now.