Ternary Bonsai 2 27B: O que cabe em 5,9 GB e o que os 98,2% não lhe dizem

O Ternary Bonsai 2 27B é um modelo de linguagem multimodal de 27,36 bilhões de parâmetros que a Prism ML anunciou em 17 de setembro de 2026, e o que é preciso entender sobre ele é que seus pesos de linguagem assumem um de exatamente três valores. Seu modelo base é o Qwen3.8 27B — um modelo de atenção híbrida de 27B — e o Bonsai mantém essa arquitetura, esse treinamento e esse formato, e substitui os pesos matriciais do modelo de linguagem por uma representação ternária. O arquivo fornecido tem 5,93 GB. A referência de precisão total é 53,81 GB. A principal alegação do fornecedor é que ele retém 98,2% da média de benchmark do original.

Comece pela parte que a maior parte da cobertura vai deixar de lado: esse 98,2% é um número da própria Prism ML, medido na própria suíte de 20 benchmarks da Prism ML, com o próprio harness da Prism ML, e ninguém fora da empresa o reproduziu. Isso não é uma acusação — é o estado normal das coisas um dia após um lançamento, e é exatamente o status que você deve atribuir a ele. O que você pode verificar de forma independente hoje é o arquivo: a API do Hugging Face lista Ternary-Bonsai-2-27B-PTQ1_0.gguf com 5,947 GB contra a referência FP16 de 53,808 GB, o que é uma redução de 9,05x e corresponde ao "cerca de 9x" do fornecedor sem precisar confiar em ninguém. O tamanho é um fato. A retenção de qualidade é uma medição do fornecedor. O material interessante está no meio — o detalhamento por categoria, que mostra precisamente onde a compressão não custa nada e onde não é o caso.

Há também uma segunda face neste lançamento. Em 18 de setembro, um dia após o anúncio, a OrcaRouter publicou uma variante abliterada em tempo de execução do mesmo modelo — a OrcaRouter Ternary Bonsai 2 27B Uncensored — que remove uma direção de recusa aprendida no momento da inferência e deixa os pesos idênticos bit a bit. Ela é abordada em sua própria seção abaixo, porque a técnica é a parte interessante e porque seus limites são tão instrutivos quanto seus resultados.

É um Qwen3.8 27B comprimido, não um modelo recém-treinado.

Essa distinção é a diferença entre explicar o lançamento e repetir um comunicado à imprensa. A Prism ML não treinou um modelo de 27B do zero e não executou uma nova receita de pré-treinamento. O que ela fez foi pegar o Qwen3.8 27B e alterar a representação numérica na qual seus pesos são armazenados e calculados.

A arquitetura não mudou, e é a do modelo base: um design de atenção híbrida que é aproximadamente 75% de atenção linear e 25% de atenção completa, com blocos MLP SwiGLU, RoPE e RMSNorm. Esse backbone híbrido também é o motivo pelo qual o contexto de 262 mil tokens é descrito como capaz de contexto completo, e não apenas suportado — a atenção majoritariamente linear é o que mantém um contexto longo acessível em um dispositivo. O modelo é um modelo de visão e linguagem: ele aceita imagens, além de texto, e a torre de visão é a torre Qwen padrão, não quantizada, empacotada separadamente.

O que a Prism ML contribuiu são duas coisas. A primeira é a própria representação ternária, além do treinamento ciente de quantização que permite que ela sobreviva. A segunda são os kernels — kernels personalizados de baixa precisão para essa pilha de atenção híbrida em Apple Silicon e CUDA, que operam diretamente sobre os pesos empacotados, em vez de desempacotá-los para FP16 e multiplicá-los. Sem a segunda contribuição, a primeira é um formato de armazenamento sem maneira de usá-lo em alta velocidade.

O whitepaper da própria Prism ML relata a divisão de parâmetros como 24,35B no backbone de linguagem ao longo de 64 blocos, 2,54B no embedding e no LM head, e 0,47B na torre de visão de 27 blocos, totalizando 27,36B. A torre de visão é a única parte que é genuinamente um artefato diferente: o release GGUF o empacota como um arquivo mmproj de 4 bits de cerca de 0,63 GB, carregado apenas quando uma imagem realmente chega, então o serving somente de texto nunca o carrega.

