[Dev] feat: hybrid-cp for dev branch (part 2)

[xiaoyao0115]

This PR is the second part of hybrid-cp. The first part is: #2054
（PR for main branch: #2304 ）

Compared to part 1, this PR adds the following:​

• Added support for SFT datasets and sequence packing, along with a script. With these additions, hybrid-cp can run end-to-end.​ Convergence has been verified on qwen3-30B on 32 GPUs, with max_seqlen is set to 12288, and max_seqlen_per_dp_cp_rank is set to 3072. In the figure below, 'bshd' refers to running with CP=4, where sequences are padded to max_seqlen and executed in the same bshd format as in pretraining. 'thd-packing' refers to using CP=4 while packing variable-length sequences. In 'hybrid-cp', the maximum CP group size is also 4.

• Added a mock SFT dataset that lets users control sequence lengths by specifying a sequence-length distribution or by providing a file containing sequence lengths.​
• Migrated the hybrid-cp and sequence packing changes into a dataiterator_wrapper to minimize code changes. Adding a new scheduling algorithm now only requires adding a new scheduler class, which keeps the logic clear and easier to maintain.​
• Added support for FSDP with hybrid-cp; the loss curve is shown below.(model : Qwen3-30B-A3B, hybrid-cp size : 4)
• Added support for PP, but does not support for FSDP+PP.

There's many improvements that we want to make in the future releases.

1. The feature is limited to creating dynamic groups of CP of power 2. We hope to add complete dynamic support using changes in TransformerEngine DPA.
2. The feature does not support CUDA graphs.
3. The feature works best with FlashAttention instead of cuDNN FusedAttention. This is because the changing lengths and CP size make cuDNN recompile the graph and all performance gains are lost. We'll advocate for dynamic support to cuDNN FusedAttention.

Contribution process

flowchart LR
    A[Pre-checks] --> B[PR Tests]
    subgraph Code Review/Approval
        C1[Expert Review] --> C2[Final Review]
    end
    B --> C1
    C2 --> D[Merge]

Loading

Pre-checks

• I want this PR in a versioned release and have added the appropriate Milestone (e.g., Core 0.8)
• I have added relevant unit tests
• I have added relevant functional tests
• I have added proper typing to my code Typing guidelines
• I have added relevant documentation
• I have run the autoformatter.sh on my PR

Code review

The following process is enforced via the CODEOWNERS file for changes into megatron/core. For changes outside of megatron/core, it is up to the PR author whether or not to tag the Final Reviewer team.

For MRs into `main` branch

(Step 1): Add PR label Expert Review

(Step 2): Collect the expert reviewers reviews

1. Attach the Expert Review label when your PR is ready for review.
2. GitHub auto-assigns expert reviewers based on your changes. They will get notified and pick up your PR soon.

⚠️ Only proceed to the next step once all reviewers have approved, merge-conflict are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

(Step 3): Final Review

1. Add Final Review label
2. GitHub auto-assigns final reviewers based on your changes. They will get notified and pick up your PR soon.

(Optional Step 4): Cherry-pick into release branch

If this PR also needs to be merged into core_r* release branches, after this PR has been merged, select Cherry-pick to open a new PR into the release branch.

For MRs into `dev` branch

The proposed review process for `dev` branch is under active discussion.

MRs are mergable after one approval by either eharper@nvidia.com or zijiey@nvidia.com.

Merging your PR

Any member of core-adlr and core-nemo will be able to merge your PR.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[yanring]

Is there any difference between this and #2054?

[kunlunl]

Is there any difference between this and #2054?

This is the second MR, we need to merge 2054 first, and then this 2000 (The reason the second MR is 2000, while the first one is 2054 (>2000), is because they were migrated from GitLab at different times)

[yanring]

Is there any difference between this and #2054?

This is the second MR, we need to merge 2054 first, and then this 2000 (The reason the second MR is 2000, while the first one is 2054 (>2000), is because they were migrated from GitLab at different times)

Got it, thanks! Could you please update the title to reflect this?

[kunlunl]

/ok to test e0c90c5

[kunlunl]

/ok to test a9def58

[kunlunl]

/ok to test d12ccf1

[kunlunl]

/ok to test 86581cd

[yanring]

Please move these validations into transformer_config.

[yanring]

Could you please clarify why these were removed?

[kunlunl]

To support pp, it would become more complex, so the thd related logic was moved to a new separate function get_batch_on_this_rank_for_sequence_packing.

[kunlunl]

The thd logic was added in the part-1 PR, it's just back to how it was before.

[yanring]

Could we put this big change in a separate file?

[kunlunl]

This data_schedule.py should be the separate file you want, it was included in the part-1 PR.

[ericharper]

@asolergi-nv FYI