Ternary Bonsai 2 27B: paridade entre WebGPU e runtime nativo para inferência de IA local

Por que o Ternary Bonsai 2 27B muda a questão entre navegador e IA local nativa

Ternary Bonsai 2 27B é interessante porque aparece em mais de um grupo de runtime. O lançamento da Prism ML de 17 de setembro descreve um checkpoint ternário de classe 27B baseado em Qwen3.8, um formato de 1,76 bits efetivos e uma pegada de modelo reportada de 5,9GB. A coleção relacionada no Hugging Face aponta para artefatos nativos como GGUF e MLX. O Space WebGPU adiciona um caminho de navegador.

Essa combinação muda a pergunta. A pergunta útil já não é "Este modelo pode rodar localmente?". É "Quais partes da experiência local sobrevivem à mudança de runtime nativo para runtime de navegador?"

Esse é um critério mais estreito e mais útil. Uma demonstração no navegador não prova paridade com CUDA ou MLX em throughput, comprimento de contexto, suporte a recursos, comportamento de memória, logging ou repetibilidade. Ela prova que há superfície pública de artefatos suficiente para testar a fronteira corretamente.

Este artigo não é uma repetição do teste de aceitação em dispositivo do Bonsai 1 anterior da Optijara. O texto de julho analisou a aceitação em dispositivo de primeira geração. O Bonsai 2 precisa de uma lente de paridade de runtime: download, cache, configuração do adaptador WebGPU, compilação de shader ou kernel, carregamento do modelo, prefill, decode, comportamento de contexto, limites de texto e imagem e repetibilidade em relação aos caminhos nativos. Para equipes que comparam o comportamento de arquivos quantizados entre runtimes, o guia de migração de layout por tensor GGUF e receita de quantização é o complemento melhor.

WebGPU no navegador é uma experiência de produto antes de ser uma história de benchmark. Pode ser uma forma de baixo atrito de permitir que uma parte interessada toque em um modelo local. Também pode ocultar os detalhes exatos de que um avaliador sério precisa. Trate-o como um runtime com seus próprios modos de falha, não como um invólucro mais bonito em torno da inferência nativa.

Mais uma proteção. Os números de desempenho nativo da Prism, publicações da comunidade e reações rápidas a demos são sinais úteis de descoberta. Eles não são evidências de benchmark intercambiáveis. A Optijara não executou um benchmark independente para este artigo. Quaisquer testes abaixo são planos de medição propostos, não resultados declarados.

O mapa de artefatos: o que cada fonte pode provar

A primeira tarefa é separar evidência de suposição. A página de lançamento pode estabelecer o anúncio, o posicionamento do modelo e as declarações do publicador. A coleção do Hugging Face pode mostrar o agrupamento público de artefatos. Cartões de modelo individuais podem mostrar arquivos específicos de runtime, licenças, revisões e notas de uso. A árvore e o README do Space WebGPU podem mostrar o que o artefato de navegador expõe em código ou interface. Nenhuma dessas fontes, sozinha, prova que toda capacidade do modelo chega ao navegador.

Isso importa porque uma pegada de pesos de 5,9GB não é memória de pico. Não é tamanho de cache do navegador. Não é overhead de transferência, cache de shader, alocação de buffer temporário ou sobrevivência da aba sob pressão. A execução no navegador pode precisar de memória de trabalho extra durante download, compilação, execução e reidratação de cache. Runtimes nativos muitas vezes expõem relatórios de memória, controles de quantização e logs mais claros.

A mesma cautela se aplica a contexto longo e declarações multimodais. Se uma família de modelos ou arquitetura menciona contexto longo ou visão, isso não significa que a demo WebGPU suporte entrada de imagem ou um comprimento máximo de contexto prático. Limites de memória do navegador, comportamento do adaptador de GPU, pressão de cache e construção de prompt também têm influência.

Mapa de paridade entre navegador e nativo

O Mapa de Paridade entre Navegador e Nativo usa cinco dimensões: disponibilidade de artefato, caminho de inicialização, caminho de tokens, superfície de recursos e envelope operacional. O objetivo não é coroar WebGPU, MLX ou CUDA. O objetivo é parar de tratar "roda no navegador" como uma resposta de sim ou não.

