7900 XTX 单卡 15 秒 OOM 复现与绕过报告，4080 16G能跑 XTX24G OOM！

xiongjie gao

@terry
可复现，三次都OOM了。但不是说XTX有多弱，实属甲沟炎踢到痔疮上了。
动一个参数就能绕过去。

7900 XTX 单卡 15 秒 OOM 复现与绕过报告

测试时间：2026-11-08　测试机器：本机 2× RX 7900 XTX 24 GB（gfx1100）
参考帖：https://lcz.me/topic/2867 《六张卡跑同一个 MiniMax-H3 视频工作流，差多少？》
说明：全部为单卡实测，未使用 TP2。

一、结论摘要

待验证的说法	判定	依据
7900 XTX 单卡 15 秒 OOM，5080 16 GB 能跑	属实	本机 3 次配置复现，均在约 105 s 失败
原因是「AMD ROCm 缺 comfy-aimdo 动态卸载」	不成立	`comfy-aimdo 0.6.0` 在 7900 XTX 上成功初始化（有 ROCm 原生 .so）
24 GB 是「必须同时装下权重+激活」的硬门槛	不成立	OOM 时 PyTorch 侧仅占用 0.18–3.25 GiB，崩溃点在音频 VAE 编码
`expandable_segments` 无效	属实	碎片不是主因（与原帖一致）
可通过配置/单点代码修改绕过	成立	分段编码补丁已使流程越过 OOM 点

一句话结论：这不是显存容量墙，而是「音频 VAE 一次性编码峰值」叠加「显存被权重铺满至 0 余量、且不为普通张量分配让路」的实现缺陷。

二、测试条件

项目	设置
模型	`minimax_h3_ref2va_pruned_int8_convrot`（20.97 GB）
文本编码器	`qwen3vl_32b_minimax_h3_int8_convrot`（原帖为 `nvfp4_awq`，本机无该文件）
视频 VAE	`minimax_h3_video_vae_int8_convrot`
音频 VAE	`minimax_h3_audio_vae_fp32`
分辨率	1344×768（ResolutionSelector 1.0 MP，16:9，multiple 32）
步数 / 采样器	8 步（`BasicScheduler` beta）
显存策略	按原帖 `--lowvram`；另做对照
时长	15 秒（`H3LVUnified.max_seconds=15 / target_seconds=15`）
服务	端口 8199，HIP_VISIBLE_DEVICES=0，ComfyUI `/mnt/ai/ComfyUI-AMD/ComfyUI`
显存采样	直接读 `/sys/class/drm/card*/device/mem_info_vram_used`，100 ms 一次

工作流取自本机实际执行过的 API 快照（queue_snapshot.json），节点与参数与原帖一致。

三、复现数据

#	启动参数	结果	用时	显存峰值	失败位置
1	`--lowvram`（动态 VRAM 默认开启）	OOM	107.64 s	22.49 GiB	音频 VAE 编码
2	`--lowvram --reserve-vram 6`	OOM	105.27 s	23.97 GiB	音频 VAE 编码
3	`--lowvram --disable-dynamic-vram`	OOM	105.14 s	23.86 GiB	音频 VAE 编码
4	动态 VRAM 开 + 文本编码器置 CPU	OOM	—	—	音频 VAE 编码（请求 10.76 GiB）
5	分段编码补丁（见第五节）	不再中断	超时 240 s 仍在跑	23.98 GiB	越过了原失败点

典型报错（第 2 次）：

torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 3.07 GiB.
GPU 0 has a total capacity of 23.98 GiB of which 38.00 MiB is free.
Of the allocated memory 180.74 MiB is allocated by PyTorch
Warning: Ran out of memory when regular VAE encoding, retrying with tiled VAE encoding.
[ERROR] Exception during processing !!! ... Tried to allocate 490.00 MiB ... 64.00 MiB free

四、根因分析

4.1 OOM 不在视频 UNET 采样，而在音频 VAE 编码

调用栈固定为：

comfy_extras/nodes_lt_audio.py:57   execute
comfy_extras/nodes_audio.py:93      t = vae.encode(waveform.movedim(1, -1))
comfy/sd.py:1473                    self.first_stage_model.encode(...)
comfy/ldm/minimax/audio_vae.py:438  x = self.pre_block(x.transpose(1, 2)).transpose(1, 2)

即参考音频（音色参考）的 fp32 编码器里一个 conv1d 要一次性申请 3.07–10.76 GiB 连续显存。它与 20 GB 视频 UNET 是否放得下无关。

4.2 三次尝试中，显存余量在编码前就已经是 0

配置	失败瞬间 PyTorch 记账	卡内其它占用	可用余量
`--lowvram`	3.25 GiB	≈19.2 GiB（aimdo staged 权重）	0 B
`--reserve-vram 6`	0.18 GiB	≈23.8 GiB	38 MiB
`--disable-dynamic-vram`	少量	≈23.8 GiB	158 MiB

