docs(perf): record the acc0 route, the SMT placement finding and the f16 layout divergence

[justinchuby]

Three entries in docs/performance/CPU_MATMUL_ASSIGNMENT.md for work that landed or was closed today. Documentation only — no code.

• §23 — the acc0 route (99f105d52, perf(cpu): enable the register-blocked int4 decode kernel at accuracy_level=0 (1.17-1.69x) #1679). Absorb MLAS SQNBit decode locality into borrowed int4 path (no resident copy) #1104's register-blocked int4 kernel shipped default-off "until the win is measured" and the measurement never happened, so accuracy_level = 0 took the per-column path for the kernel's whole life; route counters read nblock = 0. Records the corrected attribution: the first one was inflated ~3x because the probe's fetch_add sat in the timed path. Clean, the hreduce removal is worth 1.02x — nothing — and the entire 1.48x is four-column activation reuse. The numerics regress up to 3.70x relatively; disclosed rather than buried.
• §24 — the t=8 "wash" (Decode pool pins workers in logical-CPU order, so a pool wider than the physical core count runs on half the machine (2.16x) #1680). The premise does not reproduce. The win is flat through pool width 8 and collapses at 12+; root cause is decode_spmd.rs::node_shards pinning worker i to allowed_cpus()[i] in logical order, so 16 workers land on 8 physical cores. Bandwidth (83 GB/s available vs 41 GB/s drawn) and task grain were tried first and discarded. No kernel change — handed to the runtime owner with the measurement.
• §25 — the f16/bf16 layout divergence (2e1cfb67c, perf(cpu): route f16/bf16 decode through the [N,K] GEMV (1.64-2.89x), closing #1381 #1687, closing perf(cpu): give bf16 decode a GEMV, and split decode at the measured weight #1381). Same math, same bytes, three prices; [K,N] crosses a page every p. Software prefetch was tried first and is a recorded negative. Accuracy moves the same way, so there was no trade to weigh. Also records the memory-plan coupling that could have gone badly: the Every resident weight side-buffer must be in the memory plan before it is allocated #1056 predictor was Apple-only for MatMul, so the transpose would have been invisible to the plan on x86.

§23 and §25 contain the same error in two disguises — an instrument that changed what it measured, and a numerics test built from exactly-representable operands (*0.125) that could not see reassociation at all and reported a confident zero. Both are written up as such, next to §18's version of it.

All seven repo policy scripts pass (check_publish_order, check_profile_table, check_platform_naming, check_dispatch_reachability, check_dispatch_manifest, check_feature_gate_coverage, verify_documented_env_vars).

[justinchuby]

Adversarial review (Opus) returned REQUEST CHANGES with three Medium and three Low findings. All six are fixed in 6353ee651; origin/main merged in 0e331e4be. Marking ready.

Two of the Mediums were numbers stated more strongly than the evidence sitting directly beneath them, which in this file is the whole failure mode:

• §23's numerics multiplier was wrong. 2.422e-5 / 6.739e-6 = 3.59x, not the 3.70x I wrote, and I repeated the overstatement in the summary sentence. That is the cost side of "1.48x speed for X worse accuracy" — the one number in the section that has to be exact. Corrected in both places and pinned to the worst cell measured rather than an unqualified "up to".
• §24 quoted a bandwidth figure this file already refuted. My all-thread sweep read 83 GB/s; §22 measured this host at 31–36 GB/s within a CCX and ~56.6 GB/s across both, with the access pattern decode actually uses. Against §22, the 41 GB/s draw is above the within-CCX ceiling — the opposite of what I concluded. §24 cannot dismiss bandwidth on a number §22 refutes. Rewritten to state the conflict openly and rule bandwidth out on the placement A/B instead, which holds shapes, bytes, thread count and binary constant and varies only which CPUs the workers sit on. The conclusion is unchanged; its support is now sound.

The third Medium was a convention break with real consequences: every earlier section links a docs/benchmarks/ full record and these three did not, so the kernel A/B range in §25 was not reconstructable from anything quoted. Added the three records — full matrices, null controls, the discarded hypotheses and the negatives:

• 2026-08-21-int4-acc0-dormant-nblock.md
• 2026-08-21-decode-worker-cpu-placement.md
• 2026-08-21-half-decode-layout-divergence.md

Lows, all taken: dropped a cf. §18 that claimed a parallel §18 does not support — §18's probe was real kernel overhead that slowed the shipping kernel, §23's was measurement-only and corrupted its own baseline; the distinction is spelled out now instead of asserted as a repeat. Fixed an ordinal that said "fourth" while citing four priors. Replaced "the model-shaped rows are 1.2–1.6x", which its own table contradicts at attn_out (2.25x/2.96x), with the large-row claim the data actually supports. Matched the file's "adversarial review" voice.

The reviewer explicitly checked and confirmed clean: every ratio in §23's table, the 1.45x group-1→group-4 decomposition, all nine §25 production speedups, §24's internal consistency against §22's SMT model, and that the four disclosures I was most worried about softening (§23's shipped numerics regression, §25's 272 MB / worst-at-1.21x lm_head, §25's non-neutral cache admission, the square row not being representative) are all present as first-class bold headings.

Verification on the merged base: cargo fmt --all -- --check clean, all eight repo policy scripts pass (check_publish_order, check_profile_table, check_platform_naming, check_dispatch_reachability, check_dispatch_manifest, check_feature_gate_coverage, check_documented_commands, verify_documented_env_vars), and a link check resolves all relative links in the ledger.

Follow-up split out rather than folded in: #1702 (FusedMatMulBias takes no 16-bit GEMV on x86 — 2845 µs vs MatMul's 1830 µs on qkv), which carries the warning that the #1056 predictor's deliberate exclusion of that operator inverts the moment the GEMV is enabled.

[justinchuby]

Merging under Justin's direct-merge directive, with disclosure. The one red check is inherited from main and is not producible by this change.

Change scope: Detect change scope classified this docs-only and skipped every code job (Rust quality, Fast, EP conformance, CUDA compile x2, Rust Windows ARM64, coverage, CLI ORT). That is correct — the diff is four .md files and nothing else.

The failure: Mobius metadata packages.

invalid: validation/generated/diffusion: Parse error: invalid pipeline spec: ["workflow image output 'image' must declare value_range"]
invalid: validation/generated/diffusion_guided: Parse error: invalid pipeline spec: ["workflow image output 'image' must declare value_range"]

Attribution. Byte-for-byte identical on main's own run at 1842c2b90 (job 96950982436), a base that does not contain this branch. Main has been red on this job since between bdab01b85 (last success) and 9fcb0aa84. A pipeline-spec parse error is not reachable from a .md diff, and this PR is about as clean a null control for it as exists. Filed separately as #1706 with the bisect window, since it blocks everyone's gate rather than just mine.

Local verification on the merged base (0e331e4be, origin/main merged in, not stale):

gate	result
cargo fmt --all -- --check	clean
check_publish_order / check_profile_table / check_platform_naming	PASS
check_dispatch_reachability / check_dispatch_manifest / check_feature_gate_coverage	PASS
check_documented_commands / verify_documented_env_vars	PASS
relative-link resolution across the ledger	0 broken
Deletion ratio, Detect change scope (Actions)	pass

Adversarial review returned REQUEST CHANGES, all six findings fixed in 6353ee651, detailed in the comment above.

No test, kernel or build input is touched by this PR, so there is no code failure to investigate before merge — only main's, which is now tracked.