抡锤者

我测完了，结论是虽然慢但是能跑没有OOM，也没能摆脱被吊打的结果。https://lcz.me/topic/2928

摘要

本文在一张 RX 7900 XTX 24 GB 上实测 MiniMax-H3 Ref2VA 的 15 秒生成，覆盖 0.4 MP / 1.0 MP、有无音色参考、有无低显存节点，以及一次 480 秒的 8 步探针。

核心结果：

• 15 秒 / 1.0 MP / 4 步 turbo：43 分 44 秒跑完，显存峰值 99.7%；
• 去掉低显存节点：43 分 13 秒，峰值 99.5%，没有变慢；
• 加 2.58 秒音色参考：43 分 57 秒，峰值 99.8%，没有 OOM；
• 加 12.66 秒音色参考：44 分 23 秒，峰值 99.5%，没有 OOM；
• 8 步 / 无 turbo LoRA / 12.66 秒参考音频：跑到 481 秒仍在采样，没有 OOM，随后手动中断；已跨过 topic 2920 的 105 秒崩溃点，但没有跑完。

作为对照，topic 2867 / 2920 的 8 步 + --lowvram 配置在 15 秒时 OOM，崩溃点是音频 VAE 编码。本文没有复现他们的完整配置，所以下面的“原因分析”严格区分实测事实和推测。

---

---

一、环境

项	值
CPU / 内存	Intel Xeon E5-2686 v4 / 128 GB DDR3
GPU	AMD Radeon RX 7900 XTX 24 GB 涡轮卡（gfx1100）
系统	Ubuntu 24.04，kernel 6.8.0-147-generic
ROCm	7.2.0
ComfyUI	0.44.2（commit e6515b16）
前端	1.57.6
Python / PyTorch	3.12 / 2.14.1+rocm7.2

---

二、测试条件

项	值
工作流	MiniMax-H3 Ref2VA，两张参考图（female.png + male.png）
模型	minimax_h3_ref2va_pruned_int8_convrot（20.97 GB）
文本编码器	qwen3vl_32b_minimax_h3_nvfp4_awq
视频 VAE	minimax_h3_video_vae_fp16
音频 VAE	minimax_h3_audio_vae_fp32
加速 LoRA	minimax_h3_ref2v_turbo_4step_v0.1（F 组除外）
步数 / 采样器	4 步（F 组 8 步），euler，simple
Sigma	MiniMaxH3SigmaShift 12 / 3；ExtendIntermediateSigmas 5 / start 0.9
注意力	comfy kitchen attention
帧数 / 时长	362 帧 / 24 fps = 15.083 秒
参考图尺寸	match

各组差异：

组	分辨率	步数	turbo LoRA	参考音频	低显存节点
A	864×480（0.415 MP）	4	有	无	4 / 2
B	1344×768（1.032 MP）	4	有	无	4 / 2
C	1344×768	4	有	无	无
D	1344×768	4	有	平静.wav（2.58 秒）	无
E	1344×768	4	有	可莉.wav（12.66 秒）	无
F（探针）	1344×768	8	无	可莉.wav（12.66 秒）	无

A 是冷启动（含模型加载）；B–E 是热跑（模型节点命中缓存）；F 跑到 481 秒后手动中断，未完成。

---

三、实测结果

组	分辨率	墙钟	显存峰值	最高温度	输出
A	864×480	704.1 s（11 分 44 秒）	23,143 / 24,560 MiB（94.2%）	77 °C	5.2 MB
B	1344×768	2,623.8 s（43 分 44 秒）	24,483 / 24,560 MiB（99.7%）	78 °C	10.9 MB
C	1344×768	2,593.2 s（43 分 13 秒）	24,445 / 24,560 MiB（99.5%）	76 °C	10.7 MB
D	1344×768	2,637.4 s（43 分 57 秒）	24,514 / 24,560 MiB（99.8%）	77 °C	6.9 MB
E	1344×768	2,663.4 s（44 分 23 秒）	24,438 / 24,560 MiB（99.5%）	77 °C	7.2 MB
F（探针）	1344×768	481.3 s 后中断（仍在采样）	24,450 / 24,560 MiB（99.6%）	74 °C	未完成

补充：

• 10 秒 / 864×480 / 243 帧的对照：432.4 s（冷启动），峰值约 20–21 GB。
• 显存峰值用 /sys/class/drm/card*/device/mem_info_vram_used 每 5 秒采样，可能漏掉瞬时尖峰。
• 1.0 MP 的 99.5–99.8% 不是“余量充足”，是“刚好过”；1.0 MP 基本就是这张卡 15 秒的上限。
• F 组跑到 481 秒时仍在 SamplerCustomAdvanced，MiniMaxH3ReferenceToVideo 已执行，说明音频 VAE 编码已通过；481 秒已经跨过 topic 2920 的 105 秒崩溃点，但 8 步全程仍未跑完，不能据此判断全程安全。

