【 爆卖理由＋１】双7900XTX跑MiniMax-H3在TP＝2的情况下真实的能效应该是无限趋于1.97×
-
-
-
机器：2× Radeon PRO W7900 48G（gfx1100），PCIe 4.0 x8，单卡 PPT 241 W；
栈：ComfyUI 0.39 + comfy-kitchen 0.2.37 + 自研 tp2-comfy v1.2.0。
下面每个数字都是同一台机、同一张首帧、同一 seed 现跑出来的，脚本一条命令可复跑。这个回帖的目的：楼主那套 TP2 跑在 PCIe 3.0 x8 上（all_reduce 5.03 GB/s），我这台正好是 PCIe 4.0 x8（12.95 GB/s）、切分实现基本同源——所以用与楼主完全相同的口径（124 帧 / 8 步 / seed 145 / 第 2–7 步均值）把六档重跑一遍，量一下带宽从 5.03 提到 12.95 GB/s 到底能换回多少收益，顺带给出 x16 的推演和 20G/24G/48G 三档的显存边界。
先说我自己的判断
- PCIe 3.0 的带宽对这套 TP2 是够的，真正卡住加速比的是通信延迟/条数，不是协议代次。
- 通道当然是 x16 最好，3.0 x16 跟 4.0 x8 没区别。
- X99 平台能撑住这件事，但必须挑原生 C612 南桥的板子，别买 H81/B85 改出来的那种。
- 硬上 PCIe 4.0 x16 意义不大，投入回报率太低。
0. 先对齐口径，否则数字没法比
项 本文 主帖 分辨率 640×352 / 832×480 / 1024×576 / 1344×768 / 1536×864 / 1920×1088 640×352 ~ 1536×864（+1920 四步） 帧数 / 步数 124 帧 / 8 步 124 帧 / 8 步 seed / 首帧 145 / 同一张（全档共用） 145 / 各自素材 步时定义 采样进度条反推单步，取第 2–7 步均值（排除首步编译与末步解码） 同 加速比 同帧同分辨率：单卡步时 ÷ TP2 步时 同 attention / reduce --use-ck-attention/ bf16 all_reduce同 链路 PCIe 4.0 x8，集合通信实测 12.95 GB/s（64 MiB 12.60） PCIe 3.0 x8（单向 7.9 GB/s），补丁后 5.03 GB/s 通道判定 isAllDirectP2p 1 · via P2P/IPC（本来就在 P2P，不吃“默认走 SHM”那个坑）打补丁后才走 P2P
1. 主表（124 帧 / 8 步 / seed 145 / 第 2–7 步均值）
分辨率 packed 行数 单卡 s/步 TP2 s/步 TP2+重叠 s/步 TP2 加速 重叠后加速 重叠省 640×352 9026 6.21 3.77 3.63 1.65× 1.71× 3.7% 832×480 15656 12.65 7.53 7.23 1.68× 1.75× 4.0% 1024×576 22910 21.43 12.64 12.35 1.70× 1.74× 2.3% 1344×768 39758 49.67 28.01 27.03 1.77× 1.84× 3.5% 1536×864 50990 74.90 41.16 40.11 1.82× 1.87× 2.6% 1920×1088 80006 158.41 86.72 84.71 1.83× 1.87× 2.3% 平均：TP2 1.74×，加 MLP 分块重叠 1.80×（重叠平均再省 3.1%）。
（表中「+MLP重叠」= MLP 沿序列分块、块间归约与下一块计算并行；六档都验过，与整块版的解码像素逐像素相同。）
2. 天花板在哪：零通信实测 1.99×
- 把 all_reduce 整个跳过（
TP_NOAR=1，只为计时）跑同一格：832×480 档 6.33 s/步，对单卡 12.65 就是 1.998×（≈2.0）—— 和主帖报的 1.97× 几乎一样，说明两边“切分本身”都很干净。 - 通信是纯串行成本：每步 100 次 SUM × packed 行数 × 5376 × 2 B，832 档 ≈ 16.8 GB/步，我们链路 12.95 GB/s ⇒ 约 1.30 s/步，占一步 17%。
- 所以
单卡÷2 + 通信就是硬下限。主帖算过“同一个实现换 12.93 GB/s 能到 6.4–6.6 s”，
我们这台的实测正好落在那一段——两台机器殊途同归，差别只在链路。
3. 和主帖的差别：链路和功耗
主帖（双 7900 XTX） 本文（双 W7900） 单卡 832 档 11.23 s/步 12.65 s/步 all_reduce 带宽 5.03 GB/s 12.95 GB/s TP2 832 档最好 7.68 s/步（1.46×） 7.23 s/步（1.75×） 单卡 12.65 vs 11.23 这 11%：主帖的卡压在 261 W，我们 W7900 是 241 W；另外量化格式也不一样（w4a8 + Turbo LoRA vs int8 + PDD）。
4. 主帖里那张 1.9× 表：套个公式就能自检
隐含带宽 = 每步 payload ÷ (TP2 步时 − 单卡步时/2)分辨率 单卡 TP2 加速比 隐含通信 隐含带宽 640×352 6.70 3.44 1.95× 0.09 s 108 GB/s 832×480 12.88 6.84 1.88× 0.40 s 42 GB/s 1024×576 21.50 11.33 1.90× 0.58 s 42 GB/s 1344×768 48.64 25.08 1.94× 0.76 s 56 GB/s 1920×1088 149.10 77.24 1.93× 2.69 s 32 GB/s 主帖自己实测 all_reduce 是 5.03 GB/s，平台就是 PCIe 3.0 x8（单向 7.9 GB/s）。
上面这列隐含 32–108 GB/s，比链路快 4–14 倍——说明那两个时间不是同条件测的；这张早前的 8 档表后来在楼里被重测纠正过（同机重测 1.10–1.47× SHM / 1.44–1.67× P2P+重叠）。
拿同一公式套本文的格子，反推是 11–14 GB/s，正好对上我们实测的 12.95 GB/s。
5. 如果是 PCIe 4.0 x16 会怎样（预估）
x16 单向理论 32 GB/s，按现在 x8 的同等效率（12.95 / 15.75 ≈ 82%）推 x16 约 25.9 GB/s，即每步通信时间减半：
分辨率 现在 x8（TP2 / 重叠） 预估 x16（TP2 / 重叠） 现在加速 预估加速 重叠省 640×352 3.77 / 3.63 3.40 / 3.33 1.65× 1.87× 2.1% 832×480 7.53 / 7.23 6.88 / 6.73 1.68× 1.88× 2.2% 1024×576 12.64 / 12.35 11.69 / 11.54 1.70× 1.86× 1.2% 1344×768 28.01 / 27.03 26.36 / 25.87 1.77× 1.92× 1.9% 1536×864 41.16 / 40.11 39.04 / 38.52 1.82× 1.94× 1.3% 1920×1088 86.72 / 84.71 83.40 / 82.39 1.83× 1.92× 1.2% 也就是说：x16 能把我们这 6 档从 1.65–1.87× 抬到 1.87–1.94×，即再快 4–7%，已经贴着 1.998×（≈2.0）的零通信上限，再往上没有空间了。
这也正是我开头那句话的来源：x16 只值这 4–7%，为它换平台不划算。
要提醒一句：这台机器现在就是 x8 —— 03 卡的上游根端口
00:01.3是 max x8（硬限），所以不是插槽不够宽，是 03 卡那块 x16 槽的上行桥只有 x8。真想跑满 x16 得换到直连 CPU 的 x16 端口。
6. 双 24G 和双 48G 能干什么，差别在哪
6.1 实测显存峰值
124 帧 / 8 步，峰值含首步初始化。单卡那列是 48G 卡上的数，同一份工作流换到 24G / 20G 卡占用不变，只是余量没了。
分辨率 单卡峰值 GiB TP2 每卡峰值 GiB 640×352 23.1 12.6 832×480 23.5 13.4 1024×576 24.5 14.0 1344×768 26.7 15.8 1536×864 28.5 16.9 1920×1088 32.6 20.1 6.2 三档能干什么
按 20G / 24G / 48G 三档，把「能不能干」列成表：
能干什么 双 20G（7900 XT） 双 24G（7900 XTX） 双 48G（W7900，本文实测） 单卡不开 TP 跑 H3 int8 ✗ 想都别想 ✗ 权重就 19.53 GiB，640 档只剩 ~0.9 GiB、1024 起直接超 ✓ 六档单卡都能跑（23.1 → 32.6 GiB） 640 / 832 / 1024 档 TP2 ✓ 余量 6–7 GiB ✓ 余量 10–11 GiB ✓ 余量 34 GiB 1344 / 1536 档 TP2 ✓ 15.8 / 16.9 GiB，1536 还剩 ~3 GiB ✓ 宽裕 ✓ 宽裕 1080p / 124 帧 TP2 ✗ 要 20.1 GiB，差一口气 ✓ 能跑，但余量只有 3–4 GiB，还得先卸编码器 ✓ 每卡 20.1 GiB，余量 27 GB；不开 TP 也行（32.6 GiB） 1080p / 15 s（362 帧） ✗ ✗ 直接 OOM（这一档要 37.4 GiB/卡） ✓ 能跑；但权重不能常驻（常驻 44.5 GiB 贴 48G 顶） 权重常驻（每镜省 ~74 s 重载） ✗ 只在小档可行 124 帧档可常驻 SeedVR2 7B fp16 放大（34 GiB） ✗ ✗ 只能退回 3B fp8 档 ✓ 单卡可跑（实测 512 s / 5 s 素材） 综合投入产出来看：双 7900 XTX 24G 是性价比极高的那一档。 只要不碰 1080p 长片，TP2 在 640–1536 全档都能跑，成本比 48G 低一大截；48G 的溢价只在「362 帧 1080p、权重常驻、顺手跑 SeedVR2 7B」这三件事上才摊得平，为了它专门升级投入回报率很低。
20G 的 7900 XT 双卡如果二手价够低也很值得考虑：640–1536 全档 TP2 都能跑（1536 还剩 ~3 GiB），只有 1080p 差一口气（要 20.1 GiB）——不碰 1080p 的话，它和 24G 的实际体验几乎没差。
一句话：双 24G 是「能跑起来又最划算」的那档，双 48G 是「能跑长、能常驻、顺手放大」的生产力，双 20G 则是压低预算的入门选择（前提是不碰 1080p）。
7. 结论
- 天花板在链路：零通信实测 1.998×（≈2.0，我们）/ 1.97×（主帖），两边的切分实现都很干净。
- 我们的 TP2 现在 1.65–1.87×，加 MLP 分块重叠后 832 档 7.23 s/步、1920 档 84.71 s/步。
- 再往上只有两条路：改 attention 侧数据流（KV 双缓冲 + 把 out_proj 的归约拆进下一个 block），或把链路从 x8 提到 x16（预估再快 4–7%，见上表）。
- 复跑：
bash ab/bench_matrix.sh（6 档 × 3 组）→ab/bench_summary.py→ab/make_charts.py。
-
-
@terry 已修复
-
-
-
-
-
两条路都修完了，1344×768 压到 20.93 s/步——超过 25 秒的目标线
性能对比（同为 4 步 ×124 帧）
配置 升级前 升级后 提升
1344×768（单卡装不下的档位） 48.05 s/步 20.93 s/步 2.3×
768×768（你工作流的原始配置） 22.04 s/步 9.99 s/步 2.2×
作为参照：勘误帖作者（双卡压 261W 均衡档）的 1344×768 成绩是 SHM 30.78、P2P+重叠 26.77 s/步——你现在这套已经比他的最好成绩还快（他省在 P2P 上，你赢在满血功耗 + torch 2.11 的新内核）。干了什么
venv 升级：torch 2.9.1+rocm6.4 → torch 2.11.0+rocm7.2 全家桶（含 torchvision/torchaudio 配套版本、triton-rocm 3.6.0）。回滚备份在 /home/nx/tp2/pip_freeze_backup_20261031.txt。
comfy-kitchen 的 HIP 编译扩展加载成功了——这是这次升级最大的一笔：int8/w4a8/convrot 全套编译内核就位（比昨天垫片救活的 triton 后端更快）。
CK 注意力复活：flash_attention_decode 内核可用了，勘误帖的最优配置完整达成，已设为 start_tp2.sh 默认。
新样片
/home/nx/ComfyUI/output/tp2_sample_hd4_00001_.mp4 — 1344×768，江南水乡，20.93 s/步
/home/nx/ComfyUI/output/tp2_sample_v2_00001_.mp4 — 768×768（你工作流原配置），9.99 s/步
P2P 的最终答案：不是软件问题，是主板
升级后软件侧全绿（RCCL 2.27.7 + 拓扑补丁能建出 isAllDirectP2p 1 的 P2P/IPC 通道），但执行期 DMA 报 invalid device pointer。我做了一个裸 torch IPC 跨卡读写测试绕开 RCCL 直接复现同样错误——板上两卡分属两个根复合体（0000:06 和 0000:80:1c.4），跨根对等 DMA 不路由，dmabuf 也绕不过。RCCL 启动时的警告给了唯一线索：GRUB 加 iommu=pt 内核参数并重启，可能有 50% 的机会解锁（取决于主板固件的 ACS 实现）。要不要试这个需要你决定——改的是系统内核参数。当前的 SHM 通道（4.2 GB/s）配合新内核已经足够跑出上面的成绩，P2P 理论上还能再挤 5–10%。机器现状：TP2 双 rank 在线待命（当前配置已是满血版），/home/nx/ComfyUI/custom_nodes/comfyui-tp2/README.md 已更新全部实测数据和回滚说明。
-
部署成功，已实机出片
TP=2 双卡跑 MiniMax H3 在你这台机器上完整跑通了：两个 rank（各自锁一张 7900XTX）都成功生成视频，rank0 输出在 /home/nx/ComfyUI/output/tp2_h3_00001_.mp4（832×480、24fps、39 帧、seed 42）。实测数据
项目 结果
冒烟测试 832×480×39帧×4步，4.11 s/步，端到端 175 s
切片正确性 CPU 侧验证：两卡切片重组与原权重逐位一致；行并行数学误差 4.12e-3（bf16 舍入量级）
LoRA 切分 624 个张量全部按规则切分（qkv/fc1 切 B 行、out_proj/fc2 切 A 列）
通信 52 个 block（50 DiT + 2 refiner）行并行包装，MLP 4 分块重叠启用
通道带宽 SHM 中转 ~4.2 GB/s（与勘误帖基线一致）
过程中还抓到一个两篇帖子都没明说的坑：ComfyUI 会用切分后的头数（28）建 token_refiner，但它权重在文件里是全宽的，形状不匹配被静默跳过导致必炸——正确做法是把 refiner 也切分+包装（勘误帖误差分析里 refiner 有 25 token 的讨论，侧面印证了它是被切分的）。与帖子最优配置的两个差距（都已有明确路径）
P2P 没通，走的是 SHM。我把拓扑补丁做出来了（p2p_topology.xml，并验证 lspci 证实两卡确实各挂一个 switch、无共享上游），而且发现：换用系统 RCCL 2.27.7（LD_PRELOAD）+ 拓扑补丁后 P2P/IPC 通道能建立、isAllDirectP2p 1（勘误帖的成功标志）。但执行期崩——你的 venv 是 torch 2.9.1+rocm 6.4（捆绑 RCCL 2.22.3，IPC 句柄创建就失败），而 6.4/7.2 库混用会堆损坏。要拿到 5.03 GB/s，需要把 venv 升级到 rocm-7.2 匹配的 torch（勘误作者的栈），然后 TP_P2P=1 启动即可。
CK 注意力不可用：comfy-kitchen 0.2.37 的 wheel 不带预编译 HIP 内核。现在是 SDPA（与你平时单卡同后端，对比同口径）。勘误帖口径下换 CK 后 TP2 绝对速度更快。
怎么用bash
/home/nx/tp2/start_tp2.sh # 起双 rank（现在已在跑）
/home/nx/tp2/submit_workflow.py
--workflow "/home/nx/wan-video/ComfyUI/user/default/workflows/MiniMax-H3 文生视频+音频 (本地版).json" --wait关键口诀：同一工作流必须提交到 8190 和 8191 两个端口，否则 all_reduce 永远汇合不上
当前机器状态
TP2 双 rank 还在运行（空闲时模型已卸到内存，每卡只剩 ~1-3 GB 占用）。你原来被停掉的 sglang（qwen3.8-27b，另一个 agent 起的）和 wan-video ComfyUI 的完整恢复命令存在 /home/nx/tp2/restart_services.sh，需要时跑一下即可。所有代码在 /home/nx/ComfyUI/custom_nodes/comfyui-tp2/（含 README）和 /home/nx/tp2/（启动/提交/探针/拓扑补丁/测试脚本）。 -
@xiongjie-gao 高高真棒
@Hanray
你别叫人高高，我弟昵称是阿杰@xiongjie-gao
弟人家这么热情，为什么不回应人家？君子坦蛋蛋，小人敞JJ，你这样很小家子气。 -
@Hanray
你别叫人高高，我弟昵称是阿杰@xiongjie-gao
弟人家这么热情，为什么不回应人家？君子坦蛋蛋，小人敞JJ，你这样很小家子气。@terry 因为她就是那个被AI气哭的爱哭鬼
-
@terry 因为她就是那个被AI气哭的爱哭鬼
-
@xiongjie-gao 论坛不允许撒狗粮，羡慕嫉妒恨！
@terry 我冷处理你说我敞JJ，我告诉了你又说我撒狗粮。
老大我很难办的啊
-
@terry 我冷处理你说我敞JJ，我告诉了你又说我撒狗粮。
老大我很难办的啊 -
部署成功，已实机出片
TP=2 双卡跑 MiniMax H3 在你这台机器上完整跑通了：两个 rank（各自锁一张 7900XTX）都成功生成视频，rank0 输出在 /home/nx/ComfyUI/output/tp2_h3_00001_.mp4（832×480、24fps、39 帧、seed 42）。实测数据
项目 结果
冒烟测试 832×480×39帧×4步，4.11 s/步，端到端 175 s
切片正确性 CPU 侧验证：两卡切片重组与原权重逐位一致；行并行数学误差 4.12e-3（bf16 舍入量级）
LoRA 切分 624 个张量全部按规则切分（qkv/fc1 切 B 行、out_proj/fc2 切 A 列）
通信 52 个 block（50 DiT + 2 refiner）行并行包装，MLP 4 分块重叠启用
通道带宽 SHM 中转 ~4.2 GB/s（与勘误帖基线一致）
过程中还抓到一个两篇帖子都没明说的坑：ComfyUI 会用切分后的头数（28）建 token_refiner，但它权重在文件里是全宽的，形状不匹配被静默跳过导致必炸——正确做法是把 refiner 也切分+包装（勘误帖误差分析里 refiner 有 25 token 的讨论，侧面印证了它是被切分的）。与帖子最优配置的两个差距（都已有明确路径）
P2P 没通，走的是 SHM。我把拓扑补丁做出来了（p2p_topology.xml，并验证 lspci 证实两卡确实各挂一个 switch、无共享上游），而且发现：换用系统 RCCL 2.27.7（LD_PRELOAD）+ 拓扑补丁后 P2P/IPC 通道能建立、isAllDirectP2p 1（勘误帖的成功标志）。但执行期崩——你的 venv 是 torch 2.9.1+rocm 6.4（捆绑 RCCL 2.22.3，IPC 句柄创建就失败），而 6.4/7.2 库混用会堆损坏。要拿到 5.03 GB/s，需要把 venv 升级到 rocm-7.2 匹配的 torch（勘误作者的栈），然后 TP_P2P=1 启动即可。
CK 注意力不可用：comfy-kitchen 0.2.37 的 wheel 不带预编译 HIP 内核。现在是 SDPA（与你平时单卡同后端，对比同口径）。勘误帖口径下换 CK 后 TP2 绝对速度更快。
怎么用bash
/home/nx/tp2/start_tp2.sh # 起双 rank（现在已在跑）
/home/nx/tp2/submit_workflow.py
--workflow "/home/nx/wan-video/ComfyUI/user/default/workflows/MiniMax-H3 文生视频+音频 (本地版).json" --wait关键口诀：同一工作流必须提交到 8190 和 8191 两个端口，否则 all_reduce 永远汇合不上
当前机器状态
TP2 双 rank 还在运行（空闲时模型已卸到内存，每卡只剩 ~1-3 GB 占用）。你原来被停掉的 sglang（qwen3.8-27b，另一个 agent 起的）和 wan-video ComfyUI 的完整恢复命令存在 /home/nx/tp2/restart_services.sh，需要时跑一下即可。所有代码在 /home/nx/ComfyUI/custom_nodes/comfyui-tp2/（含 README）和 /home/nx/tp2/（启动/提交/探针/拓扑补丁/测试脚本）。 -
，系统 取消固定了此主题
