CUDA out of memory

快速结论：在 vLLM 中，Model Runner V2 作为稠密模型默认执行器时，`profile_cudagraph_memory()` 返回 0，导致 CUDA graph 内存未预留在 KV cache 之外，`capture_model()` 阶段出现 OOM。优先排查方式：确认是否启用了 Model Runner V2，并检查日志中 `profile_cudagraph_memory()` 是否为 0。

适用环境：vLLM（Model Runner V2）；Tensor Parallel=4、Expert Parallel 启用；已确认操作系统 Ubuntu 24.04.3 LTS，Python 3.12.3，PyTorch 2.11.0+cu130，CUDA 13.0.88，NVIDIA 驱动 580.159.03，GPU 为 NVIDIA L40S（8 卡）；另有 B200 硬件复现记录。

最快修复方案：暂无确认的一步修复方案。已验证的临时规避手段是设置环境变量 VLLM_USE_V2_MODEL_RUNNER=0 回退到 Model Runner V1；但该方案在 DeepSeek V4 上不可用（V1 拒绝为该模型启用 piecewise CUDA graphs）。社区提供的补丁 PR #49233 在复现环境中验证有效，需等待上游合入。

注意事项：环境变量回退方案仅适用于未被 V1 限制的模型；补丁方案依赖上游 PR 合入，且合入位置可能与 #47363 相关，存在冲突可能性。在官方修复发布前，也可尝试关闭 CUDA graph 或降低 KV cache 预留比例作为缓解，但这些做法未在 Issue 中被明确验证。

问题场景

当用户在 vLLM 中加载稠密模型（如 DeepSeek-V4-Pro 861B FP8，TP=4，EP=true）并启动推理时，Model Runner V2 作为默认执行器接管。在 capture_model() 阶段触发 CUDA out of memory。Issue 报告显示 profile_cudagraph_memory() 返回 0，即 CUDA graph 内存预留被跳过，KV cache 实际多出约 15 GiB 的隐形占用，最终在 FP4 MoE workspace 分配或引擎启动超时处暴露为 OOM。

报错原文

CUDA out of memory. Tried to allocate ... MiB (GPU 0; ... GiB total capacity; ... GiB already allocated; ... GiB reserved in total by PyTorch)
During: capture_model()

原因分析

可能原因：Model Runner V2（自某次默认切换后成为稠密模型默认路径）在内存规划阶段没有正确调用或执行 profile_cudagraph_memory() 所对应的 CUDA graph 内存预留逻辑，导致该函数返回 0。这使 KV cache 的预留大小未扣除 CUDA graph 执行时实际占用的显存，总显存超出物理限额。Issue 中通过二分定位将引发该行为的变更指向 #51768，该变更是将 DeepSeek V4 纳入 Model Runner V2 的提交。补丁 #49233 在复现环境下验证可以修复此问题，但尚未合入上游。

环境排查

确认 vLLM 版本是否为包含 Model Runner V2 默认启用及 #51768 变更的近期版本。
确认是否已设置 VLLM_USE_V2_MODEL_RUNNER 环境变量，若为 0 则不会触发本问题。
检查日志中 profile_cudagraph_memory() 的输出是否为 0。
确认模型是否为稠密模型（如 DeepSeek V4 系列）；MoE 模型若被 MRv2 接管也可能触发。
确认为 CUDA 12+ 环境；PyTorch 2.11.0+cu130、CUDA 13.0 为该 Issue 已验证的版本组合。
注意 VLLM_USE_V2_MODEL_RUNNER=0 回退方案对 DeepSeek V4 不生效（V1 拒绝 piecewise CUDA graphs）。

解决步骤

快速验证是否因 MRv2 引起：设置 VLLM_USE_V2_MODEL_RUNNER=0 后重启服务；若不再 OOM，则确认为 MRv2 的 CUDA graph 内存预留缺陷。注意该方案仅适用于 V1 未限制的模型。
检查 vLLM 上游是否已合入修复 PR #49233 或等价补丁；若已合入，升级 vLLM 到包含该补丁的版本。
若无法升级，可尝试手动应用 PR #49233 的补丁并重新构建，或等待社区发布包含修复的版本；该补丁在 Issue 复现环境中（B200 硬件、DeepSeek-V4-Pro 861B FP8）已验证有效。
若上述方案均不可用，作为临时缓解可尝试：减少 KV cache 预留比例（如通过 --max-model-len 或 --gpu-memory-utilization 降低预留上限），或禁用 CUDA graph（需确认你的 vLLM 版本是否支持该开关）。这两种做法未在 Issue 中验证，仅作为绕过 OOM 的备选。

验证方法

启动服务或执行推理，观察启动日志中 profile_cudagraph_memory() 是否返回非 0 值（正常应返回 CUDA graph 预计占用的显存字节数）；确认 capture_model() 阶段不再出现 CUDA out of memory。若使用 PR #49233 构建，应看到 KV cache 预留量减少约 15 GiB（与 CUDA graph footprint 匹配）并完成正常启动。