求助】AMD Radeon AI PRO R9700 (gfx1201, RDNA4) 跑 MiniMax-H3 i2v，模型加载到一半死锁/极慢，求破

[ken chan]

背景
用 MiniMax-H3（图生视频）在本地 ComfyUI 跑片。8/17、8/18、8/21 都正常连续出片（装/卸/再装都正常）；8/24 系统升级内核后开始连死，反复重启、换 torch、换环境都无法恢复稳定。

硬件

• GPU：AMD Radeon AI PRO R9700（gfx1201，RDNA4，32GB VRAM）
• CPU：24 核；内存 128GB（8/20 由 64GB 升级）
• 系统盘：NVMe SSD

软件 / 环境

• 系统：Ubuntu 24.04.4 (Noble)；内核实测历史：7.0.0-28（能跑）→ 7.0.0-29（间歇）→ 7.0.0-30（连死，已退回 -28）
• ROCm userspace：7.2.3（rocm-core 7.2.3）
• PyTorch：2.11.0+rocm7.2（也测过 2.13.0+rocm7.2，一样卡）
• ComfyUI 0.33.2 + comfy-kitchen 0.2.31；启动参数 --fast-disk（未设 expandable_segments）
• 模型：minimax_h3_fl2va_pruned_int8_convrot(UNet, ~21GB) + qwen3vl_32b_minimax_h3_int8_convrot(CLIP, ~25GB) + minimax_h3_fl2v_turbo_8step LoRA + 视频VAE fp16。H3 节点 MiniMaxH3ImageToVideo，768×1024，LightX2V 8步 euler/simple，SigmaShift 12/3。

工作流（API JSON 关键结构）
VAELoader(video_vae_fp16) → UNETLoader(int8_convrot, weight_dtype=default)
→ CLIPLoader(qwen3vl_32b_int8_convrot, type=minimax, device=default)
→ LoraLoaderModelOnly(turbo_8step, 1.0)
→ MiniMaxH3ImageToVideo(clip, first_frame) → MiniMaxH3SigmaShift(12/3)
→ BasicScheduler(simple,8步) → BasicGuider → KSamplerSelect(euler) → SamplerCustomAdvanced
→ VAEDecode → CreateVideo(24fps) → SaveVideo

完整 JSON 可按需提供。

症状

1. 提交后进入 CLIP 加载：日志停在 Requested to load MiniMaxH3TEModel_，永不出现 H3TURBO sampler，X 不出片。

2. 两种崩溃形态：

   • 慢爬僵持：read_bytes 以 ~25–40MB/min 爬，几十 GB 模型要爬几十小时；RSS 卡在 ~4GB 不动（模型没装进内存）；CPU ~99%。
   • 快速冻死：read_bytes 冻结 60s+，日志同帧，进程 D 态（lock_mm_and_find_vma）。

3. sudo dmesg 刷屏内核工作队列告警：

   workqueue: svm_range_restore_work [amdgpu] hogged CPU ... 2000+ times
   workqueue: amdgpu_amdkfd_restore_userptr_worker [amdgpu] hogged CPU ...

   （内核提示 “consider switching to WQ_UNBOUND”）

4. 卡点几乎总在同一字节位置（~12.3–13GB，即 CLIP 25GB 中段）。

已排除 / 已试过

• 确认未设 expandable_segments:True（环境/进程/脚本全查过）→ 不是它的触发点
• 换 torch 2.13 → 依然卡；全新 venv + 全新 clone ComfyUI → 依然卡（排除环境脏）
• HSA_ENABLE_SDMA=0 → 无效
• CLIPLoader device=cpu → 能过 CLIP，但卡点移到采样时 UNet 的 H2D
• GGUF CLIP → 维度不匹配（L0-49 GGUF 3456 dim vs i2v 需要 3072），不可用
• 内核回滚：-30 连死；-29 间歇（能出片但防不住）；-28 间歇（当前） —— 都不是稳定解

上游调查

• pytorch#192259（同一张 gfx1201 卡）：Tensor.to('cuda') 在 hsaKmtMemoryVaMap 无限等待，open
• AMD 工程师定位：卡在 hipMemSetAccess，因 amdgpu DRM < 3.64 时 GEM_VA timeline 能力缺失，内核从不发布完成点
• 修复 PR ROCm/rocm-systems#9821（fix(rocr): gate VM timeline output on DRM 3.64）：libhsakmt 在 DRM<3.64 改走同步 VA map，state=open 未合并，尚无 release 内含此修复
• 结论：这是 gfx1201 + ROCm 7.2.x 的 H2D/HIP 搬运路径 bug，与黑名单化/量化无关（int8 和 fp16 数据都慢/卡）

求帮助的具体问题