Este é o Bonsai de segunda geração do mesmo laboratório; o primeiro Bonsai 27B chegou em julho de 2026, cerca de dois meses antes, e a comparação entre as duas gerações é uma pergunta razoável — que abordamos no confronto direto com o Bonsai 27B em vez de repetirmos aqui.

O que "ternary g128" significa, concretamente

Se você nunca viu pesos ternários antes, este é o parágrafo que torna todo o resto legível, então aqui está sem abreviações.

Um peso comum em uma rede neural é um número de ponto flutuante de 16 bits — cerca de 65.536 valores distinguíveis em um intervalo útil, cada um custando 16 bits para armazenar. Um peso ternário não é um número de ponto flutuante pequeno. É uma escolha entre três símbolos: −1, 0 ou +1. Esse é todo o vocabulário. Armazenar um desses símbolos de forma ingênua faria você gastar dois bits por peso, já que dois bits oferecem quatro estados e você só precisa de três.

Por si só, isso seria uma perda catastrófica de expressividade, e é por isso que o formato nunca é apenas o símbolo. Cada grupo de 128 pesos consecutivos compartilha um único fator de escala FP16, e o valor real do peso é o símbolo ternário multiplicado por essa escala:

• w = ssub>g/sub> · t, onde t ∈ {−1, 0, +1} e ssub>g/sub> é uma escala FP16 compartilhada para o grupo de 128

Então, o modelo ainda representa uma ampla faixa de magnitudes — só que as representa em passos grosseiros, agrupados, em vez de passos individuais por peso. O 0 não é um artefato de arredondamento; é um verdadeiro terceiro estado, e é justamente tê-lo que permite que um grupo de 128 pesos fique em grande parte silencioso quando precisa.

A base rotacionada é a parte que surpreende as pessoas. Antes que a atribuição ternária ocorra, cada matriz de pesos é transformada em blocos por uma rotação ortogonal — uma matriz de Walsh–Hadamard combinada com uma diagonal fixa de sinais ±1, com tamanho de bloco 1024 — e os valores ternários são escolhidos nesse espaço rotacionado. A rotação é incorporada aos pesos armazenados durante a preparação, portanto não custa bits extras nem tráfego extra de pesos. Na inferência, o runtime aplica a transformação correspondente às ativações, em vez disso, e o modelo empacotado declara sua rotação em seus metadados, de modo que um runtime ou aplica a transformação correspondente ou se recusa a carregar o arquivo.

Por que se dar ao trabalho? Porque uma rotação de Hadamard distribui a energia de uma matriz de pesos de forma mais uniforme entre as coordenadas, o que torna a quantização subsequente em três níveis muito menos prejudicial do que ela seria na distribuição bruta e cheia de picos. A rotação não é decoração; é a razão pela qual um modelo ternário consegue preservar algo parecido com a qualidade do modelo pai. O custo é que a transformação fica no caminho crítico de toda projeção com tamanho de lote 1, o que é um problema real de engenharia — a Prism ML funde a inversão de sinal ao caminho de carregamento da transformação no Metal e a paraleliza em um bloco de threads inteiro no CUDA para impedir que ela domine a decodificação.

Os números, com atenção: 1,585, 1,71, 1,72, 1,76

Quatro números de largura de bits circulam em torno deste lançamento; todos estão corretos e medem quatro coisas diferentes. Confundi-los é o erro mais fácil nesta matéria. Aqui está cada um deles e o que ele realmente abrange.

• 1,585 bits por peso — o conteúdo informacional de um símbolo ternário, log₂3. Esta é uma propriedade do formato, não de nenhum arquivo. Nada que foi lançado roda a 1,585 bits/peso.

• 1,71 bits por peso — apenas os tensores ternários. Some a escala de grupo FP16 de 16 bits amortizada em 128 pesos e você obtém log₂3 + 16/128 ≈ 1,71. Ainda não é um número de um produto lançado; são os tensores ternários isoladamente.