WebGPU pode ser suficiente para uma demo, um fluxo educacional, uma avaliação interna ou um prompt local leve em que velocidade de configuração importa mais do que instrumentação profunda. É especialmente útil quando uma equipe quer que pessoas vejam um caminho de modelo local sem instalar runtimes nativos.

Caminhos nativos ainda importam quando a equipe precisa de benchmarking repetível, controles explícitos de hardware, melhor profiling, automação semelhante a servidor, suites de avaliação mais longas ou comparações cuidadosas entre arquivos quantizados. MLX é o caminho natural para Apple Silicon. CUDA e GGUF são o caminho de avaliação para workstation e servidor.

{
  "framework": "Browser-to-Native Parity Map",
  "dimensions": ["artifact_availability", "startup_path", "token_path", "feature_surface", "operating_envelope"],
  "claim": "Parity is workload-specific and must be measured separately for browser WebGPU, MLX, and CUDA or GGUF paths.",
  "benchmark_status": "proposed_test_plan_only"
}

Meça inicialização e geração de tokens separadamente

Uma comparação justa de runtime para Bonsai 2 começa separando inicialização de geração. Download da primeira visita, recarregamento com acerto de cache, inicialização do adaptador WebGPU, compilação de shader, carregamento do modelo, latência do primeiro token, velocidade de prefill, velocidade de decode, pressão de memória e estabilidade da aba são eventos separados. Junte tudo em uma pontuação de "pareceu rápido" e o verdadeiro gargalo desaparece.

Não compare um número nativo do publicador, uma anedota de velocidade em rede social e uma impressão de demo no navegador como se fossem o mesmo benchmark. Eles podem usar hardware, comprimentos de prompt, configurações de contexto, arquivos quantizados, versões de navegador e estados de aquecimento diferentes.

Um relatório útil deve incluir o pacote exato de prompts, revisão do modelo, commit do runtime, sistema operacional, adaptador de GPU, versão do navegador, arquivo quantizado, comprimento de contexto e parâmetros de decodificação. Se esses detalhes estiverem ausentes, o resultado ainda pode ser interessante, mas não deve orientar uma decisão de adoção.

Paridade de recursos é mais do que saída de texto

A geração de texto costuma ser o primeiro alvo de paridade porque é visível e fácil de testar. Mas paridade de texto não é paridade completa do modelo. As equipes também devem verificar comportamento de JSON estruturado, reuso de contexto em múltiplas rodadas, resumo de documentos longos, comportamento de recusa se relevante e variação em execuções repetidas.

Suporte a visão precisa de sua própria prova. Se uma família completa de modelos ou documentação menciona capacidade multimodal, o artefato de navegador ainda precisa de evidência de UI e código antes que alguém declare suporte a entrada de imagem. Os rótulos úteis são compatível, parcialmente compatível, incompatível ou desconhecido até ser testado.

Contexto longo merece a mesma disciplina. Uma declaração de contexto em nível de arquitetura não significa que uma aba do navegador possa processar o contexto máximo com memória, latência e estabilidade aceitáveis. Para o Bonsai 2, a melhor pergunta operacional não é "qual é o contexto teórico?". É "quais comprimentos de prompt permanecem estáveis e úteis neste runtime neste dispositivo?"

Essa formulação é menos dramática, mas ajuda as equipes a evitar transformar uma suposição de demo em promessa de produto.

Uma matriz prática de dispositivos e workflows

As equipes devem avaliar o Bonsai 2 em dispositivos e workflows, não em um único prompt favorável. A matriz abaixo é um plano proposto, não um resultado de benchmark da Optijara.

A suite de prompts deve incluir uma instrução curta, um resumo de documento longo, uma saída JSON estruturada, um teste de reuso de contexto em múltiplas rodadas, uma verificação de entrada de imagem somente se o artefato a suportar e uma verificação de recarregamento de cache. Registre aprovação, cautela ou falha. "Cautela" é útil quando um runtime funciona para texto curto, mas falha em contexto longo, precisa de uma flag específica do navegador ou se comporta de forma diferente após recarregamento aquecido.