1. 有 R9700 (gfx1201) + ROCm7.2 + ComfyUI/MiniMax-H3 成功稳定跑通的配置吗？尤其：用什么内核 DRM 版本、什么 ROCm、什么 torch、什么启动参数？
2. 怎么查到我当前 amdgpu DRM 版本号（确定是否 <3.64）？以及有没有办法让 libhsakmt 绕开 timeline 路径（比如手动上 #9821 补丁、或某个环境变量强制同步 VA map）？
3. 有没有社区/个人打过 rocm-systems#9821 补丁自编译 libhsakmt 经验？风险多大？
4. 有没有不经过 comfy-kitchen 量化 .to('cuda') 的 H3 加载方式（能在 32GB 显存内装下、又避开这条 H2D）？最好给可行方案。
5. 那个 svm_range_restore_work / restore_userptr workqueue 风暴，有没有 WQ_UNBOUND 或内核参数能先压下去、让搬运能走？

[ken chan]

启动comfyui命令：exec .venv/bin/python main.py --listen 127.0.0.1 --port 8288 --enable-manager --fast-disk

[ken chan]

工作流json
{"1": {"class_type": "VAELoader", "inputs": {"vae_name": "minimax_h3_video_vae_fp16.safetensors"}}, "2": {"class_type": "UNETLoader", "inputs": {"unet_name": "minimax_h3_fl2va_pruned_int8_convrot.safetensors", "weight_dtype": "default"}}, "3": {"class_type": "CLIPLoader", "inputs": {"clip_name": "qwen3vl_32b_minimax_h3_int8_convrot.safetensors", "type": "minimax", "device": "default"}}, "4": {"class_type": "LoraLoaderModelOnly", "inputs": {"model": ["2", 0], "lora_name": "h3/minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors", "strength_model": 1.0}}, "5": {"class_type": "LoadImage", "inputs": {"image": "y2k_sticker_fan_first_frame_768x1024.png"}}, "6": {"class_type": "MiniMaxH3ImageToVideo", "inputs": {"clip": ["3", 0], "vae": ["1", 0], "first_frame": ["5", 0], "width": 768, "height": 1024, "length": 48, "prompt": "<长英文提示词,见下方>"}}, "7": {"class_type": "RandomNoise", "inputs": {"noise_seed": 777}}, "8": {"class_type": "BasicScheduler", "inputs": {"scheduler": "simple", "steps": 8, "denoise": 1.0, "model": ["15", 0]}}, "9": {"class_type": "BasicGuider", "inputs": {"model": ["15", 0], "conditioning": ["6", 0]}}, "10": {"class_type": "KSamplerSelect", "inputs": {"sampler_name": "euler"}}, "11": {"class_type": "SamplerCustomAdvanced", "inputs": {"noise": ["7", 0], "guider": ["9", 0], "sampler": ["10", 0], "sigmas": ["8", 0], "latent_image": ["6", 1]}}, "12": {"class_type": "VAEDecode", "inputs": {"samples": ["11", 0], "vae": ["1", 0]}}, "13": {"class_type": "CreateVideo", "inputs": {"fps": 24.0, "bit_depth": 8, "images": ["12", 0]}}, "14": {"class_type": "SaveVideo", "inputs": {"filename_prefix": "video/y2k_sticker_fan_2s_test", "format": "mp4", "codec": "h264", "video": ["13", 0]}}, "15": {"class_type": "MiniMaxH3SigmaShift", "inputs": {"model": ["4", 0], "shift_video": 12.0, "shift_audio": 3.0}}}

[ken chan]

不知道哪里出问题了，什么环境出问题了，现在大模型加载不进显存，加载进去特别慢

[zhenyu huang]

是动态显存参数被关了吗

[Xiaote]

你们的排查已经很到位，pytorch#192259 + rocm-systems#9821 这条线我认同。先补一个可能被漏掉的变量，再逐条回你们的问题。

0. 先查 8/24 那次升级到底动了什么
   Ubuntu 升内核会连带升级 linux-firmware（gfx1201 这种新 RDNA4 的 firmware 很敏感，fw/内核/ROCm 三方配对）。你们回滚内核到 -28 后仍然间歇，强烈怀疑 firmware 或 ROCm 组件也在同批升级里被带上了。查 /var/log/apt/history.log 里 8/24 的包列表，如果有 linux-firmware，降回 -28 时代的版本再测一次——这是最便宜的 A/B，建议先做。

1. DRM 版本怎么查（你们的 Q2）
   apt install drm-info 后跑 drm_info -d /dev/dri/card0，输出里的 amdgpu driver version 就是 DRM 主次版本（3.xx.y）。建议把 -28/-29/-30 三个内核各启动一次跑一遍对比：如果 -30 已经 >= 3.64 却更死，说明 timeline 路径在 gfx1201 上还有别的坑，#9821 的同步路径就是唯一解；如果三个都 < 3.64，#9821 的 gate 对你们全部生效，补丁必打。

2. #9821 自编译（你们的 Q3）
   改动很小（只在 DRM<3.64 时 gate 掉 VM timeline 输出、改走同步 VA map），风险可控，注意三点：

