# Testei o Bonsai 27B, o modelo que cabe no seu telefone. Vale a pena? > Source: > Published: 2026-07-30 13:18:02+00:00 cat >> artigo.txt << EOF Nos ú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. Isso 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**. O Bonsai vem em dois sabores: Pra 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?** Comecei pelo óbvio: conhecimento factual solto. Perguntei, várias vezes cada, em que ano aconteceu um evento histórico bem específico. Isso 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. Conclusã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. Só que aí vem a parte interessante: em tarefas de código, a história muda completamente. Testei 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. Resultado: os três modelos (original, ternário e 1-bit) resolveram igual. Nove de nove nos três. Zero separação. A 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. Pra 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. Na primeira tentativa, os três erraram — mas de formas bem diferentes: Só 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. Nenhum 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. Antes 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. E 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. Moral 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. Vale 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. A 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. Nos 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. Se você quer um assistente de conhecimento geral: passa longe. A queda de qualidade ali é grande e consistente demais pra ignorar. Se 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. Entre 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. Tem 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. Pegar 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. EOF