Repository navigation
feat(fsdp): expose HSDP and HFSDP through the MFSDP v2 adapter - #6873
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test |
| ) | ||
|
|
||
| inner_size = inner_group.size() | ||
| layout = torch.arange(dist.get_world_size()).reshape(outer_group.size(), inner_size).tolist() |
There was a problem hiding this comment.
I’m a bit confused🤔: why can we use the get_world_size() to compute the expected indexs? Are we assuming that world_size = inner_dp × outer_dp?
It would be helpful to understand how this work when TP, PP, or EP(maybe with #6798) is also present, or whether support for those configurations is outside the current scope.
There was a problem hiding this comment.
Yes, the assumption is world_size == outer_dp × inner_dp. This mirrors v1: _get_hsdp_tp_mesh (:864) also reshapes torch.arange(world_size) (:869), just with extra ep/tp factors that reduce away when those are 1.
It's checked rather than assumed — this rank's row is compared against intra_dp_cp and its column against inter_dist_opt (:845, :850), so a mismatch raises instead of silently mis-mapping shards. TP/PP/CP above 1 are rejected in _validate_config (:658), so a config that would break the identity can't reach here.
ce2b895 to
3ed254e
Compare
|
/ok to test |
3ed254e to
ceb56c6
Compare
|
/ok to test |
ceb56c6 to
dbb852b
Compare
Signed-off-by: Jingyue Wu <jingyuew@nvidia.com>
Signed-off-by: Jingyue Wu <jingyuew@nvidia.com>
Signed-off-by: Jingyue Wu <jingyuew@nvidia.com>
|
🔄 Merge queue validation started! You can track the progress here: https://github.com/NVIDIA/Megatron-LM/actions/runs/33345851729 |
…ware optimizer, HSDP, and optimizer CUDA graphs Megatron-LM landed dedicated MFSDP v2 support for these, each with its own commits and tests, after this validation function was written: - clip_grad: MFSDP v2 gradient clipping across dense and expert meshes (NVIDIA/Megatron-LM#6489) - use_precision_aware_optimizer: mixed-precision optimizers in MFSDP v2 (NVIDIA/Megatron-LM#6506) - num_distributed_optimizer_instances / outer_dp_sharding_strategy (HSDP): expose HSDP and HFSDP through the MFSDP v2 adapter (NVIDIA/Megatron-LM#6873); the adapter itself now enforces the correct paired constraint, so no replacement check is needed here - optimizer_cuda_graph: verified for MFSDP v2 (NVIDIA/Megatron-LM#6498) Verified end-to-end against Megatron-LM main + Megatron-Bridge with the DeepSeek-V3 MFSDP v2 + EP proxy config (clip_grad=1.0): 20/20 iterations, finite decreasing loss, no skipped or NaN iterations.
…ware optimizer, HSDP, and optimizer CUDA graphs Megatron-LM landed dedicated MFSDP v2 support for these, each with its own commits and tests, after this validation function was written: - clip_grad: MFSDP v2 gradient clipping across dense and expert meshes (NVIDIA/Megatron-LM#6489) - use_precision_aware_optimizer: mixed-precision optimizers in MFSDP v2 (NVIDIA/Megatron-LM#6506) - num_distributed_optimizer_instances / outer_dp_sharding_strategy (HSDP): expose HSDP and HFSDP through the MFSDP v2 adapter (NVIDIA/Megatron-LM#6873); the adapter itself now enforces the correct paired constraint, so no replacement check is needed here - optimizer_cuda_graph: verified for MFSDP v2 (NVIDIA/Megatron-LM#6498) Verified end-to-end against Megatron-LM main + Megatron-Bridge with the DeepSeek-V3 MFSDP v2 + EP proxy config (clip_grad=1.0): 20/20 iterations, finite decreasing loss, no skipped or NaN iterations. Signed-off-by: Jingyue Wu <wujingyue@gmail.com>
…A#6873) Signed-off-by: Jingyue Wu <jingyuew@nvidia.com>
…ware optimizer, HSDP, and optimizer CUDA graphs Megatron-LM landed dedicated MFSDP v2 support for these, each with its own commits and tests, after this validation function was written: - clip_grad: MFSDP v2 gradient clipping across dense and expert meshes (NVIDIA/Megatron-LM#6489) - use_precision_aware_optimizer: mixed-precision optimizers in MFSDP v2 (NVIDIA/Megatron-LM#6506) - num_distributed_optimizer_instances / outer_dp_sharding_strategy (HSDP): expose HSDP and HFSDP through the MFSDP v2 adapter (NVIDIA/Megatron-LM#6873); the adapter itself now enforces the correct paired constraint, so no replacement check is needed here - optimizer_cuda_graph: verified for MFSDP v2 (NVIDIA/Megatron-LM#6498) Verified end-to-end against Megatron-LM main + Megatron-Bridge with the DeepSeek-V3 MFSDP v2 + EP proxy config (clip_grad=1.0): 20/20 iterations, finite decreasing loss, no skipped or NaN iterations. Signed-off-by: Jingyue Wu <wujingyue@gmail.com>
Summary
MFSDP v2's core already supports hybrid sharding, but the MCore adapter never built a
second data-parallel axis:
num_distributed_optimizer_instanceswas ignored and everyparameter was sharded over the full DP domain. This wires it up.
Dense parameters take a
("dp_outer", "dp_shard")mesh whenever there is more than oneinstance. Expert parameters deliberately do not — they stay ZeRO-3 over the whole
expert-DP domain, since sharding the large parameters maximally is worth more than the
intra-instance collectives hybrid sharding buys.
No HSDP/HFSDP special case
Each axis takes the placements of its own sharding strategy, per
mfsdp_design.md:no_shardoptimoptim_gradsoptim_grads_paramsSo HSDP is
no_shardouter over ZeRO-3 inner, and HFSDP is ZeRO-1 outer over ZeRO-3inner — whose optimizer is then sharded on both axes, i.e. across the flattened DP
domain. ZeRO-2 and ZeRO-3 on the outer axis come for free.
num_distributed_optimizer_instancesdecides only whether an outer axis exists;outer_dp_sharding_strategydecides what lives on it. Both strategy fields are nowvalidated in
DistributedDataParallelConfig.__post_init__rather than deep in the FSDPcode, since the names are config vocabulary.
Validation
On 4 GPUs,
TestMcoreAdapterHybrid— 5 passed:(Replicate, Shard(0))for HSDP and(Shard(0), Shard(0))for HFSDP,on a
("dp_outer", "dp_shard")meshso splitting the domain leaves the math unchanged
on
("expert_dp",), and nothing else — experts never acquire an outer axistest_mcore_adapter.pyis 11 passed; withtest_param_and_grad_buffer.py, 108 passed /4 skipped, since the new config validation runs on every
DistributedDataParallelConfig.🤖 Generated with Claude Code