Bonsai 2 chegou ao Ollama antes que alguém anunciasse que isso ia acontecer.

Em algum momento na madrugada de 17 de outubro de 2026, Ollama começou a disponibilizar Bonsai 2 — uma entrada de biblioteca com nove tags que abrange Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B e Bonsai 2 27B, cada um deles em dois empacotamentos, além de um alias padrão. A Prism ML não disse nada sobre isso. Não há publicação na página de notícias do fornecedor, nem uma linha no anúncio de 15 de outubro dos modelos pequenos — esse anúncio nomeia llama.cpp e MLX como os runtimes e um console hospedado como a demonstração, e não menciona o Ollama em momento algum. A listagem simplesmente existe, com todas as nove tags marcadas com a mesma idade de poucas horas, o que é a aparência de um push recente e não a de uma implantação gradual.

Então, a divisão honesta é esta. O que dá para saber agora, a partir do registro e dos arquivos: as tags, seus nomes, seus tamanhos exatos em bytes, seus digests de conteúdo e — como o Ollama distribui GGUF — a arquitetura e as strings de metadados dentro dos próprios pesos. Não confirmado: quem os empacotou, por que o anúncio do fornecedor omite a plataforma, se os kernels ternários estão no upstream do próprio motor do Ollama ou são vendorizados, e se algum dos números do fornecedor sobrevive à viagem. Essas são perguntas separadas, e este texto as mantém separadas.

O que está realmente na prateleira?

Nove tags, quatro tamanhos, três empacotamentos dos mesmos pesos. A página de biblioteca do Ollama lista um alias padrão por tamanho e uma -q2_0 variante por tamanho:

• bonsai-2:latest — 3,2 GB, corresponde ao 9B (digest c8b5462f8688)

• bonsai-2:2b e bonsai-2:2b-q2_0 — 911 MB, mesmo digest de2ccb4e7328

• bonsai-2:4b e bonsai-2:4b-q2_0 — 1,6 GB, mesmo digest 93edd652c932

• bonsai-2:9b e bonsai-2:9b-q2_0 — 3,2 GB, mesmo digest c8b5462f8688

• bonsai-2:27b e bonsai-2:27b-q2_0 — 8,3 GB, mesmo digest f3c4f4208659

A nomenclatura está fazendo mais do que parece. Duas tags por tamanho compartilharem um digest não é uma duplicata — é uma declaração sobre qual empacotamento o Ollama escolheu. Puxe o manifesto de bonsai-2:9b e a camada do modelo tem 2,557 GB. Esse é o arquivo do Ternary Bonsai 2 9B, Q2_0, medido no Hugging Face em 2,557 GB ao byte. O pacote PQ2_0 é 2,417 GB e o pacote PTQ1_0 — o menor, com 1,997 GB — não está aqui de forma alguma.

Essa escolha tem uma consequência que vale a pena declarar claramente, porque é o tipo de coisa que vira um tópico de suporte. No cartão de modelo do fornecedor, o llama.cpp upstream executa exatamente um dos três empacotamentos: Q2_0, "master recente, que inclui o runtime de ativação Hadamard". Ele rejeita PQ2_0 e PTQ1_0 como tipos desconhecidos, porque esses precisam do fork do llama.cpp da Prism ML. O Ollama serve seu próprio motor. Q2_0 é o pacote que um consumidor GGUF padrão pode plausivelmente carregar — e Q2_0 é precisamente o pacote que o Ollama distribuiu. Se o Ollama desenvolveu kernels ternários próprios ou encaminha para uma build vendorizada não é algo que o registro te informa. O que ele te diz é que eles não distribuíram o arquivo que não consegue carregar.

Os metadados GGUF dizem-lhe mais do que a página.

A página do Ollama relata quatro fatos por tag: um tamanho em bytes, um selo de contexto “256K”, um tipo de entrada de texto mais imagem e um carimbo de data/hora relativo. Todo o resto está dentro do arquivo. A leitura do cabeçalho GGUF de cada camada do modelo fornece o seguinte, e vale a pena lê-lo por um motivo específico: é a única parte desta história que não é uma alegação de marketing de alguém.

• general.architecture — qwen35 em todos os quatro tamanhos

• general.name — Ternary-Bonsai-2-2B, -4B, -9B nos três pequenos; a camada 27B reporta a string genérica Hf com general.basename = folded

• general.file_type — 41 em todos os quatro, com general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, correspondendo aos nomes das tags

• Contagens de tensores — 320 para o 2B, 426 para o 4B, 427 para o 9B, 851 para o 27B