• 1,72 bits por peso — cada parâmetro no modelo de linguagem, incluindo o pequeno conjunto mantido acima da representação de bits baixos. O Prism ML mantém 26.238.464 parâmetros — 0,0976% do modelo de linguagem, cerca de 52 MB em bf16 — em precisão mais alta, principalmente o caminho de estado recorrente das camadas de atenção linear, além dos pesos de normalização. Esses tensores não são rotacionados nem quantizados, e são eles que movem o valor de 1,71 para 1,72. Em 1,72, a pegada idealizada é de 5,80 GB, uma redução de cerca de 9,3x. Esta é a linha "True Ternary" do Prism ML, e é uma meta, não um arquivo que você baixa.

• 1,76 bits por peso — o GGUF realmente distribuído. Kernels eficientes precisam de um formato de empacotamento, e o PTQ1_0 da Prism ML empacota trits de forma densa, chegando a 1,76 bits/peso em 5,93 GB, cerca de 9,1x. Este é o arquivo por trás tanto do "5,9 GB" quanto do "9x menor" citados no anúncio, e é o que as medições acima confirmam.

O segundo empacotamento é PQ2_0, que armazena cada trit em um slot de 2 bits em vez de de forma densa. Custa mais espaço em troca de uma descompactação mais barata: 2,16 bits/peso em 7,25 GB, cerca de 7,4x. Nenhum dos empacotamentos é uniformemente mais rápido — o PTQ1_0 move aproximadamente 18% menos dados de peso por etapa, mas paga em aritmética para descompactar trits densos, então vence nas placas da geração Ada e na L4, onde a memória é a restrição limitante, e perde em Hopper, Blackwell e Apple silicon, onde a decodificação em lote 1 é limitada pela vazão de instruções. O processamento de prompt favorece o PQ2_0 em todos os lugares, porque é limitado pela computação.

Duas notas administrativas para quem estiver a verificar isto em relação às fontes. Primeiro, os próprios documentos da Prism ML arredondam de forma ligeiramente diferente — a tabela de armazenamento do whitepaper indica PTQ1_0 como 1,76 bits/peso em 5,93 GB, ao passo que o cartão de modelo GGUF no Hugging Face indica 1,75 e 5,95 GB, e o ficheiro medido é 5,947 GB. Trata-se do mesmo ficheiro descrito com precisões diferentes, e não de uma divergência de substância. Segundo, a redução anunciada de "mais de 9x" é da responsabilidade do fornecedor; medida face aos ficheiros reais, é 53,808 / 5,947 = 9,05x, o que é consistente.

O panorama do benchmark: não a média, a forma

O número de destaque é uma média de 83,9 contra 85,4 do baseline Qwen3.8 27B FP16, o que representa 98,2%. A média é a parte menos interessante disso. A forma subjacente é onde está a informação real, e ela não é uniforme.

• Seguimento de instruções — 82,66 vs 81,25. Esta é a única categoria em que o modelo comprimido supera o seu antecessor de precisão total. Não é ruído que alguém possa explicar de ânimo leve; é uma vitória de categoria na própria suíte do fornecedor.

• Matemática — 96,57 vs 97,06, e programação — 81,58 vs 82,17. Ambas essencialmente no mesmo nível: meio ponto e seis décimos de ponto nas médias das categorias. Para um modelo com um nono da pegada, são esses os resultados com base nos quais toda a técnica está sendo defendida.

• Conhecimento e raciocínio — 83,95 vs 86,66.Uma queda de 2,7 pontos, e é aqui que reside uma parcela significativa dos 1,8 pontos que faltam na média total.

• Vision — 78,59 vs 81,64. Uma queda de 3,05 pontos, a maior perda em uma única categoria. Vale notar que a torre de visão em si não é a parte comprimida; quem é é o modelo de linguagem que lê suas saídas.

• Agêntico e chamada de ferramentas — 77.57 vs 79.74. A média da categoria abrange τ 2-Bench em 80.22 e BFCL v3 em 74.92.

