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

快速结论：该报错通常发生在 vLLM 引擎初始化阶段，当同时启用 LoRA 且 max_model_len 超过约 87383 时触发（不同模型阈值不同，取决于 kernel 内 int32 偏移量是否溢出）。优先将 max_model_len 调低至安全阈值以下，或升级到包含修复补丁的版本。

适用环境：已确认受影响的环境包括 vLLM 0.27.1 和 0.22.1，搭配 triton 3.7.1、torch 2.13.0+cu130、flashinfer-python 0.6.16.post3，在 RTX PRO 6000 Blackwell (SM120) 和 H100 80GB (SM90) 上均复现。另外在 RTX 5880 Ada (SM89, 48GB) 上做过 kernel 级复现。

最快修复方案：暂无确认的一步修复方案。Issue 中验证的修复已提交 PR（#53034 和 #53038），需升级到包含修复的版本；短期规避可调低 max_model_len。

注意事项：由于涉及内核级 int32 溢出的根本修复，直接在配置里修改可能无法彻底解决。在升级前，如果业务必须使用长上下文，建议先调低 max_model_len 至安全值以下（对于 Gemma 4 E2B 为 87382）。

问题场景

用户在使用 vLLM 加载 Gemma 4 E2B 模型并开启 enable_lora=True 时，在 LLM(...) 构造函数中触发崩溃。问题在引擎初始化阶段即出现，无需发送任何请求或加载 LoRA 适配器即可复现。当关闭 chunked prefill 后，max_num_batched_tokens 等于 max_model_len，profile run 会在完整长度下执行，从而触发报错。

报错原文

RuntimeError: Triton Error [CUDA]: an illegal memory access was encountered
RuntimeError: Engine core initialization failed.

设置 CUDA_LAUNCH_BLOCKING=1 后可定位到具体 kernel：

File "vllm/lora/ops/triton_ops/lora_expand_op.py", line 248, in _lora_expand
  _lora_expand_kernel[grid](...)
File "triton/runtime/jit.py", line 761, in run
RuntimeError: Triton Error [CUDA]: an illegal memory access was encountered

原因分析

根本原因已定位：punica 系列 kernel 中的 ram（token 行索引）是 int32 类型，在计算地址时，行字节偏移发生 32 位整数溢出。对于 Gemma 4 E2B，intermediate_size 为 6144，合并后的 gate_up activation 行包含 2 * 6144 = 12288 个 bf16 元素，即 24576 字节。当 (num_tokens - 1) * 24576 >= 2**31 时触发崩溃，换算得到阈值正好是 87383 token。

同类问题还存在于 lora_shrink kernel（#48862），区别在于 lora_shrink 的溢出发生在输入指针上，导致静默返回错误值而非直接崩溃，更隐蔽。另外，溢出点还包括 FP8 scale 指针以及 slice_id / lora_index 的标量基地址偏移，这些位置早前的修复（#39585）均未覆盖。

环境排查

确认 vLLM 版本是否为 0.27.1 或 0.22.1（其他版本也可能受影响，但未验证）
确认是否启用了 enable_lora=True——这是必要条件，无 LoRA 配置下相同 max_model_len 不会崩溃
排查 max_model_len 是否已接近或超过 87383（不同模型因 intermediate_size 不同，阈值会变化）
此问题与后端无关，FLASH_ATTN、TRITON_ATTN、FLASHINFER 均会触发，可排除是 attention 的问题
这不是显存不足：同一长度下关闭 LoRA 可正常运行，且降低 gpu_memory_utilization 不影响崩溃结果

解决步骤

短期规避（可优先尝试）：将 max_model_len 调低到安全阈值以下。对于 Gemma 4 E2B，87382 仍可正常初始化，87383 即崩溃。具体安全值需按模型计算公式验证：(num_tokens - 1) * row_bytes < 2**31。
升级修复版本：跟踪 PR #53034（针对 do_expand_kernel 输出存储和 do_shrink_kernel 输入加载处将行索引转换为 int64）和 PR #53038（将 slice_id / lora_id / ram 在四个 punica kernel 定义处全部转为 int64，覆盖面更完整），等待合并后升级 vLLM。当前代码主线（main 分支）在该修复提交前仍存在此问题。
检查是否命中同类溢出但表现为静默错误：如果暂时无法升级且必须使用超长上下文，建议对启用 LoRA 的输出结果做抽样校验，因 lora_shrink 的溢出不会报错而是返回错误值。
确认崩溃方式：如果报错栈不是指向 lora_expand 而是出现在 torch.cuda.synchronize() 的 Inductor autotuner 内部，那是异步执行下的假象，实际错误源仍是 LoRA kernel，可设置 CUDA_LAUNCH_BLOCKING=1 定位真实故障点。

验证方法

以 max_model_len=87383 运行最小复现脚本，确认引擎可正常初始化并打印 engine init ok；再以 max_model_len=100001 做压测验证长上下文场景。升级修复版本后，建议同时验证 lora_shrink 路径（即实际发送短请求执行 LoRA 推理），确认没有静默返回错误值的回归。