A string de arquitetura é a interessante. qwen35 é o backbone de atenção híbrida do Qwen3.5 e confirma, a partir do próprio artefato, o que os cards de modelo dizem em prosa: os três menores são Qwen3.5-2B, -4B e -9B, com a arquitetura inalterada e os pesos substituídos. Também expõe uma emenda de nomenclatura que as próprias notas de lançamento do fornecedor mascaram. O post de 15 de outubro diz que os novos modelos são "baseados no Qwen3.5". O 27B é uma base totalmente diferente — Qwen3.8-27B, anunciado em 17 de setembro. Quatro tamanhos, um nome de família, dois modelos de base. Qualquer coisa que você leia sobre o comportamento do "Bonsai 2" que foi medido no 27B não se transfere automaticamente para o 9B, e o cabeçalho GGUF é onde dá para ver por quê.

Os metadados do 27B também estão visivelmente menos organizados que o resto: general.name = Hf, general.basename = folded, general.version = v5, e uma chave de amostragem extra que os três pequenos não carregam. É assim que a saída intermediária de um pipeline de conversão se parece quando é publicada sem uma passagem final de renomeação. Não é um defeito — os tensores são os tensores — mas é uma impressão digital, e sugere que a tag do 27B chegou por um caminho diferente dos três pequenos.

O que os números do Ollama não significam

É aqui que a maioria da cobertura de uma listagem de biblioteca erra, então vale a pena desacelerar. Os tamanhos em bytes na página do Ollama são tamanhos de contêiner, e para cada tamanho eles são maiores que o arquivo do modelo dentro. A tag 2B indica 911 MB contra uma camada de modelo de 0,547 GB e um projetor de visão de 0,365 GB. A tag 27B indica 8,3 GB contra uma camada de modelo de 7,626 GB e um projetor de 0,629 GB. Some os blobs de licença e de parâmetros e a conta fecha: o Ollama está citando todo o artefato baixado, torre de visão incluída.

Isto significa que os 3,2 GB da página do Ollama para o 9B não são comparáveis ao valor de "2 GB" do fornecedor para o mesmo modelo, e a diferença não é uma discrepância a comunicar — são duas medições diferentes de duas coisas diferentes. Os 0,43 GB / 0,95 GB / 2 GB da Prism ML são apenas os modelos de linguagem. A torre de visão é descarregada e carregada apenas quando chega realmente uma imagem, pelo que uma implementação só de texto nunca paga por ela, mas um ollama pull paga. Se estiver a dimensionar um dispositivo com base nos números do fornecedor e depois fizer pull a partir do Ollama, ficará 0,5 a 1 GB acima do orçamento antes mesmo de executar seja o que for.

A mesma cautela se aplica ao selo "256K". O contexto subjacente é 262.144 tokens, herdado do backbone Qwen3.5 — 24 camadas de atenção linear e 8 camadas de atenção completa no 9B — e o selo do Ollama arredonda para baixo para exibição. O contexto é real e é herdado, não algo que o Ollama adicionou. O que não é declarado em lugar nenhum da página é quanta memória custa um contexto longo, e em um modelo de atenção híbrida com um cache de atenção completa em um subconjunto de camadas isso não é um número pequeno. Nada na página do Ollama informa se 262K realmente cabe onde quer que você pretenda executá-lo.

Quem embalou isto, e isso importa?

Sem resposta, e deveria ser sinalizado como sem resposta em vez de adivinhado. Três possibilidades: a Prism ML o enviou, a Ollama o puxou dos repositórios GGUF públicos do fornecedor como parte do seu próprio trabalho de catálogo, ou um terceiro o fez. O registro não consegue dizer qual.

