<![CDATA[【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告]]>早上还在跟AI聊天，谈复刻Radiance的路径的可能性。中午就被老特投喂了个贴子：
https://lcz.me/topic/2643/

这个兄弟是个人才，看完大概心里就有数了，这事能成。
因为没搞通内网穿透的问题，所以不能跟论坛的几个大神一样远程评测，回到家把任务交待给AI，做饭去了。

洗完碗回来，一看AI给的结论，是比预想的还要好。
先给结论，因为AI在测Lora时掉了未生效，擅自画了另一个片子。我现在让它重跑这一段。但不会影响结论。

重点就三条
1，可行性
成立！RDNA3 上纯 INT8/INT4 通路 + 自写 TP=2 能稳定出片，两卡逐像素一致，画质与单卡同构图。

2，速度：本机上限被 PCIe 3.0 x16 锁死。832×480 只 1.19×；1344×768 1.42×。若换成帖子那种 12.93 GB/s 的链路，按实测计算量推算可到 ~1.6×。

上面是AI说的，我回顾了下GPU当时的功率以及内存占用的情况看，1.42×应该已经是摸着天花板了。就算是升级Gen 4不动其他硬件的情况下，超超频的情况下勉强能摸着1.5×，如此说来，X99简直香得很。相当于东拼西凑了些板子围成了桶，几乎没短板。

还有，这个，是给论坛中很多声称P2P没意义的朋友一记响亮的回应。如果这数据是在走CPU中转的情况下TP＝2的提升将会被死死卡在卡间通信的速率上。（没记错走CPU中转速率大概3G不到每秒）。

老特鸟人说我拥护P2P是附庸拍马。同志我早年也是图吧混迹的，知识框架可能过时了底层原理还是通晓的，你不能说我这是拍马，起码是同样的高度下有的雷同视角。

3，显存才是主要收益。int8 权重 19.53 GiB 单卡跑不动，TP=2 在 1344×768 只要 16.9 GB/卡，还剩 7 GB 余量（可以再上更长的帧数/更高的分辨率）尤其是在高分辨率下，说明大分辨率下通信占比被摊薄，分辨率越大，TP>1 更划算。(分界线暂不明)

好了我去收一下重跑的数据，贴出来跟大伙分享一下。

image.jpeg

－－－－－－－－－－－－－－－再现手动分割线－－－－－－－－－－－－－－

双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测

平台：2 × RX 7900 XTX 24GB（gfx1100 / RDNA3）· ROCm 7.2 · ComfyUI 0.43 · 量化走 comfy_kitchen
实现路线对齐 lcz.me/topic/2643（int8/convrot + 自写张量并行），参数口径对齐 lcz.me/topic/2582（双 R9700）

一句话结论

能用，而且画质过关；但“加速比”被本机的 PCIe 3.0 x16 卡住了。

DiT 的计算确实按卡减半（11.23 s → 5.71 s/步，1.97×），可 all_reduce 只能跑到 ~4 GB/s（P2P 实测 4.7–5.0 GB/s，链路 KFD 只报 8000 MB/s），单步里又加回 ~3.7 s。最终：832×480 1.19×、1344×768 1.42×（单卡 43.72 s → 双卡 30.78 s/步）。

真正的价值在显存：int8 权重（19.53 GiB）单卡跑不动，TP=2 后 1344×768/124 帧只要 16.9 GB/卡，还能保持 30.8 s/步。网络上，参照贴 2×W7900 的 all_reduce 是 12.93 GB/s，本机上限大约是它的 1/3，这是差距的唯一来源。

场景 每步耗时 相对单卡 备注
832×480 · 124 帧 · 8 步 9.44 s/步 1.19×（单卡 11.23 s） w4a8 + bf16 reduce
1344×768 · 124 帧 · 8 步 30.78 s/步 1.42×（单卡 43.72 s） 6m15s 端到端
纯计算（跳过 all_reduce） 5.71 s/步 1.97× 切分本身很干净
int8 @1344×768 显存 16.9 GB/卡 — 单卡不可能装下 19.53 GiB 权重

1. 实现方式（与帖子 2643 同路线，没有走 Radiance/FP8）

  • 双实例锁步：两个 ComfyUI 进程，HIP_VISIBLE_DEVICES=0/1，各跑同一工作流，RCCL(nccl) + init_method=env://。

  • 权重按 rank 切半（在 load_diffusion_model_state_dict 之前改 state_dict，模型从形状自动推出 heads=28 / ffn=7168，源码零改动）：

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

  • LoRA 同步切分：lora_B(up) 跟输出维切（qkv / fc1），lora_A(down) 只在行并行层切 K（out_proj / fc2）。模型文件用的是 diffusers 命名，见第 8 节踩坑。

  • 通信精度：默认 bf16 上线（流量减半）。fp32 reduce 每步多 4.1 s，画质只差 0.01 dB（18.84 vs 18.85），没有理由用。

  • 不能被切的元数据：weight_s_channel[N] 与 weight_codebook[16] 原样复制，[N,1] 的 per-row scale 在列切分时保持不动。

