fix(ENG-CUDAGRAPH-BREAK): three registrations never read the async mirror's identifiers, on the graph path and the eager path alike (#1305)

[localai-bot]

Three registrations routed an asynchronous step into a model that never read
ModelForwardInput::device_token_ids, so the decode graph AND both eager arms
embedded identifiers the runner deliberately leaves stale.

#1305 reads as a decode-graph hazard: qwen3_moe_registry.cpp,
deepseek_v2_registry.cpp and glm4_moe_lite_registry.cpp admit a pure-decode
step to a driver that replays against a host vector, while qwen3.cpp declines
for exactly that condition. Reading the tree found something larger. Those three
registrations never constructed a detail::DeviceTokenIdsScope, and neither
qwen3_moe.cpp's nor deepseek_v2.cpp's EmbedInto ever consulted one, so
device_token_ids reached NOTHING in either translation unit. On the
asynchronous serving path the runner's combine splices each decode row's sampled
token into the DEVICE identifiers on the main queue and leaves the host
token_ids stale by design — the synchronize that path exists to remove — and
the mirror arm is the default. Both models therefore generated from the previous
step's identifiers for every decode row, on the graph path and on the eager path
alike. No decline could have mitigated the eager half, which is why the fix here
is the consumption and not the refusal.

What lands

The three registries publish the scope, which is the mechanism qwen3.cpp,
qwen3_5.cpp, mistral_registry.cpp, internlm2_registry.cpp and
llama_registry.cpp already use, so every embed in both translation units
consumes it.

The two decode-graph drivers take the version of the fix the issue asks for
rather than a fifth private copy. Each padded size slot now owns a
vllm::StepTokenIds (include/vllm/model_executor/models/step_token_ids.h),
whose destination is a device buffer with an address that does not move and whose
refresh runs through vt::PersistentStepInput: the host arm for the padded
vector, then the DEVICE arm over the real prefix, both enqueued on the main queue
so the second is ordered after the combine instead of racing it. That gives
RefreshFromDevice its first production caller — W4 landed it with none and named
the gap under ## Owed.

last_source() is NOT given a reader, and an earlier draft of this body said it
was. Every caller of last_source() or StepInputSource is a test; what the
gate reads is the process-wide vt::GetStepInputStats(). Five of StepTokenIds'
six accessors have no caller in src/ or tests/, and the header now says so
rather than leaving a reader to assume the counters it exposes are the ones under
test.

The consumer side is written ONCE. Taking the scope and splicing it over an
embed's device buffer is four lines plus five, and qwen3.cpp and qwen3_5.cpp
each spelled both out; this change first added a third and a fourth copy, in a
row whose stated purpose is deleting them. detail::TakeDeviceTokenIds and
detail::ApplyDeviceTokenIds now sit in qwen3_5_internal.h beside the
DeviceTokenIdsScope that publishes what they read, and all four models call
them. The refusal messages keep their per-caller wording, so a shape disagreement
still names the model it came from.

What this deliberately does NOT do

qwen3.cpp's decline is untouched. W4 (#1307) measured that decline's recorded
CAUSE false, so its failure mode is unexplained, and a refactor does not retire a
mitigation whose mechanism nobody can name. Removing it still needs the two
battery runs the spec records.

The embed still sits OUTSIDE the captured region in every driver, because
vt::Embedding allocates a device flag and synchronizes the stream. The
identifiers are therefore read once per step from a stable device address, not
from inside the replay. StepTokenIds is the destination the inside-the-capture
change would need; it is not that change. Two production comments that stated the
older facts — persistent_step_input.h on RefreshFromDevice having no caller,
and qwen3.cpp's decline on the fix existing in no driver — are corrected here,
because a record edit rides in the pull request whose change made it stale.

Evidence

tests/vllm/models/test_moe_async_device_ids.cpp enters at
ModelRegistry::Forward over a synthetic safetensors checkpoint. A case that
drove the driver directly would measure the type rather than the registration.

Three runs per case, because two of them cannot separate the cases: right host
identifiers and no mirror as the reference; stale host identifiers and no mirror
as the CONTROL, which must differ; the same stale host vector with the truth
reaching the model ONLY through device_token_ids as the gate, which must be
bit-identical to the reference. Without the control, a model that ignored its
identifiers entirely would satisfy the gate.

RED before the change, for the intended reason: 2 cases, 65 assertions, 10
failed, exit 1, with 800 of 800 logit values differing over four steps on both
architectures and every seam counter at 0. GREEN after: 65/65, exit 0.

