[Bug][DCP] NVIDIA DeepSeek-V3.2 / GLM-5.2 fused attention bypasses DCP handling

快速结论：该报错发生在 vLLM 使用 NVIDIA DeepSeek-V3.2 或 GLM-5.2 模型并开启纯 DCP（Decode Context Parallelism，TP4+DCP4）时，fused attention 路径绕过 DCP 处理导致输出为重复乱码（如 locklocklock...）。优先排查 deepseek_v32/common/kernels.py 中 slot_mapping < 0 时的提前返回，以及 deepseek_v32/attention.py 中 query head 跨 rank 合并是否被 use_pcp 条件遮蔽。

适用环境：vLLM（main 分支，截至 da329cc30 仍可复现）；NVIDIA H200（4xH200 验证）；模型 GLM-5.2-NVFP4；--tensor-parallel-size 4 --decode-context-parallel-size 4 --kv-cache-dtype fp8_ds_mla。

最快修复方案：暂无已合并到 main 且经过完整验证的一步修复方案。PR #50005 修复了两个正确性问题，但已过期需 rebase；社区分支 foraxe/vllm#1 将修复合入当前 main 后验证通过。可优先尝试：将 #50005 的改动 rebase 到当前 main 后自行构建，或跟踪 #50005 合入状态。

注意事项：#50005 仅修复正确性，不包含 Shared-DCP 性能优化。修复后 GLM-5.2 在长 prompt 下仍可能因 sparse_decode.h 无条件分配 fp32 o_accum（T=8192 时每 rank 每次调用约 2 GiB）而崩溃，该问题需额外引入 #53755 的修复。

问题场景

用户使用 vLLM 以 vllm serve nvidia/GLM-5.2-NVFP4 --tensor-parallel-size 4 --decode-context-parallel-size 4 --kv-cache-dtype fp8_ds_mla 启动服务，在无需投机解码（no speculative decoding）的 4xH200 环境中发起单个 greedy 请求。当 DCP=1 时输出正常，DCP=4 时输出变为重复 token 乱码。此外，issue 还报告了 DeepSeek-V3.2 / GLM-5.2 fused 路径在纯 DCP 下存在两处正确性缺陷，并在 GLM-5.3 上以超过一千 token 的 prompt（full prompt，除缓存 prefill 外）触发相同乱码。

报错原文

[Bug][DCP] NVIDIA DeepSeek-V3.2 / GLM-5.2 fused attention bypasses DCP handling

Observable regression: On unpatched main, query output remains zero because the kernel returns before query RMSNorm.

Repro: One greedy request: DCP=1 answers normally, DCP=4 emits repeated-token garbage (`locklocklock...`).

原因分析

可能原因是在 fused DeepSeek-V3.2 / GLM-5.2 的纯 DCP 路径上存在两处绕过 DCP 处理的实现缺陷：

1. vllm/models/deepseek_v32/common/kernels.py 在 query RMSNorm 之前检查 owner-local KV slot 有效性。当 slot_mapping < 0 时意味着 token 的 KV 条目由另一个 DCP rank 持有，但 kernel 直接提前返回，并未移除本 rank 的 query 贡献，导致 query 输出保持为零。

2. vllm/models/deepseek_v32/attention.py 仅对 PCP+DCP 路径执行 query head 收集以及部分输出/LSE 合并。纯 DCP 路径因此将 rank-local query heads 送入 owner-local KV 上的 sparse attention，从未执行 DCP rank 间所需的结果合并，最终输出重复 token 乱码。

环境排查

确认 vLLM 分支及 commit：main 分支 da329cc30（Aug 22）仍复现；确认文件路径是否为重构后的 deepseek_v32/attention.py 与 deepseek_v32/common/kernels.py（旧路径为 deepseek_v32/nvidia/{attention,kernels}.py）。
确认 GPU 环境：4xH200，TP4+DCP4；若在其它显卡（如 GB200）需额外验证 kernel 测试套件。
确认启动参数：--kv-cache-dtype fp8_ds_mla（GLM-5.2）与 --dcp-comm-backend ag_rs（GLM-5.3 场景）。
确认模型版本：GLM-5.2-NVFP4（issue 主体验证）、GLM-5.3（社区反馈同样触发，状态待修复）。
确认是否已应用 #50005：当前 main 未合入，需自行 rebase 或使用 foraxe/vllm#1 分支。
确认是否已包含 #53755 的修复：该修复避免 sparse_decode.h 在不需要 split workspace 时分配 o_accum 与 lse_accum，缺少该修复时长 prompt 仍会崩溃。

解决步骤

确认复现环境：在 4xH200 上使用 GLM-5.2-NVFP4 与 TP4/DCP4 启动 vLLM，发起单个 greedy 请求，观察 DCP=4 是否输出 locklocklock... 类乱码。
查看 vllm/models/deepseek_v32/common/kernels.py 中 fused kernel 的 early-return 逻辑：当 slot_mapping < 0 时当前实现跳过 query RMSNorm，需要移除该提前返回、让 RMSNorm 独立于 owner-local KV slot 有效性执行，同时保持负 slot 继续抑制 MLA 与 indexer KV-cache 写入。
检查 vllm/models/deepseek_v32/attention.py 中 query head 收集与 cross-rank LSE 合并是否被 use_pcp 条件包裹；若确认如此，需将纯 DCP 路径改为同样执行 query-head gather 与 partial output/LSE 合并，经由 DCP manager 完成跨 rank 结果合并。
获取 #50005（或 foraxe/vllm#1 分支）的补丁，将其 rebase 到当前 main（注意 8 月文件移动后的路径变更），重新构建 vLLM。
确认当前 main 已包含 #53755 的 workspace 修复；若基于旧 base，需一并引入该修复以避免长 prompt 时 o_accum 分配导致的崩溃。
使用原始复现命令重跑 greedy 请求，对比 DCP=1 与 DCP=4 的输出。
运行 kernel 级回归：tests/kernels/test_fused_deepseek_v32_norm_rope.py 应从未修复时的 1 失败变为 67 通过（GB200 上验证）。

验证方法

在相同硬件与参数下发起 deterministic greedy 请求，比较 DCP=1 与 DCP=4 的逐字节输出。修复后 DCP=4 的输出应与 DCP=1 完全一致（字节级相同）。同时运行 tests/kernels/test_fused_deepseek_v32_norm_rope.py 确认 67 项全部通过。注意：issue 明确说明尚未进行#50005+#53755 合并后的 GLM-5.2 DCP 长 prompt 端到端验证，该集成场景仍需要自行验证。