llama.cpp merged PR 29600, 'Runtime support for Prism Bonsai 2 27B', on October 11. Model-specific runtime work has entered upstream.
On September 29 the PR author compared correctness against the Prism fork on the same Q2_0 file. The PPL ratio was 1.0001 on Metal (M5) and 0.9995 on CUDA (A100), while master without the PR gave a PPL of about 1.26 million on the same model.
This is contributor-side evidence limited to a specific file and backends. It is not validation across all packings and backends or an independent reproduction.
Why the weight format alone is not enough
According to the model card, Bonsai 2 folds a blockwise Hadamard rotation into the stored weights. The matching transform must therefore be applied to activations at inference time.
PTQ1_0 and PQ2_0 files use separate packing formats. The GGUF extension is only a container and does not guarantee the runtime implements everything inside.
Caveats: a mismatch between the merge and the docs
The Prism model card checked on October 13 still points to its own fork. It says stock llama.cpp rejects PQ2_0 and PTQ1_0 as unknown types and loads Q2_0 without warning before producing garbage.
The backend docs also describe upstream integration as pending and say to use the fork for all Bonsai 2 GGUF formats. How far each combination of new upstream builds and published packs is complete is not confirmed.
The PTQ1_0 format continued in a separate PR, 29672. One merge is not a blanket compatibility announcement.
Two separate support tables in the backend docs
The backend docs keep a file-format table and a Hadamard-transform table apart. They state that sign flips and model graph transformations are also needed, and that format decoding or a transform kernel alone is not enough.
The tables reflect source implementation at specific fork releases. On the SYCL path, for example, PTQ1_0 expands to a PQ2_0-sized layout, so a smaller file does not guarantee smaller GPU memory.
Recording the run combination as one unit
Record the model filename and revision, the runtime commit or package version, the chosen device and backend, and the actual launch arguments as one combination. Speed results carry that combination too.
That keeps a successful test reproducible after an app changes its bundled runtime or the model repository changes its recommended packing.
A first check based on output, not loading
Failure can show up as wrong text rather than an error, so a file load or token output alone is weak verification. Starting with a short prompt whose answer is known and widening to representative tasks is more reliable.
The model card says the default reasoning effort is xhigh, and low is not supported and behaves close to xhigh. A thinking trace cut off by a small output budget is easy to mistake for a backend fault.
What remains to check after the merge
The merge gives downstream apps a concrete change to adopt. Until an app documents the relevant runtime and format support, the project’s pinned-version guidance applies, and correctness comes before speed.
No hardware or model was run for this article.
The upstream merge is a starting point; which file runs correctly on which build and backend is still checked combination by combination.