Bonsai 27B: O Modelo 27B da Família Bonsai, Explicado

O Bonsai 27B é o modelo de 27 bilhões de parâmetros da família Bonsai da PrismML, e é aquele a que as pessoas se referem quando digitam "bonsai 27b" — mas o nome por si só não o levará até lá, porque três coisas diferentes respondem por algo próximo a ele. O Bonsai 27B é uma reconstrução de baixa precisão do Qwen3.6-27B, com data de 14 de julho de 2026, segundo o anúncio do próprio fornecedor, e é disponibilizado em dois pacotes do mesmo modelo: 1-bit Bonsai 27B, que armazena pesos binários {−1, +1} em cerca de 3,9 GB, e Ternary Bonsai 27B, que armazena pesos ternários {−1, 0, +1} a 1,71 bits efetivos por peso — 5,9 GB no número de destaque do fornecedor, 7,165 GB conforme o pacote é de fato distribuído. Não é o Ternary Bonsai 2 27B, a segunda geração nomeada separadamente e construída sobre o Qwen3.8-27B, e não é o modelo de visão e linguagem de 2 bilhões de parâmetros que a PrismML criou para os óculos inteligentes Snapdragon AR1 Gen 1. Ambos os pacotes do Bonsai 27B trazem um contexto de 262.000 tokens, uma torre de visão compacta de 4 bits e uma licença Apache 2.0. O modelo é o Bonsai 27B; a decisão que se segue é qual dos seus dois pacotes se encaixa no seu orçamento de memória.

Esta página é a referência para esse modelo. Não é um anúncio: o Bonsai 27B está disponível desde julho de 2026, e as perguntas que vale a pena responder sobre ele agora são aquelas com que um leitor chega — o que exatamente ele é, o que o nome distingue e quanto custa realmente executá-lo.

Qual deles é o 27B?

A possibilidade de confusão aqui é real, e vale a pena resolvê-la antes de qualquer outra coisa, porque o palpite errado leva você a um modelo de 2 bilhões de parâmetros ou à geração errada do modelo certo.

• Bonsaio nome da família e o nome que o fornecedor usa para ela. Por si só, não identifica nada que você possa baixar. A PrismML lançou Bonsai 1.7B, Bonsai 4B, Bonsai 8B, Bonsai 27B e Bonsai Image, além do modelo de óculos de 2 bilhões de parâmetros, e um lançamento anterior de abril de 2026 chamado Ternary Bonsai para a linha menor. Uma busca pela palavra isolada cai nesse conjunto de forma aleatória.

• Bonsai 27B — o assunto desta página. Primeira geração da linha 27B, derivada do Qwen3.6-27B, datada de 14 de julho de 2026. Quando uma página diz "Bonsai 27B" sem qualquer outro qualificador e sem "2", é este o modelo a que se refere, e este é o nome a usar.

• Ternary Bonsai 27B — não é um modelo diferente. É o pacote orientado à qualidade do Bonsai 27B: o mesmo modelo 27B, a mesma arquitetura e a mesma base, com pesos ternários em vez de binários. O repositório chama-se Ternary-Bonsai-27B-gguf, e o seu cartão de modelo indica o Qwen3.6-27B como base exatamente como o cartão binário faz. "Ternary" aqui é um formato de peso, não uma versão.

• Ternary Bonsai 2 27B — um modelo genuinamente diferente. A segunda geração da linha 27B, construída sobre o Qwen3.8-27B e anunciada em 17 de setembro de 2026, com uma divisão de parâmetros diferente e uma alegação de qualidade diferente. O "2" carrega toda a distinção.

• 1-bit Bonsai 2B — um membro diferente da família em uma escala diferente: um modelo de linguagem visual de 2 bilhões de parâmetros para hardware da classe de óculos, não um modelo 27B em qualquer precisão.

Então, se você veio aqui para resolver qual destes é o modelo 27B, a resposta é: a terceira e a quarta linhas acima são o mesmo modelo em dois formatos de pesos, e a quinta é a que não é. Na prática: chame-o de Bonsai 27B e adicione o pack quando for relevante.

A especificação, do cartão do modelo

Cada número nesta seção vem dos cartões de modelo publicados pela PrismML para os dois pacotes, e trata-se da declaração do próprio fornecedor sobre seu próprio modelo. Quando um número é uma alegação e não uma medição, ele é rotulado como tal.

• Parâmetros — cerca de 27,3B no total, e o "27B" refere-se a esse todo. Vale a pena conhecer a divisão porque explica o comportamento da memória: aproximadamente 24,8B residem no backbone de linguagem ao longo de 64 blocos, cerca de 2,5B no embedding e na cabeça LM, e cerca de 0,46B numa torre de visão de 27 blocos. A representação de baixa precisão é aplicada de ponta a ponta — embeddings, atenção, MLPs e a cabeça LM — sem qualquer via de escape de maior precisão em nenhum ponto da rede de linguagem.

