Add "offline" data cache generation support
State: closed | Pull request: yes
Labels: name: NLP

name: Run CICD

# What does this PR do ?

1. Adds "offline" data cache generation support. The training script will be stopped once data cache is generated.
2. Enable mcore's `num_dataset_builder_threads` param usage.



**Collection**: [Note which collection this PR will affect]

# 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**:
- [ ] Make sure you read and followed [Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md)
- [ ] Did you write any new necessary tests?
- [ ] 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**:
- [x] 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)


What is the reasoning behind overloading num_workers for the num_dataset_builder_threads, instead of passing num_dataset_builder_threads in as a separate config parameter? 

I could imagine a case where I set num_dataset_builder_threads to a very large number (64 or 128) but wouldn't want that many workers during the typical data loading. That would allow many workloads to specify a high num_dataset_builder_threads without needing to explicitly use the data_cache_generation_only offline step.

Instead I would suggest num_dataset_builder_threads as an explicit new parameter in megatron_gpt_config.yaml, and default it to 1 to mirror https://github.com/NVIDIA/Megatron-LM/blob/e33c8f78a35765d5aa37475a144da60e8a2349d1/megatron/core/datasets/blended_megatron_dataset_config.py#L48

> What is the reasoning behind overloading num_workers for the num_dataset_builder_threads, instead of passing num_dataset_builder_threads in as a separate config parameter?
> 
> I could imagine a case where I set num_dataset_builder_threads to a very large number (64 or 128) but wouldn't want that many workers during the typical data loading. That would allow many workloads to specify a high num_dataset_builder_threads without needing to explicitly use the data_cache_generation_only offline step.
> 
> Instead I would suggest num_dataset_builder_threads as an explicit new parameter in megatron_gpt_config.yaml, and default it to 1 to mirror https://github.com/NVIDIA/Megatron-LM/blob/e33c8f78a35765d5aa37475a144da60e8a2349d1/megatron/core/datasets/blended_megatron_dataset_config.py#L48

thank you for the review, fixed.