---

四、和 topic 2867 / 2920 的差异（事实）

topic 2867 的 15 秒档：

项	值
工作流	同一套 Ref2VA，5s / 10s / 15s，带台词与音色参考
步数	8 步（与 LoRA 训练步数一致）
分辨率	1344×768（1.032 MP）
显存策略	--lowvram
7900 XTX 15 秒	OOM（5 秒 490 s，10 秒峰值 23.2 GB）

topic 2920 的复现与定位：

项	值
结果	105–108 秒 OOM，23.86–23.98 GiB
崩溃位置	音频 VAE 编码（LTXVAudioVAEEncode → VAEEncodeAudio）
失败瞬间	PyTorch 0.18–3.25 GiB；aimdo staged 约 19.2–23.8 GiB；可用 0–158 MiB
绕过尝试	音频分段补丁越过了崩溃点，但 240 秒超时仍在跑；首段仍有 274 MiB OOM，由 CPU 兜底；未跑完
已验证无效	expandable_segments、--reserve-vram 6、--disable-dynamic-vram、文本编码器置 CPU、TP2

和本文的配置差异：

项	topic 2867 / 2920	本文
步数	8 步基础模型	4 步 turbo（F 组 8 步无 LoRA）
参考音频	有（台词与音色参考）	D / E / F 有，A / B / C 无
文本编码器	int8	nvfp4_awq（我测过跟int8基本无差异，所以我没有int8文件）
视频 VAE	int8	fp16
显存策略	--lowvram（动态 VRAM）	三个 --disable-* + --reserve-vram 2
低显存节点	无（改用音频分段补丁）	B 组 4 / 2；C–F 无

---

五、原因分析

5.1 有实测依据的部分

• topic 2920 的 OOM 发生在音频 VAE 编码，失败时可用显存 0–158 MiB；这是他们记录的数据。
• 本文 B / C 两组在 1.0 MP / 15 秒下峰值 99.5–99.7%，说明即使没有参考音频，24 GB 也已经到极限。
• 本文 B 与 C 的差异（低显存节点 4 / 2 vs 去掉）只有 30.6 秒、38 MiB，属于噪声；在这个配置下低显存节点没有可测收益。
• 本文 D（2.58 秒）和 E（12.66 秒）都成功，峰值 99.8% / 99.5%，说明在这套参数下，12.66 秒的参考音频没有造成 OOM。
• F 组 8 步 / 无 LoRA / 12.66 秒音频跑到 481 秒仍在采样，没有 OOM；已经跨过 105 秒的崩溃点，但没有跑完。

5.2 推测（未实测，只作为假设）

• --lowvram + comfy-aimdo 在 ROCm 上可能“只进不出”：权重被 staged 到接近满显存，音频编码需要连续空间时没有可回收余量；他们记录里 --reserve-vram 也没有变成可用余量。
• 本文的 --disable-smart-memory / --disable-dynamic-vram 可能让权重整块卸载，从而腾出连续空间；本文没有做“开 / 关这组参数”的对照，所以只能算推测。
• 8 步可能比 4 步产生更高的采样激活、更长耗时；F 组只跑了 481 秒，不能量化，也不能证明 8 步全程不会 OOM。
• 参考音频更长时可能重新逼近上限；本文只测到 12.66 秒，15 秒或更长的音频没有测。
• 低显存 attention / FFN 节点可能只在 attention/FFN 成为峰值时有用；本文 1.0 MP 的峰值主要不在那里，所以没有收益。这个结论不能外推到音频编码或 8 步场景。

---

六、结论与限制

1. 15 秒 / 1.0 MP 在 4 步 turbo 下可以跑完，但峰值 99.5–99.8%，属于极限档；0.4 MP 是安全档（94.2%，11–12 分钟）。
2. 本文这套参数下，2.58 秒和 12.66 秒参考音频都没有 OOM；这不等于“任何长度音频都安全”，15 秒以上的音频没测。
3. 8 步探针跑到 481 秒（已跨过 105 秒）没有 OOM，且已通过音频编码；但没有跑完，不能得出“8 步一定能跑”的结论。
4. topic 2920 的 OOM 是真实存在的；本文与它的差异是结构性的（4 步 vs 8 步、显存策略、文本编码器/VAE 精度、参考音频长度），不是同一张图的“优化一下”。
5. 限制：每组只跑一次；显存 5 秒采样；A 冷启动、B–E 热跑；F 未完成；没有测试 15 秒以上音频、参考视频、默认 PyTorch attention。

参考：

• https://lcz.me/topic/2867
• https://lcz.me/topic/2920

