【抄作业】MiniMax-H3 双 RX 7900 XTX TP=2 测试

Goitex

本人new bird人菜瘾大，请大佬review是否合理，是否符合基准，请帮手指正还有哪些改正优化项。感谢所有对RX7900XTX双卡TP的领路人。

1. 结论

TP=2 是真张量并行：同一份 DiT 权重按张量切到两卡，每步用 RCCL all_reduce 汇总；两 rank 输出解码后逐帧哈希一致，不是分段拼接。
5 秒档（1344×768 / 124 帧）：20 步 dense 每步 24.62 s、整段 609.1 s；换 8 步 Turbo + sol-attn 后每步 15.47 s、整段 187.0 s → 采样 3.40×、端到端 3.26×。
10 秒档（768×1376 / 243 帧）：20 步 dense 每步 78.85 s、整段 1865.5 s；8 步 Turbo + sol-attn 每步 38.70 s、整段 677.3 s → 采样 4.01×、端到端 2.75×。
长视频代价超线性：同像素面积下帧数 124→243（×1.96），token 37,731→77,409（×2.05），每步耗时 ×3.20（24.62→78.85）。
单元成本相反地倾向长视频：每视频秒耗时 10 秒 turbo 版 66.9 s，优于 5 秒 dense 的 117.9 s。
显存（采样期）：5 秒档 14.39–14.72 GiB/卡，10 秒档 15.57–16.15 GiB/卡；开 Turbo + 稀疏后略降（10 秒：16.07→15.57）。
RCCL 是直连 P2P 而非 SHM：isAllDirectP2p 1、via P2P/IPC；有效带宽 12.26–13.51 GB/s；通信占每步 7.8%（10 秒 dense）到 19.4%（5 秒 turbo），不是瓶颈。

表 1：生成速度 / 显存（turbo 开 vs 关）

档位	turbo	步数 / 采样器	每步	采样段	整段	每视频秒	显存峰值（卡 A / 卡 B）
1344×768 / 124 帧	关	20 步 / res_multistep+simple	24.62 s	493.1 s	609.1 s	117.9 s	14.59 / 14.61 GiB
1344×768 / 124 帧	开	8 步 / euler+simple + sol-attn	15.47 s（稀疏稳态）	144.9 s	187.0 s	36.2 s	14.39 / 14.38 GiB
1376×768 / 124 帧	关	20 步 / res_multistep+simple	25.49 s	510.9 s	554.2 s	107.3 s	14.72 / 14.72 GiB
768×1376 / 243 帧	关	20 步 / res_multistep+simple	78.85 s	1575.9 s	1865.5 s	184.2 s	16.07 / 16.15 GiB
768×1376 / 243 帧	开	8 步 / euler+simple + sol-attn	38.70 s（稀疏稳态）	392.9 s	677.3 s	66.9 s	15.57 / 15.74 GiB
768×1376 / 243 帧（seed 145 复核）	开	8 步 / euler+simple + sol-attn	38.70 s	403.4 s	692.6 s	68.4 s	15.61 / 15.69 GiB

1376×768 是本轮最早那组基线（换分辨率前的默认档），保留用于对照 1344×768 的面积影响：面积比 1.024，每步比 1.035。
5 秒 Turbo 档首步 24.43 s、次步 18.27 s，之后稳定 15.46–15.54 s；10 秒 Turbo 档首步 77.7 s、次步 44.9 s，之后稳定 38.65–38.74 s——首两步是 dense（start_percent=0.2），不是异常。

表 2：端到端三段拆解

档位	文本编码	采样	VAE 解码（视频 + 音频）	整段
1344×768 / 124f / 20 步	71.7 s（未命中缓存）	493.1 s	36.9 + 0.7 s	609.1 s
1344×768 / 124f / 8 步 Turbo	5 s 级（命中缓存）	144.9 s	36.8 + 0.4 s	187.0 s
768×1376 / 243f / 20 步	211.6 s	1575.9 s	71.8 + 0.7 s	1865.5 s
768×1376 / 243f / 8 步 Turbo	208.0 s	392.9 s	71.8 + 0.7 s	677.3 s

关键口径：文本编码是一次性固定成本（27 GB int8 编码器跑在 CPU，同一 prompt 二次提交会命中 ComfyUI 节点缓存，71.7 s → 约 5 s）。所以"5 秒档 20 步 609.1 s 反而慢于 1376 档 554.2 s"不是退化，是那一轮编码未命中缓存；比速度请看采样段。

2. 测试平台与环境