O que pode ser verificado é a proveniência do artefato, e tudo confere. A própria descrição do modelo da Ollama diz: "Bonsai 2 da Prism ML é uma família de modelos de visão criados para pesos ternários (−1, 0 ou +1): cerca de metade do tamanho dos modelos padrão de 4 bits, com qualidade próxima da precisão total", e indica a organização do fornecedor no Hugging Face, o whitepaper do Bonsai 2 27B e a Apache 2.0. O bloco de licença incorporado em cada um dos quatro manifestos de tamanho é o texto literal da Apache 2.0. O bloco de parâmetros dos modelos 2B, 4B e 9B diz {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — que é a receita de amostragem em modo de pensamento recomendada pelo fornecedor nos cartões de modelo, com min_p omitido exatamente como o cartão do 27B diz que os arquivos GGUF o omitem. Isso não é um palpite que alguém deu; é uma conversão que leu o cartão.

O que é reconfortante e ainda assim não lhe diz nada sobre aquilo que realmente decide a sua experiência: se os kernels ternários estão no motor que você está executando. A posição honesta é que um pull bem-sucedido prova que o arquivo é um GGUF bem formado, e nada mais. Verifique no seu próprio hardware antes de se basear nisso.

As alegações do fornecedor, e o que foi verificado

Todo número de qualidade associado a esta família vem da Prism ML, no próprio harness da Prism ML, e nenhum deles é reproduzido de forma independente. Isso é normal nesta fase e deveria ser dito explicitamente, em vez de apenas subentendido. A publicação de 15 de outubro relata 19 benchmarks em seis áreas de habilidade para os modelos pequenos, com retenção em relação às baselines Qwen3.5 de precisão completa:

• 2B — agêntico 95,5%, matemática 107,8%, seguimento de instruções 121,5%, programação 115,0%, conhecimento 82,9%, visão 89,0%

• 4B — 90,0% / 99,3% / 106,0% / 100,7% / 90,9% / 91,3%

• 9B — 92,4% / 98,2% / 100,0% / 100,1% / 93,0% / 92,5%

Vários desses ultrapassam 100%, o que não é um erro tipográfico nem um artefacto de arredondamento — significa que o modelo ternário obteve uma pontuação superior à do modelo de precisão total do qual derivou nessa categoria. O seguimento de instruções a 121,5% para o 2B é o exemplo mais gritante. Encare isso com a desconfiança que merece: um modelo comprimido a superar a sua própria linha de base num benchmark escolhido pelo fornecedor é uma afirmação sobre o treino e o harness pelo menos tanto como sobre a representação, e as pontuações da categoria de modelos pequenos são bastante mais ruidosas do que as do 27B. Os números do 27B são mais conservadores e mais credíveis no seu perfil — 84,78 contra 86,32 para FP16, uma retenção de 98,2% em 14 benchmarks de modo de pensamento, com matemática a 96,57 contra 97,06 e nível de programação a 89,42 contra 89,07, e a perda concentrada em conhecimento/raciocínio e visão. Quando uma família abdica de capacidade sob uma representação de 1,7 bits, esse é o perfil que se preveria.

A única afirmação no post sobre modelos pequenos que não é um benchmark é a que merece ser levada mais a sério: a de que o modelo de 9B "usa cerca de 40% menos tokens em tarefas padrão de seguir instruções e de matemática do dia a dia". Trata-se de uma afirmação sobre verbosidade, não sobre capacidade, e é o tipo de coisa que você pode verificar numa tarde com seus próprios prompts. Ela também interage com um aviso nos próprios model cards do fornecedor — o modo de raciocínio pode queimar mais de 3.000 tokens numa pergunta trivial, então defina pelo menos 8.192 tokens de saída, e não use decodificação greedy com o raciocínio ativado, porque ele pode ficar travado raciocinando. Um modelo 40% menos verboso e que ainda precisa de um orçamento de 8.192 tokens está dizendo que é verboso num lugar específico.

Onde isso te deixa

Se você já executa o Ollama e queria experimentar um modelo da classe 27B em um laptop sem uma GPU de datacenter, as quatro tags são o caminho mais curto que existe agora: um único pull, sem fork, sem compilação de kernel. Se você precisa do empacotamento que é realmente o menor, ou dos drafters de decodificação especulativa que o fornecedor disponibiliza para os 4B e 9B, a listagem do Ollama não os tem — isso é um download do Hugging Face e o build do llama.cpp da Prism ML, e tem sido assim desde 15 de outubro.

A outra coisa que vale a pena saber é que o local não é a única forma de consumir um modelo de baixa bitagem, e nem sempre é a forma certa. O OrcaRouter coloca uma API à frente de mais de 200 modelos hospedados com 0% de markup — o preço de tabela do provedor é repassado — além de failover automático entre provedores, para que você possa avaliar um modelo em uma carga de trabalho real antes de decidir se ele merece um lugar no seu laptop. Nenhum dos tamanhos do Bonsai 2 é servido pelo OrcaRouter hoje, e este artigo não afirma o contrário: a família é um download que você mesmo executa, e assim permanece até que o fornecedor publique um endpoint. O que a camada de roteamento oferece é a outra metade da decisão — os modelos hospedados com os quais você vai compará-lo, atrás de uma única chave, com a fusão de modelos e a DSL de roteamento disponíveis quando um único modelo não é suficiente.

O que observar, por ordem de quanto mudaria o panorama: uma tag do Ollama ganhando um ptq1_0 irmão, o que significaria que os kernels dense-trit chegaram ao upstream; uma publicação do fornecedor que reconhece a plataforma, o que responderia à questão da proveniência; e qualquer benchmark independente do 9B ou do 27B, que é a única coisa que tiraria os números de retenção da coluna dos reportados pelo fornecedor. Até que um destes apareça, a listagem é um mecanismo de entrega, não um novo modelo — e o modelo que entrega é público desde 15 de outubro.

Nada disso é hipotético: as falhas de IA documentadas e os incidentes com agentes por trás de lançamentos como este estão reunidos no Arquivo de Incidentes de IA da OrcaRouter, onde cada entrada traz as suas próprias fontes, gravidade, grau de confiança e sinalização de contestação.