抡锤者

天

感谢，四组对照（尤其 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 的功耗代价。

另外两处和文档不一致：

refs/heads/rdna3 已 404，现在是 main（PR #1 的 no-avx512f,... 修复在）。
系统 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 会更准确。

天

没跑过15秒，我跑过OOM的情况是10秒的动作迁移，因为要参考一个10秒的视频，频繁的OOM，最后用KJ的low vram attention和chunk feedforward节点分块解决的。如果硬要跑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 编码。本文没有复现他们的完整配置，所以下面的“原因分析”严格区分实测事实和推测。

一、环境

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

参考：

抡锤者

天知道

帖子

摘要