Ternary Bonsai 2 27B: WebGPU vs Native Runtime Parity for Local AI Inference

Why Ternary Bonsai 2 27B changes the browser versus native local AI question

Ternary Bonsai 2 27B is interesting because it appears in more than one runtime bucket. Prism ML's September 17 release describes a Qwen3.8-based 27B-class ternary checkpoint, a 1.76 effective bits format, and a reported 5.9GB model footprint. The related Hugging Face collection points to native artifacts such as GGUF and MLX. The WebGPU Space adds a browser path.

That mix changes the question. The useful question is no longer, "Can this model run locally?" It is, "Which parts of the local experience survive the move from native runtime to browser runtime?"

That is a narrower, more useful bar. A browser demo does not prove parity with CUDA or MLX on throughput, context length, feature support, memory behavior, logging, or repeatability. It proves there is enough public artifact surface to test the boundary properly.

This article is not a rerun of Optijara's earlier Bonsai 1 on-device acceptance test. The July piece looked at first-generation on-device acceptance. Bonsai 2 needs a runtime parity lens: download, cache, WebGPU adapter setup, shader or kernel compilation, model load, prefill, decode, context behavior, text and image boundaries, and repeatability against native paths. For teams comparing quantized file behavior across runtimes, the GGUF per-tensor layout and quant recipe migration guide is the better companion.

Browser WebGPU is a product experience before it is a benchmark story. It can be a low-friction way to let a stakeholder touch a local model. It can also hide the exact details a serious evaluator needs. Treat it as a runtime with its own failure modes, not as a prettier wrapper around native inference.

One more guardrail. Prism's native performance numbers, community posts, and quick demo reactions are useful discovery signals. They are not interchangeable benchmark evidence. Optijara did not run an independent benchmark for this article. Any tests below are proposed measurement plans, not claimed results.

The artifact map: what each source can prove

The first job is separating evidence from assumption. The release page can establish the announcement, model positioning, and publisher claims. The Hugging Face collection can show the public artifact grouping. Individual model cards can show runtime-specific files, licenses, revisions, and usage notes. The WebGPU Space tree and README can show what the browser artifact exposes in code or interface. None of those sources, alone, proves that every model capability lands in the browser.

This matters because a 5.9GB weight footprint is not peak memory. It is not browser cache size. It is not transfer overhead, shader cache, temporary buffer allocation, or tab survival under pressure. Browser execution may need extra working memory during download, compilation, execution, and cache rehydration. Native runtimes often expose clearer memory reporting, quant controls, and logs.

The same caution applies to long context and multimodal claims. If a model family or architecture references long context or vision, that does not mean the WebGPU demo supports image input or a practical maximum context length. Browser memory limits, GPU adapter behavior, cache pressure, and prompt construction all have a vote.

Browser-to-Native Parity Map

The Browser-to-Native Parity Map uses five dimensions: artifact availability, startup path, token path, feature surface, and operating envelope. The goal is not to crown WebGPU, MLX, or CUDA. The goal is to stop treating "runs in the browser" as a yes or no answer.

WebGPU can be enough for a demo, an education flow, an internal evaluation, or a lightweight local prompt where setup speed matters more than deep instrumentation. It is especially useful when a team wants people to see a local model path without installing native runtimes.

Native paths still matter when the team needs repeatable benchmarking, explicit hardware controls, better profiling, server-like automation, longer evaluation suites, or careful comparisons across quant files. MLX is the natural Apple Silicon lane. CUDA and GGUF are the workstation and server evaluation lane.

{
  "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"
}

Measure startup and token generation separately

A fair Bonsai 2 runtime comparison starts by separating startup from generation. First visit download, cache hit reload, WebGPU adapter initialization, shader compilation, model load, first token latency, prefill speed, decode speed, memory pressure, and tab stability are separate events. Roll them into one "it felt fast" score and the real bottleneck disappears.

Do not compare a publisher native number, a social media speed anecdote, and a browser demo impression as if they were the same benchmark. They may use different hardware, prompt lengths, context settings, quant files, browser versions, and warmup states.

A useful report should include the exact prompt pack, model revision, runtime commit, operating system, GPU adapter, browser version, quant file, context length, and decoding parameters. If those details are missing, the result may still be interesting, but it should not drive an adoption decision.