• Contexto — uma janela completa de 262.000 tokens, sem variante de contexto longo e sem build de contexto reduzido. O custo dessa janela é gerenciado em vez de pago integralmente: o backbone é híbrido, então apenas 16 de suas 64 camadas mantêm um cache de atenção completo, e esse cache é armazenado em um formato de 4 bits quase sem perdas. Na janela completa de 262K, o cache comprimido é o que mantém o modelo dentro de aproximadamente 9,4 GB no pacote binário e 12,8 GB no ternário.

• Modalidade — texto e imagens, ambos os pacotes. A torre de visão vem em um formato compacto de 4 bits (0,63 GB), acompanhada de uma cópia BF16 (0,93 GB). A visão também é onde a compressão custa mais, o que é abordado abaixo.

• Formato e tamanho dos pesos — O 1-bit Bonsai 27B usa pesos binários {−1, +1} com escalonamento por grupo em FP16, empacotados como GGUF Q1_0_g128 a verdadeiros 1,125 bits efetivos por peso; o arquivo distribuído tem 3,803 GB, e o card arredonda a pegada de implantação para cerca de 3,9 GB. O Ternary Bonsai 27B usa pesos ternários {−1, 0, +1} com o mesmo escalonamento por grupo; um valor ternário carrega log₂3 ≈ 1,585 bits de informação, então o piso da representação é de ~1,71 bits por peso, o que dá 5,9 GB no ideal. O pacote ternário publicado é maior do que esse ideal, porque os kernels atuais armazenam cada valor ternário em um slot de 2 bits — 2,125 bits por peso implantados — e o arquivo distribuído tem 7,165 GB. A PrismML declara os dois números, em vez de apenas o mais lisonjeiro, e a diferença entre eles é uma limitação de kernel, e não uma escolha de modelagem.

• Licença — Apache 2.0 em ambos os pacotes, declarado em ambos os repositórios e no anúncio do fornecedor. Trata-se de uma licença permissiva, sem restrição de campo de uso, o que importa mais neste tamanho de peso do que na maioria.

• Modelo base — Qwen3.6-27B em ambos os casos. Esta é uma recompressão do modelo de outra pessoa, em vez de um modelo treinado do zero, e a consequência é que tanto o teto de capacidade do Bonsai 27B quanto sua cadência de atualização acompanham a linha 27B upstream, em vez da da PrismML.

A relação ternária, enunciada uma vez

Os dois pacotes são um único modelo, e o resumo honesto é que o ternário compra qualidade e o binário compra pegada, com uma lacuna entre eles menor do que sugere a diferença de tamanho de 3,9 GB contra 7,2 GB.

Na própria suíte de 15 benchmarks de modo de raciocínio da PrismML, a linha de base FP16 Qwen3.6-27B obtém 85,07. O Bonsai 27B ternário obtém 80,49 — 94,6% de retenção, que o fornecedor arredonda para cerca de 95%. O Bonsai 27B de 1 bit obtém 76,11 — 89,5%, arredondado para cerca de 90%. Assim, o pacote orientado à qualidade recupera aproximadamente metade da distância entre o pacote binário e a precisão total, embora custe cerca de 3,3 GB a mais, e o pacote binário é o que cabe em um celular de 12 GB. A mesma suíte mostra uma versão Q4_K_XL de 4 bits da mesma linha de base com 84,99, ou 99,9% de retenção, em 17,6 GB — que é a comparação que explica por que qualquer um dos dois pacotes de baixa precisão existe, já que supera ambos em qualidade e perde em todos os dispositivos que têm menos de 18 GB para dar a um modelo.

Onde o pacote binário perde terreno é desigual, e a divisão por categoria é a parte útil. Em comparação com a linha de base FP16, ele cai de 95,33 para 91,66 em matemática e de 88,74 para 81,88 em programação, mas de 78,47 para 65,74 em seguimento de instruções, de 80,00 para 66,03 em trabalho agêntico e de chamada de ferramentas, e de 72,61 para 59,57 em visão. Se sua carga de trabalho for aritmética ou conclusão de código, 3,9 GB é quase de graça. Se forem agentes de chamada de ferramentas ou compreensão de imagens, é aí que a compressão está de fato sendo paga.

O cartão do modelo também publica uma métrica derivada que chama de densidade de inteligência — pontuação agregada por gigabyte, normalizada de modo que uma pontuação perfeita se aproxime do infinito. Nessa medida, o 1-bit Bonsai 27B alcança 0,530 e o Ternary Bonsai 27B 0,400, contra 0,199 para uma versão 2-bit IQ2_XXS da mesma linha de base, 0,155 para uma versão 4-bit Q4_K_XL, e 0,051 para o modelo FP16. O número interessante nessa lista é a primeira comparação: o pacote binário supera a versão 2-bit convencional em qualidade agregada com menos da metade da pegada, o que é toda a tese da família em uma linha.

