[Bug]: Illegal CUDA memory access in flashinfer_trtllm MoE autotune on aarch64/Grace

快速结论：该报错发生在 aarch64（NVIDIA Grace/GB200）平台上，使用 --moe-backend flashinfer_trtllm 启动 vLLM 引擎初始化阶段，FlashInfer TRTLLM fused-MoE autotune 在 CUDA graph 捕获期间触发非法内存访问。优先排查平台架构兼容性，将 MoE 后端切换为 triton 可绕过问题。

适用环境：vLLM v0.23.0（vllm/vllm-openai:latest arm64 镜像）、aarch64 / NVIDIA Grace（B200/GB200）、Qwen/Qwen3.6-35B-A3B（bf16）、--moe-backend flashinfer_trtllm。

最快修复方案：暂无确认的一步修复方案。Issue 中验证有效的变通方法是改用 --moe-backend triton（或不指定让 vLLM 自动选择）。社区已提出修复 PR（在 has_flashinfer_trtllm_fused_moe() 中增加 aarch64 平台守卫），也提及设置 CUDA_LIB_PATH 环境变量的可能尝试方向，但均未在 Issue 中完全验证。

注意事项：平台守卫方案本质是绕过而非修复底层 FlashInfer 问题；Issue 提及该问题在 FlashInfer v0.6.16+ 后无法复现，升级 FlashInfer 可优先尝试。切换到 Triton 后端可能影响 MoE 推理性能。

问题场景

在 aarch64 / NVIDIA Grace（B200/GB200）硬件上，用户使用 vLLM v0.23.0 的 arm64 镜像（vllm/vllm-openai:latest）启动 Qwen/Qwen3.6-35B-A3B（bf16，混合 Mamba2/GatedDeltaNet + attention MoE 模型），并指定 --moe-backend flashinfer_trtllm。崩溃发生在 engine-core 初始化阶段：FlashInfer fused-MoE autotune 步骤在 CUDA graph 捕获期间执行 flashinfer::trtllm_bf16_moe 调优时触发非法内存访问。同一配置与镜像在 x86_64 平台可正常启动并服务。

报错原文

[Bug]: Illegal CUDA memory access in flashinfer_trtllm MoE autotune on aarch64/Grace
torch.AcceleratorError: CUDA error: an illegal memory access was encountered

原因分析

可能原因：FlashInfer 的 TRTLLM fused-MoE CUDA kernel（cubin）仅支持 x86_64 架构。vLLM 的 has_flashinfer_trtllm_fused_moe() 函数只检查 Python 符号是否存在，并未验证 cubin 是否能在 aarch64 上运行。在 Grace 平台上，_supports_current_device() 的三个守卫全部通过（is_cuda()、is_device_capability_family(100)（B200 为 SM100）、has_flashinfer_trtllm_fused_moe()），vLLM 因而选择 FLASHINFER_TRTLLM 后端，autotuner 对 trtllm_bf16_moe 触发 CUDA graph 捕获导致崩溃。

社区讨论还提到另一种可能：FlashInfer 的 JIT loader 在加载 libcudart 时硬编码了 x86_64 CUDA 路径（flashinfer/jit/__init__.py），若设置 CUDA_LIB_PATH 指向 aarch64 路径可缓解。

环境排查

确认操作系统架构是否为 aarch64（uname -m 或 platform.machine()）。
确认 GPU 型号及 Compute Capability：B200/GB200 对应 SM100。
确认 vLLM 版本（Issue 中为 v0.23.0）和镜像架构（须为 arm64 build）。
确认 FlashInfer 版本：Issue 提到 v0.6.16+ 后无法复现该问题。
确认是否指定了 --moe-backend flashinfer_trtllm（默认或不指定通常不会触发）。

解决步骤

优先尝试：移除 --moe-backend flashinfer_trtllm，改用 --moe-backend triton（或直接不指定，让 vLLM 自动选择）。这是 Issue 中唯一验证可正常启动并在 aarch64 上完成服务的方案。
可优先尝试：升级 FlashInfer 到 v0.6.16 或更高版本，Issue 反馈者确认新版不再复现该问题。
若需继续使用 flashinfer_trtllm，可尝试在启动命令前设置 CUDA_LIB_PATH=/usr/local/cuda/targets/aarch64-linux/lib/（社区建议的实验性方向，尚未在 Issue 中验证结果）。
等待官方修复合入。社区已提议在 vllm/utils/flashinfer.py 的 has_flashinfer_trtllm_fused_moe() 中增加 platform.machine() != "x86_64" 守卫，使 aarch64 平台自动跳过该后端并回退到 Triton。该 PR 仅为 workaround，底层问题仍在 FlashInfer。

验证方法

运行原始崩溃命令（保留 --moe-backend flashinfer_trtllm），确认 vLLM 能完成 engine-core 初始化并正常输出日志；或使用 --moe-backend triton 启动后通过 API 调用完成一次推理请求，确认服务正常。若采用平台守卫补丁，可通过日志确认 aarch64 上不再选择 FLASHINFER_TRTLLM 后端（会打印类似 “FlashInfer TRTLLM fused MoE unavailable on aarch64” 的 debug 信息）。