AMD R9700 32G 硬体配置分享 + --highvram 显存溢出导致黑屏重启的解决经验
-
硬件配置
搞了一套新机器专门跑 ComfyUI 数字人视频，配置如下：
配件 型号 CPU Intel Xeon GPU AMD Radeon AI PRO R9700 32GB (gfx1201) 内存 62GB DDR4 系统 Ubuntu 24.04 LTS 内核 6.8.0-136-generic 驱动安装
- ROCm 7.14 (amdgpu-dkms 6.19.14-2364437.24.04)
- PyTorch 2.11.0+rocm7.14.0
- ComfyUI 0.28.0
整体感受
装驱动没遇到什么大障碍，ROCm 7.14 对 R9700 支持不错。安装好驱动之后，用了坛子里 work 那个帖子的下载，直接套用工作流就开始跑视频了，开箱即用的感觉。
遇到的问题：黑屏重启
但是想上无限时长工作流的时候，跑了没多久直接黑屏，然后跳到系统登录界面，像是机器重启了一样。
用 Hermes 查了系统日志（journalctl + dmesg），找到关键错误链：
amdgpu: Not enough memory for command submission! (error -12) amdgpu: Failed to pin framebuffer with error -12 GNOME Shell crashed with signal 6根本原因是 ComfyUI 启动参数带了
--highvram，这个模式下所有模型焊死在显存里不释放。我的工作流加载了：- z_image_turbo_bf16 (12GB)
- qwen_3_4b text encoder (7.5GB)
- ae VAE (320MB)
- 各种其他模型 + 中间张量
加起来超过 32GB 了，VRAM 被打爆 → amdgpu 驱动崩了 → GNOME 显示服务器跟着崩 → 黑屏登录。
解决方案
去掉
--highvram启动参数，让 ComfyUI 用默认的 NORMAL_VRAM 模式（不加任何 --vram 参数就是默认）。这样每个模型用完就卸载，不会长期占着显存。32GB 显存在 normal 模式下依然非常充裕，速度几乎没区别。启动脚本改前：
python main.py ... --highvram --enable-manager改后：
python main.py ... --enable-manager启动日志可以看到：
Set vram state to: NORMAL_VRAM Using async weight offloading with 2 streams想问问大家
这个方案是不是最优解？还是说有什么更好的办法，比如手动控制模型卸载顺序，或者在 workflow 层面做显存优化？听听各位大佬的意见。
给新朋友的提醒
如果你的 ComfyUI 启动参数里有
--highvram，加载多个大模型时一定要注意显存总量！--highvram不会卸载任何已加载的模型，工作流里模型多了很容易爆显存。特别是 R9700/AMD 卡，显存爆了不只是报错，而是整个桌面崩掉回到登录界面。遇到类似黑屏重启的问题，先去查journalctl -k看看有没有 amdgpu 报错。 -
比如你要做自动视频的时候，可以做批量化的处理，就是加载一个模型就把这个模型需要弄的工作流全部做完，然后保存中间文件，然后再进行下一步的操作加载下一步用得到的模型就行了。毕竟32g的显存在视频工作流里面也不是太大，肯定还要分批来实施的。我最近也在研究自动化视频方面的东西，一点小小的心得。
-
@老白登 关于 VoxCPM2 极致克隆模式出电子音/胡言乱语的问题，常见原因和排查方向：
-
输入音频质量是关键。极致克隆对参考音频非常敏感，建议用 5-15 秒的干净录音（单人、无背景噪音、无音乐），格式 24kHz/16bit WAV。你可以先用 Adobe Podcast 或类似工具做降噪预处理再喂给 VoxCPM2。
-
AMD 显卡上 VoxCPM2 建议加 --half 参数加载半精度，R9700 32G 上可以稳定运行。不加 --half 的话显存占用翻倍，容易 OOM 或产生音频异常。
-
如果极致克隆一直不行，先退回普通克隆模式（"标准音色克隆"），等音频质量稳定了再切回极致模式。普通模式对输入音频的宽容度高很多。
-
另外注意：VoxCPM2 的音频处理管线中，hubert 特征提取对中文发音敏感，输入音频如果有多人说话、背景音、或者录音距离太远，特征提取会混叠导致输出胡言乱语。
可以先从第一条入手：准备一段 10 秒左右的干净中文录音（自己用手机在安静房间录一段朗读），转成 24kHz WAV，再喂给极致克隆试试。
-
-
@老白登 关于 VoxCPM2 极致克隆模式出电子音/胡言乱语的问题，常见原因和排查方向：
-
输入音频质量是关键。极致克隆对参考音频非常敏感，建议用 5-15 秒的干净录音（单人、无背景噪音、无音乐），格式 24kHz/16bit WAV。你可以先用 Adobe Podcast 或类似工具做降噪预处理再喂给 VoxCPM2。
-
AMD 显卡上 VoxCPM2 建议加 --half 参数加载半精度，R9700 32G 上可以稳定运行。不加 --half 的话显存占用翻倍，容易 OOM 或产生音频异常。
-
如果极致克隆一直不行，先退回普通克隆模式（"标准音色克隆"），等音频质量稳定了再切回极致模式。普通模式对输入音频的宽容度高很多。
-
另外注意：VoxCPM2 的音频处理管线中，hubert 特征提取对中文发音敏感，输入音频如果有多人说话、背景音、或者录音距离太远，特征提取会混叠导致输出胡言乱语。
可以先从第一条入手：准备一段 10 秒左右的干净中文录音（自己用手机在安静房间录一段朗读），转成 24kHz WAV，再喂给极致克隆试试。
-
-
我的R9700 在ubuntu下用ComfyUI,每次开启模型后的第一次调用要好几分钟，之后就快多了。但一旦换模型，就又得等。根据Claude的诊断，
if (not comfy.model_management.WINDOWS
or not comfy.memory_management.aimdo_enabled
or ...):
return super()._load_from_state_dict(...) # ← 慢路径，你走的这条disable_weight_init._lazy_load_from_state_dict(...) # ← 快路径，懒加载
comfy_aimdo 的懒加载优化只在 Windows 上启用。 所以在 Ubuntu里面，WINDOWS 是 False，第一个条件立刻为真，直接走 super()._load_from_state_dict() —— 逐层同步加载全部权重。
Windows 上走的是 _lazy_load_from_state_dict：权重按需加载、边用边取，所以感觉几乎瞬间就好了。
这就是为啥 Windows 快、Ubuntu 慢的直接原因。不是硬件、不是内存、不是磁盘，是 ComfyUI 的这个优化没在 Linux 上启用。
能做什么
-
接受它。 这是上游的设计选择，不是你配置错了。日常用 --highvram 让模型常驻，少切换模型，影响就不大。
-
试试改条件。 理论上可以把 not comfy.model_management.WINDOWS 这个判断去掉，看懒加载在 Linux 上能不能跑。但风险不小——这个限制可能是因为在非 Windows 平台有已知 bug。
-
-
@老白登 直播回放抽出来的音频当参考音源，效果不好是正常的。参考音频的质量直接影响克隆效果，分享几个实操经验：
-
参考音频最好单独录，不要从直播流里抽。直播有压缩、降噪、EQ处理，这些都会干扰音色提取。
-
如果一定要用直播录音，先做预处理：用音频编辑软件（Audacity免费）把音频里的背景噪音、混响、压缩痕迹清理掉。保留一段10-30秒的干净清音段落就行。
-
VoxCPM2对参考音频很敏感。试一下把参考音频切短（8-15秒），选没有背景音乐、语气平缓的片段。
-
如果自己声音弄不好，可以考虑用 So-VITS-SVC 做音色迁移——先找一个干净的TTS音源，再把自己的音色映射上去。
郭德纲的声音确实稳定好用，但自己的声音调好了效果会更自然。有需要可以继续交流。
-
-
试一试，
-
我的R9700 在ubuntu下用ComfyUI,每次开启模型后的第一次调用要好几分钟，之后就快多了。但一旦换模型，就又得等。根据Claude的诊断，
if (not comfy.model_management.WINDOWS
or not comfy.memory_management.aimdo_enabled
or ...):
return super()._load_from_state_dict(...) # ← 慢路径，你走的这条disable_weight_init._lazy_load_from_state_dict(...) # ← 快路径，懒加载
comfy_aimdo 的懒加载优化只在 Windows 上启用。 所以在 Ubuntu里面，WINDOWS 是 False，第一个条件立刻为真，直接走 super()._load_from_state_dict() —— 逐层同步加载全部权重。
Windows 上走的是 _lazy_load_from_state_dict：权重按需加载、边用边取，所以感觉几乎瞬间就好了。
这就是为啥 Windows 快、Ubuntu 慢的直接原因。不是硬件、不是内存、不是磁盘，是 ComfyUI 的这个优化没在 Linux 上启用。
能做什么
-
接受它。 这是上游的设计选择，不是你配置错了。日常用 --highvram 让模型常驻，少切换模型，影响就不大。
-
试试改条件。 理论上可以把 not comfy.model_management.WINDOWS 这个判断去掉，看懒加载在 Linux 上能不能跑。但风险不小——这个限制可能是因为在非 Windows 平台有已知 bug。
-
-
试一试，
@imbiplaza-ASUS 这个步骤我已经让agent去解决了，他还帮我处理了用不上的节点，感谢感谢
