[Bug]: cuda_archs_loose_intersection drops plain “10.0” when TORCH_CUDA_ARCH_LIST also has “10.0a”, producing sm_100a-only kernels that fail

快速结论：报错为 no kernel image is available for execution on the device，通常发生在本机编译 vLLM 时：TORCH_CUDA_ARCH_LIST 同时包含 10.0 和 10.0a，cuda_archs_loose_intersection 会丢掉不带后缀的 10.0，导致内核只编译出 sm_100a，在 B300（CC 10.3）上无法加载。优先排查构建日志中的 CUDA_ARCHS 是否缺少 10.0。

适用环境：Issue 中已确认：CUDA 13.0.2、torch 2.11.0、vLLM v0.26.0（main 也能复现）、x86_64、RHEL 10.1、驱动 610.43.02、NVIDIA B300 SXM6（compute capability 10.3）；TORCH_CUDA_ARCH_LIST="7.5 8.0 8.6 8.7 8.9 9.0a 10.0 10.0a 12.0 12.1+PTX"。

最快修复方案：暂无确认的一步修复方案。Issue 中已关联修复 PR #56582：在目标列表同时请求纯架构时保留纯架构 SRC 条目，使 10.0 与 10.0a 都会生成；该修复随后在 B300 上验证重编 wheel 可正常加载。

注意事项：在修复进入所用版本前，临时从 TORCH_CUDA_ARCH_LIST 中移除 10.0a 或同步调整列表，属于可优先尝试的绕行方式，Issue 未明确验证；+PTX 按设计会被丢弃，因此不能依赖 PTX JIT 来规避缺少 sm_100 的问题。

问题场景

用户从源码构建 vLLM，构建时设置了包含 10.0 及其 a 后缀变体 10.0a 的 TORCH_CUDA_ARCH_LIST。构建完成后在 NVIDIA B300（CC 10.3）上启动服务并加载 openai/gpt-oss-20b 模型，在 FlashInfer 注意力后端执行 output.fill_(0) 时首次报错。受影响的 wheel 中 vllm/_C*.so 与 vllm/_moe_C*.so 只含 sm_100a，没有 sm_100、sm_100f、sm_103a。

报错原文

[Bug]: cuda_archs_loose_intersection drops plain "10.0" when TORCH_CUDA_ARCH_LIST also has "10.0a", producing sm_100a-only kernels that fail

File ".../vllm/v1/attention/backends/flashinfer.py", line 1706, in forward
    return output.fill_(0)
torch.AcceleratorError: CUDA error: no kernel image is available for execution on the device

# cuobjdump --list-elf vllm/_C_stable_libtorch.abi3.so
60 sm_100a   75 sm_120   54 sm_75   64 sm_80   44 sm_86   45 sm_87   50 sm_89   64 sm_90a   (0 sm_100)

原因分析

自 #38126（v0.19.0）起，cmake/utils.cmake 中的 cuda_archs_loose_intersection 存在去重逻辑问题：处理“对称”分支时，目标的 10.0a 会匹配到源列表的 10.0，输出 10.0a 并把 10.0 从源列表移除；随后处理目标的纯 10.0 时，源列表已没有主版本 10 的条目，于是被静默丢弃。最终全局 CUDA_ARCHS 为 7.5;8.0;8.6;8.7;8.9;9.0a;10.0a;12.0，缺少 10.0。

因此通用内核只编译出可在 CC 10.0（B200）加载的 sm_100a，在 CC 10.3 的 B300 上没有匹配的内核镜像。vLLM 自定义算子不检查启动错误，错误延后到下一次 torch 启动检查时才暴露。相同 TORCH_CUDA_ARCH_LIST 下 torch 自身会同时产出 sm_100 和 sm_100a，说明问题特定于 vLLM 的架构归一化逻辑。

环境排查

确认 Python 与 torch 版本（Issue 为 torch 2.11.0），以及 vLLM 版本（Issue 为 v0.26.0，main 也可复现）。
确认构建使用的 CUDA 版本为 13.0.2，编译机与运行 GPU 环境一致。
确认 TORCH_CUDA_ARCH_LIST 是否同时包含纯 10.0 和 10.0a，以及是否包含 12.1+PTX。
确认运行时显卡为 B300 SXM6、compute capability 10.3，驱动 610.43.02，系统 RHEL 10.1。
构建设置后检查 CMake 输出或构建日志中全局 CUDA_ARCHS 是否仍包含 10.0。

解决步骤

先确认 wheel 中的实际架构：对 vllm/_C_stable_libtorch.abi3.so 执行 cuobjdump --list-elf，查看是否存在 sm_100。Issue 中受影响 wheel 显示 60 sm_100a 且 0 sm_100。
如确认缺少 sm_100，升级到包含 #56582 修复的 vLLM 版本或源码提交；该修复会在目标同时请求纯架构时保留对应 SRC 条目，使 10.0 与 10.0a 均被输出。
如暂时无法升级，可优先尝试：在重新构建前调整 TORCH_CUDA_ARCH_LIST，避免同一主版本下同时出现纯架构与 a 后缀变体，或改用不触发该丢弃路径的列表；此绕行 Issue 未明确验证。
调整架构列表后清理构建缓存并完整重编 vLLM，确保 _C、_moe_C 与 cumem 相关内核均按新列表重新生成。

验证方法

重新构建后再次对 vllm/_C_stable_libtorch.abi3.so 执行 cuobjdump --list-elf，确认输出中包含 sm_100（与 sm_100a 并存），而不再只有 sm_100a。随后在 B300 上启动 openai/gpt-oss-20b，确认不再出现 CUDA error: no kernel image is available for execution on the device。