项目	配置
主板 / CPU	9700X 平台 / AMD Ryzen 7 9700X，8 核 16 线程，单 NUMA
内存	128 GB
显卡	2 × AMD Radeon RX 7900 XTX 24 GB，gfx1100 / RDNA3
PCIe	Gen4 ×16（`current_link_speed = 16.0 GT/s`、`current_link_width = 16`，两卡 current = max）
系统	Ubuntu 26.04.1 LTS
内核	7.0.0-38-generic
驱动	amdgpu 7.0.0-38（`rocm-smi --showdriverversion` 同上）
计算栈	PyTorch 2.11.0+rocm7.2，HIP 7.2.26015
ComfyUI	0.43.0（commit `426f5ee`）
量化后端	comfy-kitchen 0.2.40，HIP 后端可用（caps 含 int8_convrot、w4a8、sol_attn）
注意力	`--use-ck-attention`（Comfy Kitchen attention）
DiT	Comfy-Org `minimax_h3_fl2va_pruned_int8_convrot`，20.97 GB，sha256 `e889202c…03c47a`
文本编码器	Qwen3-VL-32B int8_convrot，27.14 GB，跑在 CPU（`CLIPLoader device=cpu`），sha256 `bc2ced0f…83283b`
视频 / 音频 VAE	`minimax_h3_video_vae_fp16` 5.21 GB（`7c1f1314…`）、`minimax_h3_audio_vae_fp32` 0.61 GB（`8e505d95…`）
Turbo LoRA	lightx2v `minimax_h3_fl2v_turbo_8step_v1.1_768p_comfyui_bf16`，1.96 GB，strength 1.0，`low_vram=False`（运行时旁路，不合并进权重）
稀疏注意力	`BlockSparseAttention`，method sol-attn，tau 1.3，start 0.2、end 1.0，min_tokens 12288，extra_tokens 256，sink exact_kv_and_rows
TP 实现	复现包自带 `h3-pkg/scripts/tp/`（`core.py` / `tp_boot.py` / `tp_linear.py`），不修改 ComfyUI 核心源码
运行形态	两 rank 常驻（8292 / 8293），HTTP 入口 8399；每次提交同时投给两 rank

3. TP=2 实现思路

进程模型：两个 ComfyUI 进程，各自用 ROCR_VISIBLE_DEVICES=0/1 只暴露一张卡（本地 device 恒为 0），TP_RANK 区分身份，dist.init_process_group("nccl")（ROCm 下即 RCCL，MASTER_ADDR=127.0.0.1:29770）。

权重切分：在 comfy.sd.load_diffusion_model_state_dict 之前改写 state_dict，模型从张量形状自行推出每卡 heads=28（56/2）、ffn=7168（14336/2）：

层	并行方式	每卡形状	通信
`qkv_proj`	列并行（q/k/v 各切一半头）	[10752, 5376]	无
`out_proj`	行并行（K 3584）	[5376, 3584]	`all_reduce`
`fc1`	列并行（gate/up 各切一半）	[14336, 5376]	无
`fc2`	行并行（K 7168）	[5376, 7168]	`all_reduce`

weight_scale（[N,1] 按输出行）随行切、沿 K 切时不动；comfy_quant 元数据原样保留；token_refiner 的 2 个 block 同样切分并补装归约（实测日志 refiner row reductions installed: 4）。每个 block 2 次 bf16 SUM 归约，50 块 = 100 次/步。

LoRA 同步分片：列并行层按输出维切 lora_B，行并行层按 K 维切 lora_A；实测日志 LoRA sharded tensors=208（每卡 208，两卡合计 416）。

P2P 先决条件与是否开启：

判据	实测值
拓扑	`rocm-smi --showtopo`：GPU0GPU1 = PCIE、2 hops、同 NUMA node 0
直连标志	`NCCL INFO Check P2P Type isAllDirectP2p 1 directMode 0`
传输通道	`Channel 00/0 : 0[3000] -> 1[7000] via P2P/IPC`（Ch01 相同），`p2p channels: 2`
SHM 迹象	rank0 / rank1 日志中 `via SHM`、`via CPU` 行数均为 0
结论	走 GPU 直连 P2P，无主机中转；本机不需要任何 `p2p_force` 类补丁

判据只看 RCCL 的 via ... 行，不要用 /dev/shm 占用判断——SHM transport 用 host-malloc + IPC，不落 shm 文件。

RCCL all_reduce 有效带宽（bf16，两 rank 同步计时）：

载荷	时延	有效带宽（algbw）
163 MB	13.3 ms	12.26 GB/s
872 MB	64.6 ms	13.51 GB/s
77 MB（小载荷，缓存命中）	5.8 ms	26.6 GB/s —— 不作持续带宽引用

通信占每步比例（按每步 100 次归约、载荷 = [tokens, 5376] bf16 估算）：

档位	tokens	单次载荷	每步总量	通信时间	占每步
1344×768 / 124f，20 步	37,731	406 MB	40.6 GB	3.01 s	12.2%（24.62 s）
1344×768 / 124f，8 步 Turbo	37,731	406 MB	40.6 GB	3.01 s	19.4%（15.47 s）
768×1376 / 243f，20 步	77,409	832 MB	83.2 GB	6.17 s	7.8%（78.85 s）
768×1376 / 243f，8 步 Turbo	77,409	832 MB	83.2 GB	6.17 s	15.9%（38.70 s）

tokens 数取自 BlockSparseAttention 的运行时日志（sparse producer path: N tokens）。