2. 实测：832×480 / 124 帧 / 8 步（seed 145，turbo LoRA 已生效）

配置 每步耗时 8 步端到端 显存峰值/卡 每步通信量
单卡 · w4a8 11.23 s 168.8 s 22.0 GB —
TP=2 · w4a8 · bf16 reduce 9.44 s 150–169 s 22.4 GB 14.9 GB（114 次 AR）
TP=2 · w4a8 · 关 int8 attention 11.23 s 168.2 s 22.4 GB 14.9 GB
TP=2 · int8 · bf16 reduce 9.43 s 170.5 s 22.6 GB 14.9 GB
TP=2 · w4a8 · fp32 reduce 13.34 s 179.3 s 22.4 GB 29.8 GB
TP=2 · 跳过 all_reduce（仅计时） 5.71 s 104.9 s 22.1 GB 0

端到端时间差异主要来自模型加载 / 文本编码器 / VAE 解码（不并行），不是采样本身；采样部分按 8 步算：单卡 89.8 s vs TP2 75.2 s。

瓶颈拆解

  • 114 次 all_reduce/步 × 155 MB（bf16）= 14.9 GB/步；9.44 − 5.71 ≈ 3.7 s 花在这里，等效带宽 ≈ 4.0 GB/s。

  • RCCL 现走 P2P/IPC（isAllDirectP2p 1、bad=0），4MB/16MB 分别 4.70 / 4.97 GB/s；KFD 链路报 8000 MB/s、PCIe 3.0 x16（E5-2696 v4 平台）。

  • 对比 2643：2×W7900 的 all_reduce 12.93 GB/s。按 12.93 GB/s 复算，本配置单步会是 5.71 + 1.15 ≈ 6.9 s（1.63×），与帖子 1.66× 几乎重合 —— 说明切分实现本身没问题，差距全在链路上。

3. 实测：1344×768 / 124 帧 / 8 步（对齐 2582 的分辨率）

配置 每步耗时 8 步端到端 显存峰值/卡 可行性
单卡 · w4a8 43.72 s — 18.8 GB 要大量权重换出，明显掉速
TP=2 · w4a8 30.78 s 375 s（6m15s） 16.8 GB 舒适
TP=2 · int8 30.84 s 368 s（6m08s） 16.9 GB 单卡装不下，双卡可跑

1344×768 / 124 帧的 token 数 S = 37×24×42 = 37296（是 832×480 的 2.6 倍），每步通信量涨到 37.8 GB，但耗时的增长（9.4→30.8 s）远小于 token 倍数，说明大分辨率下通信占比被摊薄，TP 更划算。

4. 画质：同 seed 与单卡的 PSNR

对比 全局 PSNR 逐帧中位数 判定
单卡 ↔ 单卡（同配置重跑，噪声底） 24.66 dB 24.56 dB 模型链路本身对内核/调度非确定（split-K atomics）
单卡 ↔ TP=2（w4a8，LoRA 已正确切分） 18.85 dB 18.72 dB 构图/主体/光照一致
单卡 ↔ TP=2（fp32 all_reduce，29.8 GB/步） 18.84 dB 18.76 dB reduce 精度无关
单卡 ↔ TP=2（out_proj/fc2 强制 bf16 GEMM） 19.08 dB — +0.23 dB，但每步 +0.87 s
单卡 ↔ 单卡（仅把 int8 attention 换成 bf16 SDPA） 22.90 dB 22.83 dB 单卡换 attention 后端就有这么大差
单卡 ↔ TP=2（两边都关 int8 attention） 18.43 dB 18.35 dB 关掉后更差 → int8 attention 不是误差源
单卡 ↔ TP=2（LoRA 未生效，修复前） 12.77 dB 12.64 dB 画的是另一条片子
TP=2 rank0 ↔ rank1 99.00 dB 99.00 dB 逐像素完全相同

对比帧（单卡基线第 0/60 帧 vs TP=2 同 seed 同 8 步）见 HTML 版报告：构图、芦苇、远树、雾带都对齐，差异属于“另一条可用的采样”。

误差来源定位（本报告最花时间的部分）

