RuntimeError: launch_gdn_decode_post_conv_mtp

快速结论：该报错发生在 NVIDIA Jetson Thor（SM110a）上使用 vLLM 0.26.1rc1 及之后 nightly 镜像，对带 MTP 投机解码的 GDN 模型（如 Qwen3.8-27B-NVFP4）进行首次 decode 时。优先排查 vLLM 构建是否已包含 #53835 修复（向 FUSED_GDN_DECODE_ARCHS 添加 11.0f），或设置环境变量 VLLM_GDN_DECODE_KERNEL=triton 强制回退 Triton 路径。

适用环境：NVIDIA Jetson AGX Thor（aarch64，计算能力 11.0 / sm_110a）；JetPack 7.1 + CUDA 13；vLLM 0.26.1rc1.dev1102+ge9d1398d9；PyTorch 2.13.0+cu130；镜像 vllm/vllm-openai:nightly-aarch64（图像 ID f559398005998c）。模型 RadixArk/Qwen3.8-27B-NVFP4。

最快修复方案：无重建的临时方案：启动服务前设置 VLLM_GDN_DECODE_KERNEL=triton 强制使用 Triton 路径（Issue 中确认可正常运行 MTP）。最终修复需等待 PR #53835 合入（一行改动：在 CMakeLists.txt 的 FUSED_GDN_DECODE_ARCHS 中添加 11.0f）。

注意事项：使用 Triton 回退会导致 MTP 场景 decode 吞吐量下降约 14–17%（Issue 实测数据），仅作临时替代；最终需要升级到包含 #53835 修复的 vLLM 版本以恢复 CUDA 内核路径。

问题场景

在 Jetson Thor（SM110a）上使用 vllm/vllm-openai:nightly-aarch64 镜像运行带 MTP（Multi-Token Prediction）投机解码的 GDN 混合线性注意力模型（如 RadixArk/Qwen3.8-27B-NVFP4），服务启动正常（日志显示 GDN decode kernel: cuda），但当发送第一个对话请求、进入首次 decode 步骤时，EngineCore 崩溃并返回上述错误。移除 --speculative-config 后，同一命令可正常运行。

报错原文

RuntimeError: launch_gdn_decode_post_conv_mtp,
/workspace/csrc/libtorch_stable/gdn/fused_gdn_decode_kernel.cu:412,
GDN decode MTP post-conv kernel launch failed: no kernel image is available for execution on the device

原因分析

可能原因：vLLM 的 CUDA 能力守卫只检查符号是否存在（hasattr(torch.ops._C, "fused_gdn_decode_post_conv_mtp")）以及设备能力是否满足最低要求（has_device_capability(80)），并未验证实际编译生成的 cubin 是否覆盖目标架构（sm_110a）。由于操作绑定（op binding）存在，设备的计算能力 11.0 ≥ 8.0，所以 vLLM 自动选择了融合 CUDA 路径，但该 wheel 的 cubin 集合只包含 sm_121（DGX Spark/GB10）而不包含 sm_110a（Jetson Thor），导致内核启动失败。上述错误只会影响 fused_gdn_decode_post_conv_mtp 变体；普通（非 MTP）的融合 GDN decode 路径不受影响。

环境排查

确认目标设备是否为 Jetson Thor（SM110a）。注意：同样镜像在 DGX Spark（GB10, SM121）上可正常运行，说明问题并非 Blackwell 架构全系存在，而是缺少 sm_110a 的 cubin 支持。
检查 vLLM 构建提交：运行 docker inspect <image> | grep VLLM_BUILD_COMMIT，确认构建是否包含修复 PR #53835（其将 11.0f 添加到 CMakeLists.txt 的 FUSED_GDN_DECODE_ARCHS 中）。
对比镜像：Issue 报告中提到旧 nightly 镜像（ID c3f199e54a26）无此问题，而新镜像（ID 1891ada1256a 或 f559398005998c）会出现此错误。

解决步骤

临时方案（免重建）：设置环境变量 VLLM_GDN_DECODE_KERNEL=triton，强制回退到周边代码已支持的 Triton 路径。启动命令示例：
```
docker run -e VLLM_GDN_DECODE_KERNEL=triton ...（其余命令不变）
```
永久修复：升级到已合入 PR #53835 的 vLLM 版本（该 PR 在 CMakeLists.txt 的 FUSED_GDN_DECODE_ARCHS 中新增 11.0f），或在本地从包含该修复的源码重新构建 wheel。
诊断确认：如果需要在当前镜像上精确定位引起问题的提交，可执行 docker inspect <image> | grep VLLM_BUILD_COMMIT 获取构建提交哈希，与修复合入前的 6cbb3c154（其 FUSED_GDN_DECODE_ARCHS 仍为 "8.0;8.6;8.9;9.0a;10.0f;12.0f"）进行比对。

验证方法

重新启动服务后，向 /v1/chat/completions 端点发送测试请求，确认不再返回 500 错误、EngineCore 不崩溃。随后检查启动日志，确认 GDN decode kernel 选用的路径是否符合预期（设置 VLLM_GDN_DECODE_KERNEL=triton 后应显示 Triton 路径）。如需完整验证，可在 Thor 设备上对 PR #53835 进行端到端构建测试（Issue 中已确认其作者在 Thor 上验证通过）。