sync(UPSTREAM-SYNC-HEADPIN): step 6 owed POST-HOC at the new pin e126687a9a -- five rows, C1c, and a red means revert

[localai-org-maint-bot]

Row: UPSTREAM-SYNC-HEADPIN

Step 6 of the sync cycle, owed against the NEW pin
e126687a9a828d513c01a07cd69f025f27d63280, which #2817 advanced to.

This is post-hoc by developer ruling, and that is the whole point of the issue

.agents/upstream-sync.md §"The sync cycle" puts step 6 before step 7. Wave
STEP6 (#2771, landed as #2783) measured that the committed harness cannot run
step 6 at a revision that is not the pin, because online_gate.py reads the
```parity-pin block and refuses on the distribution version, the runtime
version, the commit and the FlashInfer version before it reaches anything else.
The developer ruled that the pin advances first. So the baselines below were
measured against the PREVIOUS pin and are now validated after the fact.

A red here requires reverting the pin, not holding it. There is no version of
this in which a failing re-measurement leaves the pin where it is: the advance was
taken on the expectation that these numbers survive it.

READ THIS BEFORE YOU SPEND THE LEASE: the build mode decides whether the harness will run at all

The ```parity-pin block records
vllm_distribution_version = 0.28.1rc1.dev132+ge126687a9.precompiled. That
string was measured under VLLM_USE_PRECOMPILED=1. The SOURCE build at the
same revision produced a wheel with no .precompiled suffix:
vllm-0.28.1rc1.dev132+ge126687a9-cp312-cp312-linux_aarch64.whl
(.agents/sync/2026-09-03-e126687-runhalf.md §2).

tools/bench/online_gate.py:3529-3540 compares that field for equality, and
it does so BEFORE it reaches the commit assertion or the FlashInfer gate. So a
source-built oracle at this pin — which is what step 1 of the shared setup below
asks for — is refused on the distribution version, after the 94-minute build,
on a contended GB10.

Three things follow, and none of them is "edit the block until it passes":

1. Read importlib.metadata.version("vllm") from cd / as soon as the install
   finishes, before starting any measurement, and record it literally.
2. If it differs from the block, the BLOCK is wrong for a source build and is
   corrected from YOUR measurement, in its own change, with the build mode named
   beside it. Editing a fail-closed assertion to make a run pass is the The benchmark harness ENFORCES the 0.25.0 rollback oracle and would REJECT the recorded pin — nobody could have measured correctly even deliberately #520
   failure — the harness spent 17 days refusing the oracle the record required,
   and it was right to.
3. Also record the FlashInfer version and the runtime version the same way. The
   run half recorded SHALLOW=false REVCOUNT=20591; a shallow clone silently
   rewrites the version prefix (The pinned vLLM oracle BUILDS, installs and imports inside an rc lease on dgx:gpu0, and a model run is still UNTESTED #1185), so a deep fetch is part of the recipe,
   not an optimisation.

Full context: .agents/upstream-sync.md §"The .precompiled suffix is a
BUILD-MODE property" and .agents/sync/2026-09-03-e126687-advance.md §2.1.

What is owed

.agents/sync/2026-09-03-e126687-step6.md §7 is the recipe. All of it needs
dgx:gpu0 (GB10, sm_121a), which is the device every affected number was taken
on, claimed with rc run under setsid nohup with ppid == 1 verified and read
back with rc logs. FlashInfer moves 0.6.15.post1 to 0.6.18, and our own arm
must be rebuilt with VLLM_CPP_CUTLASS_DIR pointing at that wheel's
data/cutlass, because it is the same input on both sides of the ratio.

C1a, vllm-online-serving, three throughput rows plus the startup row.
nvidia/Qwen3.6-27B-NVFP4@0893e160 and Qwen3.6-35B-A3B NVFP4 at c1 and c4
against docs/benchmarks/vllm-online-serving.md:66-67 and :106-107;
Qwen/Qwen3.8-27B@1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0 bf16 at c4 against
:21; and the cold-to-/health startup row at :73.

C1b, speculative-decoding, two rows. The MTP row
(docs/benchmarks/speculative-decoding.md:5) at c1 through c8, and the DFlash
D14 row (:6) on the D14 recipe, recording the oracle's selected backend
explicitly rather than assuming it at 0.6.18.

C1c, nvidia-cutlass-dsl 4.6.0 to 4.6.2. STEP6 withdrew its discharge:
vllm/model_executor/warmup/kernel_warmup.py:125-126 gates on
has_device_capability(90), which is >= and therefore admits sm_121, and the
compile(...) it reaches is unguarded. Two questions: whether the 4.6.2 warmup
compile succeeds on GB10 at all, and what fraction of the oracle's 182.41 s
startup it is. cutedsl_warmup() and fa4_cutedsl_warmup() were never examined
and are owed with it.

The two discharges, and whether they still hold

Both were argued at the OLD pin and both are re-stated as still holding at the
new one, because neither argument depends on which revision is pinned:

• The transformers floor moved >= 5.5.3 to >= 5.10.4 and the resolved
  version is 5.14.1, above both. Still a lower bound, still satisfied.
• VLLM_ALLREDUCE_USE_FLASHINFER flipped False to True and is inert at
  tensor_parallel_size == 1, which every committed gate runs.

A rebuild of the oracle environment at the target resolves transformers to
whatever is newest that day (5.16.1 was measured), which belongs to golden-drift
re-validation, not to this denominator.

Not owed here

The declared token-exact gate at the target is #2794. docs/benchmarks/memory.md's
four unmarked PASS rows are STEP6 C7 and belong to whoever re-takes that grid.

FOLLOWING_AGENTS_PROTOCOL