假设 验证方法 结论
行并行层两半的激活量化 scale 不同 真实 blocks.0.attn.out_proj 权重 + 合成激活，比较「整 K 一次量化」与「两半各自量化后相加」，并复现 2643 的 all_reduce(MAX) 共享 scale 证伪：两法 rel 0.0091 vs 共享 0.0104；把激活整体乘 2 再除回，结果 rel=0 —— 该 kernel 的激活量化本身尺度不变，共享 scale 是空操作
TP2 下 A8 激活量化在跑 读 comfy/ops.py 的 cast_bias_weight：LoRA 补丁存在时 len(fns)>0 强制 dequant 成 bf16，_use_quantized 也要求 len(weight_function)==0 证伪：8 步 LoRA 覆盖 104 层，实际走的是 bf16 GEMM，A8 量化根本不在执行路径里
all_reduce 用 bf16 累加损失精度 同一 seed 只改 COMFY_TP_AR_DTYPE=fp32 证伪：fp32 18.84 dB / 13.34 s/步，bf16 18.85 dB / 9.44 s/步，画质无差别、速度差 41%
int8 attention 在 28 头下换了量化尺度/kernel 路径 同一份 q/k/v 分别以 56 头、2×28 头调 comfy_kitchen.int8_attention，S=25/519/4810 证伪：前 28 头输出逐位相同（rel 0.000e+00）；关掉 int8 attention 重跑，TP2↔单卡反而降到 18.43 dB
行并行层的部分和 bf16 舍入 真实 w4a8 权重反量化成 bf16，比较整 K 与切半相加，含 fp32 部分和对照 量级不够：单层 rel 2.9e-3，与 bf16 存储舍入同量级；强制 bf16 GEMM 只换回 +0.23 dB

剩下的一条证据链：逐层 dump（320×192/22 帧/1 步）显示 refiner（25 token）处单卡↔TP2 的 rel 与「单卡↔单卡」同级（3.1e-3 vs 2.3e-3），但到视频 token（S=519）的 block0 attention 输出突然变成 4.09e-2，而两组同配置重跑只有 6.2e-3 / 6.7e-3；输入侧三者都是 2.5–2.9e-3。也就是说：输入没有问题，误差在长序列 attention 里被非线性放大 —— 这与「单卡仅更换 attention 后端就差到 22.90 dB」是同一现象。结论：本栈的端到端采样对 bf16 级扰动本身就非常敏感，TP 只是提供了另一个扰动源，不存在可以「对齐 scale」修掉的单点 bug。

5. 新增的验证测试（本轮为定位误差写的，可独立复跑）

脚本 测什么 关键结果
tp2/attn_test.py comfy_kitchen.int8_attention 对 head 数是否敏感；int8 attention 对输入扰动的放大率 S=25 / 519 / 4810，56 头结果切片与 2×28 头调用 rel=0.000e+00（逐位相同）；同张量重复调用 equal=True；S=519 时 int8 vs fp32 SDPA rel 1.425e-02，而 0.3% 输入扰动经 int8 attn 放大到 1.354e-02（fp32 仅 4.809e-03）→ int8 attention 本身是噪声放大器，不是 scale 错配
tp2/split_err.py 真实 w4a8 权重反量化成 bf16 后，行并行切 K 的单层误差（手写 safetensors 头解析，不加载整模型） out_proj（K=7168, S=519）：两半相加 rel 2.859e-03，fp32 部分和对照同为 2.859e-03，纯数学 fp32 仅 9.535e-07（|out|=5.336）；fc2（K=14336）：2.860e-03 / 2.860e-03 / 1.424e-06（|out|=13.747）→ 误差就是最终 bf16 输出舍入，不是切分数学
tp2/atest.py kernel 级：整 K 量化 vs 两半各自量化；复现 2643 的 all_reduce(MAX) 共享激活 scale 切分 rel 0.00912 / 共享 amax 0.01035 / 共享逐行 0.01039 / 激活整体乘 2 再除回 0.00000 → 共享 scale 是空操作，还略差
tp2/ar_dtype_test.py all_reduce 用 bf16 还是 fp32（同 seed 只改 COMFY_TP_AR_DTYPE） fp32 18.84 dB / 13.34 s/步；bf16 18.85 dB / 9.44 s/步 → 精度无收益，慢 41%
tp2/cmp_dbg.py + TP2DumpLatent 逐层 dump 定位误差从哪一层开始放大（320×192 / 22 帧 / 1 步） refiner（25 token）单卡↔TP2 rel 3.1e-3 ≈ 噪声底 2.3e-3；视频 token（S=519）block0 attention 输出 4.09e-2，同配置重跑 6.2e-3 / 6.7e-3；输入侧三者 2.5–2.9e-3
tp2/cmp_latent.py / tp2/psnr.py 两实例 latent 逐元素比对；mp4 逐帧 PSNR（psnr.py <a> <b> <W> <H>） rank0↔rank1 99.00 dB（逐像素相同）；TP2↔单卡 18.85 dB / 18.72 中位

新增脚本都在 /home/jay/tp2/，除 split_err.py 需读 safetensors 权重外均可在 sglang-venv 里直接 python <script> 复跑。

复跑命令

