The Laguna 1.03x pairs a re-measured arm against a denominator taken 75 minutes earlier and never re-run

Row: -

docs/benchmarks/at-a-glance.md:29 publishes the Laguna decode headline as parity+, 1.03x (44.46 vs vLLM 43.10). It is the only ratio above 1.0 against vLLM anywhere on that page, so it carries more weight than any other single number there.

The two halves of that ratio were not measured beside each other. That is the whole of the claim here — this is a re-take request, not a retraction.

What each half actually is

Our 44.46 is well measured. 3fa894d3e (2026-08-04 23:13Z) records the binding figure at the new production default: 44.46/44.53/44.41 -> 44.46 tok/s, median-of-3, drop_caches, worker parked, flock, prod decode config, 256 tokens, with generated ids byte-identical to the VT_LAGUNA_RESIDENT_BF16W=0 opt-out arm. Nothing wrong with it.

The 43.10 denominator is also a real measurement — I want to be exact, because I first described this wrongly to myself. It comes from 7f5d1cca0 (2026-08-04 21:58Z), a same-tool nsys session that profiled both engines and read ours at 37.55 against vLLM's 43.10.

But the two are 75 minutes apart, and only our side was re-taken. The residency flip moved our arm 38.79 -> 44.46. The vLLM arm was not re-run beside it; the 43.10 was carried forward from the earlier session and divided into the new number. 3fa894d3e is a docs commit and measures no oracle.

Why 75 minutes on the same box is not good enough for this particular ratio

The margin being claimed is 3.2%. This repository has repeatedly measured its own run-to-run spread at or above that:

• docs/benchmarks/how-we-measure.md:68-69 puts the GB10 noise band at 0.5%, but that is for interleaved legs.
• The project has recorded a 1.6% same-arm spread swamping a 1.2% "regression" that turned out to be noise, and a 24% dispersion across speculative legs where target-only legs held 0.35%.
• It has also recorded whole-session drift — "post-midnight runs ALL depressed" — which is exactly the shape a 75-minute gap is exposed to.

AGENTS.md §Gates requires identical conditions on both sides and reproduction "on an idle host with a same-binary A/B test". how-we-measure.md:68-69 is more pointed: "We never publish a partial, contended, or stale-denominator number as binding, and when a denominator turns out to be wrong we correct every ratio built on it rather than keeping the flattering one." A denominator carried across 75 minutes and a binary change is, at minimum, not established as fresh.

What is owed

Re-take 43.10 in one interleaved lease beside 44.46, same binary, same prompt (2,785,9626,377,15360,395), 256 tokens, median-of-3, clocks pinned, legs alternating rather than batched. If it reproduces, the headline stands and is then genuinely binding. If it does not, how-we-measure.md:68-69 says which way to correct.

One thing I could NOT establish, flagged rather than asserted

I did not determine whether the 43.10 leg ran vLLM in its production configuration. AGENTS.md §Gates forbids --enforce-eager as a denominator. The record does show an earlier, different Laguna vLLM run (2026-07-31, CLAIM-LAGUNA-VLLM-NVFP4, ~18.8 tok/s) that was taken eager with VLLM_TEST_FORCE_FP8_MARLIN=1 because the auto-default FLASHINFER_CUTLASS needed an absent nvcc. That is a different number from a different session and I am not claiming it describes the 43.10 leg. Whoever takes the re-measurement should record the oracle's resolved backend and eager/graph mode explicitly, because right now no Laguna row on either surface carries it.

Related

docs/FEATURES.md already marks this row no golden, no token gate (#2841): "byte-exact" on this row means byte-exact against our own prior output under a lever A/B, never against vLLM. So the correctness side of this headline is separately owed and this issue does not cover it.

Read docs/benchmarks/at-a-glance.md:29, docs/benchmarks/how-we-measure.md:68-69, and AGENTS.md §Gates, then inspect commits 3fa894d3e and 7f5d1cca0. Re-run the vLLM and project arms in one interleaved lease using the stated prompt and conditions, recording the oracle backend and mode. Done means the ratio is supported by fresh paired measurements or corrected according to the measurement guidance.