4. 测试口径

每步耗时取采样期相邻 progress 事件的间隔并剔除首末步的编译/收尾；区间范围一并给出。bench_h3_run.py 的 steady_step_seconds 会把前两步 dense 计入均值（10 秒 Turbo：均值 46.22 vs 稀疏稳态 38.70），两者不可混称"每步"。
显存峰值取采样窗口（首个 STEP → 末个 STEP）内 vram.csv（0.5 s 采样）的最大值，不含文本编码器加载与 VAE 解码阶段。此前口头报过的 15.8 / 17.3 / 16.8 GB 是整轮瞬时快照，已按此口径更正为 14.72 / 16.07 / 15.57 GiB。
端到端 = 文本编码 + 采样 + 解码，三段分别列出；文本编码会因 ComfyUI 节点缓存命中而变为 ~5 s，跨轮比较端到端前必须先对齐这一点。
两卡一致性用解码后逐帧 SHA1 比对（124/124 帧一致），不用 mp4 文件 md5——容器元数据会让字节不同而像素相同。
口径限定（引用 25.49 s/步必带）：仅适用于「1376×768 / 124 帧 / 20 步 / res_multistep+simple / seed 102 / 不加载 Turbo LoRA / CK attention / TP2 / 文本编码器在 CPU」。
未做：P2P 关断的端到端 A/B；纯计算与纯通信分离测试；1536×864 档；W4A8 权重（Singularity）route——其 weight_s_channel / weight_s_rel 需要扩展切片逻辑才能 TP。

直接给结论：最优性价比阵型

【绝对性价比之王】5秒 (1344×768) + 8步 Turbo + sol-attn
- 投入：187.0 秒（约 3 分钟）/ 14.4 GiB 显存。
- 产出：5 秒高质量视频。
- 评价：这是你台机器上的**“印钞机”**。极低的显存、极短的时间，非常适合做大批量的抽卡测试（Prompt A/B 测试）或短视频直出。
【长视频唯一解】10秒 (768×1376) + 8步 Turbo + sol-attn
- 投入：677.3 秒（约 11 分钟）/ 15.6 GiB 显存。
- 产出：10 秒长视频一镜到底。
- 评价：虽然总时间变长了，但摊薄到每秒视频的耗时（66.9 秒/秒）远优于 5 秒 Dense 模式，是长镜头的唯一可用方案。
【避雷区】任何档位 + 20步 Dense
- 尤其是 10 秒 Dense：31 分钟整段耗时，算力成本极度高昂。

深度对比：这笔账到底怎么算的？

1. 算力投入产出比（时间维度）

按照报告中的 “每视频秒”耗时 来算：

5秒 Turbo：36.2 秒（生成1秒视频）
10秒 Turbo：66.9 秒（生成1秒视频）
5秒 Dense：117.9 秒（生成1秒视频）
10秒 Dense：184.2 秒（生成1秒视频）

惊人发现：5秒 Turbo 的生产效率，是 10秒 Dense 的 3.25 倍！ 也就是说，你用 Dense 跑一个 10 秒视频的算力，足够你用 Turbo 跑出 30 秒的成片。所以 Turbo + sol-attn 是绝对的必选项。

2. 致命痛点：超线性膨胀与固定成本

超线性惩罚：帧数从 124 涨到 243（×1.96），采样耗时（24.62 → 78.85）却翻了 3.2 倍。这说明 Attention 在 77k token 时，大量时间浪费在了无效计算上。Sol-Attn 极其关键，它把 10 秒的单步从 78.85 砍到了 38.7，挽救了长视频。
固定成本（文本编码）：10 秒档的文本编码耗时 211.6 秒。在整段 677 秒里，它占了整整 31%！这意味着，如果你连续提交 2 个 10 秒任务（如果 Prompt 相同，命中缓存只需 5 秒），总时长将瞬间从 1354 秒骤降到 1147 秒。这也是为什么一定要用常驻服务，绝不能每次跑都重启加载。

3. 终极灵魂拷问：想要 10 秒成片，怎么跑最划算？

方案 A（单次 10 秒 Turbo）：整段 677.3 秒。
方案 B（连跑两个 5 秒 Turbo）：整段 187.0 × 2 = 374.0 秒。

结论反转：用 5 秒分段生成 2 次，总耗时才 374 秒，比直接硬扛 10 秒（677 秒）快了将近一半（节省 45%）！

但方案 B 有两个代价：

需要做接缝处理（首帧接力），或者干脆剪辑成两个镜头。
动作连贯性不如一镜到底。

所以，真实的落地策略是：除非你一定要“10 秒不切镜头的连贯动作”，才去用 10 秒 Turbo 单次硬扛；否则，拆分成两个 5 秒镜头（或者多跑几个 5 秒素材来剪辑），在时间成本和算力成本上都是碾压级的最优解。

terry

连续10秒原生出片，在运镜时的优势吊打5s，5s片段你再怎么优化拼接，都不太流畅。

抡锤者