[Windows ROCm multi-GPU][DynamicVRAM] retained ModelVBAR reservation after full unload causes ~38 GB private-memory plateau

快速结论：在 Windows + ROCm 多卡环境启用 DynamicVRAM 并走到模型“完全卸载”路径后，若出现 [Windows ROCm multi-GPU][DynamicVRAM] retained ModelVBAR reservation after full unload causes ~38 GB private-memory plateau 这类高私有内存驻留，优先怀疑 AMD ROCm CLR/HIP 的 VMM 行为，而不是 ComfyUI 的显存释放逻辑本身。

适用环境：Windows 11；AMD Radeon RX 9070 XT ×2（gfx1201）；PyTorch 2.13.0+rocm10.0.0；ROCm 10.0.0；ComfyUI 0.34.0；comfy-aimdo 0.4.15；通过 --cuda-device all 暴露两张 GPU。

最快修复方案：暂无确认的一步修复方案。Issue 结论是该现象已定位到上游 AMD CLR，修复尚未进入确认的官方版本；可优先尝试清除执行缓存并执行垃圾回收以释放保留的 ModelVBAR 预留，并使用已打补丁的 CLR（验证方式见下文）。

注意事项：清缓存/GC 只能让保留的预留最终被释放，属于缓解而非根因修复；本地补丁 CLR 的做法未在官方发布中确认，存在兼容性风险，不建议在生产环境直接采用。

问题场景

在 Windows ROCm 环境下使用 2 张 GPU 并开启 DynamicVRAM 运行 ComfyUI 工作流（Issue 中为官方 Krea2 工作流结构：UNet krea2TurboOfficialComfy_krea2TurboFp8.safetensors、LoRA krea2_darkbrush.safetensors、Text Encoder qwen3vl_4b_fp8_scaled.safetensors、VAE qwen_image_vae.safetensors），当流程走到模型完全卸载路径后，进程私有内存（Private Bytes）保持高位不回落。采样器运行在 cuda:0，生成本身成功，没有报错或崩溃，问题表现为生成结束后仍持续占用的大量私有内存。

报错原文

[Windows ROCm multi-GPU][DynamicVRAM] retained ModelVBAR reservation after full unload causes ~38 GB private-memory plateau

原因分析

Issue 作者的独立探针实验表明：先创建一个 ModelVBAR、向其中映射内存、再调用 VBAR 的内存释放路径但保持 ModelVBAR 对象/预留存活时，Windows 上那块巨大的私有内存分配仍保持已提交（committed）状态；只有当 ModelVBAR 对象/预留本身被销毁/释放后，进程私有内存才大幅下降（探针中降至约 886 MB）。这说明仅释放常驻 VBAR 页面并不足以释放底层 VMM 支持的 Windows 私有内存预留。

后续调查进一步把根因定位到 AMD ROCm CLR/HIP VMM：在不涉及 ComfyUI 的独立测试中，只向一个约 15.91 GiB 的 ModelVBAR 预留中映射 32 MiB，stock HIP runtime 就会提交几乎整个预留范围。释放已映射内存不会降低 Private Commit，释放 VA 预留才会。因此这更可能是上游 CLR 的行为，而非独立的 ComfyUI bug。

环境排查

确认操作系统为 Windows 11（该现象与 Windows 私有内存提交行为相关）。
确认 GPU 为 AMD Radeon RX 9070 XT ×2，架构 gfx1201。
确认 PyTorch 版本为 2.13.0+rocm10.0.0，ROCm 为 10.0.0。
确认 ComfyUI 为 0.34.0，comfy-aimdo 为 stock 0.4.15。
确认启动参数包含 --cuda-device all，且两张 GPU 均对 ComfyUI 可见。
确认复现时是否使用了 --disable-smart-memory 与 --enable-dynamic-vram（前者用于稳定走到完全卸载路径）。
确认是否显式使用 --disable-pinned-memory，且未启用 CK Attention、未使用自定义 SelectModelDevice 节点。

解决步骤

使用与 Issue 一致的复现命令，确认是否能稳定复现内存高位驻留：

python main.py --disable-smart-memory --enable-dynamic-vram --cuda-device all --disable-pinned-memory

运行工作流直到模型走到完全卸载路径，生成结束后观察进程 Private Bytes 与最大 MEM_PRIVATE PAGE_READWRITE 分配是否维持在高位（Issue 中分别为 41.58 GB 与 38.438 GB）。
可优先尝试：在生成结束后清除执行缓存并执行垃圾回收，观察保留的 ModelVBAR 预留是否被释放、私有内存是否回落。Issue 作者指出 ComfyUI 仍会在完全卸载后保留 ModelVBAR 预留，但这些预留会在清缓存 + GC 后被成功释放；更早释放可能是有益的优化，但尚未被确认为独立的 ComfyUI bug。
若需要在本地验证根因，可在不涉及 ComfyUI 的独立环境中，向一个约 15.91 GiB 的 ModelVBAR 预留映射 32 MiB，分别测试“只释放已映射内存”和“释放 VA 预留”对 Private Commit 的影响。Issue 中显示只有释放 VA 预留才会让 Private Commit 下降。
持续关注上游 AMD CLR 修复进展：Issue 作者已另开 ROCm/rocm-systems#13232 报告根因与独立复现，本地打补丁的 CLR 可消除过度提交且无需修改 ComfyUI，但该修复尚未进入确认的官方版本。

验证方法

生成结束后统计进程 Private Bytes 与最大 MEM_PRIVATE PAGE_READWRITE 分配：若私有内存不再维持约 38 GB 级的高位驻留（Issue 中释放预留后降至约 7.33 GB / 4.250 GB，探针中降至约 886 MB），即说明预留已被释放。同时确认生成过程本身仍正常成功、无 Traceback、hipError、AcceleratorError、访问冲突或设备不匹配等报错。