Remove Triton cache manager patch

[janEbert]

Even the older LTS container uses a recent enough Triton version these days.

Fix #3239.

What does this PR do ?

Remove the Triton cache manager, since it is no longer required.

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

Feel free to message or comment the @mcore-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

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.

[duncanriach]

Thinking about this some more. It seems like there are still some race conditions and issues that show up when trying to build the cache from multiple ranks at the same time, and the rate of failure makes it a problem when the number of ranks is greater than 128. I expected at some point to possibly circle back and try to address that. That might involve patching the cache manager in a different way. For now, we have the workaround of building the cache locally, and there might be a good solution that involves building it on all ranks locally apart from one rank, and then, once it's built, sharing it across all ranks. That solution would not require patching the cache manager. But the point is that there are still unresolved issues here, and there might need to be a cache manager patch added again at some point in the future, but I still think it's best to remove this now because it's no longer relevant.

[janEbert]

I've seen the same problems with non-Megatron code as well; ideally Triton could fix these issues upstream. But I agree that having a patch solution in the meantime would be worthwhile. Do you think it makes sense to follow up on creating a patch that addresses the race condition(s) at this point?

[duncanriach]

I think it would be worth investigating and fixing the remaining issues. I don't know whether that would necessarily mean having a patch or just an upstream fix. The problem is that when compiling on more than 128 ranks, with a cache on a shared disk, there are still too many failures to make it usable. The current WAR is to use the local disk for each rank, but then we don't get to reuse the cache on subsequence runs