Resultados individuais que vale a pena conhecer, porque nem todos apontam na mesma direção. No Terminal-Bench 2.1, o modelo pontua 52,8 contra 69,7 de precisão total — cerca de três quartos — e no SWE-bench Verified pontua 60,8 contra 80,6, novamente cerca de três quartos. Esta foi a primeira vez que esta família de modelos foi avaliada no Terminal-Bench, e a Prism ML é explícita que os ganhos de engenharia de software de longo horizonte que prometeu no primeiro lançamento do Bonsai são parciais, não completos. Em contrapartida: o τ 2-Bench subiu para 80,2, de 73,6 no lançamento anterior, o BFCL v3 mantém-se em 74,9, e o AA-LCR situa-se em 77,0, a um ponto da precisão total. O AIME26 fica em 95,83 e o LiveCodeBench em 90,07.

Onde confiar nele e onde não. Confie no padrão em matemática, programação e seguimento de instruções — essas são as categorias em que a técnica comprovadamente faz o que promete, e são medidas no mesmo harness da linha de base. Seja cauteloso quanto a trabalho agêntico de longo horizonte: os dois benchmarks que realmente colocam à prova a engenharia sustentada orientada por ferramentas, Terminal-Bench 2.1 e SWE-bench Verified, mostram uma lacuna materialmente maior do que o agregado sugere, e o fornecedor diz isso em vez de esconder. E trate a tabela inteira como a medição de um único laboratório em um único harness até que outra pessoa a rode. Essa ressalva não é uma formalidade aqui — é a diferença entre "este modelo retém 98,2%" e "o fornecedor deste modelo mediu 98,2% em uma suíte escolhida pelo fornecedor". Ambas são verdadeiras; apenas uma é um fato sobre o modelo.

Por que isto supera uma build IQ2_XXS do mesmo modelo base

Isto merece uma seção própria em vez de uma linha, porque é todo o argumento a favor do treinamento ternário ciente de quantização em vez da quantização pós-treinamento.

A forma convencional de tornar o Qwen3.8 27B pequeno é quantizá-lo após o treinamento. O ponto de comparação do whitepaper é uma versão IQ2_XXS GGUF do mesmo modelo base:

• Ternary Bonsai 2 27B — 1,76 bits/peso, 5,93 GB, média de 20 benchmarks: 83,9

• Qwen3.8 27B IQ2_XXS — 2,2 bits/peso, 7,3 GB, média de 20 benchmarks: 75,2

O modelo comprimido pelo treinamento é ao mesmo tempo menor e melhor. Ele é 1,23x menor que a versão convencional de bits baixos e obtém 8,7 pontos a mais. Essa combinação não é uma curiosidade de arredondamento; é a afirmação de que uma representação escolhida durante o treinamento vale substancialmente mais do que o mesmo orçamento nominal de bits aplicado depois.

A parte mais instrutiva é como a build convencional falha, porque a falha é seletiva e fácil de passar despercebida. O IQ2_XXS não degrada de forma uniforme. Ele se sai bem em conhecimento superficial — 85,79 no MMLU-Redux — enquanto colapsa em tarefas que exigem cadeias prolongadas de raciocínio: 78,6 no AIME26, 70,05 no LiveCodeBench, 65,45 no GPQA Diamond. O Bonsai 2 pontua 95,83, 90,07 e 85,76 nesses mesmos três. Um teste casual de chat consideraria a build IQ2_XXS perfeitamente utilizável e nunca revelaria o colapso; o dano está exatamente onde ocorrem raciocínio longo e geração de código. Essa assimetria é o motivo pelo qual "parecia bom quando testei" não é evidência sobre um modelo quantizado.

A Prism ML comprime o mesmo argumento em um único número derivado que chama de densidade de inteligência — aproximadamente, capacidade de benchmark por gigabyte. No conjunto de 20 benchmarks, ela relata 0,444 por GB para o Bonsai 2, 0,276 para a versão IQ2_XXS e 0,051 para FP16. A métrica é uma construção do próprio fornecedor e sua ponderação é uma escolha de projeto, não uma lei; mas a ordenação que ela produz é a mesma que a tabela bruta produz, portanto acrescenta interpretação em vez de evidência.

