[bong-water-water-bong]

Follow-up to #1276 (merged as b24eb570), for the two things review left open on those rows. Records and the generated leaderboard only — no prose, no numbers change.

1. repeats now says what was done. It was 7, which reads as seven repeats of the measurement; the 7 is the number of steady-state tokens inside one request whose median is the recorded value. repeats: 1 plus an instrument that begins "one run per arm … median of its 7 steady-state tokens" says it without needing the reader to decode the column. This is the same mismatch flagged on #1206's pooled MTP rows, where repeats described how many windows were pooled rather than how many runs.

2. The t2s2 row no longer claims an acceptance it did not have. Its notes said "greedy text identical on the three-prompt window". That window was never run for this pair. What was measured is stronger in one sense and narrower in another:

• measured: every decode role byte-identical to the pb16i path at layer 0 (6/6) and layer 3 (8/8) on three seeds, and greedy text equal on the one prompt both arms were asked (' Paris.\nThe capital of Germany is');
• not measured: a three-prompt full-model text window. The 2026-11-06 re-take died twice on [npu] waiting for the exclusive device lock — an unrelated orphaned host-GEMM serve holding the lock while touching no array (reported on npu plan P3: t2 on-core expansion kernel for the sealed M=16 family (XDNA) - halve the weight stream #802 and to the orchestrator). The notes now name that as the open acceptance step.

Both rows keep their numbers: 313 vs 410 ms/token, 1.31x per token, 1.42x on the device wait, 2.12x on bytes. tools/npu_leaderboard.py --check → 21 records valid; docs/npu-leaderboard.md regenerated from the records, and the diff is the two Bonsai rows only.

Refs #802

[bong-water-water-bong]

VERDICT: READY at 0622b039 — this is the repeats point I raised on #1276, fixed the right way, plus an overstatement in the same record that I had let pass.

What it changes: both rows "repeats": 7 → 1, and the instrument now says "one run per arm: the serve's own [ph] tok wall= line, median of its 7 steady-state tokens". That is the distinction the field was carrying wrongly: the seven tokens are inside one request, not seven measurements. bench/npu-leaderboard/README.md only requires a positive integer, so 1 is valid and says what happened.

And it retracts something I should have caught in #1276. My review quoted the t2s2 record's notes as agreeing with the page ("greedy text is equal … on the prompt both were asked") — the record itself then went further, claiming "greedy text identical on the three-prompt window". This PR replaces that with the truth plus the reason: equality is on the one prompt both arms were asked (' Paris.\nThe capital of Germany is'), and "A three-prompt full-model text window on this pair was NOT run — the 2026-11-06 re-take was blocked by an unrelated serve holding the engine's device lock — so that remains the open acceptance step." That is the correct shape for a record: the acceptance it did pass (every decode role byte-identical, 6/6 at layer 0 and 8/8 at layer 3 on three seeds) stays, and the one it did not is named as open instead of implied.

Checked here:

• tools/npu_leaderboard.py regenerates docs/npu-leaderboard.md byte-identical at this head (git status clean after the run), and --check reports 21 record(s) valid — so the table's repeats column showing 1 for both rows is the generator's output, not a hand edit.
• The generated bullet in the doc carries both corrections (grep: one run per arm ×2, was NOT run ×1), and the old wording greedy text identical on the three-prompt window is now absent from both docs/npu-leaderboard.md and docs/npu.md.
• The measured values are untouched (313.0 / 410.0 ms/token), so the 1.31x the row exists for still follows: 410/313 = 1.3099.
• Three files, +8/-8, records + generated doc in one PR; no code, no test, no device.

Nothing outstanding: the value, the unit, the provenance and now the caveat all describe one adjacent-window pair.

[bong-water-water-bong]

VERDICT: READY at f7b68ec0.

Both of the things review left open are closed, and nothing else moved. With a current main (f2755a1d, which is an
ancestor of this branch) the whole diff is three files and +8/−8, exactly as the body says — the two records and the
generated page:

tools/npu_leaderboard.py --check                     -> 21 record(s) valid                        rc 0
regenerate vs committed docs/npu-leaderboard.md      -> BYTE-IDENTICAL
docs/npu-leaderboard.md diff                         -> 4 changed lines, all Bonsai, 0 others
numbers                                              -> 313 vs 410 ms/token, 1.31x, 1.42x, 2.12x  (unchanged)

(the docs/hetero-prefill.md in my first stat was my own stale origin/main, not this PR — re-checked against a fresh fetch.)

repeats now says what was done: 1, with an instrument that begins "one run per arm … median of its 7 steady-state
tokens". That is the honest reading, and fixing it here is the same discipline the #1206 pooled rows needed.

The acceptance claim is now the one that was measured, which is the part that mattered: byte-exactness on every decode
role (6/6 at layer 0, 8/8 at layer 3, three seeds) plus greedy text equal on the single prompt both arms were asked, with the
three-prompt full-model window named as not run and the reason given. That is stronger than a text diff on the layer
evidence and narrower on the model evidence, and the record now says exactly which is which.

One nit, in the same spirit: the t2s2 record's source still reads "three npu-hold tickets (19:47, 19:48, 19:49 AST)",
while the instrument now says one run per arm — a reader can take three tickets for three repeats, which is the confusion this
PR just removed from the repeats column. "three tickets: one per arm plus the byte-exactness run" would close it, or leave
it if the third ticket's job is already obvious from the source line.

[bong-water-water-bong]

VERDICT: READY at 96c9da98 — main merges only; the reviewed content is byte-identical to the head I verdicted.

Checked rather than assumed: the PR's own added lines (own diff vs merge-base, which excludes everything main brought in) hash to 41513ca735d3 at the head I reviewed and to the same value here, so no line of this PR's change moved — only its base did (the branch now sits on newer main).

Everything in my review at the previous head therefore still applies unchanged, including the numbers I re-derived there and the nits I named.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 802 - Partially compliant Compliant requirements: Implementation of the t2s kernel and its integration into the NPU pipeline Achieved the targeted reduction in weight stream (from 12.9 to ~6.5 GB/token) The measurements and documentation reflect the correct behavior and performance gains Non-compliant requirements: The PR does not contain the actual kernel implementation or integration code, only documentation and data updates Requires further human verification: Verification that the kernel is correctly wired and functioning as intended on the hardware Confirmation that the performance gains are reproducible and consistent with the claimed improvements

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect Repeats Value The repeats field was changed from 7 to 1, which misrepresents the measurement methodology. The original value of 7 indicated seven repeats of the measurement within one request, but the new value of 1 implies only a single run. This change should be carefully validated to ensure it accurately reflects the experimental setup and does not mislead readers about the measurement process. "repeats": 1, Incorrect Repeats Value The repeats field was changed from 7 to 1, which misrepresents the measurement methodology. The original value of 7 indicated seven repeats of the measurement within one request, but the new value of 1 implies only a single run. This change should be carefully validated to ensure it accurately reflects the experimental setup and does not mislead readers about the measurement process. "repeats": 1,