Punch-list item 9 (ROAD-V1-C6) directs a lever the project refuted and a flip that landed 10 days before the item was written

[localai-bot]

Punch-list item 9 (.agents/specs/roadmap-v1-completion.md §3) is the C6 plan of record:

ROAD-V1-C6 SERVE-ASYNC-LLM + priority prod gates (shared with A#5). W: land the depth-2 throughput lever, flip runner_supports_async prod-ON, close priority/busy-loop GPU gates.

The spec was committed 489f7771 on 2026-07-27. Two of its three clauses had
already landed before it was written, and the first clause asks for something the
project had already refuted and retired as an objective.

Clause by clause

Clause	Reality	Evidence
land the depth-2 throughput lever	Landed 11 days earlier, and REFUTED in the same commit	6ea7856 (2026-07-16) perf(engine): ENG-ASYNC-SCHED W3 throughput lever — persistent pooled sampled-id/pinned buffers; lever REFUTED as tput unlock
flip runner_supports_async prod-ON	Flipped 10 days earlier, default-ON since	a0013a2 (2026-07-17); predicate include/vllm/v1/worker/gpu/async_runner_flag.h:38
close priority/busy-loop GPU gates	Half stale, half real — busy-loop covered since 2026-08-05; priority genuinely open	1718bf155, 52d76f3a9 / no priority gate exists

1. The depth-2 throughput lever is not just landed, its goal was retired

6ea7856 implemented AsyncOutputPool (persistent sampled-id / pinned buffers +
Sampler greedy scratch, removing every per-step cudaMalloc/cudaFree/
cudaHostAlloc/event-create from the sampled-id path, including the
overlap-killing cudaFree inside get_output). Its own commit message records
the verdict: c16 throughput −0.32% against a ≥+1.5% gate, because the
removed syncs are O(10–100 µs) against a ~165 ms c16 step.

The day after, the CLAIM-W3-ASYNC-DISC discriminator measured vLLM's OWN async
self-A/B and found upstream pays −0.66 to −0.91% throughput for async
scheduling and ships it as the default anyway. .agents/specs/async-serving.md
records the conclusion verbatim: "There is NO depth-2 throughput unlock to find —
D6's search target does not exist in the reference either", and "The speed-credit
floor for W3 as a lever is retired with it".

So the clause directs a future owner to land a lever that is in the tree and to
hunt a win the project has proven does not exist in the reference. It is worse
than stale — acting on it re-opens a closed negative result.

2. runner_supports_async prod-ON, and the title's SERVE-ASYNC-LLM prod-ON, are two different things — both already ON

VT_ASYNC_RUNNER has been default-ON since a0013a2 via the CPU-unit-tested
AsyncRunnerFlagIsOn predicate, so GPUModelRunner::runner_supports_async() is
TRUE and LoadedEngine resolves an AsyncScheduler + max_concurrent_batches=2
with no environment set. DGX-proven token-neutral: 27B 235/235 + 35B 315/315 in
the default arm and in both rollback arms, bit-identical.

The item's title and the §1 C6 cell instead say "SERVE-ASYNC-LLM (GATING →
prod-ON)". That is a different row: SERVE-ASYNC-LLM is the AsyncLLM streaming
serving API, not the runner's async device path. It is also already the
production path — src/vllm/entrypoints/openai/server_main.cpp:731-734,
"the production server uses AsyncLLM over EngineCoreProc's dedicated engine
thread", with the capacity-derived fixed HTTP worker pool as the production
default and VLLM_CPP_HTTP_FIXED_POOL=0 retained only as a diagnostic.

There is no "prod-ON" flip left under either reading. What holds
SERVE-ASYNC-LLM at GATING is its declared broader every-axis parity, not
a default.

3. The priority/busy-loop clause is half done and its recorded blocker expired

Both rows record the same reason: "deferred to the next GPU-idle window — GPU
held by the SERVE-GATE-ONLINE campaign". That campaign has since produced
four bindings; the reason is a month-plus-stale scheduling excuse, not a blocker.

• ENG-CORE-BUSY-LOOP — its G1 (token-exact twins) is covered in substance
  since 1718bf155 (2026-08-05): tests/parity/test_qwen36_async_serving.cpp
  drives LoadedEngine::async_engine() → AsyncLLM →
  EngineCoreProc::step_with_batch_queue (depth-2) token-exact against the same
  pinned oracle continuation the SACRED sync gate uses, RED→GREEN on GB10, plus
  test_qwen3_dense_async_serving.cpp (52d76f3a9). G4 is covered by the
  SERVE-GATE-ONLINE binding 9ecd9d0 114/124, which runs that exact path
  (async default ON) against vLLM.
• ENG-PRIORITY-SCHED — genuinely OPEN. --scheduling-policy priority is
  plumbed all the way to the production server
  (server_main.cpp:408-411,672-673), but no priority-vs-FCFS gate exists
  anywhere under tests/, on GPU or CPU-e2e. This is the one real residual in
  the whole item.

Asked for

Reconcile the record: correct item 9 and the §1 C6 cell, correct the two rows'
stale blocker text, and state the residual where a next owner will read it —
without deleting the superseded text, which is history.

No lifecycle state is promoted by this: rerunning a row's gate is the operator's
job, and ENG-PRIORITY-SCHED's gate does not yet exist to rerun.