--reserve-vram 在 comfy-aimdo 0.6.0 的 ROCm 后端没有生效：保留量没有变成可用余量，峰值反而更高。这解释了为什么分段后连 274 MiB 的请求仍会失败。

4.3 为什么 5080（16 GB）反而能跑

5080 的原帖数据显示峰值恒定 15.2 GB，即被稳定压在预算内（NVIDIA 侧 aimdo/CUDA 的 evict 正常，分配压力能触发权重回收）；
7900 XTX 峰值是 17.7 GB（5 s）→ 23.2 GB（10 s）→ 15 s 溢出，随音频时长上涨，说明 AMD 侧权重只进不出，编码器再要一块就必然失败。

4.4 原帖还有一处不可比因素

原帖文本编码器用的是 qwen3vl_32b_minimax_h3_nvfp4_awq。nvfp4 是 NVIDIA Blackwell 的 FP4 格式，ROCm 没有对应 kernel，在 AMD 上只能反量化运行，会同时放大显存占用和时间。因此「490 s vs 124 s」里混入了格式不兼容的开销，不能直接当作 A/N 硬件差距。

五、绕过方案与验证

5.1 已实施：音频分段编码（`nodes_audio.py`）

改动文件：[comfy_extras/nodes_audio.py](file:///mnt/ai/ComfyUI-AMD/ComfyUI/comfy_extras/nodes_audio.py)

新增 _encode_audio_chunked()（第 67–107 行），把第 93 行的单次 vae.encode 改为调用它；
按 H3_AUDIO_ENCODE_CHUNK（默认 5 秒）切段，并对齐到 hop_length=800，保证每段 latent 完整；
逐段编码后 torch.cat(outs, dim=-1) 沿时间维拼接（latent 形状 [B, 32, 2, T]）；
某段在 GPU 仍 OOM 时，把音频 VAE 临时移 CPU 跑完再放回，日志打印 audio VAE encode OOM at Xs, finishing on CPU；
H3_AUDIO_ENCODE_CHUNK=0 可完全关闭本补丁。

结果：原第 105 秒必崩的路径被越过，流程继续执行；首段仍有一次 274 MiB 的 OOM，随后由 CPU 兜底接管。

5.2 已验证无效（不必再试）

手段	结果
`PYTORCH_HIP_ALLOC_CONF=expandable_segments:True`	无效，碎片非主因
`--reserve-vram 6`	无效，峰值反升
`--disable-dynamic-vram`（旧路径）	无效，同样崩在音频编码
文本编码器置 CPU	减小不了音频编码峰值（请求涨到 10.76 GiB）
TP2 双卡	已按要求排除；且实测 5 s 仅 1.79× 加速，性价比低

5.3 待验证（按成功率排序）

--novram + 分段编码：强制最小显存常驻，把余量腾出来，可能让 15 秒全程跑在 GPU 上；
给 aimdo 的 ROCm 后端补 reserve 水位：让 staging 上限 = 总显存 − 预留，从根上解决「铺满到 0」；
喂 ≤8–10 秒参考音频，15 秒用两段串接（尾帧接首帧）生成，这是生产口径下最省事的做法；
换用本机已有的 qwen3vl_32b_minimax_h3-w4a8_convrot 文本编码器，压低常驻占用。

六、对原帖数据的复核意见

原帖结论	复核
5 s / 10 s 峰值 17.7 / 23.2 GB	与本次观测的「随时长上涨」一致，可信
15 s 单卡 OOM	已复现，属实
16 GB 能跑 / 24 GB 不能跑是「动态换页」差异	方向对，但机制描述不准：N 卡被压在预算内，A 卡是权重铺满+不回收
AMD 缺 comfy-aimdo	事实错误，0.6.0 有 `aimdo_rocm.so` 并能初始化
24 GB 是硬门槛	不成立，属实现缺陷，可绕过
TP2「通信开销大」	5 s 加速 1.79×，能耗代价仅 +3%，问题在单卡基线慢 5.57×

七、附件与复现方式

文件	说明
`/tmp/h3bench/bench.py`	无头跑批脚本：起服务、提交真实 prompt、100 ms 采样显存
`/tmp/h3bench/results/server_*.log`	各配置完整服务日志
`/tmp/h3bench/results/summary_*.json`	状态、耗时、显存峰值、OOM 摘要
`/tmp/h3bench/results/vram_*.csv`	显存时间序列

复现命令示例（单卡、原帖口径）：

/home/jay/ComfyUI-AMD/venv/bin/python /tmp/h3bench/bench.py \
  --tag post_15s --seconds 15 --dynamic on \
  --server-args=--lowvram --steps 8 --megapixels 1.0 --timeout 1800

Xiaote

版主审定：本帖设为精华，作者 +6 积分奖励，希望再接再厉！

奖励凭证：精华 +6 分 · 编号 f2920-3256-1

terry

这个，AMD没办法像Nvidia那样流式进出？驱动问题？就是单卡能跑到理想水准吗？

xiongjie gao

@terry 是驱动有残疾。N卡把缺页迁移的能力写到的驱动层面，这个是Rocm没想到的。
所以，Aimdo可以在Rocm里加载，但没起到显存警戒线的作用。一次性音频编码的峰值最后点火把这个问题引爆。
所以，怎么形容好呢？阿喀琉斯之踵？

terry

@xiongjie-gao 好吧，这个问题就让我来解决吧，我来重写！
再这一方面AMD真特么是脑残，Intel更是。老黄吃肉是有道理的。

天知道

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

terry

@懒人烘培消失了？这个你去验证了
@天知道你有空可以测试下发个帖子，其实只要是软件问题都有解。

懒人烘培

@terry 说:

这个你去验证了

周末忙乎家里事情，我测试看看

xiongjie gao

@懒人烘培搓出来苏妈给你发OFFER

懒人烘培

@xiongjie-gao 尝试也失败了，结果如下：
这台机器用单张 RX 7900 XTX 跑约 15 秒的 MiniMax-H3 视频，实际瓶颈出现在第一步视频采样。测试已停止，尚未完整出片。

--lowvram：两张卡分别单卡测试，都通过了参考音频编码，但首步采样时出现约 5.89 GiB 的显存分配失败警告。GPU0 在警告后仍跑完了第一步，耗时 43 分 37 秒。
--novram：GPU1 峰值显存降到 17.77 GiB，停止前没有记录到 OOM，但运行超过 21 分钟，第一步仍未完成。现有日志只能定位到采样阶段，无法确定具体哪个算子慢。
因此没有复现帖子里的同一个错误。--novram 缓解了显存压力，15 秒完整出片仍未验证。

terry

@懒人烘培说:
@xiongjie-gao 尝试也失败了，结果如下：这台机器用单张 RX 7900 XTX 跑约 15 秒的 MiniMax-H3 视频，实际瓶颈出现在第一步视频采样。测试已停止，尚未完整出片。 --lowvram：两张卡分别单卡测试，都通过了参考音频编码，但首步采样时出现约 5.89 GiB 的显存分配失败警告。GPU0 在警告后仍跑完了第一步，耗时 43 分 37 秒。 --novram：…

其他流式结点呢？

范志刚

今天我被轮番oom干了一天，最后发现是uuid丢了，换成uuid调用嘎一下好了

terry

@范志刚我弟这个和本帖有什么关系？

范志刚

我也是oom，送渲模傻了，被各种挤压，amd双卡我没研究过，只是我今天遇到了类似的状况这么解决的@terry

懒人烘培

@terry 说:
@xiongjie-gao
其他流式结点呢？

已经测试KJ的low vram attention和chunk feedforward节点，结果如下：

两个 KJ 节点都能在单张 RX 7900 XTX 上独立跑完 MiniMax H3 的 15 秒工作流。两组都在 50 分钟内出片，没有 OOM，也没有用双卡。两段视频均验证为 1344×768、24 fps、362 帧、15.08 秒，带非静音 AAC 音轨。

单独启用的节点	工作流耗时	整卡显存采样峰值
MiniMax H3 Low VRAM Attention，4 组	36 分 52 秒	12.75 GiB
MiniMax H3 Chunk FeedForward，4 块	36 分 33 秒	10.81 GiB

这套配置下，Chunk FeedForward 更省显存，耗时基本相同。用真实 H3 权重做约 10.8 万 token 的单层对照，FeedForward 四分块把该层的额外显存峰值从 8.36 GiB 降到 3.23 GiB，抽样输出一致。

两组都用了 --novram --disable-async-offload --use-ck-attention，采样为 Euler / beta、8 步。最终音频走 CPU 解码，因为本机的 GPU 音频解码探针触发了 HIP 非法内存访问。本次用了 INT8 文本编码器和本地参考音频，未加载原帖的 8 步 LoRA。实测确认了单卡能出片，还没有单独验证这套公共配置去掉 KJ 节点后能否跑完。

另外两个流式节点，第二个实在是太慢了，未让它生成。

路径	结果	单卡显存峰值	用时
H3 Streamed Blocks	任务成功，MP4 已生成	约 6.98 GiB	总计约 50 分 36 秒；采样约 47 分 9 秒
Streaming Loader + BlockSwap	8/8 采样完成；CPU VAE 解码运行约 75 分钟后暂停，未产出 MP4	约 9.75 GiB	采样约 6 分 7 秒，解码远慢于采样

抡锤者