Ternary Bonsai 2 27B vs Bonsai 27B: Dois meses, dois modelos base, uma variante ausente

Ternary Bonsai 2 27B chegou a 17 de setembro de 2026, dois meses depois de Bonsai 27B ter chegado a 14 de julho de 2026, e a comparação principal entre eles é um único par de números: a primeira geração manteve cerca de 95% da média de benchmarks do seu modelo base de precisão total, e a segunda mantém 98,2%. Isso soa como uma melhoria geracional direta, e é quase isso — mas as duas cifras não medem a mesma coisa, porque o modelo base mudou por baixo delas. O lançamento de julho comprimiu o Qwen3.6-27B. O lançamento de setembro comprime o Qwen3.8-27B. Parte do ganho de qualidade pertence à receita de compressão e parte pertence ao Qwen3.8-27B mais recente, e nenhum número publicado separa as duas.

Há uma segunda diferença entre as gerações que recebeu muito menos atenção e que importa mais para um grupo específico de usuários: o primeiro Bonsai foi lançado em duas variantes, e o segundo é lançado em uma. A build de 3,9 GB que fez um modelo da classe 27B caber em um iPhone 17 Pro não tem sucessora neste lançamento. Se esse tamanho é o motivo pelo qual você se interessou pelo Bonsai, a geração mais nova não é uma atualização — é um produto diferente que não cobre o seu caso.

O que a primeira geração de fato entregou

O Bonsai 27B foi lançado em 14 de julho de 2026 sob Apache 2.0 como dois artefatos construídos sobre o mesmo modelo base, e a divisão entre eles era o ponto do lançamento.

• Ternary Bonsai 27B — pesos ternários {−1, 0, +1} com escalonamento por grupo em FP16, 1,71 bits efetivos por peso, uma ocupação de 5,9 GB. A versão orientada à qualidade, posicionada para um laptop do dia a dia com raciocínio completo, chamada de ferramentas e capacidade agêntica.

• 1-bit Bonsai 27B — pesos binários {−1, +1} com o mesmo escalonamento por grupo, 1,125 bits efetivos por peso, uma pegada de 3,9 GB. A build orientada a footprint, dimensionada para caber no orçamento de memória de um iPhone 17 Pro.

Ambos traziam um contexto de 262K tokens, ambos mantinham uma torre de visão compacta de 4 bits para que o modelo permanecesse multimodal, e ambos suportavam decodificação especulativa com um modelo de rascunho DSpark. Na época, o enquadramento da Prism ML era que a representação de baixos bits rodava de ponta a ponta — embeddings, atenção, MLPs e a cabeça do LM — sem escapatórias de maior precisão, e que a versão de 1 bit era o primeiro modelo da classe 27B a rodar em um celular, de fato. A vazão relatada na variante de 1 bit era de cerca de 11 tokens por segundo em um iPhone 17 Pro, 87 tok/s em um Apple M5 Max e 163 tok/s em uma RTX 5090; a variante ternária foi citada em 58 tok/s no M5 Max e 134 tok/s na 5090.

O custo de qualidade foi reportado junto a esses números, em vez de ser escondido. Em uma suíte de raciocínio de 15 benchmarks, a base de precisão total obteve 85,0, a build ternária 80,5 — cerca de 95% — e a build de 1 bit 76,1, cerca de 90%. A degradação concentrou-se na chamada de ferramentas agênticas, que caiu de 80,0 para 66,0 na build de 1 bit, e na visão, que caiu de 72,6 para 59,6. Matemática e programação resistiram consideravelmente melhor em ambas as variantes.

O que a segunda geração mudou

O Ternary Bonsai 2 27B mantém a receita e muda as entradas. A representação ternária ainda é {−1, 0, +1} com uma escala FP16 por grupo de 128 pesos, agora empacotando para 1,76 bits por peso em um arquivo de 5,93 GB, com contexto de 262K e a mesma torre de visão separada — 0,63 GB em 4 bits nesta versão, carregada apenas quando uma imagem chega.

Duas coisas são genuinamente novas, e ambas são descritas como a razão pela qual o índice de retenção mudou.

O primeiro é a precisão seletiva. Ao contrário da versão de julho, que ternarizou praticamente tudo, o Bonsai 2 mantém 26.238.464 parâmetros em precisão total — 0,0976% do modelo de linguagem, cerca de 52 MB em bf16, concentrados no caminho de estado recorrente das camadas de atenção linear, além dos pesos de normalização. Trata-se de uma pequena concessão em bytes e, aparentemente, de uma grande em comportamento.

