sixteen architectures never read device_token_ids and decode from token id 0 on the default CUDA arm

Row: -

Owed under .agents/specs/eng-async-device-ids-refusal.md ## Owed O4.

Sixteen registered architectures never read ModelForwardInput::device_token_ids. On the default CUDA arm (async_device_mirror() is DEFAULT-ON, integrated parts included) each of them embeds a host array the asynchronous runner deliberately leaves stale, and token_ids_cpu is zero-initialised, so they decode from token id 0 at every step after the first.

The set

commandr, dots3_note, gemma, gemma2, gemma3, gemma4, glm4, granite, minicpm, minicpm3, muse_glimmer, olmo2, opt, phi, phi3, stablelm.

Each reaches <Model>::ForwardDevice(input.token_ids, ...) and never reads the device pointer.

Why no gate convicts them

A token gate cannot see this. The prefill agrees, the first token looks right, and every token after it is generated from 0 — at rc=0, with fluent output there is nothing to compare against. All five previously convicted architectures were caught by hardware runs, one at a time (#1305, #2496, #2544), never by a gate.

Current disposition

ENG-ASYNC-DEVICE-IDS-REFUSAL (#2710) makes them LOUD rather than wrong: each leaves ModelFactory::consumes_device_token_ids false, so ModelRegistry::Forward refuses a step whose host identifiers are stale and names the architecture and the missing capability. VT_ASYNC_DEVICE_MIRROR=0 remains the same-binary rollback that returns the host combine and makes the host identifiers authoritative again.

That is a refusal, not a fix. Each of the sixteen is owed by the row that ports it, and the repair is small and mechanical now that both arms of the seam exist:

• the DEVICE arm, detail::DeviceTokenIdsScope — for a forward that already uploads its ids to a device buffer;
• the HOST arm, ResolveHostTokenIds (include/vllm/model_executor/models/host_token_ids.h) — for a forward that gathers embedding rows on the host.

Then set consumes_device_token_ids = true beside that forward.

#2710 deliberately does not wire sixteen forwards it has no checkpoint to gate.

Start with .agents/specs/eng-async-device-ids-refusal.md, the sixteen named architecture forwards, and include/vllm/model_executor/models/host_token_ids.h. Trace each ModelForwardInput::device_token_ids use through ModelFactory::consumes_device_token_ids and ModelRegistry::Forward, choosing DeviceTokenIdsScope or ResolveHostTokenIds as appropriate. Done means all sixteen consume device token IDs and no longer trigger the refusal on the default CUDA arm.