Qwen 27B com 6 GB de VRAM...

Autoria: Prompt Engineering · 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: Qwen 27B on 6GB VRAM… · Canal: Prompt Engineering · 14:13 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos locais e open source

Resumo

O vídeo compara o Bonsai 2, uma versão comprimida do Qwen 3.8 27B que ocupa cerca de 6 GB, com o modelo original em tarefas simples e trabalhos agentic mais longos. Nos testes curtos, os resultados dos dois modelos são parecidos; em seis projetos extensos, porém, o Qwen conclui aplicações funcionais, enquanto o Bonsai 2 trava ou não chega a produzir páginas funcionais. A análise dos registros mostra que o Bonsai 2 repete chamadas de ferramentas e tem dificuldade para avançar em tarefas complexas. O apresentador conclui que o modelo é útil para chat e ajuda rápida com código, mas recomenda um modelo completo para trabalhos agentic longos e sem supervisão.

Pontos-chave

O Bonsai 2 usa quantização ternária e ocupa cerca de 6 GB, segundo o vídeo.
A alegação de desempenho de 98% é uma média de 20 benchmarks curtos, com o thinking ativado no esforço máximo.
Em tarefas simples, os resultados do Bonsai 2 e do Qwen 3.8 27B foram semelhantes, mesmo com o thinking desativado.
Nos seis projetos agentic longos, o Qwen produziu aplicações funcionais; o Bonsai 2 não produziu nenhuma página funcional.
Nos registros do Bonsai 2, chamadas repetidas de ferramentas e exploração excessiva dos arquivos dificultaram o avanço das tarefas.
O documento técnico da Prism ML relata resultados menores em benchmarks agentic longos: cerca de 76% no Terminal Bench 2.1 e 75% no Sweep Bench Verified.
O apresentador recomenda examinar os registros de execução para entender o comportamento de agents locais.
Para chat, ajuda rápida com código e chamadas curtas de ferramentas em um laptop, o Bonsai 2 pode ser uma opção útil; para trabalhos longos sem supervisão, o apresentador prefere um modelo completo.

Capítulos

Início	Capítulo	Resumo
00:00	A promessa do Bonsai 2 e o método de compressão	O vídeo apresenta a alegação de desempenho do Bonsai 2, explica sua quantização ternária e discute o que os benchmarks medem.
04:44	Configuração dos testes e tarefas curtas	O apresentador descreve a comparação entre os modelos e mostra que eles têm resultados semelhantes em tarefas simples.
08:57	Projetos agentic longos e falhas do Bonsai 2	Nos seis projetos mais extensos, o Qwen conclui aplicações funcionais, enquanto o Bonsai 2 falha e repete chamadas de ferramentas.
12:06	Benchmarks longos e conclusões	O vídeo contextualiza os resultados em benchmarks agentic longos e recomenda o Bonsai 2 para usos curtos, não para trabalho prolongado sem supervisão.

Citações

É possível obter 98% do desempenho de um modelo de 27 bilhões de parâmetros com menos de 8 GB? — 00:00

Esse 98% é uma média de 20 benchmarks, medida com o thinking ativado no esforço máximo. — 04:44

Resultados parecidos em benchmarks não significam resultados parecidos em trabalho agentic de verdade. — 12:38

Para trabalhos agentic longos e sem supervisão, eu ainda escolheria um modelo completo. — 13:41

Conceitos e entidades

Bonsai 2 (modelo): Modelo comprimido apresentado pela Prism ML e comparado ao Qwen 3.8 27B.
Qwen3.8 27B (modelo): Modelo usado como referência na comparação de tarefas curtas e agentic.
Prism ML (empresa): Empresa que desenvolveu o Bonsai 2 e publicou resultados de benchmarks do modelo.
ternary quantization (conceito): Método que representa cada peso do modelo com um de três valores: -1, 0 ou +1, combinado a um fator de escala.
Pi (ferramenta): Harness de programação agentic usado para executar os dois modelos com as mesmas ferramentas e instruções.
llama.cpp (repo): Implementação usada para executar o Bonsai 2 localmente no Mac durante os testes.
MLX (ferramenta): Framework da Apple com suporte nativo ao Bonsai 2, mas que foi mais lento que o llama.cpp nos testes do vídeo.
Terminal-Bench 2.1 (conceito): Benchmark agentic longo citado no documento técnico da Prism ML, no qual o Bonsai 2 manteve cerca de 76% da pontuação original.
SWE-bench Verified (conceito): Benchmark baseado em issues reais do GitHub, no qual o Bonsai 2 manteve cerca de 75% da pontuação original, segundo o vídeo.