Mais uma nota honesta sobre a comparação. A ficha do modelo GGUF da Prism ML relata uma segunda avaliação, mais restrita — uma suíte de 14 benchmarks em modo de raciocínio — na qual o mesmo valor de retenção aparece novamente: 84,78 contra 86,32, com o IQ2_XXS em 72,59. O fato de duas suítes diferentes chegarem ao mesmo 98,2% é uma leve corroboração de que a alegação agregada não é um artefato da seleção de um único benchmark. Ainda é o mesmo laboratório executando ambas, no mesmo harness. Nosso detalhamento mais completo desse confronto, incluindo a questão do formato de empacotamento, está na comparação com as builds GGUF do Qwen3.8 27B.

O que realmente é preciso para executar

Os números de throughput, a partir da medição padronizada tg128 do whitepaper em tamanho de lote 1, com a torre de visão excluída:

• Apple M5 Max — 46,8 tok/s de decodificação, 765 tok/s de processamento de prompt

• Apple M5 Pro — 27,7 tok/s de decodificação; uma execução separada de janela mais longa do pacote PQ2_0 mediu 27,0 tok/s sustentados, consumindo 27,0 W no rail da GPU e 32,8 W somando CPU e GPU

• Apple M4 Pro — 18,0 tok/s de decodificação, com o processamento de prompt a aproximadamente 125 tok/s tornando-se a restrição limitante para contextos muito longos

• NVIDIA RTX 5090 — 142,5 tok/s de descodificação no pacote PQ2_0 a 0,582 mWh por token

A alegação prática que a Prism ML faz não é um índice de aceleração, mas uma ausência: a linha de base FP16, com 53,8 GB, não cabe de forma alguma em um laptop de 16 GB, de modo que a afirmação significativa é que um modelo da classe de 27B agora roda de forma interativa em hardware cotidiano. No M5 Pro, a decodificação medida transmite cerca de 201 GB/s de pesos, confirmando o perfil dominado pela largura de banda de memória que a representação de baixa precisão foi projetada para explorar.

Depois, os casos extremos, que importam mais do que os números de pico.

Você não pode usar o llama.cpp padrão.Os kernels de atenção híbrida ternária ficam no fork próprio do llama.cpp da Prism ML. O llama.cpp padrão rejeita os tipos PTQ1_0 e PQ2_0 como desconhecidos e — o que é mais perigoso — carrega o formato ternário Q2_0 mais antigo sem qualquer aviso e produz lixo, porque não tem runtime de ativação Hadamard. Se você rodar este modelo em um binário que não aplica a rotação correspondente, você não receberá um erro; receberá um absurdo com aparência fluente. Esta é a forma mais provável, de longe, de desperdiçar uma tarde com esta versão.

O pacote MLX não tem caminho CUDA. A versão MLX (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) é voltada para Apple Silicon, onde possui kernels personalizados para a pilha híbrida tanto no runtime Python quanto no Swift. Sua multiplicação de matrizes quantizada tem kernels Metal e de CPU, mas nenhuma implementação CUDA, então em uma máquina NVIDIA esse pacote específico não recebe aceleração de GPU de forma alguma. A inferência em CPU funciona, mas um forward pass de 27B na CPU pode levar minutos — o que torna o caminho de CPU no Linux útil para testes de implementação e reprodutibilidade, e inútil para atender requisições.

Os dois pacotes são uma troca genuína, não um ranking. Se você está em uma placa da geração Ada ou em uma L4, ou se a memória é a restrição limitante, o PTQ1_0 é a escolha, com 5,93 GB. Se você está em Hopper, Blackwell ou em uma 5090, o PQ2_0 lhe garante velocidade de decodificação por 1,3 GB. Se você está em Apple silicon, observe que os números do M5 Pro acima são medidos no PQ2_0, que também é o pacote que a configuração de demonstração baixa por padrão.