没跑过15秒，我跑过OOM的情况是10秒的动作迁移，因为要参考一个10秒的视频，频繁的OOM，最后用KJ的low vram attention和chunk feedforward节点分块解决的。如果硬要跑15秒，可以试试这两个节点。
当然如果能从根本上解决这个问题就是大家福音了，期待有好消息。

谢谢，两组都做了，结论反过来了。

• mes=1（dmesg 确认 mes_v11_0_0 / sdma_hqd_mask 0xfc）：同配置 26 条崩 2 次，报错和 mes=0 一字不差（conversation snapshot copy + SDMA1/MAPPING_ERROR 0x1）。不是非 MES 路径的问题。
• 6.8.0-147（mes=0、ROCm 7.2 不变）：Strata 缓存全开 120/120、0 page fault（40.8 min，32K 10.5 s）；ComfyUI 10 s 工作流 3/3，热跑 361.8 s（7.0 是 361.7 s）。
• 7.0.0-42 同配置约 30 次崩 4 次。

所以 7.0 这代内核是放大器（和 #5475 的 6.18+ 概率上涨对得上），已切 6.8 默认并重开缓存，HSA_ENABLE_SDMA=0 留兜底。6.8 不是根治，只是 120 次没触发。

补一句：这台 7.0 的 amdgpu 编译默认就是 mes=0，不是我们关的。

问一下：6.18+ 的 userptr 回归有 upstream 确认或测试内核吗？

配置：7900 XTX（gfx1100，XNACK off）、Ubuntu 24.04、内核 7.0.0-42、ROCm 7.2、PyTorch 2.14.1+rocm7.2，amdgpu.mes=0（默认值，非 MES 路径）。

现象：长上下文推理和视频生成（ComfyUI，20GB DiT + 15GB 文本塔）偶发 hipErrorIllegalAddress，进程直接死。dmesg 同一签名：

代码块

amdgpu 0000:09:00.0: [gfxhub] page fault (src_id:0 ring:128 vmid:8 pasid:3)
amdgpu 0000:09:00.0: in page starting at address 0x00000000e35e0000 from client 10
amdgpu 0000:09:00.0: Faulty UTCL2 client ID: SDMA1 (0xe)
amdgpu 0000:09:00.0: MAPPING_ERROR: 0x1
偶发：同一工作流第一次成功、第二次崩，重试又成功。关掉会话缓存后 145 次请求 0 崩；缓存全开 + HSA_ENABLE_SDMA=0 压测 120 次 0 崩（冷 prefill 慢约 21%）。

上游 drm/amd #5475 定位到 gfx1030 的 SDMA mid-command 偏移越界，但补丁只对 gfx10 生效；gfx11 默认走 MES，和我们这条非 MES 路径不一样。

想请教两个问题：

有人在 gfx1100 + mes=0（非 MES） 上见过同样的 SDMA page fault 吗？
除了关缓存和 HSA_ENABLE_SDMA=0，有没有参数或补丁层面的解法？
附件：完整 dmesg、崩溃调用栈、复现脚本。
sdma-pagefault-evidence.zip

没用加速还跑20步肯定慢了，我图上是0.9mp/10s开加速跑4步(603s)、8步(1130s)、20步(2392s)的速度。听别人说跟4070的速度差不多，我用3060跑4步是1970秒。

感谢，四组对照（尤其 C/D 两组）很有用。补一个实测坑：

GPU_MAX_HW_QUEUES=8 会让引擎空闲时占满 GPU。

照 README 的 IQ3_S 配置（含该变量）启动后，/v1/telemetry 显示 active=0，但 gpu_busy_percent=100、进程 CPU 50–130%；停服务立刻归 0，重启又满。二分 48 个 STRATA_* 后，仅这一个变量可独立复现，其余 47 个单独测都干净。

同机实测（3 次中位数）：

GPU_MAX_HW_QUEUES	空闲 GPU	3.2K decode	59K prefill
8	100%	71.7	3,352
4	0%	75.6	3,293
不设	0%	67.0	3,137

短 prompt 4 反而略快（队列太多互相争抢），长上下文 8 仍最好。建议默认 4，或在 docs/RDNA3_SETTINGS.md 里注明 8 的功耗代价。

另外两处和文档不一致：

1. refs/heads/rdna3 已 404，现在是 main（PR #1 的 no-avx512f,... 修复在）。
2. 系统 ROCm 7.2 的 device lib 在 $R/amdgcn/bitcode，不是文档写的 $R/lib/llvm/amdgcn/bitcode，照抄会报 cannot find ROCm device library。

最后一点观察：我这台原版 0.1.50 的 prefill 本身就有 3,021 tok/s（59K 输入），换 fork 后 3,293、decode 68.3→81。所以 2.8× 可能主要来自 0.1.52 预编译版与 rx7900 视觉版的差异；摘要里标一下原版的构建 variant 会更准确。