最终配置全分辨率扫描 + 最佳模式
最终配置（已固化进 start-tp2.sh）：CK attention + mmap + disable-smart-memory + disable-pinned-memory + disable-async-offload + reserve-vram 2（后三个是这次从旧版脚本抢救回来的），SHM 通道。

实测步速（8 步口径，全部比优化前快）：

分辨率 步速 较优化前 12 步整条（冷） 4 步+LoRA 热跑（批量）
832×480 7.64 秒 ↓24% ~2.3 分钟 ~1.0 分钟
1024×576 12.74 秒 ↓20% ~3.1 分钟 ~1.4 分钟
1280×720 23.66 秒 ↓10% ~5.4 分钟 ~2.6 分钟
1920×1080 横屏 77.5 秒 ↓26% ~16.4 分钟 ~9 分钟
1088×1920 竖屏×107帧 ~60-64 秒 — ~14 分钟（你的生产口径） ~7.5 分钟
三个参数的收益随分辨率增大（480p −24%、1080p 横屏 −26%），576p/720p 也全面受益。没有发现任何回退。

最佳模式推荐（按用途）
竖屏剧集成片（e4v2/e3v2 口径，1088×1920×107f×12步）：约 14 分钟/条，比旧版（15.4 分钟）稳快。你刚才那条实际产出验证通过。若镜头以人物/静态为主，换 turbo LoRA 4 步 → 约 7.5 分钟/条。
效率甜点仍是 1024×576：12.74 秒/步（24.5 s/MP，线性区内），配合放大出 1080p 是吞吐最优路线；批量热跑 4 步 LoRA 约 1.4 分钟/条。
1080p 原生：横屏 16.4 分钟、竖屏 14 分钟——修完参数后回到了可用的范围，但注意热漂移：连跑大批 1080p 时后面会慢 10-25%（你第一次尝试 106 秒/步、恢复后 59.6 秒/步就是这个原因），大批量中间让卡歇一两分钟。

这个对吗？

部署成功，已实机出片
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/（启动/提交/探针/拓扑补丁/测试脚本）。

两条路都修完了，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 已更新全部实测数据和回滚说明。