cd /home/jay/tp2
/home/jay/sglang-venv/bin/python attn_test.py      # head 数敏感性 + 扰动放大率
/home/jay/sglang-venv/bin/python split_err.py      # 行并行单层 bf16 误差
/home/jay/sglang-venv/bin/python atest.py          # kernel 等价性 / 共享 scale
/home/jay/sglang-venv/bin/python ar_dtype_test.py  # bf16 vs fp32 all_reduce

6. 与 2643 / 2582 的横向对照

项目 2×W7900（2643） 2×R9700（2582） 本机 2×7900 XTX
显存/卡 48 GB 32 GB（报告 31.86） 24 GB
量化 int8 + convrot(25?) FP8 权重 + Radiance（RDNA4 专用内核） w4a8 / int8 + convrot，全走 INT8 通路
all_reduce 12.93 GB/s 有分片，未量化带宽 ~4.0 GB/s（P2P 4.7–5.0）
832×480 采样 12.8 s/步 → 7.7 s（1.66×） 20 步 15.5 min → 8 min 11.23 → 9.44 s/步（1.19×）
1344×768 / 8 步 — 总 15m35s（含约 5 min 预处理） 总 6m15s，30.8 s/步
显存峰值/卡 12.9 / 13.2 GiB 27.9 GiB 16.8 / 16.9 GiB（1344×768）
软件栈 ComfyUI + 自写 TP2 非 ComfyUI 自研管线 ComfyUI + 自写 TP2

怎么读这张表：2582 的 1344×768 那组含参考图/参考视频/参考音频的全量 Ref2VA 条件，还含约 5 分钟预处理，口径比我们更重，只能当量级参照；2582 的“等效容量 ≈ 32N − 11.55(N−1)”也是它自家显存池算出来的，和我们不是同一套分配器，不能直接换算。真正同口径的是 2643：同为 ComfyUI + 自写 TP2 + INT8 通路，唯一差别是链路带宽。

7. 踩过的坑（都已修，值得记下来）

现象 原因 处理
TP2 画质 12.77 dB，画的是另一条片子 LoRA 键名是 lora_A/lora_B，只按 lora_down/lora_up 匹配 → 切分命中 0/416，补丁形状不符后 ComfyUI 静默跳过 兼容两种命名；lora split keys=208/416，PSNR 升到 18.85 dB
报 codebook must have shape (16,), got (8,) weight_codebook 是全局 16 值码本，被当成普通权重切了 切分白名单跳过 codebook 与 comfy_quant
rank1 在列切分层 IndexError [N,1] 的 per-row weight_s_channel 被沿 dim=1 切 列模式对 1 维 / 末维为 1 的张量原样保留
怀疑切分数学不对 convrot 是否块对角 kernel 级验证：int8 整 K 与切半求和 rel_max 0.0109 / 0.0118；w4a8 两法互差 6e-5 → 等价
bench 打出旧实例、显存不释放 上一轮实例还占着端口 run_case.sh 起实例前按端口清理
fp32 all_reduce 更稳？ 假设不成立 实测 13.34 s/步、PSNR 18.84（bf16 18.85），无收益且每步多 4.1 s，bf16 定为默认
假设行并行层两半的激活量化 scale 不一致是 18.85 vs 24.66 dB 的主因（2643 用 all_reduce(MAX) 对齐） 本栈 A8 内核的激活量化是尺度不变的：真权重上复现「整 K 量化」vs「两半各自量化后求和」rel 0.0091 vs 0.0104，共享 scale 反而略差；把激活乘 2 再除回结果 rel=0 不做。共享 scale 在本内核上是空操作，不需要改 comfy_kitchen 的 hip kernel
想用 fp16 做 all_reduce 再省一半流量 行并行层输出是部分和，amax 实测到 1.8e6，超 fp16 上限（65504）直接 NaN 删掉 fp16 分支，只留 bf16 / fp32
怀疑 int8 attention 切到 28 头后走了另一套量化尺度 同一份 q/k/v 以 56 头与 2×28 头分别调用，前 28 头输出 rel = 0.000e+00（逐位相同） 排除。误差来自长序列 attention 对输入的混沌放大，不是 head 切分

8. 结论与后续建议

  • 可行性：成立。 RDNA3 上纯 INT8/INT4 通路 + 自写 TP=2 能稳定出片，两卡逐像素一致，画质与单卡同构图。

  • 速度：本机上限被 PCIe 3.0 x16 锁死。 832×480 只 1.19×；1344×768 1.42×。若换成帖子那种 12.93 GB/s 的链路，按实测计算量推算可到 ~1.6×。

  • 显存才是主要收益。 int8 权重 19.53 GiB 单卡跑不动，TP=2 在 1344×768 只要 16.9 GB/卡，还剩 7 GB 余量（可以再上更长的帧数/更高的分辨率）。

  • 还能再抠的地方（按收益排序）：

    • 画质目前没有单点可修。 18.85 vs 24.66 dB 的差已定位为 bf16 级数值扰动被端到端采样混沌放大：激活量化（尺度不变）、all_reduce 精度（fp32 只差 0.01 dB）、int8 attention（28 头逐位相同、关掉反而 18.43 dB）、行并行部分和舍入（单层 2.9e-3，全局切换 bf16 GEMM 也只 +0.23 dB）四项全部证伪。想再提升只能整体抬数值精度——最直接的是把 out_proj/fc2 强制 bf16 GEMM（COMFY_TP_ROW_BF16=1，19.08 dB，代价 +0.87 s/步）；

    • 把 out_proj/fc2 的 all_reduce 与下一层 norm 的独立计算做流水重叠（当前是纯串行等待）；

    • 不再需要 bf16→fp32→bf16 中间转换；以及确认 114 次/步里是否有可合并的重复 reduce。

