feat(qwen35): allow the auto scheduler policy with stream decode-overlap

[CAICAIIs]

Summary

Retire the #715 startup rejection that forced --qwen35-scheduler-policy=off whenever --decode-overlap stream was enabled, and allow the two opt-in controls to be combined.

The two controls are orthogonal in the scheduler: auto only shapes the per-step prefill budget (choose_prefill_budget); stream only changes how a Unified plan executes (async chunk launch on a second stream + decode tick). The rejection was a conservative "untested combination" guard, not a mechanical conflict.

Changes

• Remove the auto-vs-stream rejection in the Qwen3.5 engine entry (lib.rs) and the CLI validation layer (model_line.rs).
• Flip model_line::rejects_auto_policy_with_overlap to the acceptance contract (accepts_auto_policy_with_overlap); retire the engine-level rejection probe in lib.rs — the surviving TP / --max-batch <= 32 / TP-rejects-auto guards keep every other fail-closed path.
• Update docs/models/qwen35/unified-prefill-overlap.md: the guard list no longer names the combination, and the TL;DR records the measured effect.

Evidence (1x A100-40GB, upstream/main 70a600b7 + this change, vLLM 0.27.0 baseline)

1024-token prompts, greedy, vllm bench serve, zero failed requests; single run per cell (gap-map grade):

cell	base TPOT / ITL p99 ms	combo TPOT / ITL p99 ms	vLLM 0.27 TPOT / ITL p99 ms
1024/256 c8	12.23 / 65.5	11.94 / 34.2	9.88 / 12.0
1024/256 c16	14.87 / 81.4	14.26 / 36.5	11.00 / 83.3
QPS16 1024/128	36.74 / 101.3	20.81 / 41.7	23.60 / 93.4

The combination dominates every single-lever config (stream alone, auto alone, fixed 512-token chunks) and beats vLLM 0.27 on c16 ITL p99 and on QPS16 TPOT and ITL p99. The trade: open-loop TTFT at QPS16 rises 867 → 1828 ms and QPS16 output throughput drops 15%; fixed-concurrency TTFT stays within +5% of base. Individual-lever matrix and analysis: #727 (comment).

Correctness on the combination: release lib tests 98 passed, hf_golden_gate TP1 2/2 and TP2 (--ignored) 2/2, e2e_scheduler passed.

Claim boundary

Still opt-in (off remains the default for both knobs); stream keeps the --max-batch <= 32 cap and single-GPU-only restrictions. Single-run numbers on one GPU — not a parity or production-readiness claim. The remaining c8 TPOT/tail distance to vLLM is kernel-side (batch decode slope), not addressed here.

[FeathBow]

Thanks, the change looks right to me and the orthogonality argument holds on a trace of the scheduler loop. Since the cited gates never actually run auto + stream (hf_golden_gate skips the scheduler and the overlap E2E starts both engines with Policy::Off), should we add an Auto + SharedSm engine to test_e2e_qwen35_shared_sm_last_decoder that asserts the same greedy tokens as the Off reference, and post that run before merging?

[CAICAIIs]

Done — test_e2e_qwen35_shared_sm_last_decoder now starts a third engine with Qwen35SchedulerPolicy::Auto + Qwen35DecodeOverlap::SharedSm (commit 00f0088) that replays the in-flight-prefill scenario against the same default-Off reference: background decode 512/128, one 8192-token prefill of max_tokens=2 overlapped in-flight, assert_no_generated_event before the overlap bound, then the last decoder is cancelled and the promoted prefill must finish with exactly the reference's greedy tokens — proving the auto policy's reshaped chunk boundaries survive the overlap oracle.

Run on the bench host (1x NVIDIA A100-SXM4-40GB, sm_80, Qwen3.5-4B, PEGAINFER_TEST_MODEL_PATH=/mnt/data/models/Qwen3.5-4B, release build at 00f0088cbd16740c3effc16a7dacbd1b339e979c):

cargo test --release -p pegainfer-qwen35 --features qwen35 \
  --test e2e_scheduler test_e2e_qwen35_shared_sm_last_decoder -- --nocapture

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out; finished in 15.10s

The other gates from the PR description were re-run on the same tree earlier (lib 98 passed, hf_golden_gate TP1 2/2 + TP2 2/2, e2e_scheduler passed).

[FeathBow]

lgtm :)