Clip mtp grads separately when mtp_detach_heads=True

[yfw]

What does this PR do ?

Clip MTP gradients independently when mtp_detach_heads=True

When MTP heads are detached from the main model (mtp_detach_heads=True), the MTP parameter gradients can have very different magnitudes from the main model gradients. Clipping them together using a single global grad norm leads to either under-clipping MTP grads or over-clipping main model grads.

This PR separates MTP gradient clipping from the main model by:

• Tagging all MTP block parameters with is_mtp_param=True so the optimizer can distinguish them
• Refactoring get_main_grads_for_grad_norm into a shared _filter_grads_for_norm helper that accepts a parameter filter predicate
• Computing and clipping MTP gradient norms independently from the main model gradient norm
• Propagating the is_mtp_param attribute through Float16OptimizerWithFloat16Params and DistributedOptimizer param copies
• Applying grad_norm_skip_threshold independently to MTP grads in ChainedOptimizer
• Exposing mtp_grad_norm on the optimizer for external logging

Note: This PR is part of a related series of MTP post-training improvements. They should be reviewed and merged in the following order, as each builds on the previous:

1. #3460 — Skip gradient updates when grad norm exceeds threshold
2. #3459 — Add separate mtp_grad_scale_func for MTP loss scaling
3. #3458 — Roll input IDs for MTP labels in RL mode
4. #3457 — Add MTP acceptance rate metrics
5. #3456 — Detach MTP heads from the main model
6. → #4116 — Clip MTP gradients independently when mtp_detach_heads=True (this PR)

⚠️ For major changes (either in lines of code or in its impact), please make sure to first share a design doc with the team. If you're unsure what's the best way to do so, contact the @mcore-oncall.

Contribution process

Pre-checks

• 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

Feel free to message or comment the @mcore-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!

All PRs start as draft. If you open a non-draft PR, it will be automatically converted to draft.

Step 1: Mark PR as "Ready for Review"

1. When your PR is ready, click Ready for Review.
2. An oncall reviewer is auto-assigned and expert reviewers are notified based on your changes.
   • Some PRs may jump straight to step 2. This is determined by .github/CODEOWNERS.

⚠️ Only mark as ready once merge-conflicts are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

Step 2: Final Review

For PRs that change megatron/core, once all expert reviewers have approved, the Final Review label is applied automatically and final reviewers are assigned.

For PRs outside megatron/core, this step is skipped.

Step 3: Approved

Once all required reviewers have approved, the Approved label is applied automatically.

Merge

Any member of mcore-engineers will be able to merge your PR.

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.

[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.

[github-actions]

This PR has been automatically converted to draft because all PRs must start as drafts.

When you are ready for review, click Ready for Review to begin the review process. This will:

1. Add the oncall reviewer (optional reviewer)
2. Add required review teams based on your changes

See the contribution guide for more details.