[Benchmark] torch_npu FSDP2 vs hyper_parallel Torch fully_shard（Qwen3.5 形状，8×910B）

背景

在 8 × Ascend 910B 上，系统对比 torch_npu FSDP2（czr_pta/pytorch → torch_npu.distributed.fsdp）与 hyper_parallel Torch 后端 fully_shard 的训练 step 性能。

• 自研 benchmark：bench_qwen35_35b_fsdp2/
• 模型：Qwen3.5-35B-A3B 形状（简化实现，非官方完整模型）
• 通用配置：batch_size=1，world_size=8，warmup=2，measure=20，HYPER_PARALLEL_PLATFORM=torch，comm_fusion=False
• 交错实验：每轮 torch → hyper，共 3 轮（实验 E 为 1 轮），降低频率漂移
• layer prefetch：显式 forward=1 / backward=1（decoder 层链式预取，除实验 A 外均开启）

---

实验总览

编号	mesh	seq_len	layers	prefetch	profiler	torch step 中位数	hyper step 中位数	hyper/torch	结论
A	8（纯 FSDP）	16384	4	否	是	1841 ms	1948 ms	1.058×	hyper 慢 ~6%，通信几乎无掩盖
B	8	16384	4	是	否	1831 ms	1784 ms	0.974×	基本持平，hyper 略快 ~2.6%
C	8	8192	8	是	是	1929 ms	1770 ms	0.907×	hyper 快 ~8.3%，profiler 已分析
D	2,4（HSDP）	8192	8	是	否	2423 ms	2294 ms	0.947×	hyper 快 ~5.3%，HSDP 引入额外 AR 开销
E	2,4（HSDP）	8192	8	是	是	2426 ms	2238 ms	0.923×	hyper 快 ~7.7%，profiler 分阶段分析

hyper/torch < 1 表示 hyper_parallel 更快。

---

分阶段汇总（step 中位数，ms）

实验	框架	forward	backward	step
A（16K/4L，无 prefetch）	torch	465	1378	1841
	hyper	465	1464	1948
B（16K/4L，prefetch=1）	torch	457	1372	1831
	hyper	421	1361	1784
C（8K/8L，mesh=8）	torch	493	1436	1929
	hyper	423	1350	1770
D（8K/8L，mesh=2,4）	torch	595	1824	2423
	hyper	456	1832	2294
E（8K/8L，mesh=2,4 + profiler）	torch	592	1834	2426
	hyper	462	1774	2238

规律：

• forward：hyper 在各场景稳定快 ~35–140 ms（Slice/Cast/Concat 等算子路径更轻）
• backward：无 prefetch 时 hyper 慢；开启 prefetch 后与 torch 持平或略快
• mesh 2,4 vs 8：HSDP 使两边 step 均增加 ~500 ms（replicate 维 all_reduce），hyper 相对优势在 E 中回升至 ~7.7%

---

Profiler：通信掩盖率（step3，8 卡均值）

场景	torch 掩盖率	hyper 掩盖率	torch 暴露通信	hyper 暴露通信	HCCL 粒度（AG/RS/AR 次/rank）
A：16K/4L，无 prefetch	48.8%	5.9%	—	—	12 / 7 / 0
C：8K/8L，mesh=8，prefetch=1	53.4%	45.7%	614 ms	760 ms	20/11/0 vs 244/111/0
E：8K/8L，mesh=2,4，prefetch=1	56.5%	48.3%	852 ms	1166 ms	20/11/11 vs 244/111/11

• 无 prefetch：hyper 通信几乎串行暴露（~94% 在关键路径），是实验 A 落后的主因
• prefetch=1：hyper 掩盖率从 ~6% 升至 ~44–48%，但仍低于 torch（~53–57%）
• 根因：hyper 参数级 all_gather_inputs（数百次小 HCCL）vs torch module 级 bucket（数十次）
• HSDP 2×4 新增 replicate 维 all_reduce（~11 次/步），暴露通信较 mesh=8 增加 +249 ms（torch）/ +406 ms（hyper）

mesh=8 → mesh=2,4（Profiler 对比，prefetch=1）

指标	torch（C→E）	hyper（C→E）
掩盖率	53.4% → 56.5%	45.7% → 48.3%
暴露通信	614 → 852 ms (+238)	760 → 1166 ms (+406)
纯计算	1565 → 1711 ms	1453 → 1556 ms
新增 AR	0 → 11 次 / ~1042 ms	0 → 11 次 / ~1332 ms
AG / RS 次数	20/11 → 20/11（不变）	244/111 → 244/111（不变）

Profiler 算子差异

实验 C（mesh=8，rank0 单步）

类别	差异	说明
hyper 更快	Slice −64 ms、ConcatD −24 ms、Cast −14 ms	总 kernel 更轻
hyper 更慢	暴露通信 +146 ms、Launch_Ffts 更多	HCCL launch 碎片化

实验 E（mesh=2,4，rank0 单步）

算子	torch	hyper	Δ	说明
Slice	185 ms	76 ms	−109 ms	forward 最大收益
ConcatD	29 ms	3 ms	−26 ms	拼接路径更轻
Cast	115 ms	99 ms	−16 ms	调用更多但更快
RealDiv	69 ms	100 ms	+31 ms	284 vs 84 次
MatMul/Add	~353 ms	~348 ms	≈0	核心算力相当

实验 E HCCL elapse（每 rank 均值）

