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