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

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

一、结论摘要

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

二、测试条件

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

三、复现数据

典型报错（第 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

--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 已验证无效（不必再试）

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

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

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

七、附件与复现方式

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

/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