Improve performance of request_metadata logic

[tdene]

What does this PR do ?

The current dynamic sampling code relies on code that surrounds the request_metadata tensor in the dynamic context.
Profiling, and A/B timeit testing, shows that this request_metadata code is poorly optimized.

This PR will address 3 issues found by @mathemakitten

1. Copying & dtype-casting GPU tensors takes miliseconds, even with non_blocking=True.
2. Bucketizing a tensor via torch.unique is orders of magnitude slower than doing it via list comprehension.
   3. In order to fix 1) and 2), the "hashed sampling parameters" tracked metadata must be resurrected.

BENCHMARK INFO:

• The "golden" benchmark prior to this PR returns an average value of 81.77, with expected noise of +/- 2%
• The "golden" benchmark after the commit, Split request_metadata 2D tensor into 1D slices, returns an average value of 81.41, with expected noise of +/- 2%. This particular change had a risk of degrading performance, but it does not seem to do so.
• The "golden" benchmark after the commit, Avoid casting/copying request metadata, returns an average value of 84.87, with expected noise of +/- 2%. This particular change was intended to improve performance, and it does.
• The "golden" benchmark after the commit, Replace tensorized bucketization with for loop, returns an average value of 85.95, with expected noise of +/- 2%. This particular change was intended to improve performance, and it does.

Contribution process

flowchart LR
    A[Pre-checks] --> B[PR Tests]
    subgraph Code Review/Approval
        C1[Expert Review] --> C2[Final Review]
    end
    B --> C1
    C2 --> D[Merge]

Loading

Pre-checks

• I want this PR in a versioned release and have added the appropriate Milestone (e.g., Core 0.8)
• 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

The following process is enforced via the CODEOWNERS file for changes into megatron/core. For changes outside of megatron/core, it is up to the PR author whether or not to tag the Final Reviewer team.

For MRs into `main` branch

(Step 1): Add PR label Expert Review

(Step 2): Collect the expert reviewers reviews

1. Attach the Expert Review label when your PR is ready for review.
2. GitHub auto-assigns expert reviewers based on your changes. They will get notified and pick up your PR soon.

⚠️ Only proceed to the next step once all reviewers have approved, merge-conflict are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

(Step 3): Final Review

1. Add Final Review label
2. GitHub auto-assigns final reviewers based on your changes. They will get notified and pick up your PR soon.

(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, select Cherry-pick to 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.com or zijiey@nvidia.com.

Merging your PR

Any member of core-adlr and core-nemo will be able to merge your PR.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

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

[tdene]

/ok to test 5b2bb81