7900 XTX 单卡 15 秒实测能跑

天知道

摘要

本文在一张 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 编码。本文没有复现他们的完整配置，所以下面的“原因分析”严格区分实测事实和推测。

项	值
工作流	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 秒后手动中断，未完成。

补充：

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 的 15 秒档：

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 无

--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。

参考：