• 从 ROCm 7.2.3 对应的 ROCR tag 拉源码再 cherry-pick 这个 PR，rocr 和 libhsakmt 严格配套，别混版本；
• 替换 /opt/rocm/lib/libhsa-runtime64.so.1 之前先备份，失败秒回滚；
• 补丁只在 DRM<3.64 时改变行为，正常路径不受影响。
  另外先查有没有更新的 ROCm 点版本（7.2.4+/7.3.x）已合入修复——有就别自己编。社区自编译这个 PR 的先例不多（毕竟还 open），但 rocr 自编译是 ROCm 开发者的常规操作，风险主要在版本配套，不在补丁本身。

3. 加载路径（你们的 Q4）
   任何 ComfyUI 加载路径最后都是 .to(device)，H2D 绕不开，但注意你们的卡点位置：~12.3-13GB ≈ 32GB 显存 − 21GB UNet ≈ 11GB，正是 CLIP 加载把显存顶满、开始触发 KFD SVM 迁移/逐出的时刻——svm_range_restore_work / restore_userptr_worker 风暴就是这条路径在空转。所以 loader 级能试的：

• 把工作集压进 ~30GB 避免加载中途逐出：CLIP 再压一档量化（q4 → ~12.5GB）或 UNet 换 q4（~10.5GB），全程不触发 SVM 逐出；
• vmtouch 把三个模型文件预加载进页缓存再跑——你们的 read_bytes 25-40MB/min 慢得不正常，像每个 page fault 都卡在 workqueue 里，先排除磁盘变量；
• 换 Comfy-Org 官方 H3 节点/不同实现，加载代码路径不同，可能绕开具体卡点。
  但根本解还是 runtime 层（#9821 / DRM 3.64 / 换 ROCm）。

4. WQ_UNBOUND（你们的 Q5）
   那是内核 workqueue watchdog 的提示，不是可配置项，也没有现成内核参数能压；workqueue 风暴是 SVM restore 卡死的症状不是原因——VA map 路径修好（上面 1-2 两条），风暴自然消失。

5. 换老 ROCm A/B
   论坛 TID:1063 有 R9700 + ROCm 7.2.4 + ComfyUI 跑 H3 的成功例（慢但稳定，那边也有人建议换 7.2.0/7.2.1），说明 H3 在 R9700 + 7.2.x 上不是不能跑，你们这个更像 7.2.x + 新内核的配对回归。你们只试过 7.2（torch 2.11/2.13 都是 rocm7.2），可以装一套 ROCm 7.1/7.2.0 + 对应老 torch 做隔离测试。注意老 ROCm 对新内核的 KFD 版本检查可能直接拒绝，装前查支持矩阵。

顺带回楼上 zhenyu huang 的动态显存问题：expandable_segments 你们已确认没开，这条基本可以划掉——这是 mmap+SVM 搬运路径的问题，不是分配器碎片问题。

[ken chan]

启动脚本终于可以正常了，现在生成视频还挺快,冷启动，生成的768×1024的视频速度：
2秒视频：4分钟
8秒视频：12分钟
15秒视频：37分钟

之前的启动comfyui的参数，冷启动要一个小时，现在ai跟我说，以后冷启动，都只要4分钟加载大模型就可以，启动参数如下（这个启动参数，可能是要大内存，我是后面内存加到128G的，一开始ai也是帮我配置成 --fast-disk，可能是因为当时内存只有64G？）：
exec .venv/bin/python main.py --listen 127.0.0.1 --port 8288 --enable-manager --disable-mmap

之前很慢，是用了这个启动参数(要1个小时，才加载好，)：
exec .venv/bin/python main.py --listen 127.0.0.1 --port 8288 --enable-manager --fast-disk

不加 --disable-mmap，就是会报上面那个错误，一直死锁，要不就是加载模型到gpu无敌慢，参考这个issue中，别人的方案，修改了启动参数：https://github.com/Comfy-Org/ComfyUI/issues/15001

[Xiaote]

恭喜搞定！你这个修复和之前判断的方向对上了：H2D 卡死/慢的根子大概率就是 mmap 映射 + 页缓存压力——--disable-mmap 让模型加载走普通拷贝路径，绕开 page cache 抖动，跟显存顶满触发 SVM 逐出是同一类内存压力问题。--fast-disk 本来是为慢盘设计的（把模型先读进内存），但内存只有 64G 时反而跟系统抢内存，就死锁/慢到没法用；加到 128G 后空间够了，配合 --disable-mmap 就稳了。

4 分钟冷启动对 H3 算正常水平：pruned INT8 DiT 21GB 流式加载 + NVFP4 编码器按需装载，ROCm 这边的初始化开销也比 CUDA 平台大，不是故障。

后面如果想再压冷启动，把模型文件放 NVMe 盘 + 保持 --disable-mmap 是最实际的优化。当前这个组合（128G + disable-mmap）已经是最优解，稳定跑就行，恭喜上车！

[imbiplaza ASUS]

我的comfyui 加载，

[zhenyu huang]

工作流有用加速lora吗 这个速度

[fanwen1974]

我自己的經驗是不要用 7.x 的kernel 退回 6.x 的kernel ，我是指 ubuntu 24.04 的環境，然後把 sage attention 編一下。這樣在ComfyUI 會比較順。