[Bug]: GLM-5（Sparse MLA / DSA 模型）无法在 sm80 GPU（A100/A800）上运行 — DeepGemm 硬依赖无 fallback

快速结论：该报错发生在尝试在 sm80 GPU（如 A100/A800）上运行 GLM-5 等使用 DeepSeek Sparse Attention (DSA) 的模型时。优先排查是否缺失三层关键修复：C++ 编译防护、Triton sparse MLA attention backend 注册，以及 DeepGemm 的 PyTorch fallback。

问题场景

用户在运行 vLLM (latest main, commit 1391378) 加载 ZhipuAI/GLM-5-FP8 模型时触发。环境为 8x NVIDIA A800-SXM4-80GB (sm80, Ampere)，PyTorch 2.7.0+cu126，CUDA 12.6。用户通过 vllm.entrypoints.openai.api_server 启动，配置了 --tensor-parallel-size 8、--trust-remote-code 等参数。

报错原文

# 多层报错，具体取决于缺失的修复层

# 层1: C++ 编译失败 (dsv3_fused_a_gemm)
# 无明确单行报错，编译时因 sm90+ 代码无条件编译导致失败。

# 层2: Attention backend 缺失
# RuntimeError: No sparse MLA attention backend available for sm80
# 或类似找不到 FLASHMLA_SPARSE 以外的 backend 错误。

# 层3: Indexer fallback 缺失
# 调用 DeepGemm 的 fp8_mqa_logits / fp8_paged_mqa_logits 时失败
# 报错类似: RuntimeError: DeepGemm is not supported on sm80
# 或直接因 DeepGemm 硬依赖而崩溃，即使包已安装，但架构不兼容。

原因分析

该问题并非单一原因，而是至少三个独立的 sm80 不兼容层叠加导致：

C++ 编译层：csrc/ops.h 和 csrc/torch_bindings.cpp 中的 dsv3_fused_a_gemm 函数无条件编译 sm90+ 代码，在 sm80 GPU 上编译时代码路径不通，需要添加 #ifdef ENABLE_DSV3_FUSED_A_GEMM 防护宏以跳过。
Attention backend 层：上游 vLLM 仅提供了 FLASHMLA_SPARSE backend，该 backend 限制在 sm90+（如 H100）。sm80 GPU 上完全没有可用的 sparse MLA attention backend，无法执行注意力计算。需要实现一个基于 Triton 的 backend（如 TRITON_MLA_SPARSE）并在 cuda.py 和 registry.py 中注册。
Indexer fallback 层：sparse_attn_indexer.py 中直接调用了 DeepGemm 的 fp8_mqa_logits / fp8_paged_mqa_logits，但没有先使用 is_deep_gemm_supported() 进行架构检查。即使 DeepGemm 包已安装，在 sm80 上也会因不兼容而崩溃。需要添加 PyTorch 原生 fallback 函数（如 fp8_mqa_logits_torch）。注意：应使用 is_deep_gemm_supported()（检查 sm90+ 架构），而非 has_deep_gemm()（仅检查包是否安装）。

重要修正：原始 Issue 描述仅提到层3的缺失，经全面测试后发现需要全部三层修复。

环境排查

vLLM 版本：latest main (commit 1391378) 或更新
PyTorch 版本：2.7.0+cu126（或 2.10 等，需测试兼容性）
CUDA 版本：12.8（或 12.6）
GPU 型号：NVIDIA A800-SXM4-80GB / A100 (sm80, Ampere)
模型：ZhipuAI/GLM-5-FP8 (744B total / 40B active, 256 experts, 78 layers, GlmMoeDsaForCausalLM)
启动参数：--tensor-parallel-size 8, --max-model-len 1024 或其他, --cpu-offload-gb 40, --gpu-memory-utilization 0.92 等
DeepGemm 安装状态：已安装但架构不兼容
注意：非 sparse MLA 路径（如 DeepSeek-V3）在 sm80 上通过 Triton MLA backend 工作正常，仅 sparse 变体受影响。

解决步骤

检查目前 vLLM 主分支的修复状态：
- PR #35271 已合入主分支，该 PR 仅处理 层3：Indexer fallback。它在 sparse_attn_indexer.py 中添加了 is_deep_gemm_supported() 防护和 PyTorch fallback 函数。
- 重要：仅合入主分支的代码不足够运行。用户测试发现，即使主分支已包含 PR #35271，GLM-5 在 A800 上仍然无法启动。原因在于缺少层1和层2的修复。
解决层1：C++ 编译防护（需手动打补丁或等待上游合并）：
- 在 csrc/ops.h 和 csrc/torch_bindings.cpp 中，将 dsv3_fused_a_gemm 相关的代码包裹在 #ifdef ENABLE_DSV3_FUSED_A_GEMM 预处理条件中，以在 sm80 架构上跳过编译。
- 可优先尝试此步骤作为临时方案。
解决层2：实现并注册 Triton Sparse MLA Backend（工程量较大，需开发或等待上游支持）：
- 创建三个新文件：triton_mla_sparse.py、triton_sparse_decode_attention.py、fp8_mqa_logits_fallback.py，提供完整的基于 Triton 的 sparse MLA attention 实现。
- 在 cuda.py 和 registry.py 中注册 TRITON_MLA_SPARSE backend 到优先级列表和枚举中。
- 注意：PoC 已在 8xA800 集群上测试通过，证实该方案可行。
验证层3的修复是否正确（主分支已包含，但需确认）：
- 检查 sparse_attn_indexer.py 中调用 DeepGemm 函数前是否有 is_deep_gemm_supported() 检查，并确认使用了 PyTorch fallback 函数而非直接 DeepGemm。
- 确保使用的是 is_deep_gemm_supported()（检查架构），而非 has_deep_gemm()（仅检查包安装）。

验证方法

使用以下命令启动服务，确认能成功加载模型并正常生成推理结果：

python -m vllm.entrypoints.openai.api_server \
  --model ZhipuAI/GLM-5-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 1024 \
  --cpu-offload-gb 40 \
  --gpu-memory-utilization 0.92 \
  --max-num-seqs 16 \
  --trust-remote-code \
  --enforce-eager \
  --port 8000

成功标准：
– 服务启动无报错
– 可进行基本对话、数学推理、代码生成和多轮对话测试
– 产出正确结果（与无 sparse 路径的模型结果对比，或基于已知正确输出验证）