复现入口

  • 插件：/home/jay/ComfyUI/custom_nodes/comfyui-tp2/__init__.py（权重切分 + LoRA 切分 + all_reduce + 计时 + latent 导出节点）

  • 编排：/home/jay/tp2/run_case.sh <tag> <world> <W> <H> <F> <steps> → 起实例 → 投工作流 → 收耗时/显存/latent

  • 对比：cmp_latent.py（latent 逐元素）、psnr.py（mp4 逐帧）、bw.py / ktest.py（链路带宽 / 量化等价性）

  • 环境变量：COMFY_TP_AR_DTYPE=bf16|fp32、COMFY_TP_AR_SKIP=1（跳 reduce 仅计时）、COMFY_TP_ROW_BF16=1（行并行层走 bf16 GEMM）、EXTRA_ARGS=""（关掉 --use-ck-attention）

]]>https://lcz.me/topic/2665RSS for NodeMon, 09 Nov 2026 09:13:18 GMTWed, 28 Oct 2026 13:58:12 GMT60<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 14:54:19 GMT]]>@xiongjie-gao 可以，到时候大家来看看有没有测试或者设置的问题。

]]>https://lcz.me/post/29228https://lcz.me/post/29228Thu, 29 Oct 2026 14:54:19 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 14:47:23 GMT]]>@懒人烘培 把这场优化测试的流程和设计思路让AI写一份可复现的MD文件，发个帖子吧。这很重要。

]]>https://lcz.me/post/29226https://lcz.me/post/29226Thu, 29 Oct 2026 14:47:23 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 13:22:41 GMT]]>@xiongjie-gao 你说得对是刨掉的，看楼主的计算也是刨掉的。

]]>https://lcz.me/post/29193https://lcz.me/post/29193Thu, 29 Oct 2026 13:22:41 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 12:47:33 GMT]]>@懒人烘培
你这是把w4a8/int8编码的时间刨掉了吧？

]]>https://lcz.me/post/29174https://lcz.me/post/29174Thu, 29 Oct 2026 12:47:33 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 12:02:03 GMT]]>@terry @xiongjie-gao @enigma
我也按照帖子的信息部署，提升还可以，DDR5平台会好些，提升接近2倍

1-local-measured-communication-table.png

2-local-measured-step-and-speedup.png

]]>https://lcz.me/post/29159https://lcz.me/post/29159Thu, 29 Oct 2026 12:02:03 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 08:39:18 GMT]]>@Enigma 你这个信息也很重要，测试出了极限，这个分辨率已经很牛逼了。其实大多数时候走720P附近，质量就很好了。

]]>https://lcz.me/post/29059https://lcz.me/post/29059Thu, 29 Oct 2026 08:39:18 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 07:54:24 GMT]]>非常有参考价值，多谢。

]]>https://lcz.me/post/29051https://lcz.me/post/29051Thu, 29 Oct 2026 07:54:24 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 07:14:11 GMT]]>@koala # 双 RX 7900 XTX · TP=2 · 15 秒直出实测（仅新增测试部分）

平台：2 × RX 7900 XTX 24GB（gfx1100 / RDNA3）· ROCm 7.2 · ComfyUI 0.43 · w4a8 + convrot + 自写 TP=2
测试日期：2026-10-29 ｜ seed 145 ｜ turbo LoRA（8 步档）｜ 所有轮次均带 --use-ck-attention --disable-smart-memory

1. 测试口径

  • H3 的最佳输出时长是 15 s，帧数受模型 17k+5 网格约束：15 s @24 fps 对应 362 帧（15.083 s），latent_t = 107。

  • 相对此前的 124 帧（5.17 s，latent_t = 37），15 s 的 token 数是 2.89×（S = 107 × (W/32) × (H/32)）。

  • 为节省时间，每档只跑 4 步采集稳态单步耗时（4 步的 deltas 波动均 < 1%），8 步端到端由「8×单步 + 实测非采样开销」推算。

  • 必须加 --disable-smart-memory：长序列下文本编码器常驻的 10 GB + DiT 6 GB + 激活会直接撞满 24 GB。首轮未加该参数、且 strata.service 还额外占用 22.6 GB/卡，测试直接 OOM；停掉 strata 后三档全部通过。