A fresh review then proved that gate covered half of what this change claims,
by mutation rather than by reading, and the repair is in this branch. Deleting
the TakeDeviceTokenIds + d.b.Copy block from BOTH
EmbedInto(const std::vector<int32_t>&) overloads — restoring the pre-fix EAGER
behaviour, the half this body calls the reason the fix is a consumption — left
the gate green at 2/2 cases and 65/65 assertions. Deleting the two-line
DeviceTokenIdsScope from glm4_moe_lite_registry.cpp, the THIRD of the three
registries this body says publish a scope, did too; the original reachability
mutation had covered only two.

The gate is now 6 cases, 191 assertions, exit 0: both lanes for all three
registrations, through one A/B/C helper. The lane is chosen by the registry's OWN
predicate rather than by the test — a case that constructs StaticGraphCpu gets
the decode graph, a case that does not gets ForwardDevice — and through_seam
asserts the vt::PersistentStepInput counters BOTH ways, moving on the graph
lane and at zero on the eager one, so a case cannot drift onto the other lane and
stay green. GLM-4-MoE-Lite gets its own fixture rather than a claim of coverage:
it shares the driver, the model and the weights struct with DeepSeek-V2, so the
only thing it owns is its scope.

Four mutations, each with its compile status printed:

mutation	compile	exit	cases	what reds
delete both eager EmbedInto consumers	rc=0	1	3 of 6 pass	the 3 EAGER cases, on differing == 0
delete glm4_moe_lite_registry.cpp's scope	rc=0	1	4 of 6 pass	the 2 GLM cases only
delete StepTokenIds::Refresh's RefreshFromDevice	rc=0	1	3 of 6 pass	the 3 GRAPH cases, on device_refreshes AND differing == 0
shared ApplyDeviceTokenIds copies 0 bytes	rc=0	1	3 of 6 pass	the 3 EAGER cases — the hoisted body is reached

A fifth deleted that shared copy outright and FAILED TO BUILD under
-Wunused-parameter. Its verdict was DISCARDED, not read as a pass.

Neighbours green on the same binary after merging origin/main at 96ed8346f:
test_qwen3_moe_decode_graph_seam 228, test_deepseek_v2_decode_graph_seam 230,
test_qwen3_decode_graph_seam 231, test_persistent_step_input 66,
test_model_registry 924, test_qwen3_moe_forward 504,
test_deepseek_v2_forward 1052, test_glm4_moe_lite_load 15 — all 0 failed,
exit 0. test_qwen3_dense_async_serving exits 0 over 8 cases and 0 assertions,
which is a skip wearing a pass: it needs checkpoints this box does not have.
Component checkers green: check-agent-record,
check-issue-index-append-only, check-surface-coverage,
check-test-registration, check-symbol-anchors, check-public-doc-tables,
check-runner-routing-consistency, check-fusion-consistency,
check-device-leakage, check-now-current, check-doc-checkpoint,
check-gate-commands, check-role-discipline, check-prompt-contract,
check-commit-style, check-commit-trailers.

