support to sync params when train_tp divides inference_tp.

[charles9304]

No description provided.

[haolin-nju]

Anyway，我觉得我这边review的意见可以分成如下几点：

1. TP不对等情况下broadcast是不是在做两阶段的通信？如果追求性能，是不是也需要像TP对等一样实现P2P的通信，再对比P2P和两阶段broadcast的最终效果呢？
2. 现在直接上两阶段broadcast的话整体看下来代码比较复杂，如果业务方需求dst_tp < src_tp，或者有一个新的模型定义，可能要对代码进行二次改动，维护成本比较高
3. 代码的封装和解耦可能需要再细化一下
4. 2 stage的param sync缺少UT，Regression Test成本较高且很难暴露corner case

[haolin-nju]

Anyway，我觉得我这边review的意见可以分成如下几点：

1. TP不对等情况下broadcast是不是在做两阶段的通信？如果追求性能，是不是也需要像TP对等一样实现P2P的通信，再对比P2P和两阶段broadcast的最终效果呢？
2. 现在直接上两阶段broadcast的话整体看下来代码比较复杂，如果业务方需求dst_tp < src_tp，或者有一个新的模型定义，可能要对代码进行二次改动，维护成本比较高
3. 代码的封装和解耦可能需要再细化一下
4. 2 stage的param sync缺少UT，Regression Test成本较高且很难暴露corner case

Resolved:
问题1/2: TP不对等的场景下，p2p不可行，会出现同个GPU send/recv的操作，这个在nccl通信是不支持的。

问题3：之前沟通的时候，建议将tp对等和非对等场景代码分开。也是担心改动影响tp对等场景。所以这版一些能共用的代码我也没有分开，暂时先不做改动，后面再慢慢合并两个场景的支持吧

问题4 ut/ft正准备专门提一个CI

[charles9304]

support for mcore model: #105