Erros comuns ao testar IA local no navegador contra runtimes nativos

O primeiro erro é tratar tamanho de download como requisito de memória. A pegada do publicador é um fato do artefato do modelo, não um envelope completo de runtime. Meça memória de pico, tamanho de cache, buffers temporários e comportamento de falha.

O segundo erro é tratar throughput nativo como throughput no navegador. Números nativos de CUDA ou MLX não são transferidos automaticamente para WebGPU. Meça cada runtime em seu próprio caminho.

O terceiro erro é tratar suporte de demo como suporte completo do modelo. Um Space de navegador pode expor geração de texto enquanto deixa entrada de imagem, contexto completo ou controles avançados sem suporte. Inspecione arquivos, UI e comportamento de rede antes de fazer declarações.

O quarto erro é presumir que IA local no navegador é privada por padrão. Execução local ainda pode envolver endpoints de fetch, comportamento de armazenamento, service workers, telemetria ou chamadas de dependência. Inspecione o caminho de rede. Desconecte a rede após o carregamento aquecido e veja o que ainda funciona.

O quinto erro é usar um único prompt como benchmark. Uma instrução educada isolada pode ocultar problemas de contexto, estrutura, decodificação e estabilidade. Use uma suite de prompts e mantenha entradas exatas sob controle de versão.

Ressalvas e trocas operacionais

IA local com navegador em primeiro lugar pode reduzir o atrito de configuração, mas não remove o trabalho de implementação. Segurança e privacidade ainda precisam de revisão de código, inspeção de rede, revisão de cache, revisão de dependências e teste de comportamento offline.

O desempenho varia por navegador, driver, adaptador de GPU, memória do dispositivo, estado térmico e cadência de atualização do runtime. A reprodutibilidade é mais difícil quando o navegador faz parte do runtime. Uma atualização de navegador, atualização de driver, mudança no compilador de shader ou invalidação de cache pode mudar a experiência.

Caminhos nativos exigem mais configuração, mas muitas vezes dão às equipes maior controle sobre versões, logs, profiling e automação. Manutenção é o custo oculto. Se uma equipe entrega IA no navegador como ferramenta interna, alguém é responsável por compatibilidade de navegador, atualizações de artefato do modelo, invalidação de cache e notas de suporte para dispositivos incompatíveis. Se uma equipe entrega workflows nativos, alguém é responsável por instalação de runtime, drivers, arquivos quantizados e restrições de hardware. Nenhum caminho é gratuito.

Guia de decisão: WebGPU, MLX, CUDA ou um caminho misto

Escolha WebGPU no navegador quando o objetivo for uma demo de baixo atrito, walkthrough educacional, piloto interno ou caminho de avaliação em que usuários possam tolerar limites explícitos de recursos. É uma boa primeira experiência quando a equipe quer testar interesse antes de instalar stacks nativas.

Escolha MLX quando o público de avaliação estiver majoritariamente em Apple Silicon e a equipe precisar de integração nativa, repetibilidade e caracterização de dispositivos Apple. MLX também é útil quando o caminho de navegador funciona, mas não expõe observabilidade suficiente para uma comparação séria.

Escolha CUDA ou GGUF quando a equipe precisar de avaliação no estilo workstation ou servidor, instrumentação mais profunda, comparação de quantização, suites de prompts mais longas ou teste de desempenho controlado. Esse caminho tem mais custo de configuração, mas geralmente é a via mais forte para medição repetível.

Use múltiplos runtimes quando o Bonsai 2 aparecer em mais de um ambiente. Uma demo no navegador pode ajudar partes interessadas a entender a experiência. MLX pode apoiar laptops de desenvolvedores Apple. CUDA ou GGUF pode ancorar avaliação controlada. É aí que o Mapa de Paridade entre Navegador e Nativo justifica seu uso: ele transforma a escolha de runtime em um teste de aceitação documentado, em vez de um debate sobre manchetes de lançamento.

Para equipes que precisam de um plano de teste neutro, a Optijara pode ajudar a definir a suite de prompts, matriz de runtimes, campos de medição e notas de adoção sem presumir de antemão que navegador, MLX ou CUDA é a resposta certa.