[Bug]: Qwen3.6-35B-A3B (hybrid GDN + MoE): a prompt’s logprobs move by up to 0.2 when another sequence shares its engine step (v0.30.0, sm_1

快速结论：在 vLLM 0.30.0 中用 LLM.generate([p, p]) 对同一 prompt 批量打分时，logprobs 会在两次运行间漂移。这通常不是内核随机的，而是两个请求到达 engine core 的时机不同，导致“批量为 2”有时实际是两行同步 prefill、有时是分两次单行执行。优先排查批组成（batch composition），而不是先怀疑 MoE 或 GDN 内核。

适用环境：vLLM 0.30.0（pip wheel），torch 2.13.0+cu130，Python 3.12；模型为 Qwen/Qwen3.6-35B-A3B-FP8 @ 95a723d 与 Qwen/Qwen3.6-35B-A3B（bf16）@ 995ad96；显卡覆盖 NVIDIA RTX PRO 6000 Blackwell Workstation Edition（sm_120）与 RTX 6000 Ada（sm_89）；设置 VLLM_USE_DEEP_GEMM=0；bf16 需额外使用 max_num_seqs=256（默认 1024 在 96 GB 单卡上因 885 个 Mamba cache blocks 无法启动）。

最快修复方案：设置 VLLM_ENABLE_V1_MULTIPROCESSING=0 启用进程内 engine，使两个请求在第一步之前全部加入，批次内两行必然共享同一 engine step。

注意事项：该设置只消除运行间差异（batch2_repeat 降到 0.0），不能消除单行 vs 双行的批量差异（alone_vs_batch2 仍有约 0.149～0.198）。若业务要求不同负载下同一 prompt 输出完全一致，需使用 batch-invariant 内核；但当前 VLLM_BATCH_INVARIANT=1 对该模型会以 “not supported for GDN_ATTN” 拒绝启动。sm_89 上还观察到同一 step 内两行在 layer 0 的 FP8 in_proj_qkvz 不等，sm_120 未复现，属不同内核路径，需单独排查。

问题场景

用户使用 vLLM 0.30.0 的 LLM.generate()，对同一条约 1,400 token 的 prompt 只打分一个 output token 并取 20 个候选 id 的 logprobs，分别以“单行”“单行重复”“两行相同 prompt 的批量”“该批量重复”四种方式运行。结果单行完全可复现（Δ=0.0），但批量重复出现最多 0.168 的漂移，单行与批量之间最多 0.198。在 272 条真实 prompt 的决策式用法中，同一 prompt 单行与批量打分导致选项变化的比例为 10%～17%。

报错原文

[Bug]: Qwen3.6-35B-A3B (hybrid GDN + MoE): a prompt's logprobs move by up to 0.2 when another sequence shares its engine step (v0.30.0, sm_120)
--gdn-prefill-backend triton
not supported for GDN_ATTN
# default
{'alone_repeat': 0.0, 'alone_vs_batch2': 0.1606, 'batch2_repeat': 0.1606}
# VLLM_ENABLE_V1_MULTIPROCESSING=0
{'alone_repeat': 0.0, 'alone_vs_batch2': 0.1636, 'batch2_repeat': 0.0}
Using default MoE config

原因分析

维护者复现后确认：LLM.generate([p, p]) 把两个请求逐个送入 engine-core 进程，core 在 vllm/v1/engine/core.py 的 _process_input_queue 中按“当前已到达的请求”开启一个 step。因此“批量为 2”有时两行在同一 step 一起 prefill，有时各自单独执行，这就是运行间漂移的来源，并非某个内核随机。

设为进程内 engine（VLLM_ENABLE_V1_MULTIPROCESSING=0）后，两个请求在首个 step 前均已加入，sm_120 上 FP8 与 bf16 的 batch2_repeat 均精确为 0.0，验证了该解释。

剩余差异属于正常批量方差（batch variance）：同一行在单行 step 与共享 step 中的结果会有小幅不同。sm_120 上共享 step 内的两行彼此逐位一致（40/40），forward hook 检查 40 层（含 30 个 GDN 层、attention 与 MoE experts）共 602 个逐 token 模块输出均一致。sm_89 上则发现两行在 layer 0 的 FP8 in_proj_qkvz 出现差异，可能原因是对应的 block FP8 走了 MarlinFP8ScaledMMLinearKernel 等不同内核，与本议题主体问题不同。

附带现象：enable_return_routed_experts=True 时，批量中两份相同请求约 40% 的 (token, layer) 条目与单行请求不一致，而两份副本彼此一致；这可能与多请求共享 step 时 per-request 采集错位有关，Issue 中视为可能独立的问题。

环境排查

确认 vLLM 版本是否为 0.30.0，以及所用的 LLM.generate() 调用方式。
确认是否设置 VLLM_ENABLE_V1_MULTIPROCESSING；默认多进程，设为 0 则进程内执行。
确认 checkpoint：Qwen/Qwen3.6-35B-A3B-FP8 @ 95a723d 或 bf16 @ 995ad96。
确认 max_num_seqs：bf16 在 96 GB 单卡上需降至 256 才能启动（默认 1024 失败）。
确认是否加载插件、是否设置 VLLM_USE_DEEP_GEMM=0；Batch-invariant 模式当前会因 “not supported for GDN_ATTN” 拒绝该模型。
确认显卡计算能力（sm_120 与 sm_89 走不同 FP8 内核路径，表现不同）。

解决步骤

先区分“运行间漂移”与“单行 vs 批量差异”：用同一脚本分别统计 alone_repeat、alone_vs_batch2、batch2_repeat 三项指标，并额外记录 40 次批量中有多少次两行与单行结果逐位一致。
设置环境变量 VLLM_ENABLE_V1_MULTIPROCESSING=0 后重跑。预期 batch2_repeat 变为 0.0，两行必然共享同一 step。
若 batch2_repeat 仍非 0，再检查是否有其他因素导致请求非同时入队，而不是继续怀疑 MoE 或 GDN 内核。
对 alone_vs_batch2 的残余差异，按批量方差对待；如果业务要求消除，可关注 batch-invariant 内核（#48613、#49827、#55868）对 GDN 模型的进展，在支持前无法用 VLLM_BATCH_INVARIANT=1 解决。
sm_89 环境若发现同一 step 内两行不一致，可用 forward hook 对比 layer 0 的 in_proj_qkvz 输出定位；该现象与 sm_120 结论不同，需单独分析。

验证方法

在 VLLM_ENABLE_V1_MULTIPROCESSING=0 下重跑 Issue 提供的 repro_upstream.py：sm_120 上 FP8 与 bf16 的 batch2_repeat 均应精确为 0.0，且 40/40 批中两行彼此逐位一致。同时确认 alone_repeat 仍为 0.0，而 alone_vs_batch2 仍有约 0.1～0.2 的差异，这属于预期行为，不是回归。若开启 forward hook，应看到共享 step 内两行的各层输出与最终 logprobs 一致。