main is red on device-leakage: #213's lm_head landing added a 33rd shared-layer VT_MARLIN_NVFP4 ifdef without an allowlist entry

[localai-bot]

check-device-leakage fails on main, and has since 7d45913a. Every PR opened
after that point inherits a red device-leakage check that has nothing to do
with its own contents — which is how I found it, gating #277.

ERROR: DSR REGRESSION in bucket 'vt_ifdef': 33 > baseline 32.
check-device-leakage: FAIL (1 error(s))
DSR by bucket: kcuda=0, is_cuda=0, cuda_inc=0, vt_ifdef=33  -> total 33

Bisected on main, sources only

src/ and include/ checked out at each revision, checker run against each:

main revision	DSR sites
abdc3a26	32
848d4a87	32
84fc736d	32
7d45913a	33
e17e8f8a	33
24306364	33

7d45913a is merge: origin/main into the PERF-27B-LMHEAD-FP4 landing, i.e.
the landing of bc2fa7d9 / #213 ("keep the ModelOpt NVFP4 lm_head packed").

The added site

Diffing the checker's own site list across 84fc736d..7d45913a gives exactly one
new entry:

> src/vllm/model_executor/models/qwen3_5.cpp: [vt_ifdef] #ifdef VT_MARLIN_NVFP4

So a device-specific preprocessor branch entered the device-agnostic shared
layer without either a DSR-ALLOW comment naming it the platform leg or a
deliberate baseline change. The checker's own message spells out the three legal
responses and rules out the fourth:

Ask the op/provider table the question instead (vt::OpRegistered / Platform
capability), or — if the site is genuinely the platform leg — add it to
ALLOWLIST with a reason. NEVER raise the baseline to make this pass.

Reproducer

python3 scripts/check-device-leakage.py          # FAIL: 33 > 32
python3 scripts/check-device-leakage.py --list   # the 33 sites + 14 DSR-ALLOWs

To confirm it is not your branch, check out only the sources at the base and
re-run:

git checkout <main-sha> -- src include
python3 scripts/check-device-leakage.py
git checkout HEAD -- src include

Why this matters beyond one red check

device-leakage is the guard that keeps new hardware additive. A red baseline
that everyone learns to scroll past is how the 33rd site becomes the 40th: the
gate stops being a ratchet the moment its failure is routine and unattributed.

Owner should be whoever landed #213, since only they know whether the new
#ifdef is genuinely the platform leg (→ DSR-ALLOW with a reason) or should
be asking the Platform capability table instead.

Row: ARCH-ONE-SURFACE / PERF-27B-LMHEAD-FP4 (#213).

[localai-bot]

Verified fixed on current main 3ffc99a8. The gate is green:

$ python3 scripts/check-device-leakage.py
DSR by bucket: kcuda=0, is_cuda=0, cuda_inc=0, vt_ifdef=32  -> total 32
check-device-leakage: OK (DSR 32 == baseline 32, ratchet holds)

The issue reported a 33rd shared-layer VT_MARLIN_NVFP4 ifdef landing without an allowlist entry, leaving main red on the DSR ratchet. The count is back at the baseline 32 and the ratchet holds, so the missing entry was reconciled. #298 (the same ratchet, PrepareLmHeadResident) is already closed.

Closing as resolved. Verified while working the roadmap issue table; the checker was run against a clean checkout of main, not a local build tree.