2. 15 秒直出结果

分辨率 S（token） TP=2 s/步 单卡 s/步 加速比 all_reduce/步 显存峰值/卡 4 步实测 e2e 8 步端到端（推算）
832×480 41 730 36.94 53.85 1.46× 43.0 GiB 16.84 GB 291.7 s ≈ 7.3 min
1024×576 61 632 65.89 — — 62.9 GiB 16.84 GB 411.4 s ≈ 11.3 min
1344×768 107 856 159.29 — —（估算 ~1.7×） 109.2 GiB 17.77 GB 864.9 s ≈ 25 min

  • 8 步推算所用的非采样开销：832×480 143.9 s、1024×576 147.8 s、1344×768 228.0 s（后者主要是 362 帧 × 1344×768 的 VAE 解码）。

  • 1344×768 的 15 s mp4 已产出：362 帧 / 15.083 s，视频轨正常；音频封装仍报 avcodec_send_frame() returned 22，输出只有视频轨（5 s 时代就存在的既有问题，需另外合音轨）。

  • 未重跑 15 s 版本的 PSNR；画质结论沿用 5 s 档的 18.85 dB（噪声底 24.66 dB）。

3. 时长带来的超线性（相对各自 124 帧 / 5.2 s 的配置）

配置 5.2 s（124 帧） 15.1 s（362 帧） 单步增长 token 增长
832×480 · TP=2 9.44 s 36.94 s 3.91× 2.89×
832×480 · 单卡 11.23 s 53.85 s 4.79× 2.89×
1024×576 · TP=2 14.99 s 65.89 s 4.40× 2.89×
1344×768 · TP=2 30.78 s 159.29 s 5.18× 2.89×

  • token 只涨 2.89×，单步却涨 3.9–5.2×，且分辨率越高增长越快（1344×768 的 5.18× > 1024×576 的 4.40× > 832×480 的 3.91×）：attention 是 O(S²)，其占比随分辨率上升，理论最坏 8.35×（=2.89²）。

  • 单卡在长时长下更吃亏（4.79× vs TP2 的 3.91×），因为单卡还要承担整份权重换出的代价。

4. 与前面结论的衔接

  1. TP 的收益随时长变大：832×480 的加速比从 5 s 的 1.19× 升到 15 s 的 1.46×；1344×768 上 109 GiB/步的 all_reduce 折算约 27 s（占单步 17%），按同口径估算加速比 ~1.7×。上限仍是 2×。
  2. 瓶颈依旧是 PCIe 3.0 x16：通信量随 S 线性增长（43 → 63 → 109 GiB/步），等效带宽 3.6–4.2 GB/s 不变；时长变长只是让「计算分母」更大，所以占比反而降到 17%。
  3. 显存不是瓶颈，但换出策略是关键：三档峰值 16.8–17.8 GB，长时长主要吃时间不吃显存（激活是流式的）。不加 --disable-smart-memory 会因编码器常驻而 OOM——这一点在 5 s 档只是「峰值虚高到 22.4 GB」，到 15 s 就变成「跑不起来」。
  4. 画质问题与时长无关：误差来源已定位为 bf16 级扰动被端到端采样混沌放大（18.85 vs 24.66 dB），没有单点可修；15 s 没有引入新的误差机制。
  5. 出片流程建议：832×480（≈7 min）或 1024×576（≈11 min）试构图与 prompt，1344×768（≈25 min）出最终 15 s；一次 reroll 的代价是 5 s 时代的 4–5 倍，值得把重试放在低分辨率完成。

5. 复跑命令

cd /home/jay/tp2

# 15 s = 362 帧；832×480 单卡 / TP2
EXTRA_ARGS="--use-ck-attention --disable-smart-memory" bash run_case.sh s15_832_s 1 832 480 362 4
EXTRA_ARGS="--use-ck-attention --disable-smart-memory" bash run_case.sh s15_832_t 2 832 480 362 4

# 高分辨率
EXTRA_ARGS="--use-ck-attention --disable-smart-memory" bash run_case.sh s15_1024_t 2 1024 576 362 4
EXTRA_ARGS="--use-ck-attention --disable-smart-memory" bash run_case.sh s15_1344_t 2 1344 768 362 4

