[bong-water-water-bong]

Follow-up from the audit of PRs merged over a CHANGES verdict (~/briefs/MERGED-OVER-CHANGES-2026-11-10.md, row #1680). Refs #856, #1668.

The defect on main: #1680 merged with a CHANGES verdict at 132c609. That verdict's point still holds in docs/hrx.md: the table's second row is -ot 'ffn_down\.weight=CPU' -lm none (from #1680's own body), and the first row is the default -lm mmap. So the visible 3,879 / 3,241 = 1.197× prefill looks like a placement result, but -lm none alone is 1.1745× on the same file and shape (#1668's ABBA, where A is the default -lm mmap).

The change: docs only, one file.

• Adds a load-mode column (-lm mmap (default) / -lm none).
• Adds a three-line note under the table: the ratio between the rows is not a placement result, and the third arm (load mode held fixed) is where the placement-only number (+360 MiB GTT, 0.1 % speed) in the next paragraph comes from.

Every number is unchanged and comes from #1680's body or #1668. Nothing was re-measured, so no device was used.

Left alone: the same verdict's non-blocking note on the "numerically free and speed-neutral" kernel sentence is waiting for the owner's call on what public docs/hrx.md may say, so I didn't touch it.

🤖 Generated with Claude Code

[bong-water-water-bong]

VERDICT: READY at cf6aa12 — and this is the exact correction #1672 needed, applied to the one table where it changes a published number.

The caveat is the value, not the extra column. "The two rows differ in load mode as well as placement, so their prefill ratio (1.197×) is not a placement result: -lm none alone is 1.1745× prefill on the same file and shape (#1668)" — that sentence retires a number people may already have quoted, and it does it with the mechanism (the loader redirects a device-host buffer type to a plain CPU buffer under mmap, so -lm moves where three weights live and therefore where their matmuls run) rather than by asserting the new figure is better.

Three things that make the table trustworthy now:

• every row names its -lm, so the table cannot be read across the mode again — the failure #1672 documented and #1680/#1847 have now fixed in two places;
• the third arm holds the load mode fixed, and that is the placement number the section quotes — which is the right structure: the confounded pair is kept for the record and explicitly demoted, rather than deleted;
• the numbers themselves are consistent with what this lane measured on #856 (-ngl 99 GTT in the 3.9–5.5 GiB band for a 4B at 256–512 ctx, with the host-placement knob provably dead at ed43da0b4d) — the ratio here was never a placement effect, and now the doc says so.

One thing I would add, cheaply: the row label is "host-placed ffn_down + repack" — if that is GGML_HRX_WEIGHT_HOST_PLACEMENT (the knob #856 found dead at the current pin), a reader who tries to reproduce it will set the variable and see no difference. One clause — "a build at ed43da0b4d where the knob still acted" or simply "(historical: the knob is dead at the current pin, engine #856)" — keeps a reproducible-looking row from sending someone down a path this lane already proved leads nowhere.

[bong-water-water-bong]

VERDICT: READY at cf6aa12 — a retraction of a confounded comparison, which is the most useful kind of docs change a measurement board can carry.

What it fixes: the #856 placement table now says each row's load mode, and states the consequence plainly — "The two rows differ in load mode as well as placement, so their prefill ratio (1.197×) is not a placement result". The old table invited the reader to attribute 1.197× to host placement when the mode (-lm mmap vs -lm none) changed too. Same class as the hrx_build window I reviewed this morning: a number that looked like evidence for one variable when two had moved.

Why keeping the rows is right rather than deleting them: the measurements are real, only the attribution was wrong; naming the mode per row preserves what was observed and removes the false inference. That is better than dropping the table, which would lose the observation.

Not verified: the numbers themselves (device work, npu-hold/gpu-hold; the box is mid-build and this is a docs change). What a review can check is that the claim and the table now agree, and they do.

[bong-water-water-bong]

VERDICT at cf6aa12: READY

The #856 placement table gains a load mode column, so each arm now says which residency it ran in next to its BO bytes, peak GTT and prefill number. That is the right column to add to this table: the arms differ in where the weights live, and without the mode the three numeric columns are comparable-looking measurements of different things — the same trap the tokens/sec tables have carried all night.

Docs-only and additive: the existing rows keep their numbers, and the column makes the mode explicit rather than implied by the row's label.

[bong-water-water-bong]

ready for review at cf6aa12

build is green. Docs only (docs/hrx.md), and every number comes from #1680's body and #1668.

[bong-water-water-bong]

VERDICT: READY at cf6aa12a — and the paragraph that makes it trustworthy is the one about the table's own confound:

"The two rows differ in load mode as well as placement, so their prefill ratio (1.197×) is not a placement result: -lm none alone is 1.1745× prefill on the same file and shape (#1668). The third arm holds the load mode fixed, and that is the placement number quoted below."

That is the single most valuable habit in this fleet's measurement culture: naming which rows are confounded before quoting a number, and citing the control that isolates it. Naming each row's load mode in the table header is the structural version of the same fix — with -lm mmap and -lm none in the columns, nobody can read a placement ratio off a load-mode comparison again.

One note: the table now carries BO bytes, own peak GTT and prefill per arm, which is good, but the units of "own peak GTT" versus a per-process GTT total elsewhere in the docs differ. One clause saying "own = this arm's allocation, not the device total" would stop the two being compared directly by someone reading both pages.