Continuous integration is REMOTE_UNVERIFIED: every check on this branch reads
pending and none starts (#1376).

What is still owed, and why #1305 does NOT close here

The issue splits, and only one half settles. The EAGER half is fixed and
gated on all three registrations and deserves to close. The GRAPH half does not,
and the reason is sharper than "the battery did not run": the mechanism these two
drivers now have is functionally what qwen3.cpp ALREADY HAD at 338cbbfd1^ — a
registry scope, consumed by EmbedInto, copying the mirror's identifiers over the
embed source OUTSIDE the capture — and W4 recorded at qwen3.cpp:1083-1095 that
the depth-2 graph-ON battery STILL FAILED with exactly that in place. A stable
device address buys nothing while the embed stays outside the capture, which this
body concedes two sections above.

The depth-2 four-concurrent battery against Qwen3-Coder and DeepSeek-V2-Lite on a
real device — #1305's own settlement condition — has NOT been run, and the reason
is a fleet state rather than an intention: at 2026-08-19 rc devices read
dgx:gpu0 busy, the only box whose HuggingFace cache carries the checkpoint,
while thor:gpu0 and orin:gpu0 were ready and carry none. So #1305 stays
open, with the ENG-CUDAGRAPH-BREAK row as owner and the residual recorded in
the spec's ## Owed.

The DEVICE half of the refresh contract is untested on any device, and the gate's
own opening comment used to say the opposite. On CPU vt::Backend::Alloc returns
HOST-addressable memory, so both refresh arms reduce to the same memcpy from the
same address; swapping the device arm for the host arm leaves every logit
bit-identical at 0 of 800 differing and reds only the
device_refreshes/host_refreshes counters. Those counters are a legitimate
stand-in for which arm ran and they are what the file asserts, but they gate the
INSTRUMENT, not the behaviour. Owed with the battery, same window, same owner.

Found on main while doing this, and not caused by it

test_qwen3_5_decode_graph_seam exits 139 at 5f68e60df, which was origin/main
exactly, while its assertion line reads 135 of 135 passed and 0 failed. Only the
exit status and a CRASHED: SIGSEGV line say otherwise. Re-measured on this
branch: exit 139 at the SAME crash case and site
(test_qwen3_5_decode_graph_seam.cpp:800, W6: two spec shapes of EQUAL S and different q get two graphs) both with and without this branch's working-tree
changes, and its printed counts are not reproducible — three consecutive runs of
ONE unchanged baseline binary gave 6 passed with 2 failed and 141 assertions,
then no summary at all, then no summary at all. The exit code is the only stable
observation there. Filed as #1390 with ENG-CUDAGRAPH-BREAK as the owner and
recorded under ## Owed; that issue stays open.

Records

.agents/specs/eng-cudagraph-break.md ## Owed, ## Now and ## Outcome,
.agents/engine-matrix.md, and one appended .agents/issue-index.md row for
#1390. No lifecycle state moved, so docs/STATUS.md and docs/BENCHMARKS.md
owe nothing.

An earlier draft of this section said the engine-matrix issue cell "listed #1305
twice" at the base. It did not. The cell carries #1305 ONCE at the merge base and
once at origin/main; the duplicate was this branch's own, introduced by
831f8d3ce and removed by 91087e670. That sentence attributed a self-inflicted
transient to the base, and the net state is one mention, unchanged.

Repaired after a fresh re-review

The re-review returned PASS_WITH_FINDINGS on the code — all six production call
sites proved individually, the four-way hoist behaviour-identical to every
original, baseline 6 cases / 191 assertions / exit 0 — plus one blocking record
defect. It is repaired here, and no source line moves.

The blocking one. ## Owed said last_source() and StepInputSource "gain
their reader with it". They do not, and this change already says so in three
other places: both headers state it, and this body retracts it below.
Re-derived rather than assumed — grep -rn 'last_source()' src/ returns NOTHING,
the only readers of a value are six CHECKs in
tests/vt/test_persistent_step_input.cpp, and step_token_ids.h:122 forwards to
cell_.last_source() but is itself never called. What gains a production caller
is RefreshFromDevice; the arm observable stays unread. A record asserting a
reader exists is precisely the drift the two header repairs in this branch were
made to end, which is why it blocked.

Four smaller ones. include/vt/persistent_step_input.h said "every caller of
either is a test", false by exactly one — that forwarding wrapper — and now says
every caller that reads a VALUE is a test, naming the wrapper. The #1390
measurement was recorded three ways: the spec presented 8 cases, 7 passed, 1 failed, 135 of 135 as the measurement while this body and the engine-matrix row
already carried the correction that those printed counts are not reproducible.
The spec now agrees with them and states the general rule plainly: on a
crashing suite no assertion count means anything, because the process dies before
the harness totals it — only the exit code carries a verdict.
.agents/issue-index.md is append-only and cannot be edited, so it still shows
the original numbers; the spec and the issue are named as the authority over that
row. And a stray .; in .agents/engine-matrix.md field 7, where the appended
#1305 block was concatenated onto the #1380 sentence.

Two are RECORDED as bounded residuals in ## Outcome rather than repaired.
The shape-refusal hoist moves __FILE__/__LINE__ to qwen3_5.cpp:562 for all
four refusals, so three of the four callers now name the wrong file; no test
asserts those strings (grepped for the message and for each of the four what
values), the what prefix still carries caller identity, and the audience is
somebody reading one refusal out of a log. The two rewritten call sites in files
this branch was not repairing (qwen3.cpp:213, qwen3_5.cpp:7829) are covered
only by checkpoint-gated skips reporting assertions: 0, and
test_qwen3_decode_graph_seam.cpp:341-349 gates the DECLINE rather than the
consumption; the shared body they call IS gated, so the ungated surface is two
argument lists, the gap pre-dates this branch, and net the hoist IMPROVES
coverage, because a defect in the shared body now reds
test_moe_async_device_ids.

Advances #1305, which stays open on the battery above.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]