RuntimeError: Triton Error [CUDA]: an illegal memory access was encountered

快速结论：该报错通常出现在 vLLM 以张量/流水线并行方式加载 Qwen3 系列 GDN hybrid MoE 模型、并开启 prefix caching 或 CUDA graphs 运行时的前向计算阶段，表现为 Triton/CUDA kernel 非法显存访问（伴随 Xid 31）。优先排查流水线阶段划分（PP partition）、prefix caching 与 CUDA graphs / torch.compile 的组合，此外还要排查 GDN hybrid 模型里状态（KV/状态缓存）的绑定是否正确。

适用环境：Ubuntu 24.04.3 LTS（x86_64）；Python 3.12.3；PyTorch 2.13.0+cu130；CUDA 运行时 13.0.88；vLLM 容器镜像 vllm/vllm-openai:v0.32.0（问题在 v0.28.0 之后出现，v0.31.0、v0.32.0 均可复现）；PP=3，且运行在 sm_86 级别 GPU 上。Issue 中未给出具体的 GPU 型号和驱动版本。

最快修复方案：暂无确认的一步修复方案。Issue 关闭时仍未定位到根因，也没有合入的补丁；目前只有经过验证的诊断方向：开启 --enforce-eager 并设置 CUDA_LAUNCH_BLOCKING=1 后，故障不再出现，但这只是诊断性对照，并不是推荐的长期配置。

注意事项：用 24,24,16 替换 23,23,18 这一做法在 Issue 测试中仍然报错，因此它不属于有效 workaround，只能作为对比诊断。改用 --enforce-eager 会关闭 torch.compile 与 CUDA graphs，可能导致推理性能明显下降，因此只适合排查或临时规避。由于报错堆栈是异步产生的，堆栈里报告的 kernel 不一定是真正出错的 kernel，需要结合 Xid 日志中的 GPU 编号一起查看。

问题场景

用户用 vLLM 加载 Qwen3.8-27B（GDN hybrid MoE 模型），配置 PP=3，在 sm_86 GPU 上以 V1 model runner（VLLM_USE_V2_MODEL_RUNNER=0）提供服务。系统运行在 v0.32.0 时，报错表现为两种情况：

开启 prefix caching 时，约 25k~27.5k token 的冷 prefill（合成、随机 session ID、0% 前缀命中）在请求开始约 5 秒后触发 CUDA 非法访存，PP1 最先失败并伴随对应 GPU 的 Xid；短提示词（如 2+2=?）仍能正常返回。
关闭 prefix caching 时，输出变成乱码（gibberish output）。

该问题自 v0.28.0 之后出现，v0.31.0、v0.32.0、V0 与 V1 两种 model runner 均可复现。

报错原文

RuntimeError: Triton Error [CUDA]: an illegal memory access was encountered

(Worker_PP1) File "vllm/v1/worker/gpu_model_runner.py", line 3645, in _model_forward
(Worker_PP1) File "vllm/compilation/cuda_graph.py", line 256, in __call__
(Worker_PP1) File "vllm/model_executor/models/qwen3_5.py", line 592, in forward
(Worker_PP1) File "vllm/model_executor/models/qwen3_next.py", line 698, in forward
(Worker_PP1) File "vllm/compilation/caching.py", line 224, in __call__
(Worker_PP1) File "vllm/compilation/cuda_graph.py", line 256, in __call__
(Worker_PP1) File "vllm/compilation/piecewise_backend.py", line 379, in __call__
(Worker_PP1) File "torch/_inductor/output_code.py", line 763, in __call__
(Worker_PP1) File ".../inductor_cache/ls/cls424qxc6cm....py", line 1195, in call

主机侧 GPU 驱动报出的对应错误为 Xid 31（GPU memory page fault）。

原因分析

Issue 中维护者明确说明尚未确认根因，因此以下均为可能原因，而非结论：