O segundo é uma base de pesos rotacionada. As matrizes de pesos são armazenadas após uma rotação de Walsh–Hadamard em blocos, com tamanho de bloco 1.024, com a transformação correspondente aplicada às ativações em tempo de execução, partindo do princípio de que distribuir os outliers pelas coordenadas torna uma aproximação de três níveis menos sujeita a perdas. Não custa armazenamento extra porque a rotação é incorporada aos pesos, mas, ainda assim, fica no caminho computacional.

Há também a mudança que não é uma técnica propriamente dita: o modelo base. O Qwen3.8-27B é um design de atenção híbrida — cerca de 75% de atenção linear, 25% de atenção total —, ao passo que seu antecessor não era. As pontuações por categoria relatadas pela Prism ML mostram o que essa mudança rendeu. A capacidade de seguir instruções está em 82,66 para o Bonsai 2, contra 74,53 para o Qwen3.6-27B, a base que a primeira geração comprimiu. Raciocínio e conhecimento ficam em 83,95 contra 84,71 da base mais antiga, e programação em 81,58 contra 82,57. A nova base é muito melhor em seguir instruções, por uma margem ampla, e ligeiramente atrás em duas outras categorias, que é exatamente o tipo de perfil que torna as porcentagens de retenção entre gerações pouco úteis isoladamente.

Por que os dois números de retenção não são comparáveis

95% e 98,2% parecem duas leituras na mesma escala. Não são, por três razões que vale a pena manter claras antes de concluir que a receita melhorou 3,2 pontos.

• Os denominadores diferem. Os 95% da primeira geração foram medidos em uma suíte de 15 benchmarks contra o Qwen3.6-27B. Os 98,2% da segunda vêm de uma suíte de 20 benchmarks contra o Qwen3.8-27B. Suítes diferentes, linhas de base diferentes, misturas de dificuldade diferentes.

• As linhas de base mudaram de forma independente. Parte do ganho na retenção vem de o modelo comprimido estar ficando melhor em comprimir, e parte vem de o modelo base estar mudando de maneiras que, por acaso, são mais favoráveis a pesos ternários. Nada publicado separa essas contribuições.

• A retenção é relativa, por isso pode subir enquanto a capacidade absoluta cai em uma categoria. Um modelo que retém 99% de um modelo pai mais fraco ainda pode ficar atrás de um modelo que retém 96% de um mais forte.

A comparação absoluta é mais informativa do que a relativa e, nessa base, a história fica mais clara. O agregado de 83,9 do Bonsai 2 está acima dos 83,6 que o Qwen3.6-27B de precisão total obteve na suíte mais antiga — ou seja, o sucessor comprimido agora está à frente do modelo não comprimido que ele substituiu uma geração antes. A versão ternária de primeira geração obteve 80,5 em sua própria suíte. Ambos esses números são da Prism ML, e as suítes são diferentes, então leia a ordenação, e não os decimais.

A variante que não voltou

Esta é a parte da comparação que muda uma decisão de compra, em vez de um gráfico de benchmark.

Não existe um Bonsai 2 de 1 bit. O lançamento de setembro traz uma build ternária, em dois empacotamentos — PTQ1_0 a 1,76 bits por peso e 5,93 GB, e PQ2_0 a 2,16 bits por peso e 7,25 GB — além de um contêiner MLX para Apple Silicon. Não existe uma variante binária de 3,9 GB, nem anúncio de uma. O valor de 3,9 GB da classe de celular que aparece na cobertura atual ainda se refere ao modelo de julho.

A consequência prática é direta. Se o seu alvo é um iPhone ou iPad, ou qualquer dispositivo que não comporte um modelo de linguagem de 5,9 GB, mais uma torre de visão de 0,63 GB, mais um orçamento de contexto, então a build de 1 bit de primeira geração continua sendo a única opção nesta família, e continuará sendo até que exista um Bonsai 2 de 1 bit. Atualizar o caminho ternário não atualiza esse caminho. Qualquer pessoa que leia "Bonsai 2 é melhor" e baixe novamente para um telefone descobrirá que o arquivo não cabe.

Se você estiver em um laptop ou desktop, o cálculo é o oposto: não há motivo para rodar o build ternário de julho quando o de setembro é menor por unidade de qualidade, melhor nos benchmarks que importam e carrega o mesmo contexto de 262K.

Speed, onde as gerações são genuinamente difíceis de classificar

O throughput é a parte desta comparação em que a resposta honesta é que os números publicados não sustentam um ranking claro, e vale a pena dizê-lo em vez de escolher o par lisonjeiro.