Tradução completa (pt-BR)

00:00 Dá para obter 98% do desempenho de um modelo de 27 bilhões de parâmetros com menos de 8 GB? É exatamente isso que a Prism ML afirma com seu novo modelo Bonsai 2. Mas a questão é: ele realmente se sustenta em testes no mundo real? Então, coloquei o modelo à prova no meu próprio benchmark, comparando-o diretamente com o Qwen 3.8 27B. Em tarefas mais simples, ele chega bem perto. Basicamente, dá empate. Mas, em tarefas agentic mais longas, nas quais o modelo precisa planejar, escrever código e verificar

00:31 o próprio trabalho e depois continuar a partir daí, a história é bem diferente. Então, neste vídeo, quero mostrar o tipo de impacto que a compressão pode ter em um modelo, onde isso aparece de fato e como você pode identificar isso por conta própria, porque há muito que podemos aprender com isso. Certo, mas antes precisamos falar sobre o que exatamente é o Bonsai 2. A forma como ele é feito é muito interessante e faz parte da história toda que quero abordar. Então,

01:02 O Qwen 3.8 27B em precisão total armazena cada peso como um número de 16 bits. Então, estamos falando de 54 GB se você usar precisão de ponto flutuante de 16 bits, mais memória do que a maioria dos notebooks ou GPUs para consumidores tem. O Bonsai 2 reduz isso para cerca de 6 GB, aproximadamente nove vezes menos. Normalmente, quando você quer diminuir um modelo, você o quantiza. Uma boa maneira de entender a quantização é

01:33 como arredondamento. Você pega um modelo que já foi treinado e arredonda cada peso para um número que precisa de menos bits. É barato e rápido, e é o que vemos na maioria dos modelos por aí. Mas o problema é que, se você arredondar demais, o modelo começa a perder a inteligência que está nos pesos. Agora, uma versão comum de 2 bits do mesmo modelo Qwen terá cerca de 7,3 GB. E, de acordo com a própria tabela da Prism ML, ela mantém cerca de

02:03 88% das pontuações de benchmark. Depois, há uma versão mais inteligente dessa ideia, que abordei no meu vídeo de 12 estrelas. A ideia era não quantizar tudo. Você mantém em maior precisão a parte mais importante do modelo e quantiza agressivamente o restante. Ou seja, é uma quantização realmente seletiva, mas ainda é o arredondamento de um modelo que já foi treinado. Já o Bonsai 2 segue um caminho bem diferente. Ele parte do Quen 3.8 27B pré-treinado e depois é treinado para

02:37 um novo formato. Então, em vez de simplesmente ser arredondado para esse formato, segundo a Prism ML, ele foi treinado em uma TPU do Google, mas eles não publicaram o método, os dados nem quanto poder computacional foi necessário. Então, parte disso é simplesmente uma caixa-preta. Mas temos os pesos finais e o formato em que ele é quantizado. Agora, o Bonsai usa algo chamado quantização ternária, que converte cada peso em um de três valores possíveis: -1, 0 ou +1.

03:09 Nesse caso, os pesos positivos grandes viram +1, os negativos grandes viram -1 e os pequenos são arredondados para zero. Eles também usam um fator de escala adicional para preservar a magnitude do peso. Assim, cada grupo de 128 pesos compartilha uma escala, e o peso real é basicamente essa escala multiplicada pelo valor ternário. São necessários cerca de 1,7 bit por peso para armazenar esses valores ternários mais o fator de escala, o que é cerca de nove

03:40 vezes menos que 16 bits, que é a precisão total do modelo Quen 3.8 7B. Eles também usam outro truque. Em qualquer rede neural padrão, um punhado de pesos enormes pode fazer a escala compartilhada de todo o grupo de 128 pesos sair completamente do controle. Para corrigir isso, antes de transformar tudo em valores ternários, eles aplicam uma matriz de rotação para suavizar esses picos enormes entre todos os valores. Depois que esses números discrepantes são distribuídos, encaixá-los nesses três

