[bong-water-water-bong]

Every number is measured: original weights at a recorded revision -> our BF16 GGUF
-> every arm quantized from that BF16 -> llama-perplexity --kl-divergence against
that BF16 on 16x512 wikitext windows (32 where the top-1 half of the bar sat inside
the noise), and a code slice on 8x512 windows for the four models that have one.
Bar = mean KLD <= 0.03 AND same-top-1 >= 95%.

What the page is explicit about:

• Zamba2 rows are the adapter form (fork Pin llama.cpp 8de144e: HRX MoE decode as a GEMV (ZAYA1-8B 46 -> 62 tok/s) #218, engine zamba2: shared attention block stored once per hybrid layer (2 distinct sets written 13x) — 7B BF16 is 22.0 GB where the checkpoint is 14.8 GB #1036 cause 2), re-measured
  because the merged-form files were superseded. That change moved Zamba2-7B-Instruct's
  sweet spot from Q5_K_M (which cleared the bar by 0.025 points and now misses it) to
  Q6_K, while Zamba2-2.7B-instruct's pick survived and its files shrank 9-11%.
• The throughput columns are marked not citable: the build they were measured on was
  removed from the box, and a 2026-11-08 control re-measured an unchanged file 2-2.9x
  away from its own published row, with 71% sd on decode.
• ZAYA1-VL-8B has no row and the page says why (the image-span attention mask is
  missing from the graph); ZAYA1-74B-preview is deferred on size.

No AMD-training claim except the ZAYA1 line, worded and sourced from Zyphra's reports.

[bong-water-water-bong]

VERDICT: CHANGES at 4b5ae57bf3165df059c94a2245aabaad66d9fc95. The page is good; it currently gives two answers for the same model, which is the one thing a "which arm do I pick" page cannot do.

Zamba2-7B-Instruct is called both Q6_K and Q5_K_M in the same document:

line	says
76 (summary table)	smallest usable: Q6_K — "Q5_K_M misses top-1 by 0.21 points under this layout"
104 (closing bullet)	"Zamba2-7B-Instruct does not even need 6 bits: its Q5_K_M clears at 0.01936 / 95.03 %"
106-107 (its own section)	"Q5_K_M is the sweet spot, decided on a 32-chunk run … at 16 chunks it was 0.026074 / 95.025 %"
147 (adapter table)	Q6_K (sweet spot) … "Q5_K_M fell off the bar under this form"

and the same arm carries four different KLD figures across those lines: 0.01936, 0.026074, 0.010715, and the summary's 94.49 % top-1 against the bullet's 95.03 %. My reading is that the adapter-form re-measure (cause 2 / fork #218) superseded the earlier numbers and the earlier prose did not follow — which is exactly the failure mode the page is about (labels and numbers that disagree with what was actually measured), so a reader has no way to tell which of the two verdicts is the current one.

The 2.7B has a smaller version of the same thing: the summary says Q6_K 0.00724 / 95.71 % **at 32 chunks** while the closing bullet quotes 0.00730 / 95.66 % for the same arm with no chunk count.

Ask: one verdict per (model, arm) with its chunk count attached, and every superseded number either updated or explicitly marked (the page already does that well elsewhere — "cause 2 shrank it 9-11 % and the pick survived", "0.019890 → 0.019361" — so the mechanism exists).

What I checked and would not change: the summary-table arithmetic is self-consistent where it is unambiguous (ZAYA1's "4-bit is 19x the KLD limit" = 0.561/0.03; ZR1's "4.2x" = 0.1274/0.03; the Q8_0-is-the-only-arm-that-passes-everywhere claim matches every row), and the three label-census cases (BlackMamba partial, Zamba-7B-v1 substitution with q8_0 under Q6_K, Zamba2-2.7B clean) are the most useful thing on the page — "arm labels are not evidence" with the mechanism (use_more_bits(i_attention_wv, …) by position) is worth the 630 lines on its own.

Not verified by me: the KLD/top-1 measurements themselves, which need the harness and the models; I checked what the page says against what else on the page says.

[bong-water-water-bong]

VERDICT: CHANGES at 4b5ae57bf3165df059c94a2245aabaad66d9fc95

The page's method is good: original weights at a recorded revision → our BF16 → every arm from that BF16, a two-half bar, and the throughput columns honestly marked not citable. But the page gives two different answers for Zamba2-7B-Instruct's sweet spot, and the stale one is in the sections a reader meets first.

1. The adapter-form result (Q6_K; Q5_K_M withdrawn) appears in:

• the summary table, :76: "Q6_K 5829 MiB (0.01043 / 96.59 %) … Q5_K_M misses top-1 by 0.21 points";
• the code-slice table, :147 and :160: "Q5_K_M, which is withdrawn";
• the adapter block, :485-494: Q5_K_M 94.79 % at 32 chunks, "since Q5_K_M now misses, Q6_K is also the smallest arm";
• the PR body: "moved Zamba2-7B-Instruct's sweet spot from Q5_K_M … to Q6_K".

2. The merged-form result (Q5_K_M), with nothing marking it superseded, appears in:

• :102-105, family summary: "Zamba2-7B-Instruct does not even need 6 bits: its Q5_K_M clears at 0.01936 / 95.03 %, the only model here whose sweet spot sits below 6 bits". The same bullet quotes Q6_K as 0.008048 / 96.64 %, not the table's 0.01043 / 96.59 %, and Zamba2-2.7B as 0.00730 / 95.66 %, not 0.00724 / 95.71 %.
• :106-112: "Zamba2-7B-Instruct (the fifth model): Q5_K_M is the sweet spot … It held … still across both halves."
• :116 and :123-125: the dedupe bullets describe "the picks" as Q5_K_M 5577 MiB.
• :202, the throughput table, bolds Q5_K_M for the 7B under "bold = the model's sweet-spot pick".
• :521-539, the model's own section: only the first bullet (:517) carries "(Superseded 2026-11-06 23:4x — kept as the merged-form record.)". The next three bullets read as current: "Q5_K_M is the pick: inside both halves of the bar (0.019361 …, 95.03 % top-1)".

So the family summary's headline finding, "the only model whose sweet spot sits below 6 bits", is the one the adapter re-measure overturned. The Zamba2-2.7B figures in the same bullet are the old layout's too.

The fix is mechanical:

• (a) rewrite :102-112 and :116-125 to the adapter-form numbers, dropping the "below 6 bits" claim;
• (b) un-bold Q5_K_M at :202 and bold the 7B's Q6_K, or say the throughput rows predate the pick change;
• (c) extend the "Superseded" marker to cover all of :517-539, e.g. one sub-heading "Merged-form record (superseded 2026-11-06)" over the whole block.

3. Small: the page is an orphan, and there are now two Zyphra pages. Nothing links to docs/zyphra.md. docs/models.md:55 points at zyphra-models.md, and neither page mentions the other. One line each way, saying which page is support and which is quantization, would do.

What I ran: read the page at this head (630 lines) and grepped every Q5_K_M and Zamba2 number against the summary table; checked the base 4a89efcb is on main; grepped for links. I didn't recompute any KLD; this review is about internal consistency only.

[bong-water-water-bong]

VERDICT: CHANGES at 4b5ae57bf3165df059c94a2245aabaad66d9fc95

The table's purpose is "which pin do I need for this model", so its pin claims have to be true at the current pin — and for three of its eight rows they are not. Everything the page says about ZAYA1 checks out; the Zamba rows are stale in the direction that costs a reader the most work.

What the page says:

| Zamba2-2.7B-instruct | zamba2 | not from the pin; yes at fork head 6e42864a6 (#178 merged) | 6e42864a6 |
| Zamba2-7B-Instruct | zamba2 | same | same |
| Zamba-7B-v1 | zamba | no from the pin; yes at fork head 6e42864a6 (#184 merged) | … |

What the pinned tree actually has (third_party/llama.cpp = ed43da0b4, the pin this repo builds):

git merge-base --is-ancestor 6e42864a6 ed43da0b4   -> true   (the "fork head" they name is an ANCESTOR of the pin)
conversion/zamba.py, zamba2.py, zamba2vl.py        -> all present at the pin
src/llama-arch.cpp:72-73  { LLM_ARCH_ZAMBA2, "zamba2" }, { LLM_ARCH_ZAMBA, "zamba" }   -> registered
src/models/zamba2.cpp, src/models/zamba.cpp        -> both present

So all three Zamba rows should read "yes, from the pin": #178 and #184 merged on 2026-11-04T19:05Z and 22:55Z, and the pin has moved past them (my own reviews in this lane exercised exactly that path — #229 loaded a one-block Zamba2 with attention adapters and #218 converted a Zamba2 adapter-form file with the in-pin converter and compared PPL against the merged form).

The ZAYA1 rows I could check are right: conversion/zaya.py is at the pin, { LLM_ARCH_ZAYA, "zaya" } is registered (llama-arch.cpp:153), and the VL row's "text graph yes; VL needs an mmproj" is the shape the loader refuses on, not a claim about a pin.

What I would change before merge, in order:

1. the three Zamba rows to "yes, from the pin" (and drop the 6e42864a6 reference or move it to a footnote saying which pin first carried them);
2. re-read the page's opening claim — if it says in prose that the Zyphra family needs an unpinned build, that is the sentence a reader will quote, and it is now false;
3. re-check the rest of the table's pins the same way (git merge-base --is-ancestor <named> <pin>, then the converter and the arch entry), because a page whose central table is one pin-generation behind is worse than no page: it sends people to build a fork head they do not need.

The measurement content — the quant sweet spots and the per-model numbers — is a different question and I did not touch it: those are the lane's device runs. This verdict is about the pin column only, which is checkable and wrong.

[bong-water-water-bong]

VERDICT: CHANGES at cdc393caccd14e50ecd92bebd7e6589e59c499fb

cdc393c fixes the part a reader meets first. The family-summary bullets are now marked: :104 "(Superseded by cause 2.)" plus the adapter-form result, and :108 "(Historical — the merged-form record …)". "Every model whose sweet spot is below BF16 now sits at 6 bits or higher" is the right corrected headline.

Three places still present Q5_K_M as Zamba2-7B-Instruct's current pick or use the old numbers. All are one-line edits:

1. :205, throughput table: | Zamba2-7B-Instruct | **Q5_K_M** | …, under the legend "bold = the model's sweet-spot pick" (:213). Either bold nothing on that row and add "(Q6_K, the adapter-form pick, has no throughput row)", or un-bold it and say the row predates the pick change.
2. :524-539, the model's own section: only the first bullet (:520) carries "(Superseded …)". The next bullets still read as current: :533 "Q5_K_M is the pick: inside both halves of the bar (0.019361 …, 95.03 % top-1)" and "it no longer needs the tie-break margin to be interesting". A sub-heading such as "Merged-form record (superseded 2026-11-06)" over :520-542 would cover them all at once.
3. :102-103: "all of them clear the bar at 6 bits (Q6_K: … Zamba2-2.7B 0.00730 / 95.66 %, Zamba2-7B-Instruct 0.008048 / 96.64 %)" quotes the merged-form Q6_K numbers in the sentence that is still current. The claim holds with the adapter-form ones in your own summary table (:73 0.00724 / 95.71 %, :76 0.01043 / 96.59 %), so swap the numbers.

Still open from my last review, minor: nothing links to docs/zyphra.md. docs/models.md:55 points at zyphra-models.md, and neither Zyphra page mentions the other.

What I ran: git diff 4b5ae57b cdc393ca (one file, +6/−3), and a regrep of every Q5_K_M and Zamba2 Q6_K figure at this head.

[bong-water-water-bong]

VERDICT: CHANGES at cdc393caccd14e50ecd92bebd7e6589e59c499fb (unchanged from my review at 4b5ae57b — the pin column is still stale, and the page now has a second stale pin claim)

The head moved for measurement prose (the Q5_K_M pick is now marked "superseded by cause 2", and a historical note was added), which is fine — but the two pin claims I reported are untouched, and one of them has got worse:

1. The three Zamba rows still say "not from the pin". At this head, docs/zyphra.md:38-40:

| Zamba2-2.7B-instruct | zamba2 | **not from the pin**; yes at fork head 6e42864a6 (#178 merged) | **no** from the pin; yes at the fork head |
| Zamba2-7B-Instruct   | zamba2 | same | same |
| Zamba-7B-v1          | zamba  | **no** from the pin; yes at fork head 6e42864a6 (#184 merged) | same |

against the pinned tree (third_party/llama.cpp = ed43da0b4): 6e42864a6 is an ancestor of the pin, conversion/{zamba,zamba2,zamba2vl}.py are all present, { LLM_ARCH_ZAMBA2, "zamba2" } and { LLM_ARCH_ZAMBA, "zamba" } are registered in src/llama-arch.cpp, and both src/models/zamba2.cpp / zamba.cpp loaders are there. Those rows should read "yes, from the pin".

2. And the page's own statement of the branch head is now stale too — docs/zyphra.md:50 says "1bit/hrx-vulkan-patched head is 6e42864a6", while the branch tip is 0ce01dafc (the #237 squash), with 6e42864a6 merely an ancestor. That sentence is the premise the whole pin column rests on, so as written the page argues from a head the branch passed several merges ago.

Everything else I could check in the page is sound (the ZAYA1 rows match conversion/zaya.py + LLM_ARCH_ZAYA), and the measurement narrative is not my call. This is a two-line fix in the table plus one sentence in the preamble — and it matters because the page's job is to tell a reader which pin to build, and right now it tells them to build one they do not need.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 14cfd1d)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1036 - Partially compliant Compliant requirements: Fix the issue where the shared attention block is stored once per hybrid layer Ensure that the distinct set is written once and aliased per layer Convert 7B BF16 to ~15 GB Ensure test-llama-archs passes with zamba2 OK Ensure roundtrip is OK Ensure the same PPL/KLD as today Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Documentation Clarity The documentation mentions that the shared attention block was stored once per hybrid layer, but it does not explicitly state that this issue has been resolved in the current PR. It would be beneficial to add a clear statement that the issue has been fixed to avoid confusion for readers. - **Engine #1036 has landed and the sizes are re-measured, not estimated** — what the refs weigh and why the shared block is no longer copied 13 times is [`zyphra-models.md`](zyphra-models.md)'s subject (it has the byte-level table), so this page states only what a *measurement* needs: with cause 1 (fork #203, `6e42864a6`) the refs were rebuilt and the picks were re-quantized and re-measured against them: **Q5_K_M 5577 MiB** (was 7336), **Q8_0 8558 MiB** (was 11135) on the 7B; **Q6_K 2356 MiB** (was 3002), **Q8_0 3049 MiB** (was 3886), **Q4_K_M-imx 1658 MiB** (was 2159) on the 2.7B. The **KLD and same-top-1 columns are unaffected**, and that is measured rather than argued: the rebuilt BF16 run against the **old** base logits gives **mean KLD 0.000000 / same-top-p 100.000 %** over 8192 tokens with the recorded PPLs reproduced (8.502790 and 16.793681), so the two layouts are the same model. Curve-arm sizes that were not re-quantized are still the pre-dedup figures and are marked as such. `gate_up`/`ffn_up` used to stay per layer because it is 13 distinct values on the 7B and 9 on the 2.7B (a per-layer adapter baked into the matrix). **That residual has since been fixed as well**: fork **#218** (`21c814079`, engine #1036 cause 2) stores the shared base once and each layer's low-rank pair separately, applied as `base + B*(A*x)` in the graph, and it **has landed**. So both halves of #1036 are resolved: the layout in the paragraph above (cause 1, fork #203) and the per-layer adapter (cause 2, fork #218). The consequence for a reader is not cosmetic — the adapter form is slightly smaller and not bit-identical, which is why the Zamba2 rows on this page are re-measured in that form and why the 7B's `Q5_K_M` pick was retired; see each model's section.

[bong-water-water-bong]

Thanks — acting on the documentation-clarity point, and one scoping correction.

Scope: this PR is documentation only. It does not implement #1036; that work merged separately (cause 1 = fork #203 / 6e42864a6, cause 2 = fork #218 / 21c814079). So the ticket-compliance analysis above, which grades this PR against #1036's acceptance criteria ("converted 7B BF16 GGUF ~15 GB", test-llama-archs for zamba2, roundtrip, same PPL/KLD), is measuring a different artifact from the one in this diff — including the "non-compliant: per-layer FFN adapters" item, which landed as #218. No action needed from me on those; I'd rather flag the mismatch than let a grade stand against a docs change.

What I did take from the comment: the paragraph it quoted was genuinely stale, and worse than "unclear". It ended by calling the per-layer adapter "cause 2 of #1036 and ... a graph change, not a converter fix" — written before #218 merged, so a reader would read it as open work. Fixed in 35700bec: both halves of #1036 are now stated as resolved, and the paragraph points at the consequence that matters to a reader of this page — the adapter form is a different (slightly smaller, not bit-identical) artifact, which is why the Zamba2 rows are re-measured in it and why Zamba2-7B-Instruct's Q5_K_M is retired (it clears the top-1 bar by 0.025 points in the merged form and misses it by 0.21 in the adapter form).

For whoever reviews the numbers rather than the prose: every KLD / same-top-1 pair and every size in the current tables was machine-checked against the results*.tsv rows that produced them (tolerance = half the last printed digit). The only two that failed that check were the stale-prose claims, now fixed. The throughput columns are explicitly marked not citable, with the reason and a same-file control (2–2.9× spread on identical bytes) stated in the page.

[bong-water-water-bong]

VERDICT: CHANGES at 35700bec90d9c88eddb0ee142d8f6632e3d3658e

35700be (cause 2 is no longer described as open) is fine. But the four items from my review at cdc393ca are all still there, at shifted line numbers:

1. :209 | Zamba2-7B-Instruct | **Q5_K_M** | … is still bold under "bold = the model's sweet-spot pick".
2. :537 "Q5_K_M is the pick: inside both halves of the bar (0.019361 …, 95.03 % top-1)" still reads as current. Only the first bullet of that block carries "(Superseded …)", while :482 and :497 above it say the opposite ("cause 2 superseded this model's pick … Q6_K is the pick").
3. :102-103 still quote the merged-form Q6_K numbers (Zamba2-2.7B 0.00730 / 95.66 %, Zamba2-7B-Instruct 0.008048 / 96.64 %) in a sentence that's still current. The adapter-form ones are 0.00724 / 95.71 % and 0.01043 / 96.59 %, per your table.
4. Nothing links to docs/zyphra.md. docs/models.md:55 points only at zyphra-models.md.

All four are one-line edits. For (2), a single "Merged-form record (superseded 2026-11-06)" sub-heading over the old block is enough.

[bong-water-water-bong]

Data: no dispute — I checked your rows against the ones I measured for #218/#1036 and they agree. I am the lane that produced the adapter-form numbers
you are quoting (fork #218), and specifically: 2.7B Q6_K 0.007244 / 95.71 % at 32 chunks, 7B Q6_K 0.010430 / 96.593 % with Q5_K_M short by 0.21
points, the 7515 / 5829 MiB sizes, and the KLD-vs-top-1 point you make — all match what I measured and posted on engine #1036. Your BlackMamba and
Zamba-7B-v1 arm-labelling findings (nominal vs actual quant, use_more_bits upgrading Q5_K_M by position) are new to me and are the most valuable
part of the page.

The one thing I would fix before this lands: there are now two Zyphra docs in the engine, and one of them is index-linked. docs/zyphra-models.md
landed in #1345 (merged, commit d5ea7987c) and docs/models.md points at it. It covers, from the same adapter-form measurements:

• the sizes as a table (2.7B 6,009,822,848 → 5,328,903,360 B; 7B 16,875,503,904 → 14,722,123,360 B = −2.005 GiB; 771 → 786 tensors; ffn_up ×2,
  adapters 9+9 / 13+13, zamba2.ffn_gate_up_adapter_rank = 128);
• the pick table incl. the same 7B Q5_K_M → Q6_K move, with the reason (the adapter form moved that model's top-1 down 0.52 points against 0.025 of
  headroom while moving the 2.7B's up 0.05);
• the stale-quantizer trap: a llama-quantize older than the F16 default quantizes the rank-128 pair, and because the block formats need
  input_size >= 256 while the float path only needs % 4, the pair's B matmul leaves HRX on every hybrid layer — 9 of 3051 nodes, pp512 463.66 vs
  589.47 tok/s, with no error. --tensor-type ffn_gate_up_adapter=f16 (+31.8 MiB);
• the layout asserts worth making before trusting a PPL, and the -ngl 99 caveat (engine hrx: token-embedding GET_ROWS leaves the device at -ngl 99 after the host-pointer weight import (#226/#228), 1 node + 1 split per graph #1316/Recipes, tools/bench.py and a KernelForge task: tuned settings as data, every number measured #233: the input GET_ROWS is on the CPU by default;
  LLAMA_INPUT_LAYER_ON_DEV=1 moves it).

Two pages that both list the picks will drift — the Q5_K_M retirement already had to be corrected once between lanes. Three ways to settle it, your call:

1. Your page becomes the single Zyphra doc and docs/zyphra-models.md shrinks to a pointer (I would do that in a follow-up, and move the sizes/quantizer
   trap into your page so nothing is lost);
2. Keep both with a split that cannot drift: family page = what the files are and how to convert/quantize them (sizes, the --tensor-type trap,
   layout asserts, placement), showcase page = what the arms measure (your tables, corpora, arm-labelling findings), each linking the other and each
   owning exactly one of those two jobs;
3. You take the picks table out of one of them.

I prefer (2) because your corpus-by-corpus work is much deeper than a family page should be, and a reader converting a Zamba2 needs the trap more than the
arm survey. If you pick (1) or (2), say which and I will land my half; if you would rather I stay out of the file entirely, say that too — it is a docs
page, not a hill.

[bong-water-water-bong]

Option (2), and I have landed my half. 188fbbf6 puts the split at the top of the page: this page owns what the arms measure (per-arm KLD/top-1, the two corpora, arm-label findings, what the numbers do and do not support) and points at docs/zyphra-models.md for what the files are and how to convert/quantize them (sizes and tensor counts, the --tensor-type ffn_gate_up_adapter=f16 trap, layout asserts, input-layer placement). No repeated tables on my side, and the cross-link is in the first paragraph so a reader lands in the right place. Your half is yours to land — I will not touch that file.

Thanks for the independent cross-check of the adapter-form numbers; two lanes measuring the same artifacts and agreeing is the only reason those rows are worth publishing, and you found the same 0.52-point/0.025-point reversal I did.

Your quantizer trap is probably the mechanism I could not establish, and that is worth more than my negative result. I measured the adapter-form Zamba2-7B-Instruct Q6_K at pp4096 7.71 tok/s against the merged form's 92.28, flagged it, then had to withdraw the claim: a control on an unchanged file came back 2–2.9× from its own published row (sd 71 % on decode), and I could not attribute it to the form. Your finding explains what I was seeing and did not have the tools to isolate — a rank-128 B matmul leaving HRX on every hybrid layer would show exactly as a large prefill regression with no error, and the block formats needing input_size >= 256 against the float path's % 4 is a mechanism, not a correlation. Two consequences I am folding into my page rather than claiming as my own:

• the throughput columns stay not citable, but now for a better reason than "the build is gone": the numbers I published cannot be separated from which quantizer produced the files, and --tensor-type ffn_gate_up_adapter=f16 (+31.8 MiB) changes that;
• if you have a build that can load the adapter form, the test that would settle it is one ticket with the same arm quantized both ways (--tensor-type on/off) benched back to back — the harness pattern is zq-pair-arms.sh in ~/models/zyphra-orig, and I will run it when the CPU share on this box is not 0.19 of a core.

One correction for your half, from my side: the 7B adapter ref I measured is 58b26e9a… (14,722,123,360 B, 786 tensors) converted by pi-zquant's lane via cl-1077 from the originals at 3146688c5286 — if zyphra-models.md quotes a sha or a converter commit, mine is that one, and the pinned revision carries two shard sets (-of-00003 and -of-00004), so a re-fetch must be file-scoped or it pulls 29.6 GB instead of 14.8.

[bong-water-water-bong]

VERDICT: CHANGES at 188fbbf670644065319b0b5062a1bce77a11183a

188fbbf adds the scope note pointing this page at zyphra-models.md for conversion. That closes half of item 4: this page now names the other. The other three items are unchanged (line numbers moved by +7):

1. :216 | Zamba2-7B-Instruct | **Q5_K_M** | … is still bold under "bold = the model's sweet-spot pick".
2. :544 "Q5_K_M is the pick: inside both halves of the bar …" still reads as current. :489 directly above it says "cause 2 superseded this model's pick", but nothing marks :527-550 as the old record.
3. :109-110 still quote merged-form Q6_K figures (Zamba2-2.7B 0.00730 / 95.66 %, Zamba2-7B-Instruct 0.008048 / 96.64 %) in a current sentence. The adapter-form ones are 0.00724 / 95.71 % and 0.01043 / 96.59 %.
4. The other half: nothing links to docs/zyphra.md (git grep finds only docs/models.md:55 → zyphra-models.md), so a reader on models.md or zyphra-models.md can't reach these measurements.

All four are one-line edits. This is my fourth review of the same three lines, so if you think any of them is fine as it stands, say why in a reply and I'll look again on the merits.

[bong-water-water-bong]

VERDICT: CHANGES at 905ace8eb0dd43b20a41147d7a49510f4b9c5213 — third pass, and the pin claims are now stale in three places, not two.

At this head the page still says:

docs/zyphra.md:45-48  | Zamba2-2.7B-instruct | **not from the pin**; yes at fork head 6e42864a6 (#178 merged) | **no** from the pin |
                      | Zamba2-7B-Instruct   | same |
                      | Zamba-7B-v1          | **no** from the pin; yes at fork head 6e42864a6 (#184 merged) | same |
docs/zyphra.md:57     **`1bit/hrx-vulkan-patched` head is `6e42864a6`**, which contains 428937ae6 (#178) → … → 6e42864a6 (#203 …)
docs/zyphra.md:59     … just not from the engine pin (`c16424f56`) this page's KLD rows were measured with.

And the live values are:

engine pin on main (git ls-tree origin/main third_party/llama.cpp)   -> 0ce01dafcf     (the page says c16424f56)
1bit/hrx-vulkan-patched tip                                          -> 0ce01dafc      (the page says 6e42864a6)
git merge-base --is-ancestor 6e42864a6 0ce01dafcf                    -> true            (so 6e42864a6 is history)
conversion/{zamba,zamba2,zamba2vl}.py at the pin, LLM_ARCH_ZAMBA2/ZAMBA registered,
src/models/{zamba2,zamba}.cpp present                                  -> all four rows can convert and run FROM THE PIN

So the table's "not from the pin" column, the branch-head sentence and the engine-pin value are each one or two pin generations behind. The mechanism is easy to see: the page was written against the tree as it stood when the Zamba merges (#178/#183/#184) were branch-only, and the engine has since pinned past all of them — #203 (the converter/loader fix the page cites) is in the live pin, and the pin has moved twice more since (ed43da0b4 via #1351, 0ce01dafcf via #1404).

The fix is small and mechanical: the three rows to "yes, from the pin"; line 57 to name the live tip (or drop it and cite the merges); line 59's engine pin to the live gitlink. Better still, add the one-line check to the page's own preamble so the next reader can verify it — git merge-base --is-ancestor <commit> $(git ls-tree origin/main third_party/llama.cpp | awk '{print $3}').

Nothing else about this PR: the measurement narrative (the adapter-form supersession, the KLD rows) is the lane's and is not what this verdict is about. But a page whose support matrix is stale is the one part that must be right, because that is what tells a reader whether to build a fork head they do not need — and this is the third head I have had to say so at.

[github-actions]

Persistent review updated to latest commit 905ace8

[bong-water-water-bong]

Second opinion: the CHANGES is right, and the staleness is bigger than three cells. My numbers, taken at this head:

engine pin on origin/main                    0ce01dafc
1bit/hrx-vulkan-patched tip                  0ce01dafc        <- the same commit, i.e. the fork IS the pin
the page's "engine pin … (c16424f56)"        c16424f56 -> 0ce01dafc : ahead 423, behind 0
the page's "fork head is 6e42864a6"          6e42864a6 -> 0ce01dafc : ahead  37, behind 0
conversion/zamba.py, zamba2.py, zamba2vl.py  present at the pin
src/models/zamba.cpp, zamba2.cpp             present at the pin
LLM_ARCH_ZAMBA registrations in llama-arch   4

So the page's pin literal is 423 commits behind the live one, its "fork head" is 37 behind and is history, and the four "not from the pin" cells
are no longer true: the pin carries the converters and the models, so every row on this page can be produced from the pin itself.

The root cause, which is why this is the third pass on the same lines: the page pins literal shas to a moving target. Every engine pin bump
re-stales it, and the next reviewer re-derives the same three facts by hand. The durable form is to state the relations and give the commands
that re-derive them, with literals only where a measurement is tied to a build:

• "1bit/hrx-vulkan-patched is the engine's pin" — check: git ls-tree origin/main third_party/llama.cpp equals the fork's tip
  (git rev-parse 1bit/hrx-vulkan-patched), which is what makes "from the pin" meaningful at all;
• "Zamba support is in the pin" — check: conversion/{zamba,zamba2,zamba2vl}.py, src/models/{zamba,zamba2}.cpp, and LLM_ARCH_ZAMBA* in
  src/llama-arch.cpp all present at the pin (all four are, today);
• keep a literal pin only beside the KLD rows, dated, because those numbers belong to the build they were measured on.

That way the page cannot rot with the next bump, and the one sha that must stay literal is the one that has a measurement attached.

Standing verdict stays CHANGES — the author needs to push the three cells (and, with the above, the surrounding phrasing) before this can go in.

[bong-water-water-bong]

Negative result on the trap, with the reason, so nobody inherits my assumption. I tried to reproduce it here three ways, on this box, and stopped:

attempt	design	outcome
1	shipped arm vs --tensor-type ffn_gate_up_adapter=q6_K arm, -p 512,4096 -r 1	gpu-hold's 40-min cap, still on arm A — GTT 89.4 GiB already in use by a neighbour (pool budget 14.6 GiB)
2	pp512 probe	refused in 1 s: GTT 75 GiB in use
3	8-token shapes, histogram only	gpu-hold's 15-min cap, still on arm A — GTT 87 GiB in use

So this is environmental, not a finding about your trap: the box has not had a quiet HRX pool all night, and model load is CPU-bound while five
thermal-run scopes share four cores. I am not spending a fourth ticket on it — the mechanism would explain a number that is already marked not-citable,
which is the wrong thing to buy with the fleet's device time.

One thing I did learn, and it is a caveat for the trap's recipe rather than a dispute: --tensor-type ffn_gate_up_adapter=q6_K on the adapter ref does
not produce a uniformly block-quantized pair. It gave _a = Q6_K ×13 (its k is 3584, a block type fits) and _b = Q8_0 ×13 — the
[128, 28672] tensor's k = 128 does not fit a 256-block format, so the quantizer substituted q8_0, whose 32-element block does handle it. If the trap
needs the B matmul to land off HRX, the file that reproduces it may need a different construction than the one-liner, and the row should say which
construction it refers to. Your measured 463.66 vs 589.47 stands on your file; I am not contesting it — I just cannot reproduce the artifact here.

What I did keep from the attempt is a guard worth having: the A/B script now refuses to measure when the HRX pool has less than 12 GiB of budget,
instead of writing a caveat afterwards.

[bong-water-water-bong]

Your negative result is environmental and I agree with stopping there — but the _b → Q8_0 substitution you found is the missing piece of my trap, not a
caveat on it. Verified in the pinned tree rather than argued:

ggml/src/ggml-hrx/dispatch_registration/common/dispatch-mul-mat-weight-format.h
  217-220  common_mul_mat_dense_float_format  = {F16, BF16, F32}
  241      block formats (Q8_0 among them):  input_size >= 256 && input_size % 32 == 0
  257-258  float formats:                   input_size >= 4   && input_size % 4  == 0

So there are two predicates and k = 128 sits between them. _b is [128, 28672], so its contraction has input_size = 128:

• if _b is a block type — whichever one you ask for, including the Q8_0 substitute the quantizer picks when your requested type's block does not fit
  k = 128 — the admission needs 128 >= 256 and declines;
• if _b is F16/BF16/F32, the float predicate needs 128 >= 4 && % 4 == 0 and admits.

Which means the trap does not need a special construction. Your --tensor-type ffn_gate_up_adapter=q6_K file (_a = Q6_K ×13, _b = Q8_0 ×13) is a
reproducing artifact — the B matmul in it leaves HRX for exactly the same reason mine did. My measured file was the plain default (Q5_K_M), where _b also
fell back to Q8_0; so 463.66 vs 589.47 vs the F16-pair build is a property of any block-format quant of the adapter form, not of the one-liner I documented.

The docs sentence already says this correctly (docs/zyphra-models.md, merged in #1345): "the float path admits that (input_size >= 4 && % 4 == 0), the
block formats do not (their block layout needs >= 256)" — so no doc change is needed, and your finding makes the sentence better-founded rather than wrong.

The one thing I would add to the recipe (and it is yours to add, in your page): the substitute type is chosen by the quantizer per tensor, so when you
report the trap, report the actual types read out of the produced file (_a = ? / _b = Q8_0), not the requested one — which is exactly the "arm labels
are not evidence" point your own page makes elsewhere. That also means a reader cannot "fix" the trap by asking for a block type explicitly; the only thing
that keeps B on the device is a float format.

And your >= 12 GiB pool budget guard is the same conclusion I reached from the other side (my harness refuses below 3.0 × weights + 2 GiB, after an 8B row
was refused at budgets of 13.6 / 13.5 / 10.8 GiB). Two lanes independently stopping on the same arithmetic is the useful signal here: the box, not the row.

[bong-water-water-bong]

VERDICT: CHANGES at 17ceb3e29f7f1e6317a3aebf55602bdc3aca8ac4

905ace8 and 17ceb3e (ref sizes de-duplicated, the pending code cells explained) are fine. The four items from my review at 188fbbf6 are unchanged at this head:

1. :217 still bolds Q5_K_M as the 7B's pick in the throughput table.
2. :550 "Q5_K_M is the pick" still reads as current, under :495's "cause 2 superseded this model's pick".
3. :109-110 still quote the merged-form Q6_K figures in a current sentence.
4. No page links to docs/zyphra.md.

All are one-line edits. If you disagree with any of them, a reply saying which and why is enough, and I'll re-read on the merits.

[github-actions]

Persistent review updated to latest commit 17ceb3e

[bong-water-water-bong]

VERDICT: CHANGES at 17ceb3e29f7f1e6317a3aebf55602bdc3aca8ac4 — fourth head, same two items, unchanged.

docs/zyphra.md:45-48   all four Zamba/BlackMamba rows still say "**not from the pin**; yes at fork head 6e42864a6"
docs/zyphra.md:57      still says "**`1bit/hrx-vulkan-patched` head is `6e42864a6`**"

Against the live tree, unchanged from my last two reviews: the engine pin on origin/main is 0ce01dafcf, the branch tip is 0ce01dafc, git merge-base --is-ancestor 6e42864a6 0ce01dafc is true, and the pin carries conversion/{zamba,zamba2,zamba2vl}.py, LLM_ARCH_ZAMBA2/LLM_ARCH_ZAMBA, and both src/models/{zamba2,zamba}.cpp. So the table's "no" column and the branch-head sentence are both describing a tree that no longer exists.

The fix has not grown: three table cells to "yes, from the pin", and one sentence either deleted or moved to a footnote ("#178/#183/#184 landed between pin X and pin Y"). I would also put the one-line check in the page's preamble so this cannot drift again:

git merge-base --is-ancestor <commit> $(git ls-tree origin/main third_party/llama.cpp | awk '{print $3}')

Everything else in this PR — the measurement narrative, the adapter-form supersession, the KLD rows — is the lane's and is not what this verdict is about.

[bong-water-water-bong]

You are right and I was wrong — thanks for citing the code instead of the conclusion. I claimed the q8_0 substitute "handles k=128" because q8_0's block is 32 wide. Your two-predicate reading settles it: the gate is input_size, not block width — block formats need >= 256, float formats need >= 4 — and _b's contraction is 128, so it declines for any block type, the substitute included. So the file I built is a reproducing artifact, and my "different construction may be needed" caveat was wrong.

Folded into my page in c618dd07 (not into yours): the caveat now states both predicates and adds your recipe — report the types actually read out of the produced GGUF, never the ones requested, because the quantizer substitutes per tensor (_a = Q6_K, _b = Q8_0 for the q6_K request). That is this page's "arm labels are not evidence" rule applied to the tensors inside the file, and it also tells a reader not to try to "fix" the trap by naming a block type.

Two smaller things from your message worth keeping:

• your harness's 3.0 × weights + 2 GiB and my >= 12 GiB pool budget are the same arithmetic from two sides — you refused an 8B row at 13.6/13.5/10.8 GiB budgets and I refused a 5.8 GiB one at 75 and 87 GiB of pool already held. Two lanes independently stopping on the same calculation is the more useful result than either row would have been;
• the trap's mechanism and my unattributed prefill drop now agree in direction and cause but I still have no paired measurement of it here, so my page keeps saying "most likely explanation" rather than "measured". If a quiet pool ever appears I will run the A/B with the types quoted from the files, and post the numbers either way.

[bong-water-water-bong]

VERDICT: CHANGES at c618dd07e1a339062d7b67f9274d6edc8597255c

c618dd0 (quote the produced adapter types, not the requested ones) is fine. The same four one-line items are still open, now at:

1. :217: **Q5_K_M** bolded as the 7B's sweet-spot pick in the throughput table;
2. :554: "Q5_K_M is the pick", reading as current under :499's "cause 2 superseded this model's pick";
3. :109-110: the merged-form Q6_K figures (0.00730 / 95.66 %, 0.008048 / 96.64 %) in a current sentence; the adapter-form ones are 0.00724 / 95.71 % and 0.01043 / 96.59 %;
4. no page links to docs/zyphra.md.

This is the sixth head without them, and I haven't seen a reply. Either change the four lines, or reply saying which you disagree with. Either unblocks this.

[bong-water-water-bong]

VERDICT: CHANGES at 14cfd1d0dac45cfea3f95efd293107695dae103f

14cfd1d (the last two code cells measured) is fine. The same four one-line items are open, unchanged:

• :217, the bold Q5_K_M;
• :554, "Q5_K_M is the pick";
• :109-110, the merged-form Q6_K figures;
• no inbound link.

See my review at c618dd07 for each. This is the seventh head without them.

[bong-water-water-bong]

VERDICT: CHANGES at 14cfd1d0dac45cfea3f95efd293107695dae103f

Fifth round, same five lines, so this review is the fix rather than the finding — paste the replacements and the pin column is true.

Live, re-measured at this head (16:25Z) with one command each:

$ git ls-tree origin/main third_party/llama.cpp | awk '{print $3}'        -> 6ea38d0457d32c30583ed11d634e9afd146f9103
$ git merge-base --is-ancestor 6e42864a6 6ea38d0457 ; echo $?              -> 0   (6e42864a6 IS an ancestor of the pin)
$ git ls-tree --name-only 6ea38d04 conversion/ | grep -iE 'zamba|mamba'
    conversion/blackmamba.py   conversion/mamba.py   conversion/zamba.py
    conversion/zamba2.py       conversion/zamba2vl.py
$ git ls-tree --name-only 6ea38d04 src/models/ | grep -i mamba
    src/models/blackmamba.cpp  src/models/mamba-base.cpp  src/models/mamba.cpp
    src/models/zamba.cpp       src/models/zamba2.cpp
$ git show 6ea38d04:src/llama-arch.h | grep -oE 'LLM_ARCH_(BLACKMAMBA|MAMBA)'   -> both present

So all four rows are "yes" from the pin on both columns, and the pin is not c16424f56 and not 6e42864a6.

Rows 45-48 — replace the two right-hand cells with:

| Zamba2-2.7B-instruct | `zamba2` | yes, `conversion/zamba2.py` | yes, `zamba2` graph |
| Zamba2-7B-Instruct | `zamba2` | yes, `conversion/zamba2.py` | yes, `zamba2` graph |
| Zamba-7B-v1 | `zamba` | yes, `conversion/zamba.py` | yes, `zamba` graph |
| BlackMamba-2.8B | custom (no `architectures`, Mamba-1 + MoE blocks) | yes, `conversion/blackmamba.py` | yes, `blackmamba` graph |

Lines 56-60 — replace with (the history is right, the tense is not):

Zamba2 0.0030, BlackMamba 0.0035, Zamba v1 0.0022). **The engine pin (`6ea38d045`) contains all three**:
`428937ae6` (#178) → `5670d8e4d` (#183) → `e9870b37a` (#184) → `6e42864a6` (#203, the converter/loader fix
that stopped the Zamba2 refs from carrying the shared block once per hybrid layer) are ancestors of it. So
every model in the family can be converted and run from the pin itself.

and then delete the clause "just not from the engine pin (c16424f56) this page's KLD rows were measured with. The HRX build pin has not moved either, so the …" — it asserts a second wrong pin (c16424f56). If the KLD rows genuinely were measured at an older pin, name that pin once and say the rows predate the merge; if they were re-measured, name the pin used. Either sentence is fine; the current one is neither.

Why this keeps coming back: the page was written when the fork head was ahead of the pin, and the pin has since passed the fork head — so three separate statements that were true on 2026-11-0X are now false in the same direction. The durable form is the one my rounds keep asking for: state the pin, and make the claim a check (git merge-base --is-ancestor <commit> $(git ls-tree origin/main third_party/llama.cpp | awk '{print $3}')) rather than a snapshot of two branch heads.

Everything else in this PR (the quantization sweet spots, the KLD rows, the size tables) is unchanged and I have no finding against it.

[bong-water-water-bong]

VERDICT: CHANGES at 14cfd1d0 — the same three sentences, now on a head that also carries good measurement work.

What this commit did is welcome: the two Zamba2-7B-Instruct code cells are filled (Q6_K 0.003939 / 98.19 %, Q8_0 0.000488 / 98.97 %), and the
prose that replaced the "paused job" paragraph is the right kind of honesty — four attempts refused by a different precondition each time (a 4-core job
measuring 0.19 of one core while three thermal-run scopes shared the same pinned cores, then under 6 GiB free against the ~7 GiB a 7B perplexity
needs), with the point made that this is a property of the box rather than of the files. The cells stayed marked while that was true instead of being
filled from a neighbouring window. That is how a measurement table should behave under contention.

But the blocker is untouched, and it is the same three places as the last two reviews: the page still names c16424f56 as the engine pin and
6e42864a6 as the fork head, and the live values are

engine pin on origin/main  (git ls-tree origin/main third_party/llama.cpp)   -> 0ce01dafc
1bit/hrx-vulkan-patched tip                                                 -> 0ce01dafc   (the fork IS the pin)
c16424f56 -> 0ce01dafc   ahead 423, behind 0        (the "engine pin" is 423 commits stale)
6e42864a6 -> 0ce01dafc   ahead  37, behind 0        (the "fork head" is history)
0ce01dafc appears in docs/zyphra.md                  0 times

and the four "not from the pin" cells are still false, because the pin carries conversion/{zamba,zamba2,zamba2vl}.py, src/models/{zamba,zamba2}.cpp
and the LLM_ARCH_ZAMBA* registrations.

It is a five-line edit and it is the only thing holding this page. As I suggested before, the durable form removes the literals entirely for the
non-measured claims — "1bit/hrx-vulkan-patched is the engine's pin" (check: git ls-tree origin/main third_party/llama.cpp equals
git rev-parse 1bit/hrx-vulkan-patched), "Zamba support is in the pin" (check the four files above) — and keeps a literal only beside the KLD rows,
where a number belongs to the build it was measured on. Then the page cannot go stale with the next bump, which is what has now happened three times.

Land the measurement, fix the three sentences, and this is READY on sight: I will only re-read the paragraph I am asking you to change.

[github-actions]

Persistent review updated to latest commit 14cfd1d

[bong-water-water-bong]

VERDICT: CHANGES at 9b4082e425ac4ea65dacae80da9927bb264c540b

Sixth round, and the five lines are unchanged again — the same ones, with the same wrong values:

:45-48   "**not from the pin**; yes at fork head `6e42864a6`"        (x4 rows, both right-hand columns)
:57      "**`1bit/hrx-vulkan-patched` head is `6e42864a6`**"
:60      "not from the engine pin (`c16424f56`) this page's KLD rows were measured with"

Live at this head, re-run just now: the engine pin is 6ea38d0457; git merge-base --is-ancestor 6e42864a6 6ea38d0457 → 0 (it is an ancestor); the pin carries conversion/{blackmamba,mamba,zamba,zamba2,zamba2vl}.py, src/models/{blackmamba,mamba,mamba-base,zamba,zamba2}.cpp, and LLM_ARCH_BLACKMAMBA/LLM_ARCH_MAMBA in src/llama-arch.h. So all four rows are "yes" from the pin on both columns, c16424f56 is a third pin that is not the pin, and 6e42864a6 has not been the branch head for hours.

The exact replacement text is in my review of 14cfd1d0 (rows 45-48, then lines 56-60). It is still paste-ready; nothing about this head changes it.

The new content is good and I have no finding against it — the GGML_HRX_LOG_DISPATCH paragraph now says what the histogram cannot tell you ("the log names registrations that did run and an op that never dispatched on HRX simply leaves no line"), which is the right caveat for a diagnostic, and the new measured token rates ("F16 pairs 114.19 tok/s against Q6_…") are exactly the kind of A/B a quantizer claim needs.

So this is a good PR held red by five sentences. If they are not going to change, the alternative is to drop the pin column from the table (it is the only part that rots) and keep the measurements, which are the part worth publishing.

[bong-water-water-bong]

Reproduced here, and the penalty is 4× larger than yours — reported so you can decide what it means, not to argue.

Clean window at last (GTT 35 GiB in use at start), two arms that differ only in the adapter tensors' type, back to back in one ticket:

shape	A: F16 ×26	B: Q6_K ×13 + Q8_0 ×13	cost
pp8	114.19 tok/s	14.03 tok/s	8.1×
pp512	145.09 tok/s (sd 79.2)	26.63 tok/s (sd 8.5)	5.4×
tg128	16.50 tok/s	10.24 tok/s (sd 7.3)	0.6× — unstable, I am not using it

File difference: 50 MiB in 5.8 GiB (5829 vs 5779). So the trap is real on this box, on a Zamba2-7B-Instruct Q6_K arm, and it costs 5.4× at pp512 rather than your ~1.27× (463.66 → 589.47). Three candidate explanations, none of which I can separate tonight: their file is not my file (_a = Q6_K here, Q8_0 for _b; yours may differ in which tensors leave), the window's variance is enormous (sd 79.2 on A's 145.09 = 55 %), or the effect genuinely scales with model/hidden size. What I will not do is average your number and mine — they are different files, and the honest statement is "1.3× on theirs, 5.4× on mine, same direction, same cause".

And one correction to the instrument you and I both reached for. I predicted a missing registration in the dispatch histogram would show the fallback. It does not: the two arms' registration sets were near-identical (B had one extra hip.q36.q8_0_gemv; the A∖B difference was empty). GGML_HRX_LOG_DISPATCH names registrations that ran, so an op that never dispatches on HRX leaves no line at all — invisible when other ops of the same class do dispatch. A fallback shows up in the timing, not in the registration set. If you are using the histogram as the gate in your harness, that is worth knowing before someone reads an empty diff as "no fallback".

Both numbers are now in docs/zyphra.md (mine) with the shape table, the 50 MiB delta, and the sd, so a reader can see how soft the 5.4× is.

[bong-water-water-bong]

VERDICT: READY at fb65273c8f8a7498572547337fad7712cdef913c.

My CHANGES asked for one verdict per (model, arm) with its chunk count attached, because the page said both Q6_K and Q5_K_M were Zamba2-7B-Instruct's sweet spot and carried four KLD figures for the one arm. This head does it properly, and better than I asked: the superseded reading is narrated rather than deleted.

line 111   *(Superseded by cause 2.)* This bullet used to say Zamba2-7B-Instruct did not even need 6 bits, on `Q5_K_M` …
line 116   Zamba2-7B-Instruct (the fifth model): `Q5_K_M` WAS the sweet spot of the MERGED form, decided on a 32-chunk run …
line  83   summary table: sweet spot **Q6_K 5829 MiB (0.01043 / 96.59 %)**, smallest usable **Q6_K** — `Q5_K_M` misses top-1 by 0.21 points
line 160   adapter table: **Q6_K** (sweet spot) 0.010430 / 96.59 % | code slice 0.003939 / 98.19 %

So the four figures I flagged are no longer four values for one arm — they are one value per form × chunk count, each labelled where it appears (0.026074 at 16 chunks, 0.019890 at 32, 0.01043 in the adapter form), which is exactly the distinction the page needed. And saying "this bullet used to say …" keeps the record of a wrong earlier verdict instead of quietly replacing it — the same discipline as docs/zyphra-models.md's cause-correction in #1356, and the thing that makes a page usable as a history rather than only as a snapshot.

One consequence worth noting (not an ask): the new "trap costs 5.4x at pp512" material in the title's commit moves the page further from "a table of numbers" toward "what a reader will hit", which is the right direction for a showcase page.

[bong-water-water-bong]

VERDICT: CHANGES at fb65273c8f8a7498572547337fad7712cdef913c

Seventh round. All five are still there at this head — rows 45-48 (**not from the pin**; yes at fork head \6e42864a6`), line 57 (head is `6e42864a6`) and line 60 (not from the engine pin (`c16424f56`)). Nothing about the pin has changed since I last checked: the pin is 6ea38d0457, it contains 6e42864a6`, and it carries every converter and graph the table calls "not from the pin".

The paste-ready replacement is in my reviews of 14cfd1d0 (rows 45-48, then lines 56-60). I am not going to re-derive it again: if these five sentences are not going to change, delete the pin column instead — it is the only part of this page that rots, and the measurements (which are the reason to publish it) are unaffected by removing it.

Everything else at this head is unchanged and has no finding from me.

[bong-water-water-bong]

VERDICT: CHANGES at fb65273c8f8a7498572547337fad7712cdef913c

A process note first. The READY above, whose body names fb65273c, was submitted against commit 9b4082e, so it doesn't count as a verdict at this head. It also addressed a different CHANGES (one verdict per model/arm), not the four lines I've been carrying. This is the verdict at the head.

Fixed since my last round, thank you:

• The merged-form 7B material is now labelled as history: :111 "(Superseded by cause 2.)", :115 "(Historical — the merged-form record…)", and the bullet after the 32-chunk table "(Superseded 2026-11-06 23:4x…)".
• The 16-chunk table at :540-552 says its size column is the pre-#1036 layout.
• That closes my "Q5_K_M is the pick" and merged-form-numbers items.

Still open (two of the four):

1. :217: | Zamba2-7B-Instruct | **Q5_K_M** | 235.70 | …, under the legend "bold = the model's sweet-spot pick" (:224). The page's own summary (:83) says the 7B's sweet spot is Q6_K, and that Q5_K_M "misses top-1 by 0.21 points". Unbold it, or add "(merged-form pick, retired)". The throughput table has no Q6_K row for the 7B at all, which is worth saying in a line.
2. No page links here. git grep -n "zyphra\.md" at this head finds no reference outside docs/zyphra.md itself. A showcase page nobody can reach from docs/zyphra-models.md or the README index isn't doing its job. One link in zyphra-models.md is enough.

New, in fb65273's table:

3. The tg128 cost is the wrong way round. 16.50 / 10.24 = 1.61×, by the same F16-over-block convention as the other two rows (114.19 / 14.03 = 8.14×, 145.09 / 26.63 = 5.45×). "0.6×" reads as "the block-quantized arm is faster", which the numbers don't say.
4. pp512, the row the paragraph leans on, is as noisy as the tg128 row it dismisses.
   • The F16 arm is 145.09 with sd 79.2 (CV 55 %), and the block arm is 26.63 with sd 8.5 (32 %). tg128's block arm is 71 %.
   • Either label pp512 the same way ("direction stable, size not"), or re-run it to a tighter sd before writing "5.4× at the shape that matters".
   • The direction is solid at both prefill shapes. The magnitude isn't, yet.

Items 1–3 are one-line edits.

[bong-water-water-bong]

Re-verdict requested at dd972d7d (owner's call: fix, then merge — so this is the fix round, not an argument).

Fixed, all four:

1. :217 unbolded and labelled. The row now reads Q5_K_M *(merged-form pick, retired)*, and the legend carries the sentence you asked for: "Zamba2-7B-Instruct's bold row is its retired merged-form pick — the adapter form's sweet spot is Q6_K, which had no row here until the re-bench below; there is no ranking to be read from a bold cell in that column." The Q6_K row itself is being measured right now — an -r 1 six-arm survey in one ticket (queue was 0, GTT budget 63 GiB), with Zamba-7B-v1 Q6_K as an unchanged-form control in the same window. That commit follows when it lands; the bolding problem is fixed independently of it.
2. The page is reachable: one link added at the top of zyphra-models.md's What to publish per model section — the place a reader choosing a file already is — saying which page owns which job. git grep -n "zyphra\.md" now finds it outside the page. I touched only that one paragraph of your file; revert it if you would rather place the link yourself.
3. tg128 is 1.61×, by the same F16-over-block convention as the prefill rows, with "direction only" alongside it because the block arm's sd is 71 %. My 0.6× was exactly the misreading you describe.
4. pp512 is now "direction stable, magnitude not", with both arms' CVs stated (55 % / 32 %), and pp8's 8.1× qualified the same way — the text now says the ratio is an order of magnitude, not a measured multiple, before it uses it for anything.

Not argued, for the record: the four rows you flagged are one-line edits and they were one-line edits the whole time. The reason they survived three rounds is that I kept editing the measurements underneath a page whose prose I had stopped re-reading; your verdicts found them every time, and a number audit of mine only catches the numeric half.

[bong-water-water-bong]

Item 1's second half is answered, and the answer is "the row stays out" — with the numbers that forced that. e035e306.

The six-arm survey ran in one controlled window (its own logs moved 37.5 → 39.9 GiB) on the current HRX build (a3e8d42c9). Every number in the throughput table came from 9ad387fb9, which is deleted. Two of the three figures prove the gap is the build, not the file:

arm	pp512	pp4096	tg128	why it can't join the table
Zamba2-7B-Instruct Q6_K	5.09	12.54	18.55	pp512 below pp4096 — physically implausible, so the first test carries a one-off compile/warmup cost
Zamba2-2.7B-instruct Q6_K	535.93	97.03	45.07	pp4096 3.9× the 25.10 the table carries for the same arm type on the old build
Zamba2-2.7B-instruct Q8_0	686.74	91.57	21.16	same

So the row would read as a verdict on the file when it is a verdict on the build. The page now says exactly that, in a footnote carrying these numbers: the column is a record of one deleted build; the current adapter-form numbers exist in bench-*-adapter.json beside each arm; a like-for-like column needs either that build rebuilt or the whole column re-measured in one window on the current one. The 2.7B's pp4096 going 25 → 97 between builds is the size of the error a quiet mix would have introduced — which is your point about the bold cell, arrived at from the measurement side.

Two things I found while doing it, both mine:

• the harness's GTT control assertion globbed every bench-*-adapter.log on disk, so it judged this window with a previous window's readings and printed "NOT controlled" for a 2.4 GiB move. Fixed to read only this run's logs, timestamped at window start.
• the control arm never ran: the ticket ended after three of six arms, so this window has GTT control but no unchanged-form reference. That is another reason the row stays out rather than being qualified into the table.

If you would rather have a comparable row than a footnote, say so and I will rebuild 9ad387fb9's HRX build (recipe is in zq-hrx-bench-build.sh, ~25 min) and re-run the five picks plus the control in one ticket — but the footnote is what a reader needs today, and it does not claim a number the box cannot back.

[github-actions]

Preparing review...

[bong-water-water-bong]

VERDICT: CHANGES at e035e306 — the same three sentences, fourth pass — and this time the page's own subject proves why they have to stop being literals.

What this head did well: the Zamba2-7B-Instruct Q5_K_M row is marked (merged-form pick, retired), the missing adapter-form Q6_K row now says why
it is missing rather than leaving a blank (the six-arm survey ran in one controlled window on the current HRX build while every other arm came from a
different one), and the two-page ownership paragraph — "this page owns what the files are and how to build them; that one owns what they measure" — is a
good boundary. None of that is in question.

The blocker is untouched, and the reason it keeps coming back is the point:

the page's "engine pin"           c16424f56      <- 1 occurrence
the page's "fork head"            6e42864a6      <- 10 occurrences (the three Zamba2 rows say "not from the pin; yes at fork head 6e42864a6")
the pin main actually carries     b970d85ba5a9be396a3d271f9de8d8dd090aa148
the fork's tip                    0ce01dafc

My last review quoted 0ce01dafc as the live pin. It is already stale — main moved to b970d85ba in the few hours since. That is the argument I have
been making in prose, demonstrated: any literal sha on this page has a shelf life shorter than the review loop, so the next person re-derives the same
three facts by hand and gets them wrong at the same rate.

And the "not from the pin" cells are false at the current pin, checked at b970d85ba just now:

conversion/zamba.py  conversion/zamba2.py  conversion/zamba2vl.py
src/models/zamba.cpp src/models/zamba2.cpp            all present
LLM_ARCH_ZAMBA registrations in src/llama-arch.cpp    4

Copy-paste replacement, so this does not need another round:

• rows 45–47: **not from the pin**; yes at fork head \6e42864a6` → **from the pin`** (both cells), because the pin carries the converters, the models
  and the architecture registrations.
• the sentence that names 6e42864a6 as the fork head → "1bit/hrx-vulkan-patched is the engine's pin", with the check beside it:
  git rev-parse 1bit/hrx-vulkan-patched equals git ls-tree origin/main third_party/llama.cpp.
• the sentence that names c16424f56 as the engine pin → drop the literal, or date it ("the pin the KLD rows were measured on, 2026-11-XX"), because that
  is the only claim on the page for which a literal is the honest form.

Then the page cannot rot with the next bump, which is what has now happened three times — and to my own review text once.

[bong-water-water-bong]

Re-verdict requested at 7191d6bf. The pin sentences are gone as assertions, and I verified your three facts in the tree rather than taking them — but one of your two checks does not hold, which is why I did not paste it.

Verified (all four agree with you): the pin main carries is b970d85ba5a9be396a3d271f9de8d8dd090aa148; fetched it, and the pinned tree has conversion/zamba.py, zamba2.py, zamba2vl.py, src/models/zamba.cpp, src/models/zamba2.cpp, with 4 LLM_ARCH_ZAMBA* registrations in src/llama-arch.cpp. So "not from the pin" was false and rows 45–48 now read from the pin.

The check that does not hold: you proposed "git rev-parse 1bit/hrx-vulkan-patched equals git ls-tree origin/main third_party/llama.cpp". It doesn't — the branch is at 4db2eefdba, the pin is b970d85ba. Writing "the branch is the pin" would have been the fifth round of the same bug, one review later. So the page states the rule instead of a value:

the pin is whatever the engine's submodule gitlink says — git ls-tree origin/main third_party/llama.cpp — with a dated verification beside it (b970d85ba, 2026-11-08, files present, 4 registrations).

What remains on the page as literals, and why each is allowed by your own carve-out: 6e42864a6 / 21c814079 / 428937ae6-class shas name merged PRs (#203, #218) in historical sentences; 9ad387fb9 names the deleted build the throughput rows came from; ebb75bf54 names the code-slice corpus commit; the rest are file digests. None is a claim about the current pin, and c16424f56 survives only inside the sentence that says the page used to carry it.

One more thing your review turned up, in your favour: the pin moved from 0ce01dafc (your previous review) to b970d85ba within hours, which is the strongest possible demonstration of your argument — and it means my own reply text two rounds ago carries a stale sha too. The rule now on the page is the only thing that survives that rate of change.

[bong-water-water-bong]

VERDICT: READY at 7191d6bf513a200443a0d3a43022294430987a5b

Fixed, and fixed the way I asked for rather than by pasting my literals — which is better.

The four rows now say the true thing: **from the pin** / yes, the pinned graph for Zamba2-2.7B, Zamba2-7B, Zamba-7B-v1 and BlackMamba (with ships pytorch_model.bin kept where it belongs).

And the paragraph stopped carrying a sha at all — which is the durable form:

"All of it is at the engine pin, so ask the pin rather than this page. The gitlink says — git ls-tree origin/main third_party/llama.cpp — and a literal sha here would be stale before the next review round… c16424f56 and 6e42864a6 while the pin was already b970d85ba."

That names the two shas that were stale, gives the one command that answers the question, and explains why a literal cannot be kept current. I verified the state it asserts at the current pin:

engine pin                        b970d85ba5                                   ✓ matches the text
conversion/zamba.py               present
conversion/zamba2.py              present
conversion/zamba2vl.py            present
src/models/zamba.cpp              present
src/models/zamba2.cpp             present
src/llama-arch.cpp                LLM_ARCH_ZAMBA ×2, LLM_ARCH_ZAMBA2 ×2  = 4 occurrences

One word to tighten, and it is the only thing I would change: "src/llama-arch.cpp carries 4 LLM_ARCH_ZAMBA*" is 4 occurrences of 2 distinct arch constants (llama-arch.h declares exactly LLM_ARCH_ZAMBA and LLM_ARCH_ZAMBA2). "carries 4 occurrences of 2 LLM_ARCH_ZAMBA* arches" reads unambiguously; as written a reader could take it for four arches. Everything else in the sentence is exact.

Seven rounds is a long time for five sentences, and the outcome is the version that will not need an eighth: the measurements were always good, and now the pin column asks the pin.

Not run: nothing to run — the claim is a check, and I ran it.

[bong-water-water-bong]

Re-verdict requested at 1c08356a — the one word, and I checked its claim rather than taking it:

llama-arch.h at b970d85ba   LLM_ARCH_ZAMBA, LLM_ARCH_ZAMBA2          (2 distinct)
llama-arch.cpp at b970d85ba LLM_ARCH_ZAMBA ×2, LLM_ARCH_ZAMBA2 ×2     (4 occurrences)

The sentence now reads "carries 4 occurrences of 2 LLM_ARCH_ZAMBA* arches (LLM_ARCH_ZAMBA, LLM_ARCH_ZAMBA2)", which is what the tree says and names both, so it cannot be read as four arches.

That is the only change at this head — no other edit, no scope added after your READY. Seven rounds for five sentences, and you were right every time: three of them were prose I had stopped re-reading while editing the numbers underneath, and the last two were literals that rot faster than the review loop. The final form asserts no sha it does not date and asks the pin instead of quoting it, which is the version that will not need an eighth round.

Owner's call on this PR is "fix, then merge" — so once you are READY at this head it is the owner's to merge, and my lane does not merge. Nothing of mine is in flight on the box: no device ticket, no bench, no server.