集合通信	torch 次数/elapse	hyper 次数/elapse
allGather	20 / 647 ms	244 / 801 ms
reduceScatter	11 / 1054 ms	111 / 975 ms
allReduce	11 / 1042 ms	11 / 1332 ms

hyper backward 中 RS 略快（−79 ms），但 AR 慢 ~290 ms，抵消了计算侧优势。

---

各实验明细

实验 A — 16K / 4 层 / mesh=8 / 无 prefetch / profiler

	torch	hyper
step	1841 ms	1948 ms
forward	465 ms	465 ms
backward	1378 ms	1464 ms

Profiler：results/profiler_20260625_143330/

实验 B — 16K / 4 层 / mesh=8 / prefetch=1 / 交错 3 轮

Round	torch	hyper	ratio
1	1831	1784	0.974×
2	1829	1781	0.974×
3	1831	1784	0.974×

结果：results/interleaved_20260625_152124/

实验 C — 8K / 8 层 / mesh=8 / prefetch=1 + profiler / 交错 3 轮

Round	torch	hyper	ratio
1	2026	1770	0.874×
2	1929	1768	0.917×
3	1911	1784	0.933×

结果：results/interleaved_8k_8L_prof_20260625_163102/

实验 D — 8K / 8 层 / mesh=2,4 HSDP / prefetch=1 / 交错 3 轮

Round	torch	hyper	ratio
1	2448	2264	0.925×
2	2423	2299	0.949×
3	2409	2294	0.952×

mesh 维度：replicate=2, shard=4。结果：results/interleaved_8k_8L_hsdp24_20260625_184243/

实验 E — 8K / 8 层 / mesh=2,4 HSDP / prefetch=1 + profiler / 1 轮

阶段	torch	hyper	Δ
forward	592 ms	462 ms	−130 ms
backward	1834 ms	1774 ms	−60 ms
step	2426 ms	2238 ms	−187 ms（快 7.7%）

Profiler step3（8 卡均值）：torch 计算 1711 ms / 暴露通信 852 ms / 掩盖 56.5%；hyper 计算 1556 ms / 暴露通信 1166 ms / 掩盖 48.3%。

分阶段归因：

• forward 快 130 ms：Slice（−109 ms）+ ConcatD（−26 ms）+ Cast（−16 ms），部分被 RealDiv（+31 ms）抵消
• backward 快 60 ms：RS elapse 优势被 AR 慢 ~290 ms 吃掉；纯计算仍省 ~155 ms
• HSDP 共同代价：新增 AR ~11 次/步，两边 step 较 mesh=8 各增 ~500 ms

结果：results/interleaved_8k_8L_hsdp24_prof_20260625_190343/

---

结论

1. layer prefetch 是关键开关：未开启时 hyper 通信掩盖 ~6%，step 慢于 torch；开启后各场景 hyper 均不慢于 torch，8K/8L 最快约 ~8%。
2. hyper 优势在 forward 算子路径（Slice/Cast/Concat 等），劣势在 HCCL 调度粒度（参数级 vs module 级）。
3. HSDP 2×4 激活 replicate 维 AR 后，两边 step 均增 ~500 ms；hyper 在 E 中仍快 ~7.7%，优势仍在 forward（−130 ms），backward 仅快 60 ms。
4. HSDP 下 hyper AR elapse 比 torch 慢 ~290 ms，是 backward 优势受限的主因；优化 AR overlap / bucket 合并有明确收益。
5. 即便 prefetch=1，hyper 通信掩盖率（~45–48%）仍低于 torch（~53–57%），module-bucket 合并仍有空间。

---

建议优化方向

优先级	方向	预期
P0	参数级 AG/RS → module-bucket 合并	降 HCCL 次数、提掩盖率
P1	HSDP 下 all_reduce overlap 优化	缩小 AR 慢于 torch 的 ~290 ms gap
P1	减少 BARRIER / Launch_Ffts / DeviceSync	对齐 torch 同步开销
P2	comm_fusion=True、prefetch depth=2	A/B 验证
P2	HSDP 2×4 下 RS/AR overlap（comm_fusion=false 路径）	参考 PR848 benchmark

---

复现

source /home/czr/env.sh
cd bench_qwen35_35b_fsdp2

# B: 16K/4L, prefetch=1, 交错 3 轮
bash run_interleaved.sh

# C: 8K/8L, prefetch=1, profiler
SEQ_LEN=8192 NUM_LAYERS=8 ENABLE_PROFILER=1 bash run_interleaved.sh

# D: 8K/8L, HSDP mesh=2,4
MESH=2,4 SEQ_LEN=8192 NUM_LAYERS=8 bash run_interleaved.sh

# E: 8K/8L, HSDP mesh=2,4, profiler
MESH=2,4 SEQ_LEN=8192 NUM_LAYERS=8 ENABLE_PROFILER=1 bash run_interleaved.sh

---

环境

• CANN 9.1.0，Ascend 910B × 8
• torch + torch_npu（czr_pta FSDP2 patch）
• hyper_parallel Torch 后端，comm_fusion=False

schema_version: 1
source: gitcode
gitcode_repo: mindspore/hyper-parallel
gitcode_issue: 251
source_url: https://gitcode.com/mindspore/hyper-parallel/issues/251

Start in bench_qwen35_35b_fsdp2/ and inspect run_interleaved.sh plus the reported profiler and interleaved result directories. Reproduce experiments B–E on the specified Ascend 910B environment, then compare step times, communication counts, and overlap against the recorded results. Done means a validated benchmark comparison or a concrete optimization direction supported by profiler data.