Fix stale parameter index map in DistributedOptimizer#2872
Open
ahmadki wants to merge 2 commits intoNVIDIA:mainfrom
Open
Fix stale parameter index map in DistributedOptimizer#2872ahmadki wants to merge 2 commits intoNVIDIA:mainfrom
ahmadki wants to merge 2 commits intoNVIDIA:mainfrom
Conversation
ahmadki
force-pushed
the
ahmadki/issue_2777
branch
from
c957986 to
543579d
Compare
Member
|
/ok to test bfe8a04 |
Phlip79
approved these changes
Jan 12, 2026
Member
Phlip79
left a comment
Phlip79
left a comment
There was a problem hiding this comment.
Thanks for the comments and tests!
Phlip79
added
Final Review
During mixed-precision training, model_param_group_index_map becomes stale after parameters are reordered by dtype. The map is initialized based on original parameter order, but _build_model_and_main_param_groups reorders parameters (FP32 first, then FP16/BF16) for checkpoint consistency. The map was never updated to reflect this reordering. This caused get_parameter_state_dp_zero to access wrong parameters when saving checkpoints, resulting in size mismatch errors. Solution: Rebuild model_param_group_index_map after parameter reordering to keep it synchronized with optimizer.param_groups. Fixes NVIDIA#2777
Parameter shards should never participate in autograd, inconsistent with FP16/BF16
ahmadki
force-pushed
the
ahmadki/issue_2777
branch
from
bfe8a04 to
537fa1a
Compare
asolergi-nv
reviewed
Jan 13, 2026
Comment on lines
+586
to
+625
| (self.model_param_group_index_map, self.opt_group_ranges) = ( | ||
| self._build_optimizer_group_ranges(self.optimizer.param_groups, self.gbuf_ranges) | ||
| ) | ||
|
|
||
| # Allocate main param shards. | ||
| ( | ||
| self.model_float16_groups, | ||
| self.model_fp32_groups, | ||
| self.shard_float16_groups, | ||
| self.shard_fp32_groups, | ||
| self.shard_fp32_from_float16_groups, | ||
| ) = self._build_model_and_main_param_groups( | ||
| self.gbuf_ranges, self.model_param_gbuf_map, self.opt_group_ranges, config | ||
| ) | ||
|
|
||
| if isinstance(self.optimizer, HybridDeviceOptimizer): | ||
| self.optimizer = HybridDeviceOptimizer( | ||
| params=[g["orig_group"] for g in self.opt_group_ranges], **self.optimizer.defaults | ||
| ) | ||
| else: | ||
| self.optimizer.param_groups = [g["orig_group"] for g in self.opt_group_ranges] | ||
| self.optimizer.load_state_dict(self.optimizer.state_dict()) | ||
|
|
||
| # Rebuild model_param_group_index_map to reflect parameter reordering. | ||
| # The _build_model_and_main_param_groups method reorders parameters by dtype | ||
| # (FP32 first, then FP16/BF16), so we need to update the mapping to match | ||
| # the new positions in optimizer.param_groups. | ||
| for group_index, group_range in enumerate(self.opt_group_ranges): | ||
| param_order = 0 | ||
| # First, add FP32 params (in the same order as they appear in group_range["params"]) | ||
| for model_param in group_range["params"]: | ||
| if model_param.type() == 'torch.cuda.FloatTensor': | ||
| self.model_param_group_index_map[model_param] = (group_index, param_order) | ||
| param_order += 1 | ||
| # Then, add FP16/BF16 params (in the same order as they appear in group_range["params"]) | ||
| for model_param in group_range["params"]: | ||
| if model_param.type() in ['torch.cuda.HalfTensor', 'torch.cuda.BFloat16Tensor']: | ||
| self.model_param_group_index_map[model_param] = (group_index, param_order) | ||
| param_order += 1 | ||
|
|
Contributor
There was a problem hiding this comment.
Wouldn't it be possible to directly build model_param_group_index_map in the desired order in _build_optimizer_group_ranges?
Contributor
|
/ok to test 537fa1a |
deepakn94
reviewed
Jan 29, 2026
| # (FP32 first, then FP16/BF16), so we need to update the mapping to match | ||
| # the new positions in optimizer.param_groups. | ||
| for group_index, group_range in enumerate(self.opt_group_ranges): | ||
| param_order = 0 |
deepakn94
reviewed
Jan 29, 2026
| # First, add FP32 params (in the same order as they appear in group_range["params"]) | ||
| for model_param in group_range["params"]: | ||
| if model_param.type() == 'torch.cuda.FloatTensor': | ||
| self.model_param_group_index_map[model_param] = (group_index, param_order) |
Contributor
There was a problem hiding this comment.
Does this have repercussions on DDP's param_index_map too?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do ?
During mixed-precision training, model_param_group_index_map becomes stale after parameters are reordered by dtype. The map is initialized based on original parameter order, but _build_model_and_main_param_groups reorders parameters (FP32 first, then FP16/BF16) for checkpoint consistency. The map was never updated to reflect this reordering. This caused get_parameter_state_dp_zero to access wrong parameters when saving checkpoints, resulting in size mismatch errors.
Solution: Rebuild model_param_group_index_map after parameter reordering to keep it synchronized with optimizer.param_groups.## Contribution process
Fixes #2777
flowchart LR A[Pre-checks] --> B[PR Tests] subgraph Code Review/Approval C1[Expert Review] --> C2[Final Review] end B --> C1 C2 --> D[Merge]Pre-checks
Core 0.8)Code review
The following process is enforced via the CODEOWNERS file for changes into
megatron/core. For changes outside ofmegatron/core, it is up to the PR author whether or not to tag the Final Reviewer team.For MRs into `main` branch
Feel free to message or comment the @megatron-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!
(Step 1): Add PR label
Expert Review(Step 2): Collect the expert reviewers reviews
Expert Reviewlabel when your PR is ready for review.Final Review might get declined if these requirements are not fulfilled.
(Step 3): Final Review
Final Reviewlabel(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, selectCherry-pickto 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.comorzijiey@nvidia.com.Merging your PR
Any member of core-adlr and
core-nemowill be able to merge your PR.