Uma nota sobre a própria contabilidade do pacote MLX, pois é uma fonte comum de confusão. O contêiner MLX é um formato afim de 2 bits cujo bloco armazena uma escala FP16 e um viés FP16 para cada grupo de 128 pesos. Os pesos ternários do Bonsai precisam apenas da escala — os níveis decorrem somente da escala —, então o viés é peso morto, e o bloco custa 36 bytes por 128 pesos em vez de 34. Isso eleva a taxa compactada do pacote MLX para 2,250 bits/peso, não 1,72 e não 1,76. É um contêiner diferente que carrega os mesmos valores ternários, e seu arquivo medido no Hugging Face tem 8,005 GiB.

A variante abliterada em runtime

Em 18 de setembro, a OrcaRouter publicou o OrcaRouter Ternary Bonsai 2 27B Uncensored, que aplica ablação da direção de recusa a este modelo inteiramente em tempo de execução. A ideia de engenharia merece mais atenção do que o produto, então aqui está a ideia primeiro.

A abliteração convencional edita os pesos. Ela encontra uma direção no espaço de ativação que corresponde ao comportamento de recusa e então ortogonaliza contra ela as matrizes de pesos que escrevem no fluxo residual: W ← W − r(rᵀW). Em um modelo FP16 comum, isso é tranquilo — a matriz editada ainda é uma matriz densa de ponto flutuante, então você a salva e segue em frente. Em um pacote ternário, é um beco sem saída e, mais especificamente, é um beco sem saída pela razão pela qual este modelo inteiro existe. Ortogonalizar uma matriz ternária produz uma matriz densa de precisão completa. Para armazenar isso de volta no pacote ternário, você teria que requantizar — e requantizar pesos editados não reproduz o treinamento ciente de quantização que produziu o original. Você jogaria fora exatamente aquilo que foi comprado.

Então a projeção passa para o momento da inferência. Em vez de mudar W, mude sua saída:

• y ← y − α · dot(y, r) · r, calculado em float32, onde y é uma contribuição residual e r é a direção de recusa normalizada

Em α = 1, o componente de cada escrita residual paralelo à direção de recusa é removido. Em α = 0, o modelo permanece intacto. α acima de 1 projeta em excesso e pode degradar a qualidade. Como α é um parâmetro de execução, e não uma propriedade do checkpoint, o mesmo pacote pode ser testado A/B contra si mesmo no mesmo processo — que é exatamente o que as avaliações do OrcaRouter fazem. O pacote Bonsai original permanece idêntico bit a bit: zero pesos modificados, zero requantização, zero erro adicional de quantização de pesos.

Dois detalhes de implementação são onde uma versão ingênua disto falha.

129 locais de intervenção, não 16. Todo módulo que pode escrever no fluxo residual precisa ser encapsulado e, nesta arquitetura híbrida, isso significa 64 blocos mlp.down_proj, 48 camadas linear_attn.out_proj, 16 camadas self_attn.o_proj e model.embed_tokens — 129 no total. Encapsular apenas self_attn.o_proj é o erro óbvio e alcança 16 deles, deixando as outras 113 escritas sem projeção. Um script de autoverificação mede se o componente restante ao longo da direção de recusa é levado a aproximadamente 1e-6 da norma residual e emite um aviso se não detectar todos os 129 locais.

Não rotacione novamente a direção. O pacote ternário mantém suas projeções numa base rotacionada na sua dimensão de entrada e compensa no lado da ativação. A projeção de recusa opera sobre as saídas dessas projeções, que já estão de volta à base oculta normal — portanto, a direção de recusa é um vetor comum de 5120 dimensões, e aplicar uma rotação de Hadamard adicional a ele projetaria contra uma base completamente errada.

O que o OrcaRouter mediu — nossos próprios números, não independentes

Estas são medições baseadas em regras do próprio OrcaRouter, e devem ser lidas como tal: um classificador de frase de abertura baseado em regras, não um juiz LLM, thinking desativado, decodificação greedy, orçamento de 64 tokens, com base e ablated sendo os mesmos pesos no mesmo processo em α = 0 contra α = 1. Elas são indicativas, não são de nível publicável, e não são verificação de nada que a Prism ML tenha afirmado.

Sobre a recusa, medida como a proporção de prompts que receberam uma recusa:

