[Bug][HiSparse] GLM-5.3 TP8 B200: unspecified launch failure with MNNVL all-reduce (#61989) once KV spills to host

快速结论：该报错出现在启用 HiSparse 后 GPU KV 池不足、resident pages 需要 spill 到 host 压力场景：FlashInfer 的 MNNVL 融合 all-reduce + residual + RMSNorm kernel 在带 CUDA graphs/PDL 的单节点 TP8 上触发 CUDA error: unspecified launch failure，与 HiSparse 本身无关。优先确认启动日志里 all-reduce backend 是否已变为 mnnvl，并回退到 trtllm。

适用环境：vLLM main（崩溃版本 65faf4efa0，2026-10-28 预编译 wheel，Model Runner V2）；torch 2.14.0+cu130；flashinfer-python 0.7.2.post1；8× NVIDIA B200，driver 595.91.07，TP8；模型 RedHatAI/GLM-5.3-NVFP4（rev c8917e42）；FLASHINFER_MLA_SPARSE；默认 FULL_AND_PIECEWISE CUDA graphs。

最快修复方案：在今天的 main 上设置环境变量 VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm，Issue 中同一复现可干净跑完（16 并发 decode 60 s，约 1,230 tok/s，无崩溃）；对另一款同样命中的 DSA 模型也有效。

注意事项：该变量只适用于单节点 TP 组；多节点组（例如跨两个 GB200/GB300 机柜的 TP8）MNNVL 是 FlashInfer 唯一后端，没有这个回退。根因修复在 flashinfer-ai/flashinfer#7782（draft），落地后 vLLM 只需升级 flashinfer-python，无需改代码。

问题场景

用户在 8× NVIDIA B200、TP8 上以 vllm serve 启动 RedHatAI/GLM-5.3-NVFP4，启用 HiSparseConnector（--kv-transfer-config，host_pool_gib 128），并用 --kv-cache-memory-bytes 12884901888 把 GPU KV 压到 12 GiB，然后用 vllm bench serve 跑 16 × (32768 in / 4096 out)、并发 16。当 running requests 的 KV 放不进 GPU pool、HiSparse 要把常驻页 spill 到 host 时，服务启动约 30 s、prefill 刚结束的纯 decode 阶段发生崩溃；各请求生成几十个 token 后全部停止，但 vllm bench serve 仍把它们计为成功。faulting rank 每次不同（曾见 TP0、TP2、TP3、TP5、TP7）。

报错原文

(Worker_TP5) ERROR [multiproc_executor.py] Error getting async model runner output
  File "vllm/v1/worker/gpu/async_utils.py", line 175, in get_output
    self.copy_event.synchronize()
torch.AcceleratorError: CUDA error: unspecified launch failure
...
(EngineCore) TimeoutError: RPC call to sample_tokens timed out.

原因分析

根因已定位在 FlashInfer 的 MNNVL 融合 all-reduce + residual + RMSNorm kernel，不是 HiSparse 的改动。MNNVL 在 #61989（2b85d9cb65，2026-10-17）成为单节点默认后，启动日志从 backend=trtllm 翻转为 backend=mnnvl，bisect 显示 f98ae6a9fd（10-17，trtllm）干净、21e09ea959（10-17，mnnvl）开始崩溃。具体缺陷在 LamportFlags::ctaArrive()（cluster 路径，trtllm_mnnvl_allreduce.cuh）：每个线程都在 cluster barrier 上 arrive，但只有一个 warp 等待；随后 RMSNorm 归约写入 peer CTA 的 shared memory 并再次 arrive，破坏了“每线程每阶段只 arrive 一次”的规则，使 CTA 可能在 peer 仍写入其 DSMEM 时退出。该问题只在 HiSparse 因 GPU 页压力向 host spill 时暴露，可能与 HiSparse 的并发 copy-stream kernel 加上 PDL 提前 launch 让 CTA 间漂移足够大有关；尚无独立 reproducer 确认这一时序机制。

环境排查

确认 vLLM 版本/commit：崩溃版本为 65faf4efa0（2026-10-28），干净对照组为 4a30c4cad0（2026-10-05）。
在启动日志中查找 Initialized FlashInfer Allreduce norm fusion workspace with backend=...，确认是 mnnvl 还是 trtllm。
确认单节点还是多节点 TP 组：多节点组无法使用本 workaround。
确认是否启用 CUDA graphs 与 PDL：--enforce-eager 下同工作负载可完成；崩溃需要 CUDA graphs。注意 Issue 中 eager 验证是在另一款 DSA 模型上做的，GLM 上尚未验证。
确认 HiSparse 是否确实进入 host spill（GPU KV 池是否被压小，或并发 × 上下文是否超过 GPU pool）；默认 102 GiB 全池 HiSparse 与不开 HiSparse 的对照均干净。
版本参考：torch 2.14.0+cu130、flashinfer-python 0.7.2.post1、driver 595.91.07。

解决步骤

在启动 vLLM 服务前导出 VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm，然后按原命令（含 HiSparseConnector、–kv-cache-memory-bytes 等）重启 vllm serve。
检查启动日志中 FlashInfer Allreduce backend 已显示为 trtllm，而非 mnnvl。
用原 vllm bench serve 命令复跑同一 16 × 32k/4k 负载，观察是否在第一个 wave 的 decode 阶段崩溃。
如需继续使用 MNNVL（例如为了其性能收益），等待 flashinfer-ai/flashinfer#7782 修复合入后升级 flashinfer-python；Issue 中“MNNVL + 修复”复跑 8/8 waves 干净。
可优先尝试的方向（尚未在 GLM 上逐一确认）：仅对融合 kernel 关闭 PDL（Issue 中 launch_with_pdl=False 只作用于 fused kernels 时干净）；根因确认前不建议作为长期方案。
多节点 TP 组无法使用 trtllm 回退，需关注 FlashInfer 修复进度；暂时可减小并发或上下文以避开 host spill 压力，但这是规避而非修复。

验证方法

用相同 vllm bench serve 参数（16 × 32768/4096、并发 16、seeds 42–45）连续跑多个 wave，确认启动后约 30 s 的 prefill 完成节点之后不再出现 CUDA error: unspecified launch failure 和 sample_tokens timed out，每个请求生成满 4096 个输出 token（而非几十 token 即停），引擎在整个 wave 内保持存活。Issue 中 trtllm 回退的验证结果为 60 s 的 16 路 decode 无崩溃，MNNVL + 修复为 8/8 waves 干净。