04:12 valores distintos fica bem mais fácil. Eles afirmam que isso ajuda a preservar a inteligência do modelo. Uma versão ingênua de dois bits mantém aproximadamente 88%. O Bonsai reduz ainda mais o tamanho e, ao mesmo tempo, alcança uma pontuação de 98% em benchmarks importantes. A ideia, portanto, é obter um arquivo menor e um desempenho melhor, o que vai meio que contra o que costuma acontecer. Agora, um detalhe importante que quero mencionar é que os 98% são uma média de 20

04:44 benchmarks e foram medidos com o thinking do modelo ativado no esforço máximo. Lembre-se disso, porque vamos voltar a esse ponto nos meus próprios experimentos. A maioria desses benchmarks e das comparações que você vai ver é de uma única rodada. Você dá um prompt ao modelo, ele responde e você avalia a resposta. Mas não é assim que usamos esses modelos em uma configuração agentic. Em um loop agentic, o modelo vai ler arquivos, escrever código, executá-lo, fazer capturas de tela, encontrar bugs, corrigi-los e planejar

05:17 a partir disso. E, para fazer tudo isso, às vezes são necessárias dezenas ou centenas de etapas. Então, a pergunta de verdade que eu queria testar era: esses 98% se mantêm em um loop agentic? Certo, aqui está a configuração que experimentei. De um lado, temos o Bonsai 2 rodando localmente no meu Mac, por meio de um fork próprio da Prism ML do llama.cpp. Do outro lado, temos o quant 3.8 27B original em precisão total, que é exatamente com o que a Prism ML o compara. Agora, não consigo executá-lo

05:48 no meu MacBook, então vamos usar o OpenRouter. Os dois modelos estão rodando dentro do Pi, o harness de programação agentic que estou usando, com as mesmas ferramentas, os mesmos prompts e as mesmas instruções. Para os dois, deixei o thinking desativado. O motivo foi obter uma linha de base bem clara do próprio modelo. E deixar o thinking desativado também aparece nas tarefas mais difíceis, que vamos ver daqui a pouco. Mais uma observação,

06:20 a Prism ML também oferece suporte nativo ao framework MLX da Apple, mas, nos meus testes, ele foi bem mais lento que o Llama.cpp, então optei pelo Llama.cpp. Certo, executei dois tipos diferentes de tarefas. O primeiro conjunto é de tarefas curtas, do tipo que as pessoas costumam testar. O segundo conjunto consiste em projetos agentic longos e, nesses casos, não avaliei os resultados só no olho. Cada projeto vem com uma lista de verificação de requisitos específicos, e um script confere cada um automaticamente. E isso é

06:51 importante, porque não estou apenas usando o critério de “parece bom para mim”. Há um teste objetivo: por exemplo, temos um certo número de recursos que queremos que o agent crie, e depois o avaliador verifica se ele criou esses recursos. Certo, vamos começar com as tarefas mais simples. A primeira é uma tarefa de desenho. O prompt era desenhar, em SVG, um polvo tocando uma bateria, com limites rígidos para cores e formas. O Qwen marcou sete de 10, e o Bonsai marcou seis, com base nos critérios que forneci. Os dois

07:24 ficaram bem próximos. Em seguida, um relógio analógico que precisava mostrar a hora exata indicada pela URL que forneci. Isso é mais difícil do que parece, porque o verificador mede para onde cada ponteiro aponta, com precisão de poucos graus. Nesse caso, os dois tiveram dificuldades: o Qwen marcou três, e o Bonsai, quatro. Depois, uma tarefa de depuração: dei aos dois modelos um jogo de Breakout com seis bugs inseridos. Quatro foram relatados pelos jogadores, e dois

07:54 só dava para encontrar lendo o código. Curiosamente, o Bonsai corrigiu cinco dos seis e marcou 8,5; o Qwen marcou sete neste caso. Depois, há duas tarefas agentic curtas. Uma é uma planilha de vendas bagunçada com quatro armadilhas escondidas, como linhas duplicadas e uma confusão entre moedas. A outra é um relatório de reembolsos com problemas em um banco de dados. Os dois modelos identificaram todas as armadilhas e corrigiram o relatório, o que é bem animador, não é? Então, nas tarefas mais simples, parece que os dois estão

