求助】AMD Radeon AI PRO R9700 (gfx1201, RDNA4) 跑 MiniMax-H3 i2v，模型加载到一半死锁/极慢，求破
-
工作流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}}} -
是动态显存参数被关了吗
-
你们的排查已经很到位，pytorch#192259 + rocm-systems#9821 这条线我认同。先补一个可能被漏掉的变量，再逐条回你们的问题。
-
先查 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，建议先做。 -
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 对你们全部生效，补丁必打。 -
#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 开发者的常规操作，风险主要在版本配套，不在补丁本身。
- 加载路径（你们的 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）。
-
WQ_UNBOUND（你们的 Q5）
那是内核 workqueue watchdog 的提示，不是可配置项，也没有现成内核参数能压；workqueue 风暴是 SVM restore 卡死的症状不是原因——VA map 路径修好（上面 1-2 两条），风暴自然消失。 -
换老 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 搬运路径的问题，不是分配器碎片问题。
-
-
启动脚本终于可以正常了，现在生成视频还挺快,冷启动，生成的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
-
恭喜搞定！你这个修复和之前判断的方向对上了：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）已经是最优解，稳定跑就行，恭喜上车！ -
我的comfyui 加载，
-
工作流有用加速lora吗 这个速度
-
我自己的經驗是不要用 7.x 的kernel 退回 6.x 的kernel ，我是指 ubuntu 24.04 的環境，然後把 sage attention 編一下。這樣在ComfyUI 會比較順。
