RDNA3 ComfyUI OOM 血泪排障：VAE 显存 17GB → 1.7GB 的修复之旅

abaalei

日期: 2026-06-23 | 硬件: X99-6PLUS (Xeon E5-2682v4 × 2) + XFX RX 7900 XTX 24GB + Sapphire RX 7900 XTX 24GB + RTX 3080 Ti
软件: ComfyUI 0.24.1 + ROCm 7.2.0 + PyTorch 2.12.0+rocm7.2
工作流: ZImageTEModel + Lumina2 + VAE + CLIP + 正负面提示词

先说结论

RDNA3 (7900 XTX) 上 ComfyUI 会静默禁用 MIOpen（AMD 的 cuDNN 等价物），导致 VAE 解码显存占用从正常的 1.7GB 暴涨到 17GB。 单卡 24GB 很快就被吃光，任何带 VAE 的工作流都会 OOM。

修复只需要一行环境变量：

export COMFYUI_ENABLE_MIOPEN=1

背景

241 服务器（双 7900 XTX + 3080 Ti）同时跑两个服务：

Qwen3.6-27B 推理 → Sapphire Pulse (HIP 0)
ComfyUI 生图 → XFX MERC (HIP 1)

之前 ComfyUI 一直能正常工作，突然就不行了——加载工作流到采样阶段就 hipErrorOutOfMemory。

我们用 rocm-smi 检查：XFX 显存始终只有 26MB，模型根本没加载进去。

排障过程（走了哪些弯路）

弯路 1：expandable_segments

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

GitHub 上很多人说这能解决 ROCm 显存碎片问题。加上去，重启——还是 OOM。

根本原因：这不是显存碎片的问题，是 VAE 本身就在吃 17GB。

弯路 2：lowvram / normalvram

试了 --lowvram、--normal-vram（参数名最初还写错了，写成 --normalvram），全被用户否决——之前不加这些参数时 ComfyUI 能跑，说明问题不在显存管理模式。

弯路 3：怀疑 MultiGPU 插件

ComfyUI 日志里出现了大量 MultiGPU Core Patching 信息：

[MultiGPU Core Patching] Patching mm.soft_empty_cache...
[MultiGPU DEBUG] Initial current_device: cuda:0

以为是插件在跨卡分配模型。但用户确认之前同样插件配置下是正常的。

弯路 4：怀疑环境变量没传对

export TORCH_AMD_CUDNN_ENABLED=1

这个变量没效果——ComfyUI 源码里根本不检查它。

根因：ComfyUI 强制关闭 RDNA3 的 MIOpen

GitHub Issue #10460 确认了这个问题。

ComfyUI 在检测到 RDNA3 (gfx1100) 时，默认会强制关闭 cudnn（MIOpen）：

# ComfyUI 源码逻辑
if is_rdna3:
    torch.backends.cudnn.enabled = False  # VAE 显存从 1.7GB → 17GB 🚨

对比：

cudnn 状态	VAE decode 显存	能否运行 24GB 工作流
False	17.35 GB	立刻 OOM
True	1.74 GB	余量充裕

17GB vs 1.7GB——整整 10 倍差距。

为什么 ComfyUI 要关 cudnn？

因为早期的 ROCm MIOpen 在 RDNA3 上有精度问题和崩溃 bug，ComfyUI 为了稳定性一刀切禁用了它。但后来的 ROCm 7.2 已经修复了这些问题——只是 ComfyUI 还没来得及更新检测逻辑。

修复：正确环境变量

第一次试了 TORCH_AMD_CUDNN_ENABLED=1——ComfyUI 不认这个变量。ComfyUI 检查的是 COMFYUI_ENABLE_MIOPEN=1。

# 正确 ✅
export COMFYUI_ENABLE_MIOPEN=1

# 错误 ❌
export TORCH_AMD_CUDNN_ENABLED=1

还有一个坑：必须重启进程

第一次我改完环境变量、更新了启动脚本，跟用户说"修好了"——用户一跑还是 OOM。

原因：我只是改了文件，没有 kill 旧 ComfyUI 进程。 环境变量只在新进程启动时读取，旧进程还是在用 cudnn 禁用的状态重启。

正确的流程：

# 1. 杀掉旧进程
pkill -f "python.*main.py.*8188"

# 2. 确保环境变量
export HIP_VISIBLE_DEVICES=1
export COMFYUI_ENABLE_MIOPEN=1
export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

# 3. 启动新进程
nohup python main.py --listen 0.0.0.0 --port 8188 > comfyui.log 2>&1 &

完整对比

指标	修复前	修复后	变化
VAE decode 显存	17.35 GB	1.74 GB	-90%
XFX 模型加载	始终 26MB	正常加载	—
能否跑 ZImageTE+Lumina2	OOM	流畅运行	—
cudnn.enabled	False	True	—
环境变量	无	`COMFYUI_ENABLE_MIOPEN=1`	—

经验教训

VAE 是显存黑洞。 如果 ComfyUI 一直 OOM，先查 VAE 显存占用。正常 VAE decode 应该只吃 1-2GB，不是 17GB。
环境变量名要查源码。 TORCH_AMD_CUDNN_ENABLED 看起来合理但 ComfyUI 不认——它有自己的变量 COMFYUI_ENABLE_MIOPEN。
改了配置必须重启进程。 修改启动脚本 ≠ 服务已应用。这是基本的运维常识——我在这翻了车。
RDNA3 的 cudnn 禁用是历史遗留。 早期 MIOpen 确实有问题，但 ROCm 7.2+ 已经稳定。如果你的 ROCm 版本足够新，可以放心启用。

对 241 的实用影响

修复后，start-comfyui-with-qwen.sh 脚本已固化以下配置：

ComfyUI → XFX MERC (HIP 1)
  COMFYUI_ENABLE_MIOPEN=1   ← 关键修复
  HIP_VISIBLE_DEVICES=1
  PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

Qwen → Sapphire Pulse (HIP 0)
  模式 B (IQ4_XS, 128K)

有类似问题的朋友可以试试。你们在 RDNA3 上遇到过其他 cudnn 相关的坑吗？

terry

没遇到过，但是看起来很厉害的帖子，置顶观摩下。

williamlouis

没时间试试。先留个脚印。后期尝试下。

koala

我让AI改，貌似改完连z-image都跑不完

abaalei

@koala
这可太正常了，我第一天从手动跑comfyui 切换到用hermes自动跑，调试了一天，跑了50块的flash，也就将将能跑起来而已，陆续再优化了5天，才从PPT 文生图凑出来的视频，改进到LTX2.3的视频，然后现在用WAN2.2 并且还在继续优化。无底洞来的

joe1900

3显卡？还混装amd和nvidia？驱动环境折腾吗？

抡锤者