08:26 empatados. Depois, há um teste de contexto longo. Dei aos dois modelos uma base de código real com cerca de 100.000 tokens, na qual inseri alguns fatos, e fiz sete perguntas. Os dois acertaram todas. A última tarefa foi criar, em uma única etapa, um clone de Linear em um único arquivo, e os dois produziram uma página que travava ao carregar, certo? Então, os dois falharam da mesma forma. Parece que, nas tarefas mais simples, os sucessos e as falhas são bem parecidos.

08:57 Então, eu diria que a afirmação dos 98% realmente se sustenta para tarefas mais simples, mesmo com o modo de raciocínio desativado. Mas todas essas eram tarefas que você consegue concluir em uma resposta ou em apenas alguns passos. Certo, vamos falar da segunda rodada: as construções com agents. O segundo conjunto tem seis construções reais. A primeira é uma simulação de buraco negro com lente gravitacional; depois, uma batalha de navios piratas em um estilo de no máximo um bit; e, em seguida, uma tartaruga-marinha voxel em um recife de coral. Outra é um rastreador da ISS

09:27 que posiciona a estação em um globo 3D com posicionamento celular real; depois, uma página de lançamento criada a partir de um resumo de pesquisa. E a última é um clone completo do Linear, com ciclos de equipe, atalhos de teclado e desfazer. Neste caso, o modelo precisa realmente planejar, escrever vários arquivos, executá-los, analisar capturas de tela e corrigir o que está quebrado. Então, o Qwen marcou 35 de 60. Ele criou o clone do Linear, que atende a 19 dos 24 requisitos. A página de lançamento, ele

10:00 atende a todos os 11 de 13. No rastreador da ISS, são 9 de 13. Na cena da tartaruga, são 9 de 15. Ele teve dificuldades com os gráficos mais complexos, como a física do buraco negro e as regras rígidas de pixels da cena dos piratas. Mas conseguiu entregar um app funcional de verdade. O Bonsai falhou completamente nessas tarefas. Ele não produziu uma única página funcional nas seis tarefas. Em cinco delas, nem chegou a criar uma página na pasta do projeto.

10:32 Certo. Uma coisa que quero destacar: o Bonsai está sendo executado no meu Mac. O Qwen está sendo executado pela API. Então, voltei a um conjunto anterior de execuções que fiz no meu DGX Spark, cerca de 10 dias atrás, em que o Bonsai teve horas para cada tarefa. Ele também falhou exatamente da mesma forma naquela ocasião. E acho que é muito importante analisar por que essas falhas acontecem. Eu estava guardando todos os logs e encontrei algumas coisas bem interessantes. Em tarefas de campo difíceis, ele geralmente

11:02 fica preso simplesmente olhando ao redor. O Bonsai fez 153 chamadas de ferramentas na tarefa do rastreador da ISS. 150 delas foram apenas para olhar ao redor, ler arquivos, listar arquivos e fazer buscas. Outra coisa era entrar em loop. Percebi que, em muitas dessas tarefas mais difíceis, ele executava uma ferramenta, obtinha os resultados e depois executava a mesma ferramenta de novo, obtendo repetidamente os mesmos resultados. Por exemplo, em um caso, ele executou uma ferramenta 114 vezes. Agora,

11:35 comparando diretamente com o Qwen, a maior repetição entre esses seis projetos foi de seis vezes. Então, o Qwen também tinha seus próprios problemas. Na cena dos piratas, passou cerca de 40 minutos tentando corrigir um erro de sintaxe no próprio código. E tem o hábito de reescrever arquivos inteiros em vez de editá-los. Mas esses são erros de um modelo que está construindo algo. O Bonsai e o Qwen são bem diferentes. O Bonsai consegue escrever código perfeitamente fluente, mas parece não perceber que

12:06 já fez alguma coisa. Então, em tarefas mais difíceis, basicamente nunca avança. Certo. Depois de executar os experimentos, tentei entender o que exatamente estava acontecendo. Notei que o próprio white paper da Prism ML aponta para a mesma coisa. Eles citam esse número de 98% em 20 benchmarks mais curtos, mas o artigo também relata dois benchmarks agentic longos, e esses dois não entram na média. No Terminal Bench 2.1, o Bonsai mantém cerca de 76% da pontuação original. No Sweep