A comparação direta completa entre os dois pacotes, e de onde vêm os números de cada um, está detalhada na página Bonsai vs Bonsai 27B deste blog, ao lado do modelo de 2 bilhões de parâmetros que compartilha o nome da família.

Uma pergunta que surge com este modelo merece uma resposta factual e nada mais. Os pacotes são codificações de baixa bit do mesmo modelo subjacente, e não uma variante retreinada, e os repositórios não publicam nenhum checkpoint ajustado separadamente ou sem censura ao lado deles — o único artefato de precisão total oferecido é uma conversão FP16 desempacotada dos mesmos pesos, publicada para que você possa comparar um pacote comprimido com sua própria linha de base em ferramentas padrão.

Pesos e licença, dos repositórios

Os pesos do Bonsai 27B são publicados no Hugging Face sob a organização prism-ml, e a listagem de arquivos é a coisa mais concreta sobre o lançamento. O repositório do pacote binário contém o próprio modelo com 3,803 GB, um GGUF FP16 do mesmo modelo com 53,808 GB para comparação, um drafter DSpark de decodificação especulativa com 1,787 GB em 4 bits e 7,292 GB em BF16, e torres de visão com 0,931 GB e 0,629 GB. O repositório ternário contém o seu próprio pacote de 7,165 GB, além de um segundo empacotamento de 7,585 GB, que é group-64 em vez de group-128 e compatível com upstream em vez de ideal, e os mesmos arquivos de drafter e de visão. Ambos os repositórios são Apache 2.0 e ambos indicam o Qwen3.6-27B como base.

Duas coisas decorrem dessa listagem. A primeira é que 53,808 GB contra 3,803 GB é a proporção de 14,2x que o cartão do modelo apresenta em destaque, e isso é verificável, e não apenas afirmado — o arquivo de precisão total está ali mesmo. A segunda é que o lançamento é mais pesado que o modelo: se você também incluir o modelo de rascunho e a torre de visão, que o caminho multimodal exige, você está acrescentando cerca de 2,4 GB a um modelo de 3,9 GB. O número de destaque de 3,9 GB refere-se aos pesos de linguagem, e não à implantação.

Os downloads são o único ponto em que o pacote voltado à qualidade lidera: em outubro de 2026, o repositório GGUF ternário ultrapassou 590.000 downloads, contra pouco mais de 400.000 do pacote binário, enquanto os contêineres MLX de ambos ficam acima de um milhão cada. O formato disso sugere que a maior parte deste modelo está sendo executada em hardware Apple, e não em servidores, e que as pessoas que o baixam estão comprando os cinco pontos extras de retenção em vez do menor arquivo possível — que é mais ou menos para isso que o fornecedor projetou o par.

Executando.

O que você pode obter hoje são quatro tipos de artefato por pacote, e qual deles você quer é decidido pelo seu runtime, e não pela qualidade.

• GGUF para llama.cpp — o caminho principal, e aquele para o qual os kernels de baixa precisão foram escritos. Ambos os pacotes são compilações do llama.cpp para CUDA, Metal e CPU, mas os kernels de 1 bit e ternários ficam no fork próprio da PrismML, e não no upstream, então o llama.cpp padrão ainda não conseguirá carregá-los corretamente. O empacotamento ternário group-64 existe precisamente para os casos em que você precisa de compatibilidade com o upstream e aceita usar 7,585 GB em vez de 7,165 GB para obtê-la.

• MLX para Apple silicon — contentores distintos fornecidos, com 5,129 GB para o pacote binário e 8,491 GB para o ternário. Note que o contentor binário do MLX é maior do que o pacote binário do GGUF, o que constitui uma diferença de sobrecarga do contentor e não um modelo diferente.

• AWQ 4-bit para frameworks de servidor — uma build de 4 bits de cada modelo para os frameworks de serving que esperam um checkpoint AWQ, em nove shards totalizando 18,70 GB, incluindo uma receita multi-GPU. Isto não é um artefato de baixa precisão; é o mesmo modelo numa precisão que faz sentido num rack, e abre mão de toda a razão pela qual o modelo existe.

• safetensors FP16 desempacotados — o modelo completo de ~54 GB no formato padrão do Hugging Face, publicado explicitamente para frameworks que ainda não oferecem suporte nativo a pesos de 1 bit. O fornecedor diz que este artefato será descontinuado quando os kernels de baixa precisão forem integrados no upstream.