As medições padronizadas da segunda geração, com tamanho de lote 1 e com a torre de visão excluída, são 142,5 tok/s de descodificação numa RTX 5090 no empacotamento PQ2_0, 46,8 tok/s num Apple M5 Max, 27,7 num M5 Pro e 18,0 num M4 Pro. A primeira geração indicava 134 tok/s numa RTX 5090 e 58 tok/s num M5 Max para a sua versão ternária. O valor da 5090 avança modestamente na direção esperada. O valor do M5 Max move-se no sentido contrário — de 58 para 46,8 —, o que não é o que um passo geracional de dois meses deveria parecer.

Dois ressalvas impedem que isso seja uma descoberta. As bases de medição diferem entre as versões, e {{1}}pelo menos um valor publicado do M5 Max{{/1}} para o modelo mais recente foi atribuído a uma build anterior à otimização de rotação. Mas vale a pena sinalizar como uma questão em aberto, porque o mecanismo que explicaria isso está nas notas de versão: a base rotacionada coloca uma transformação no caminho crítico de cada projeção com batch size 1, e o decode em Apple Silicon é o regime em que isso mais prejudica. A técnica que compra qualidade pode custar throughput de decode, e em hardware de memória unificada essa troca é mais acirrada.

O contêiner MLX adiciona uma complicação à parte para usuários da Apple. É um formato afim de 2 bits cujo bloco armazena tanto uma escala quanto um viés para cada grupo de 128 pesos, mas pesos ternários precisam apenas da escala, então o viés é peso morto — o bloco custa 36 bytes por 128 pesos em vez de 34, e a taxa empacotada fica em 2,25 bits por peso, com um tamanho de arquivo medido de 8,005 GiB. É um contêiner diferente que carrega os mesmos valores, e é o pacote que a configuração de demonstração baixa por padrão.

Executando qualquer geração

Ambas as gerações compartilham uma restrição operacional da qual nenhuma versão deste modelo escapou: nenhuma delas roda no llama.cpp padrão. Os kernels ternários para esta arquitetura vivem no fork próprio da Prism ML, o llama.cpp padrão rejeita os empacotamentos atuais como desconhecidos e — pior — carrega o formato ternário mais antigo sem reclamar e produz lixo fluente, porque não aplica a rotação que os pesos pressupõem. A build do MLX traz kernels Metal e CPU, mas nenhum caminho CUDA. Qualquer que seja a geração que você escolher, a questão do runtime é respondida pela própria distribuição da Prism ML ou por um runtime que adotou seus kernels, e não pelo ecossistema ggml como um todo.

Onde o OrcaRouter se encaixa numa decisão como esta é um nível acima. Nenhuma geração do Bonsai é hospedada aqui — são downloads que você executa no seu próprio hardware. Para o que a camada de roteamento é útil é na fronteira: as requisições que o seu modelo local não deveria estar respondendo. Defina a política de escalonamento uma vez na configuração de roteamento em vez de no código da aplicação, para que uma camada servida localmente encaminhe requisições de contexto longo, com uso intenso de visão ou fora do escopo para um modelo hospedado em vez de falhar com elas, e para que o fallback sobreviva a qualquer geração do Bonsai que você tenha instalado. Tanto a camada local quanto a hospedada então ficam atrás de uma única chave, e a política fica em um só lugar quando a próxima geração do Bonsai chegar e as fronteiras das camadas se moverem novamente.

O que fazer com isto

• Se você executa o build ternary de julho em um laptop ou desktop — mude para o Ternary Bonsai 2 27B. É um modelo melhor com um footprint aproximadamente igual, e as pontuações de categoria em que ele vence são as que importam para trabalho agêntico e de seguimento de instruções.

• Se você executa a build de 1 bit de julho em um celular — fique. Não há sucessor, e a build ternária de 5,93 GB não é um substituto direto para uma de 3,9 GB.

• Se está a avaliar a família pela primeira vez — decida primeiro o footprint, depois a geração. A variante de que precisa determina em que lançamento está a comprar, e essa ordem é o inverso de como esta atualização é habitualmente descrita.

• Se você está escolhendo com base em benchmarks — trate 95% e 98,2% como duas medições diferentes, e não como dois pontos em uma linha, e trate cada número nos dois casos como sendo do próprio fornecedor até que surja uma avaliação independente do modelo de setembro. Essa avaliação é o que deve ser observado, porque é a primeira que conseguirá comparar as duas gerações em uma base comum.