结果落在 logs/<tag>/result.json（含 per_step、deltas、vram_peak_gb、all_reduce_gb），日志 r0.log / r1.log，latent dump 为 latent_8191.pt / latent_8192.pt。

]]>https://lcz.me/post/29040https://lcz.me/post/29040Thu, 29 Oct 2026 07:14:11 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 06:38:06 GMT]]>@terry 我一直是4080s16g单卡，跑comfyui也几个月了，感觉都挺流畅的，wan2.2 ltx2.3都能跑，分辨率保底960没问题，有的工作流能到1024。 这个h3分辨率到1344速度也十分快。

]]>https://lcz.me/post/29032https://lcz.me/post/29032Thu, 29 Oct 2026 06:38:06 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 06:26:10 GMT]]>@Michael-ZHANG 你这个硬盘小，你玩儿comfyui后会发现，有很多大模型都需要去尝试，还有会下很多lora，我现在2t刚刚好，以后估计2t都不够用。你这个1t以后不够用了再换就麻烦。

]]>https://lcz.me/post/29025https://lcz.me/post/29025Thu, 29 Oct 2026 06:26:10 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 06:19:31 GMT]]>

@xiongjie-gao 说:

@Werther-Wang CPU和内存不会是瓶颈

通信摊薄曲线：640×352 → 1536×864（124 帧，均为 4–8 步实测）

分辨率 S（token） 单卡 s/步 TP=2 s/步 加速比 all_reduce 通信耗时占单步
640×352 8 140 5.80 5.28 1.10× 8.6 GB 45%
832×480 14 430 11.23 9.44 1.19× 14.9 GB 40%
1024×576 21 312 19.10 14.99 1.27× 21.8 GB 36%
1280×704 32 560 35.49 26.00 1.37× 33.0 GB 32%
1344×768 37 296 43.72 30.78 1.42× 37.8 GB 29%
1536×864 47 952 65.60 44.49 1.47× 48.5 GB 26%

通信耗时 = TP2 单步 − 单卡单步/2（把「计算完美二分」当基准），等效带宽稳定在 3.6–4.2 GB/s。加速比随 S 单调上升，S 从 8.1k 到 48k（5.9×）时单卡单步涨 11.3×，因为 attention 是 S²、all_reduce 只是 S——这就是“摊薄”的来源。

image.jpeg

左：单卡 vs TP=2 每步耗时；右：加速比。640×352 只有 1.10×（通信占单步 45%），到 1536×864 升到 1.47×（通信占 26%），上限趋近 2×。

基本印证跟我的对提升上限1.50×的猜想

我在自己的双 7900XTX 上往上走了一档，结果和你的一致——但墙不是带宽，是显存。

机器：X570 + 3500X，双 XTX 拆 8+8（P2P 实测 14.2 GB/s），ROCm 7.2.3，用的是 fcys 的 tp2-comfy。

分辨率 我们 s/步 峰值显存/卡
832×480 7.54 —
1600×896（124 帧） 45.8 22.8 / 25.3 GB
1920×1088 OOM 放不下

你说的"分辨率越大越划算"成立：我们 8.4× 像素只多花 6.1× 时间，通信确实被摊薄了。按你的 1344×768（30.78 s/步）线性外推到 1600×896 应该是 ~42.5 s/步，我们 45.8，同量级。

但到 1600×896 就到头了：第二张卡用到 25.3/25.75 GB，只剩 0.4 GB，1920×1088 直接 OOM。所以 24G 卡双卡 TP2 的天花板在 1600×896 这一档——要上 1920，只能减帧数（length 124→64 应该就下来了），不是换链路。

另外踩到一个坑，提醒后来的人：TP2 每个 block 里是 dist.all_reduce，同一个 prompt 必须同时发给两个端口。我们只发了一边，另一边就在第一个 all_reduce 上挂死了——41 分钟后以 OOM 收场，日志里完全看不出来是这原因。

（还有个和速度无关但占比最大的：这套工作流的文本编码器在 CPU，一次 ~11 分钟，比 8 步 DiT 的 6 分钟还长。）

]]>https://lcz.me/post/29022https://lcz.me/post/29022Thu, 29 Oct 2026 06:19:31 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 06:00:15 GMT]]>帖子非常不错，可以抄作业，复现一下。

]]>https://lcz.me/post/29014https://lcz.me/post/29014Thu, 29 Oct 2026 06:00:15 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Thu, 29 Oct 2026 05:33:13 GMT]]>感谢楼主的详细测试，MinimaxH3最佳时长是15s，随着时间推移需要的时间会更多，有机会的话看看能不能测试一下15s直出的话大概会有多少提升，谢谢。

]]>https://lcz.me/post/29005https://lcz.me/post/29005Thu, 29 Oct 2026 05:33:13 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 22:46:27 GMT]]>⭐ 版主认可：感谢细致的测试，确认了双卡 TP 跑 H3 的瓶颈和边际成本和收益，为社区提供了很有价值的实测参考。