12:38 Bench Verified, que é baseado em issues reais do GitHub, fica em cerca de 75%. Para ser justo, ainda é uma pontuação impressionante para um modelo desse tamanho, mas mostra que ele é um bom modelo para tarefas mais curtas. Certo, então quais são exatamente as conclusões disso? Primeiro, ter resultados parecidos em benchmarks não significa ter resultados parecidos em trabalho real com agents. Em tarefas curtas, o Bonsai basicamente empata com o modelo completo, mas, em construções longas, não conseguiu concluir praticamente nada, pelo menos nos meus experimentos.

13:09 Segundo, se você executa agents localmente, leia os traces, porque eles vão mostrar exatamente o que está acontecendo com o agent. Isso também pode ajudar você a melhorar os loops do seu agent. Terceiro, se quiser executar esse modelo em um MacBook, recomendo muito experimentar a versão do Llama CPP da Prism ML, feita para qualquer coisa agentic, porque ela armazena em cache a conversa entre os passos; a versão MLX, pelo menos na gravação deste vídeo, não faz isso. E, por fim, onde isso deixa o Bonsai 2? Então, eu

13:41 diria que, para chat, ajuda rápida com programação e chamadas curtas de ferramentas em um laptop, ele é, na verdade, um modelo muito bom. E a compressão realmente funciona nesses casos. Para trabalho agentic longo e sem supervisão, eu ainda escolheria um modelo completo. A compressão nos permite executar esses modelos grandes em máquinas locais, mas, em geral, ela não preserva a verdadeira inteligência do modelo. Tenha isso em mente se estiver optando por um modelo local quantizado em vez de uma versão completa maior. Enfim, espero que este vídeo tenha sido

14:13 útil. Obrigado por assistir e, como sempre, até o próximo vídeo.

Transcrição original

[00:00] Can you get 98% performance of a 27 billion parameter model in under 8 GB? That’s exactly what Prism ML is claiming with their new Bonsai 2 model. Now, the question is does it actually hold up in real-world testing? So, I put it to a test in my own benchmark, directly comparing it with the Qwen 3.8 27B. And on simpler tasks, it is really close. It basically is a tie. But on longer agentic tasks, where the model has to plan, write code, and check

[00:31] its own work, and then keep going from there, it is a very different story. So, in this video, I really want to show you what kind of impact compression can have on a model, and where it actually shows up, and how you can spot it yourself, because we can learn a lot from it. Okay, but before that, we need to talk about what exactly Bonsai 2 is. Because the way it is made is very interesting, and it’s a part of the whole story that I want to cover. So,

[01:02] Qwen 3.8 27B at full precision stores every weight as 16-bit number. So, we’re talking about 54 GB if you use 16-bit floating-point precision, is more than memory most laptops or consumer GPUs have. Bonsai 2 cuts that down to about 6 GB, which is roughly nine times smaller. Now, usually when you want to make a model smaller, you quantize it. A good mental model of quantization is

[01:33] rounding. You take a model that’s already trained, and you round every weight to a number that needs fewer bits. It’s cheap and fast, and you see this for most models out there. But the problem is if you round too hard, the model starts losing its intelligence, is in the weights. Now, an ordinary 2-bit version of the same Qwen model is going to be about 7.3 GB. And according to Prism ML’s own table, it keeps about

[02:03] 88% of the benchmark scores. Then, there is a smarter version of that idea, which I covered in my 12-star video. The insight there was that you don’t quantize everything. You keep the part of the model that matters most at higher precision, and you aggressively quantize the rest. So, it’s really selective quantization, but it’s still rounding a model that’s already been trained. Now, Bonsai 2 takes a very different path. It starts from the pre-trained Quen 3.8 27B, and then it’s trained into

[02:37] a new format. So, instead of just being rounded into it, Prism ML says that it was trained on Google’s TPU, but they haven’t published the method, the data, or how much compute it took. So, part of it is simply black box. But, we do have the final weights and the format in which it is quantized. Now, Bonsai uses uh something called ternary quantization, which converts every weight into one of three possible values: -1, 0, or +1.

