{"slug": "testei-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-pena", "title": "Testei o Bonsai 27B, o modelo que cabe no seu telefone. Vale a pena?", "summary": "Prism ML, a Caltech spinout, compressed the 27-billion-parameter Qwen 3.6 model to under 4GB, fitting entirely on a phone. Testing showed the compressed models lost specific factual knowledge but performed equally on coding tasks, and the most compressed 1-bit version completed a novel programming task faster than the original.", "body_md": "cat >> artigo.txt << EOF\n\nNos últimos dias apareceu um modelo chamado **Bonsai 27B** rodando solto pelas redes e, confesso, no começo achei que era só mais um \"recorde de compressão\" pra vender case. Um time chamado Prism ML (spinout da Caltech) pegou o Qwen 3.6, um modelo de 27 bilhões de parâmetros que originalmente pesa ~54GB em FP16, e conseguiu encolher ele pra caber **inteiro no seu telefone**, ocupando menos de 4GB.\n\nIsso não é pouca coisa. Compressão agressiva desse tipo normalmente vira ruído — o modelo passa a alucinar mais, esquece regras básicas, trava em tarefas simples. Então a pergunta que eu queria responder não era \"será que funciona\", era **onde exatamente ele quebra**.\n\nO Bonsai vem em dois sabores:\n\nPra comparação valer alguma coisa, o \"modelo pai\" (Qwen 3.6) não foi testado no FP16 cru — ninguém roda 54GB em casa mesmo. Testei ele numa quantização Q4 (a mesma que a galera já usa no dia a dia), em ~16,8GB. Ou seja, mesmo o \"controle\" do experimento já vinha comprimido, só que do jeito convencional. A pergunta real era: **ir além do Q4 compra alguma coisa a mais, pra pior ou pra melhor?**\n\nComecei pelo óbvio: conhecimento factual solto. Perguntei, várias vezes cada, em que ano aconteceu um evento histórico bem específico.\n\nIsso confirma algo que já era esperado na teoria: comprimir um modelo apaga primeiro a informação que aparece **pouco** durante o treinamento. Fatos muito específicos (tipo a data exata de um evento histórico) somem rápido. Já padrões gerais de linguagem e raciocínio — que aparecem o tempo inteiro nos dados — sobrevivem muito melhor.\n\nConclusão prática: se você quer um chatbot de conhecimento geral, pra tirar dúvida solta ou resumir assunto que você não domina, **esse não é o modelo**. Nem o ternário, nem o 1-bit. A queda aqui é limpa demais pra ignorar.\n\nSó que aí vem a parte interessante: em tarefas de código, a história muda completamente.\n\nTestei bugs clássicos, incluindo uma race condition real — duas transações mexendo no mesmo saldo sem nenhum lock, o tipo de bug que a indústria documenta como difícil porque exige raciocinar sobre execução fora de ordem. Rodei cada correção três vezes seguidas pra garantir que não era sorte.\n\nResultado: os três modelos (original, ternário e 1-bit) resolveram igual. Nove de nove nos três. Zero separação.\n\nA explicação mais provável não é \"os modelos comprimidos são geniais\", é que esse tipo de bug catalogado já está bem representado em qualquer treinamento moderno hoje em dia. Difícil pra um humano não significa necessariamente fora do que o modelo já viu.\n\nPra realmente separar os três, precisei ir pra uma tarefa aberta: pedir que cada um criasse uma composição visual programática nova, usando uma lib de animação em React conectada a um design system específico. E aqui apareceu o achado que eu não esperava.\n\nNa primeira tentativa, os três erraram — mas de formas bem diferentes:\n\nSó que o desfecho é o que mais me surpreendeu: o modelo **mais comprimido de todos** (1-bit) fechou sem erro em apenas duas tentativas. O ternário levou dez tentativas pra convergir, e ainda travou o backend gráfico do servidor no meio do caminho (erro real de memória, exigiu reiniciar tudo do zero). O modelo original, com toda sua capacidade intacta, levou quatro tentativas porque gastou tempo demais só explorando o código antes de escrever qualquer coisa.\n\nNenhum dos três tinha problema de raciocínio sobre o bug em si — todos sabiam o que precisava mudar. A diferença real foi **como cada um lidou com a própria ferramenta de edição**. Numa tarefa com prazo e timeout, o modelo mais rápido — que por acaso é o mais comprimido — foi o único que entregou dentro de um orçamento de tempo razoável. Ter mais parâmetros não significa terminar o trabalho primeiro.\n\nAntes de qualquer benchmark bonito, tem um detalhe chato: o Bonsai **não roda no Ollama**, que é a ferramenta mais comum pra rodar modelo local. A versão ternária roda no MLX padrão da Apple, mas a versão 1-bit exige um fork customizado feito pela própria Prism ML, com binário pré-compilado.\n\nE tem mais: no MLX padrão, o ternário apresentou um bug de determinismo — independente da temperatura configurada, ele sempre devolvia exatamente a mesma resposta, byte a byte. Só resolvi trocando pro mesmo runtime customizado do 1-bit.\n\nMoral da história: quanto mais agressiva a compressão, mais dependente de infraestrutura própria (e não padrão) o modelo fica. É meio irônico, porque isso é o oposto do que a palavra \"acessibilidade\" sugere. Se você não tem paciência pra mexer em binário e configuração de servidor, essa é fricção real antes mesmo de digitar a primeira pergunta.\n\nVale registrar também: numa primeira tentativa, o 1-bit simplesmente não chamava nenhuma ferramenta, só descrevia em texto o que faria. Parecia limitação do modelo — mas era erro de configuração (template de conversa trocado por um genérico, contexto pequeno demais pro prompt de sistema caber). Corrigido isso, ele passou a chamar ferramenta sem problema. Fica o alerta: antes de concluir que o modelo \"não é capaz\" de algo, vale checar sua própria configuração.\n\nA própria Prism ML avisa que o modelo não é recomendado pra uso agêntico longo, com muitos arquivos — é justamente onde a compressão mais perde nos benchmarks internos deles, numa escala bem maior que matemática ou código isolado.\n\nNos meus testes, rodando tarefa por tarefa, não vi essa queda acontecer. Mas o tipo de projeto longo e multiarquivo que eles descrevem é bem maior do que qualquer coisa que consegui testar em algumas horas. Então as duas leituras são possíveis — vai depender do tamanho real do seu projeto. Na prática, o conselho que sobra: use o Bonsai plugado no editor, respondendo pergunta por pergunta, revisando trecho de código — não como agente autônomo solto num harness de terminal, decidindo sozinho editar vários arquivos, turno atrás de turno, sem ninguém no meio. Ele é um ótimo copiloto. Não é feito pra ser piloto automático.\n\nSe você quer um assistente de conhecimento geral: passa longe. A queda de qualidade ali é grande e consistente demais pra ignorar.\n\nSe o motivo de você estar de olho nesse modelo é **codar em casa, depois do expediente, sem gastar token de plano pago**: os dois modelos comprimidos resolveram exatamente os mesmos problemas que o modelo original resolveu, do bug clássico ao típico problema de entrevista técnica — e na única tarefa aberta e realista testada, foi justamente o mais comprimido dos dois que terminou primeiro.\n\nEntre os dois filhos, minha recomendação vai pro **1-bit**, não pro ternário: é menor, mais rápido, e na única vez que competiram diretamente, convergiu em duas tentativas contra dez do ternário — sem os travamentos de infraestrutura que apareceram no caminho. O ternário te dá um pouco mais de precisão em conhecimento factual, mas não o suficiente pra compensar o resto.\n\nTem ainda um uso que passa despercebido: dedicar uma fatia pequena da máquina (uns 5GB de RAM) pra deixar o Bonsai residente, rodando local o tempo todo, resolvendo consultas pontuais dentro de um pipeline maior. Não é o cérebro principal do projeto, mas é uma peça barata que resolve pergunta simples sem sair da máquina e sem gastar token de API. Benchmarks independentes, inclusive, colocam o Bonsai entre 8 e 12 pontos atrás do Qwen original numa bateria ampla de tarefas — o que bate com o que os testes de conhecimento mostraram: a perda existe, só que ela não aparece onde a maioria das pessoas está procurando.\n\nPegar um modelo de 27 bilhões de parâmetros e comprimir 14 vezes até caber em menos de 4GB, sem perder nada mensurável em capacidade de código ou uso de ferramenta, é um trabalho de engenharia genuinamente impressionante. A conta fecha — só que ela fecha num lugar bem mais específico do que \"conhecimento geral\", e isso muda totalmente a forma como vale a pena usar esse modelo.\n\nEOF", "url": "https://wpnews.pro/news/testei-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-pena", "canonical_source": "https://dev.to/lincoln_romais/testei-mentalmente-no-hd-e-na-paciencia-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-1b7e", "published_at": "2026-07-30 13:18:02+00:00", "updated_at": "2026-07-30 13:32:42.569749+00:00", "lang": "en", "topics": ["machine-learning", "large-language-models", "ai-research", "ai-products", "developer-tools"], "entities": ["Prism ML", "Caltech", "Qwen 3.6", "Bonsai 27B", "Ollama", "MLX", "Apple"], "alternates": {"html": "https://wpnews.pro/news/testei-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-pena", "markdown": "https://wpnews.pro/news/testei-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-pena.md", "text": "https://wpnews.pro/news/testei-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-pena.txt", "jsonld": "https://wpnews.pro/news/testei-o-bonsai-27b-o-modelo-que-cabe-no-seu-telefone-vale-a-pena.jsonld"}}