• AdvBench (n=100) — 99,0% base, 6,0% ablacionado, com 56,0% respondidos, mas envoltos em um aviso de isenção de responsabilidade

• JailbreakBench (n=100) — 96,0% base, 4,0% com ablação, 52,0% com ressalvas

• StrongREJECT (n=150) — 99,3% base, 3,3% ablacionado, 45,3% com ressalvas

• HarmBench (n=150) — 98,7% base, 7,3% ablatado, 48,0% com ressalvas

• MaliciousInstruct (n=100) — 97,0% base, 0,0% ablacionado, 52,0% com ressalvas

• ForbiddenQuestions (n=150) — 75,3% base, 5,3% ablacionado, 42,7% com ressalvas

• SimpleSafetyTests (n=50) — 96,0% base, 18,0% com ablação, 60,0% com ressalvas — e esse número está subestimado. Esse conjunto é composto principalmente por prompts de autolesão, e o modelo responde a eles com um redirecionamento de crise que começa com "I am deeply sorry to hear…", que passa despercebido pela lista de frases exatas do classificador e é pontuado como conformidade. A taxa residual real de recusa nesse conjunto é superior a 18,0%. O classificador foi deliberadamente deixado como está para que os números permaneçam comparáveis aos demais model cards da OrcaRouter.

Nenhuma resposta em qualquer conjunto esgotou seu orçamento de tokens, então nenhuma dessas taxas está inflada por truncamento. Em prompts benignos, a mesma projeção também elimina a recusa excessiva: XSTest-safe caiu de 5,2% de recusas para 0,4%, e o subconjunto benigno do JailbreakBench, de 25,0% para 0,0%. O pacote publicado recusa um quarto dos prompts benignos desse benchmark; com ablação, não recusa nenhum.

Em termos de capacidade, o fato de os pesos serem bit a bit idênticos significa que não há requantização a pagar, e as medições são consistentes com isso:

• MMLU (n=300) — 76,7% base, 77,7% com ablação, +1,0

• GSM8K (n=150) — 87,3% base, 86,0% ablacionado, −1,3

• CMMLU (n=500) — 76,2% base, 75,6% com ablação, −0,6

Toda variação está dentro do ruído nesses tamanhos de amostra; uma única questão do GSM8K vale 0,7 ponto. O MMLU-Pro é excluído em vez de ser reportado: seu prompt pede raciocínio antes da resposta, e 63–64% das respostas de ambos os lados não haviam chegado a um raciocínio dentro do orçamento de tokens, então qualquer valor de acurácia seria um piso definido pelo orçamento, e não uma medição.

A ressalva que mais importa

A direção de recusa foi estimada a partir do modelo base BF16 do qual o Bonsai pack foi treinado. A arquitetura e a base oculta são idênticas, então a geometria se alinha. Mas quão bem essa direção sobrevive ao treinamento com reconhecimento de quantização não foi totalmente medido.

O runtime pode provar, matematicamente e com precisão de cerca de 1e-6, que remove a direção fornecida de toda escrita residual. Não pode provar apenas com isso que a direção ainda captura, no modelo quantizado, a mesma característica comportamental que capturava no modelo denso. Essas são afirmações diferentes, e apenas a primeira está resolvida. Qualquer pessoa que leia a tabela de segurança acima deve lê-la sabendo que a intervenção é exatamente tão eficaz quanto a suposição de transferência de direção, e essa suposição é a questão em aberto.

Há também o enquadramento prático que a OrcaRouter dá ao próprio lançamento, que vale a pena repetir em vez de atenuar com paráfrase: remover uma direção de recusa aprendida pode fazer com que um modelo responda a solicitações que o original teria recusado. Este é um mecanismo de pesquisa e de controle de inferência, não uma evidência de que qualquer saída resultante seja segura, correta ou apropriada, e implantações que o utilizem devem aplicar os seus próprios controles de acesso e aplicação de políticas. Remover recusas não é uma melhoria gratuita, e este texto não foi escrito como se fosse.