[03:09] In this case, the big positive weights become +1, big negative becomes -1, and the small ones are rounded to zero. They also use an additional scale factor to preserve how big weight was. So, every group of 128 weights share one scale, and the real weight is basically that scale times the ternary value. Now, you need about 1.7 bits per weight in order to store those ternary values plus the scale factor, which is about nine

[03:40] times smaller compared to 16, which is the actual uh full precision for the Quen 3.8 7B model. They also use an additional trick. In any standard neural network, a handful of massive weights will completely blow out the shared scale for entire group of those 128 weights. To fix that, before turning everything into ternary, they apply a rotation matrix to smooth out those huge spikes across all the values. Once those outliers numbers are spread out, fitting them into those three

[04:12] distinct value gets a lot cleaner. Now, they claim that this helps preserving the intelligence of the model. So, a naive two-bit version retains roughly 88%. Bonsai shrinks the footprint further while hitting a 98% rating on key benchmarks. So, the idea is that you get a smaller file alongside better performance, which kind of goes against what usually happens. Now, one important detail that I want to mention that 98% is an average over 20

[04:44] benchmarks, and it was measured with the models thinking turned on at maximal effort. Keep that in mind because we’re going to come back to it in my own experiments. Now, most of these benchmarks and most of the comparisons that you’re going to see are single shot. You give the model prompt, it gives you an answer, and you score the answer. But, that’s not how we are using these models in agentic setup. In an agentic loop, the model is going to read files, write code, run it, take screenshots, find bugs, fix those, plan

[05:17] around it. And, in order to do all of these things, they are going to take sometimes dozens or hundreds of steps. So, the real question that I wanted to test was does that 98% hold up in an agentic loop? Okay, so here’s the setup that I tried. On one side, we have Bonsai 2 running locally on my Mac through Prism ML’s own fork of llama.cpp. On the other side, we have the original quant 3.8 27B at full precision, which is exactly what Prism ML compares it against. Now, I can’t run

[05:48] that on my MacBook, so we are using it to open router. Both of these models are running inside Pi, which is the agentic coding harness that I’m using within the same tools and same prompts with the same instructions. Now, for both of them, I kept the thinking off. And the reason was that I wanted to get a really clean baseline for the model itself. And the thinking off actually shows up in harder tasks, too, which we are going to look at in a minute. One more note,

[06:20] Prism ML also have native support for Apple’s MLX framework, but in my testing, it was much slower compared to Llama.cpp, so that’s why I went with Llama.cpp. Okay, so there are two different kinds of tasks that I ran. The first set is short, kind of thing people usually test. The second set is long agentic builds, and for those, I didn’t just eyeball the results. So, every build comes with a checklist of specific requirements, and a a script checks each one automatically. And this is

[06:51] important, so I’m not just using the this looks good to me. There is an objective test where uh say we have a certain number of features that we want the agent to build, and then the grader actually checks whether it built those features or not. Okay, so let’s start with the simpler tasks. The first one is a drawing task. So, the prompt was draw an octopus playing a drum kit as an SVG with strict limits on colors and shapes. Gwen scored seven out of 10, Bonsai scored six based on the rubric that I provided. Both of

[07:24] them are pretty close. Next, an analog clock that has to show an exact time from uh the URL that I provide. Now, this is harder than than it looks because the checker measures where every hand points down to a few degrees. In this case, both of them actually struggled, so Quen got three, Bonsai got four. Then a debugging task, so I gave both models a breakout game with six planted bugs. Four were reported by players, and two

[07:54] you could only find by reading the code. Interestingly enough, Bonsai fixed five out of the six and scored 8.5, Quen scored seven in this case. Then there are two short agentic tasks. So, one is a messy sales spreadsheet with four hidden traps, like duplicate rows and a currency mix-up. The other is a broken refund report in a database. Both models caught every trap and fixed the report, which is actually pretty encouraging, right? So, for on simpler tasks, seems like both of them are head

[08:26] to head. And then there’s a long context test. So, I gave both models a real code base of about 100,000 tokens with some facts planted in it and asked seven questions. Now, both of them got every single one right. And the last one was one-shot linear clone in a single file, and both of them produced a page that crashed on load, right? So, same failure on both sides. So, seems like for simpler tasks, both the successes and failures looks very similar.