PP 阶段划分与 GDN hybrid 的状态和缓存绑定不一致：模型每 4 层重复出现 3 个 GDN 层加 1 个 full-attention 层。按 23,23,18 切分（64 层）会切断这种 4 层周期，可能使不同 PP stage 之间状态索引或缓存视图的“绑定”出错，导致长时间 prefill 时越界访问。维护者在 CPU 上用简化 cache spec 对比了 23,23,18、默认划分与 24,24,16，认为分组和投影函数对各层与 group 身份的处理是正确的，但这只是 CPU 侧的检查，不能确认 GPU 上的状态绑定是否正确。
编译路径与状态 kernel 的交互问题：开启 --enforce-eager（同时关闭 torch.compile 与 CUDA graphs）后，故障无法复现，说明问题更可能出在编译路径和 CUDA graphs 与状态 kernel 的组合上；但堆栈是异步的，无法确认真正出错的是哪个 kernelis。
prefix caching 路径与 KV/状态缓存管理的回归：关闭 prefix caching 时输出乱码、开启时非法访存，这种差异指向 v0.28.0 之后与 kv-cache-manager 相关、并影响 GDN 状态处理的变更。

环境排查

确认 vLLM 版本是否在 v0.28.0 之后（v0.31.0、v0.32.0 已知会复现）；可对比 v0.28.0 之前的行为作为回归判定基线。
确认 model runner：Issue 中同时记录了 V0 与 V1 均可复现，V1 下用 VLLM_USE_V2_MODEL_RUNNER=0 复现。
确认 VLLM_PP_LAYER_PARTITION 设置（Issue 使用 23,23,18）、PP 数（3）、是否开启 prefix caching。
确认 PyTorch 2.13.0+cu130、CUDA 13.0.88、Python 3.12.3 与镜像 vllm/vllm-openai:v0.32.0 一致。
确认 GPU 架构为 sm_86，并查看 GPU 型号、驱动版本与 Xid 日志中的 GPU 编号是否对应最先失败的 PP rank。
确认 KV cache 容量是否足够（Issue 中 23,23,18 为 370,617 tokens，24,24,16 为 340,485 tokens），避免把 OOM 误判为同一故障。

解决步骤

暂无已验证的根治方案。以下为 Issue 中实际执行过、可用于定位问题的步骤（可优先尝试用于确认问题范围）：

保持原配置（prefix caching 开启、PP partition 23,23,18、编译与 CUDA graphs 开启），用约 25k~27.5k token 的合成冷 prefill（随机 session ID，确保 0% 前缀命中）复现故障，并记录首个失败的 PP rank 与对应的 Xid。
诊断对照组一：保持 partition 23,23,18 与 prefix caching 开启，追加 --enforce-eager 并设置环境变量 CUDA_LAUNCH_BLOCKING=1。Issue 中该组短提示词 3/3 正确，27,525 token 冷 prefill 无故障且输出正确（PASS），这说明故障与编译/CUDA graphs 路径相关，但不能据此认为问题已修复。
诊断对照组二：保持原执行模式（编译 + CUDA graphs），仅把 partition 改为 24,24,16。Issue 中该组短提示词仍正确，但冷 prefill 在请求约 5 秒后仍触发非法访存，PP1 最先失败并伴随 Xid（FAIL），说明按模型 4 层周期对齐切分无法规避该问题。
若需要临时稳定运行，可考虑使用第 2 步的 eager 配置作为规避手段，但需接受性能损失，并持续关注上游修复；该做法未被维护者确认为正式 workaround。

验证方法

复现脚本建议同时包含两类请求：一是短确定性提示词（如 2+2=?，temperature 0，跑 3 次），确认全部输出 2 + 2 = 4；二是约 25k 以上 token 的合成冷 prefill（随机 session ID，确认 0% 前缀命中），让它从正文中抽取一条已知记录并核对内容。若长时间 prefill 完成、输出正确且各 PP rank 均无 Xid 31 / illegal memory access，则视为该配置下问题未复现；由于根因未确认，不建议把任何单一配置的通过当作全局修复。