Três notas práticas adicionais para quem for reproduzi-lo. O pacote deve ser carregado com seu próprio runtime embutido — um carregador MLX comum pode parecer carregá-lo com sucesso enquanto calcula silenciosamente a coisa errada, então se as saídas parecerem erradas antes mesmo de a ablação ser ativada, verifique primeiro o caminho de carregamento. A ablação seletiva por camada é suportada, então a intervenção não precisa ser tudo ou nada. E a avaliação de ablação foi executada na expansão FP16 desdobrada do pacote, em vez de o pacote executar seus próprios kernels, porque a matmul quantizada empacotada não tem implementação CUDA e o backend de CPU precisa de minutos por passagem direta; essa expansão carrega os valores ternários do pacote exatamente e reproduz as próprias distribuições de próximo token do pacote com três casas decimais em verificações pontuais, mas é uma mudança de contêiner e vale a pena saber. O código e as tabelas completas estão no repositório OrcaRouter Ternary Bonsai 2 27B Uncensored. Uma comparação separada cobrindo a build MLX ablacionada contra o caminho MLX do Qwen3.8 27B não modificado se aprofunda nos detalhes específicos do runtime.

Para onde isto vai, e o que ainda não foi comprovado

O que um modelo de 27B quase sem perdas, em cerca de seis gigabytes, muda para agentes locais tem a ver, sobretudo, com o que passa a ficar residente. Um modelo de linguagem que cabe junto com uma janela de contexto real em um laptop de 16 GB pode permanecer carregado enquanto um agente faz outro trabalho — lendo arquivos, chamando ferramentas, mantendo um plano ao longo dos turnos — em vez de ser trocado a cada requisição ou enviado para um servidor. Essa é a diferença entre um modelo local que você experimenta e um modelo local que você deixa rodando, e é a propriedade específica que os números agênticos, τ 2-Bench em 80,2 e BFCL v3 em 74,9, existem para comprovar.

O que não está comprovado é uma lista mais longa do que o anúncio sugere.

• Sem reprodução independente. Cada número de qualidade neste artigo — o 83,9, o 98,2%, as médias por categoria — é medição da própria Prism ML em sua própria suíte. Isso não é um defeito no lançamento; é simplesmente o que um dia de existência parece. Também é a primeira coisa que vai mudar.

• O trabalho agêntico de longo horizonte é a parte mais fraca da própria tabela do fornecedor, não a mais forte. Terminal-Bench 2.1 com 52,8 contra 69,7 é uma lacuna real, e o fornecedor diz que a capacidade é parcial.

• Prompts que você ainda não testou. O perfil de falha de modelos de baixa precisão é seletivo, e o colapso do IQ2_XXS no AIME26 e no LiveCodeBench enquanto mantém 85,79 no MMLU-Redux é a evidência mais clara disponível de que uma média de benchmark não diz o que acontece na sua carga de trabalho. O Bonsai 2 não mostra esse colapso nesses dois benchmarks, o que é encorajador e não é o mesmo que uma garantia.

• A questão da transferência de direção na variante abliterada, acima, que não é resolvida por construção.

• Se os kernels se mantêm à medida que os runtimes evoluem. No momento, este modelo precisa de um fork; o llama.cpp padrão rejeita dois dos três formatos e corrompe silenciosamente o terceiro. Até que esses kernels cheguem ao upstream, "roda em qualquer lugar onde o llama.cpp roda" ainda não é verdade para este modelo.

O lançamento em si não está em questão. Um modelo multimodal da classe 27B com 5,93 GB — um nono da pegada daquilo de que foi comprimido —, com matemática e programação no nível do modelo original e capacidade de seguir instruções ligeiramente superior, é um ponto de operação genuinamente diferente para inferência local. A postura razoável em 18 de setembro de 2026 é tomar o tamanho do arquivo como fato, tomar o valor de retenção como uma alegação cuidadosa do fornecedor feita há um dia sobre uma suíte escolhida pelo fornecedor, e reservar o julgamento sobre sua própria carga de trabalho até tê-lo executado nela.

O código de ablação em tempo de execução, a direção de recusa e as tabelas completas de avaliação são publicados pela OrcaRouter, juntamente com a plataforma de roteamento que a equipe desenvolve.