[08:57] So, I would say that 98% claim actually holds up for simpler tasks, even if you have thinking off. But, all of these were tasks that you can finish in one answer on or in just few steps. Okay, so let’s talk about round two, the agentic builds. Uh the second set is six real builds. So, first is a black hole simulation with gravitational lensing, then a pirate ship battle in one bit max style, and then a voxel sea turtle on a coral reef. Uh another one is an ISS

[09:27] tracker that places the station on a 3D globe with a real cell positioning, and then a launch page built from a research brief. And the last one is a full linear clone with team cycles, keyboard shortcuts, and undo. Now, in this case, the model is required to actually plan, write several files, run them, look at screenshots, and fix what is broken. So, Quinn scored 35 out of 60. It built the linear that passes 19 of the 24 requirements. Lunch, it

[10:00] passes all 11 of 13. On the ISS tracker, uh it’s nine out of 13. On a turtle scene, it’s nine out of 15. Now, it struggled with the hardest graphics like the physics of the black hole and the strict pixel rules of the pirate scene. But, it did ship a real working app in Bonsai completely crashed on these. So, it didn’t produce a single working page across all six tasks. On five of them, it never even got to a page uh in its project folder.

[10:32] Okay. One thing that I want to point out. Uh the Bonsai is running on my Mac. Quinn is running through the API. So, I actually went to an earlier set of runs I did on my DGX Spark about 10 days ago where Bonsai had hours for every task. Now, it failed in exactly the same way there as well. And I think this is where it’s really important to look at why these failures happen. Uh so, I was keeping all of the logs and found some really interesting things. On difficult field tasks, it usually

[11:02] gets stuck on simply looking around. So, Bonsai made 153 tool calls uh on the ISS tracker task. 150 of them were those were just looking around, uh reading files, listing files, and searching. And one other thing was looping. So, I I noticed that on a lot of these harder tasks, it would run a tool, get the results, and then it would run that tool again and get the same results repeatedly. For example, in one case, it ran one tool 114 times. Now,

[11:35] when you compare directly to Qwen, the worst repeat across all of these six different projects was six. So, Qwen had its own problems. On the pirate scene, it spent about 40 minutes chasing one syntax error on its and its own code. And it has a habit of rewriting whole files instead of editing them. But, those are mistakes of a model that’s building something bonsai Qwen is way different. It can write perfectly fluent code, but it doesn’t seem to notice that

[12:06] it has already done something. So, on harder task, it basically never moves on. Okay. So, after running the experiments, I was actually trying to figure out what exactly was happening. So, I noticed that Prism ML’s own white paper points to the same thing. Now, they cite this 98% number on 20 shorter benchmarks, but their paper also reports two long agentic benchmarks, and those two are not in the average. On Terminal Bench 2.1, bonsai keeps about 76% of the original score. On Sweep

[12:38] Bench Verified, which is built from real GitHub issues, it’s about 75%. Now, to be fair, it’s still an impressive score for the model of its size, but it shows that it’s a good model for shorter task. Okay, so what exactly are the takeaways from this, right? So, first, matching on benchmarks doesn’t mean matching on actual agent work. On short tasks, bonsai basically ties up to the full model, but on long builds, it couldn’t really finish anything, at least in my experiments.

[13:09] Second, if you run agents locally, read the traces because they’re are going to tell you what exactly is happening with the agent. And this can also help you improve your agent to loops. Third, if you want to run this model on a MacBook, I would highly recommend to try out Prism ML’s Llama CPP built for anything agentic because it caches the conversation between steps and the MLX version at least doesn’t as of the recording of this video. And finally, where does that leave Bonsai 2? So, I

[13:41] would say for chat, quick coding help, and short tool calls on a laptop, it’s actually a pretty great model. And the compression actually works there. For long unsupervised agent work, I would still reach for a full model. So, compression enables us to run these big models on local machines, but in general, it doesn’t really hold the true intelligence of the model. Keep that in mind if you’re reaching out for a quantized local model against a bigger full version. Anyways, I hope you found

[14:13] this video useful. Thanks for watching, and as always, see you in the next one.