奖励 +10 积分。

]]>https://lcz.me/post/28883https://lcz.me/post/28883Wed, 28 Oct 2026 22:46:27 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 22:38:11 GMT]]>@Werther-Wang 这是你的测试结果吗？怎么最近我有段时间没玩了，视频的要求已经这么低了？原生高分辨率的意义就是在正式出片时，大显存强算力单卡生产。否则试错成本太高不值得。放大也有专门的节点和工作流，虽然没原生好，调试下，也能用。

]]>https://lcz.me/post/28882https://lcz.me/post/28882Wed, 28 Oct 2026 22:38:11 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 22:31:20 GMT]]>@Michael-ZHANG 4080S 32G会更舒服点，但是XTX玩法更多，更灵活，它单卡也挺快的。

]]>https://lcz.me/post/28880https://lcz.me/post/28880Wed, 28 Oct 2026 22:31:20 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 22:28:00 GMT]]>⭐ 版主审定：本帖设为精华，作者 +6 积分奖励，希望再接再厉！

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

]]>https://lcz.me/post/28879https://lcz.me/post/28879Wed, 28 Oct 2026 22:28:00 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 15:30:56 GMT]]>@Werther-Wang 我的两张卡性能开关都在均衡上，要测极限还要动硬件。太累了👷

]]>https://lcz.me/post/28844https://lcz.me/post/28844Wed, 28 Oct 2026 15:30:56 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 15:25:21 GMT]]>@xiongjie-gao 分辨率还能再提高么？最高能生成多大的分辨率，我比较好奇。

]]>https://lcz.me/post/28843https://lcz.me/post/28843Wed, 28 Oct 2026 15:25:21 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 15:22:48 GMT]]>@Werther-Wang CPU和内存不会是瓶颈

通信摊薄曲线：640×352 → 1536×864（124 帧，均为 4–8 步实测）

分辨率 S（token） 单卡 s/步 TP=2 s/步 加速比 all_reduce 通信耗时占单步
640×352 8 140 5.80 5.28 1.10× 8.6 GB 45%
832×480 14 430 11.23 9.44 1.19× 14.9 GB 40%
1024×576 21 312 19.10 14.99 1.27× 21.8 GB 36%
1280×704 32 560 35.49 26.00 1.37× 33.0 GB 32%
1344×768 37 296 43.72 30.78 1.42× 37.8 GB 29%
1536×864 47 952 65.60 44.49 1.47× 48.5 GB 26%

通信耗时 = TP2 单步 − 单卡单步/2（把「计算完美二分」当基准），等效带宽稳定在 3.6–4.2 GB/s。加速比随 S 单调上升，S 从 8.1k 到 48k（5.9×）时单卡单步涨 11.3×，因为 attention 是 S²、all_reduce 只是 S——这就是“摊薄”的来源。

image.jpeg

左：单卡 vs TP=2 每步耗时；右：加速比。640×352 只有 1.10×（通信占单步 45%），到 1536×864 升到 1.47×（通信占 26%），上限趋近 2×。

基本印证跟我的对提升上限1.50×的猜想

]]>https://lcz.me/post/28841https://lcz.me/post/28841Wed, 28 Oct 2026 15:22:48 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 15:10:26 GMT]]>@Werther-Wang 我的配置：
CPU：AMD EPYC 7k62
内存：镁光DDR4 3200 RECC 32GB x2
硬盘：SSD致钛1TB NVme
主板：华南金牌H12D-8D（单路）
电源：长城F16白金1600W
显卡：AMD MI50x2 
机箱：长城黑匣子AI09
网卡：主板自带2.5GBx2
C PU，内存，SSD，显卡是公司淘汰的，其他的我自己买的。目前准备再买2条32GB REC C内存。再买显卡把MI50换了，之前考虑A卡Pro9700一张或者2张， 看了大家的测评，感觉买一张N卡就可以了。这套系统主要跑comfyui。LLM用在线API，主要用Deepseek/MiniMax/千问三家的。

]]>https://lcz.me/post/28837https://lcz.me/post/28837Wed, 28 Oct 2026 15:10:26 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 15:07:37 GMT]]>谢谢老哥的对比测试, 目前单卡起步跑儿童频道, 多几个月买多一张了过来抄作业. 🤩 也感谢各位a卡发热的老哥们🙏🏻🙏🏻现在好稀罕几个月前买下的7900xtx 下了班折腾折腾还挺好玩🤣

]]>https://lcz.me/post/28835https://lcz.me/post/28835Wed, 28 Oct 2026 15:07:37 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 14:56:26 GMT]]>@Michael-ZHANG 不过你还要考虑cpu和内存有没有影响，这个我不知道，我测试用的cpu和内存你也考虑下。

]]>https://lcz.me/post/28834https://lcz.me/post/28834Wed, 28 Oct 2026 14:56:26 GMT<![CDATA[Reply to 【结论：可行！】双 RX 7900 XTX 以 TP=2 跑 MiniMax-H3 的可行性实测报告 on Wed, 28 Oct 2026 14:52:52 GMT]]>@Werther-Wang 谢谢你的对比测试,有参考意义.

]]>https://lcz.me/post/28832https://lcz.me/post/28832Wed, 28 Oct 2026 14:52:52 GMT