1. 结论

1. TP=2 是真张量并行：同一份 DiT 权重按张量切到两卡，每步用 RCCL all_reduce 汇总；两 rank 输出解码后逐帧哈希一致，不是分段拼接。
2. 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×。
3. 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×。
4. 长视频代价超线性：同像素面积下帧数 124→243（×1.96），token 37,731→77,409（×2.05），每步耗时 ×3.20（24.62→78.85）。
5. 单元成本相反地倾向长视频：每视频秒耗时 10 秒 turbo 版 66.9 s，优于 5 秒 dense 的 117.9 s。
6. 显存（采样期）：5 秒档 14.39–14.72 GiB/卡，10 秒档 15.57–16.15 GiB/卡；开 Turbo + 稀疏后略降（10 秒：16.07→15.57）。
7. 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 关）

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：端到端三段拆解

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

2. 测试平台与环境

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）：

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 同步计时）：

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

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

4. 测试口径

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

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

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

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

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