A vazão de decodificação medida no pacote binário, conforme a própria tabela da ficha do modelo, é de 66,4 tokens por segundo em um M5 Max, 44,2 em um M5 Pro, 26,0 em um M4 Pro e 104,8 em um H100, com prefill a 874, 421, 133 e 2.755 tokens por segundo, respectivamente. A página de anúncio cita picos mais altos — até 87 tokens por segundo em um M5 Max e 163 em uma RTX 5090 — que são a configuração de melhor caso do próprio fornecedor, e não a da tabela. Trate os dois conjuntos como condições de medição diferentes, não como uma contradição, e trate ambos como reportados pelo fornecedor. A memória de pico, novamente da ficha, é de 5,2 GB em um contexto de 4K, 5,6 GB em 10K e 11,6 GB em 100K no pacote binário, e de 8,4, 8,7 e 14,7 GB no pacote ternário — com a ressalva de que esses números são anteriores ao cache KV de 4 bits, que é o que leva a janela completa de 262K para a faixa de um dígito em gigabytes.

O rascunhador DSpark é opcional e vale a pena entendê-lo antes de ativá-lo, porque ele não muda nada nas saídas: é um transformer paralelo por blocos de seis camadas, condicionado a estados ocultos extraídos de cinco camadas-alvo uniformemente espaçadas, adiciona cerca de 0,5 GB na precisão de serving e faz a verificação em relação ao modelo-alvo em vez de amostrar por conta própria. É por isso que o fornecedor pode citar uma aceleração de 1,37x em CUDA sem alterar os números de qualidade. Ele não é ativado por padrão em Apple silicon.

Onde o modelo local esgota o seu alcance é a questão de engenharia interessante, e é uma questão de encaminhamento, não uma questão de modelo. Um modelo de 3,9 GB num portátil trata do que cabe no seu contexto; tudo o resto tem de ir para algum lado, e esse algum lado é um modelo alojado por trás de uma API. O OrcaRouter é essa camada — um único endpoint para mais de 200 modelos alojados com 0% de margem sobre os preços de tabela dos fornecedores, failover automático entre fornecedores, e a regra de escalonamento de um nível local para um alojado expressa como configuração em vez de montada à mão. É a camada acima de um modelo local, não um substituto para ele.

O índice de comparação

O Bonsai 27B está em uma família em que cada vizinho responde a uma pergunta diferente, e estas são as páginas que abordam cada uma — nenhuma delas é rediscutida aqui.

• Bonsai vs Bonsai 27B — o modelo de óculos de 2 bilhões de parâmetros contra este: dezesseis vezes os parâmetros e duzentas e cinquenta e seis vezes o contexto, e por que o nome da família não traz nenhuma informação sobre o que você está baixando. A página é um post de blog aqui, não um modelo hospedado, o que é uma distinção que vale a pena manter clara nesta família.

• Bonsai 27B contra Qwen3.8-27B — o confronto direto entre este modelo e a base mais nova que ele não utiliza. Uma página dedicada neste lote traz essa comparação e, como os dois modelos têm nomes semelhantes e estão separados por uma geração, vale a pena lê-la por si só, e não como uma extensão desta especificação.

• Bonsai vs Ternary Bonsai 2 27B — o salto geracional, e o facto de os dois lançamentos reportarem a sua qualidade com base em duas réguas diferentes: a retenção de uma linha de base num caso, e uma afirmação comparativa no outro.

• Ternary Bonsai 2 27B — a segunda geração por si só, no Qwen3.8-27B, para leitores que decidiram que querem o modelo mais novo em vez deste.

O que não está resolvido

Todos os números de qualidade nesta página são da PrismML, medidos na própria suíte de 15 benchmarks da PrismML, e ninguém fora da empresa publicou uma reprodução dela. Essa é a maior lacuna no que se sabe sobre o Bonsai 27B: as alegações de compressão são incomumente específicas e incomumente verificáveis, e permanecem sem verificação por terceiros. O fornecedor também deixa explícito que a codificação agêntica — fluxos de trabalho de longo horizonte, com vários arquivos, de executar e corrigir — não é um alvo forte desta versão e que uma variante ajustada para isso é o próximo item do roteiro, o que é consistente com as perdas em chamadas de ferramentas e em seguimento de instruções na divisão por categoria acima. Até que exista uma avaliação independente, tanto o número de retenção quanto a classificação de densidade devem ser lidos como a posição do fornecedor, e não como um resultado estabelecido.

O que está definido é menor e mais útil: os pesos existem, os tamanhos podem ser verificados na listagem de arquivos, a licença é Apache 2.0, e os dois pacotes diferem em cerca de 3,3 GB em troca de aproximadamente cinco pontos de qualidade retida. Isso é suficiente para escolher entre eles. Qual deles é o certo para você depende de se a sua carga de trabalho se parece mais com aritmética ou mais com chamadas de ferramentas, e os números de categoria acima são a melhor evidência disponível para essa decisão hoje.