Gtp refit support

[wdykas]

• I, the PR author, have personally reviewed every line of this PR.

What does this PR do?

This is tested and I review but is AI generated to support GTP refit natively. It also greatly simplifies the planner. The majority of the actual line changes are testing related and naming.

⚠️ 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 @NVIDIA/mcore-oncall.

Issue tracking

For PRs from open-source community contributors:

• New features: a linked issue is required. Please open a feature request and reference it here before submitting the PR.
• Small updates (bug fixes, minor improvements): a linked issue is recommended and will accelerate the PR review process.

Linked issue:

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 @NVIDIA/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.

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

[wdykas]

/ok to test 2386a45

[wdykas]

/claude strict-review

[wdykas]

/claude strict-review

[claude]

Strict review passed — no significant issues found. LGTM

Traced the new logical-coordinate shard planner (shard_planner.py), the quantized-staging changes in execution.py, GTP metadata extraction in utils.py, and the cache-key/config-tuple widening in refit.py, cross-checking against the external gtp_api, fp8_utils, and parallel_state APIs they depend on.

Highlights:

• Algorithm correctness: The intersection-in-global-coordinates approach unifies replicated / column-TP / row-TP / strided / packed / GTP / TP×GTP layouts. Verified strided interleaving ([0,1,0,1]), GTP padding spanning multiple shards, and combined packed+GTP+padding cases by hand — all consistent with the tests.
• Safer than the code it replaces: the transferred == expected coverage guard and the overlapping-destination guard make the planner fail loudly on incomplete/duplicate coverage instead of silently mis-tiling.
• with_gtp_remat=False is correct: refit needs the replicate DP group (identical weights), not gtp_remat peers (distinct shards); identical to the old group for non-GTP configs, so no regression.
• Quantized staging: BF16 accumulation buffer is zeroed only when the GTP shard carries padding, keeping non-GTP MXFP8 behavior (torch.empty) unchanged; padding rows are excluded from transfers and neutralized before a single quantize_.
• No unused new identifiers; no stale references to the removed _plan_tp/_finalize_dp_transfers/descriptor helpers; ShardingDescriptor retained for import compat.
• Cache-key change is in-memory only — no checkpoint/persistence backward-compat impact.

Risk level: low. Clean, well-tested refactor that adds GTP support while simplifying the planner.

[kvareddy]

@fanshiqing can you please take a look at this MR?