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