[dist checkpointing] Enable filtering common state dict keys before megatron core consistency check
State: open | Pull request: yes
Labels: name: Run CICD

# What does this PR do ?

Megatron core distributed checkpointing gathers the common state dict and compares values across ranks to ensure they are consistent. By default, non-tensor values get accumulated there, but certan application-specific data will differ across ranks. Megatron core offers the `preprocess_common_before_consistancy_check` option as part of saving to handle this type of filtering. 

This PR adds a function to remove values known to be different across ranks from consideration during the consistency check. For now, this hardcodes removing the Timer Callback states from the consistency check, but the function can be extended if/when more such cases emerge.

Now warnings like the following will no longer be logged:
```
[NeMo W 2024-12-02 11:45:59 validation:387] There is difference in the common state dict in different ranks. The differences are {1: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)]), 2: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)]), 3: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)]), 4: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)]), 5: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)]), 6: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)]), 7: ([], [], [(('callbacks', 'Timer', 'time_elapsed', 'train'), <class 'float'>, <class 'float'>), (('callbacks', 'Timer', 'time_elapsed', 'validate'), <class 'float'>, <class 'float'>)])}
```

**Collection**: N/A

# Changelog 
- Add specific line by line info of high level changes in this PR.

# Usage
* You can potentially add a usage example below

```python
# Add a code snippet demonstrating how to use this 
```

# GitHub Actions CI

The Jenkins CI system has been replaced by GitHub Actions self-hosted runners.

The GitHub Actions CI will run automatically when the "Run CICD" label is added to the PR.
To re-run CI remove and add the label again.
To run CI on an untrusted fork, a NeMo user with write access must first click "Approve and run".

# Before your PR is "Ready for review"
**Pre checks**:
- [x] Make sure you read and followed [Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md)
- [x] Did you write any new necessary tests?
- [x] Did you add or update any necessary documentation?
- [ ] Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)
  - [ ] Reviewer: Does the PR have correct import guards for all optional libraries?
  
**PR Type**:
- [ ] New Feature
- [ ] Bugfix
- [ ] Documentation

If you haven't finished some of the above items you can still open "Draft" PR.


## Who can review?

Anyone in the community is free to review the PR once the checks have passed. 
[Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md) contains specific people who can review PRs to various areas.

# Additional Information
* Related to # (issue)


just curious why the TImerCallback is inconsistent across ranks? also, if it's inconsistent, but goes in the common state, is only one rank's state saved? does that affect restore?



> just curious why the TImerCallback is inconsistent across ranks? 

The times aren't synchronized across ranks, so aren't expected to be the exact same: https://github.com/Lightning-AI/pytorch-lightning/blob/master/src/lightning/pytorch/callbacks/timer.py

> also, if it's inconsistent, but goes in the common state, is only one rank's state saved? does that affect restore?

yes, if saving with mcore dist checkpointing, only the values fraom rank 0 are saved and restored. This means timing stats are not consistent after a checkpoint restore as the times for non rank-0-ranks are reset with the values from rank 0

This PR is stale because it has been open for 14 days with no activity. Remove stale label or comment or update or this will be closed in 7 days.

This PR was closed because it has been inactive for 7 days since being marked as stale.