Feature parity is more than text output

Text generation is usually the first parity target because it is visible and easy to test. But text parity is not full model parity. Teams should also check structured JSON behavior, multi-turn context reuse, long document summarization, refusal behavior if relevant, and variance across repeated runs.

Vision support needs its own proof. If a full model family or documentation references multimodal capability, the browser artifact still needs UI and code evidence before anyone claims image input support. The useful labels are supported, partially supported, unsupported, or unknown until tested.

Long context deserves the same discipline. An architecture-level context claim does not mean a browser tab can process the maximum context with acceptable memory, latency, and stability. For Bonsai 2, the better operating question is not "what is the theoretical context?" It is "which prompt lengths remain stable and useful in this runtime on this device?"

That wording is less dramatic, but it helps teams avoid shipping a demo assumption as a product promise.

A practical device and workflow test matrix

Teams should evaluate Bonsai 2 across devices and workflows, not one friendly prompt. The matrix below is a proposed plan, not an Optijara benchmark result.

The prompt suite should include a short instruction, a long document summary, a structured JSON output, a multi-turn context reuse test, an image-input check only if the artifact supports it, and a cache reload check. Record pass, caution, or fail. "Caution" is useful when a runtime works for short text but fails long context, needs a specific browser flag, or behaves differently after warm reload.

Common mistakes when testing browser local AI against native runtimes

The first mistake is treating download size as memory requirement. The publisher footprint is a model artifact fact, not a full runtime envelope. Measure peak memory, cache size, temporary buffers, and failure behavior.

The second mistake is treating native throughput as browser throughput. Native CUDA or MLX figures do not automatically transfer to WebGPU. Measure each runtime on its own path.

The third mistake is treating demo support as full model support. A browser Space may expose text generation while leaving image input, full context, or advanced controls unsupported. Inspect files, UI, and network behavior before making claims.

The fourth mistake is assuming browser local AI is private by default. Local execution can still involve fetch endpoints, storage behavior, service workers, telemetry, or dependency calls. Inspect the network path. Disconnect the network after warm load and see what still works.

The fifth mistake is using one prompt as a benchmark. A single polite instruction can hide context, structure, decoding, and stability issues. Use a prompt suite and keep exact inputs under version control.

Caveats and operating trade-offs

Browser-first local AI can reduce setup friction, but it does not remove implementation work. Security and privacy still need code review, network inspection, cache review, dependency review, and offline behavior testing.

Performance varies by browser, driver, GPU adapter, device memory, thermal state, and runtime update cadence. Reproducibility is harder when the browser is part of the runtime. A browser update, driver update, shader compiler change, or cache invalidation can change the experience.

Native paths require more setup, but they often give teams stronger control over versions, logs, profiling, and automation. Maintenance is the hidden cost. If a team ships browser AI as an internal tool, someone owns browser compatibility, model artifact updates, cache invalidation, and support notes for unsupported devices. If a team ships native workflows, someone owns runtime installation, drivers, quant files, and hardware constraints. Neither path is free.

Decision guide: WebGPU, MLX, CUDA, or a mixed path

Choose browser WebGPU when the goal is a low-friction demo, educational walkthrough, internal pilot, or evaluation path where users can tolerate explicit feature boundaries. It is a good first experience when the team wants to test interest before installing native stacks.

Choose MLX when the evaluation audience is mostly on Apple Silicon and the team needs native integration, repeatability, and Apple-device characterization. MLX is also useful when the browser path works but does not expose enough observability for a serious comparison.

Choose CUDA or GGUF when the team needs workstation or server-style evaluation, deeper instrumentation, quant comparison, longer prompt suites, or controlled performance testing. This path has more setup cost, but it is usually the stronger lane for repeatable measurement.

Use multiple runtimes when Bonsai 2 will appear in more than one environment. A browser demo can help stakeholders understand the experience. MLX can support Apple developer laptops. CUDA or GGUF can anchor controlled evaluation. That is where the Browser-to-Native Parity Map earns its keep: it turns runtime choice into a documented acceptance test instead of a debate about launch headlines.

For teams that need a neutral test plan, Optijara can help define the prompt suite, runtime matrix, measurement fields, and adoption notes without assuming that browser, MLX, or CUDA is the right answer in advance.