feat(checkpoint): TP recomputation communication optimization

[li126com]

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.

Motivation

Refer to mindspeed:

When tensor parallelism is enabled, an AllReduce operation is inserted at the end of the forward pass. In the backward pass, this corresponds to an Identity operation. Since recomputation is only used to retrieve intermediate activation values, the output of the AllReduce at the end of the recomputation is redundant. Therefore, the AllReduce at the end can be removed without affecting the intermediate calculations or subsequent backward calculations.

When sequence parallelism is enabled, a ReduceScatter communication is inserted at the end of the forward pass, and an AllGather communication is inserted in the backward pass. During recomputation, the ReduceScatter communication can be directly removed. Additionally, since the gradient at the very end is not related to recomputation, the AllGather in the backward pass can overlap with the forward recomputation. This is illustrated in the diagram below.

7B tp=4 checkpoint tgs:
mtp: 2215->2269
msp: 2309->2336

Loss

BC-breaking (Optional)

Does the modification introduce changes that break the backward compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.

Use cases (Optional)

If this PR introduces a new feature, it is better to list some use cases here and update the documentation.

Checklist

Before PR:

• Pre-commit or other linting tools are used to fix the potential lint issues.
• Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
• The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
• The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

• If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects.
• CLA has been signed and all committers have signed the CLA in this PR.

[sunpengsdu]

这样会不会很hardcode?