是否可以接受引入torch.distributed以外的集合通信库？

[hanhan-networking]

最近在将ckpt engine引入到其他系统中，遇到一个通信组的问题：两组资源相对隔离，都有一个由torch.distributed创建的global 通信域，现在引入ckpt engine后，无法从ckpt engine视角看到包括两组资源的global 通信组。我们准备为ckpt engine提供一个pr，引入vllm/sglang(两者都有，到时候以安装的依赖导入)中的支持statelessProcessGroup集合通信库，基于此构建global通信域，不知社区是否会接受？或者有没有其他建议？感谢。

[hanhan-networking]

@specture724 @weixiao-huang 请问有没有什么意见或者建议，感谢

[weixiao-huang]

感觉可能是可以的，当时用 torch 主要是感觉是现成的，足够简单。如果换成类似 statelessProcessGroup 应该也没问题，只是不知道和别的卡（比如华为卡）会不会有兼容上的问题

[x1314aq]

看了下，vllm的statelessProcessGroup缺少一些torch.distributed的特性，主要是new_group()，all_gather_object()，barrier()这三个。

all_gather_object()和barrier()这两个可以用已有的集合通信函数包装一下实现，但new_group()比较困难，除非直接修改PyNcclCommunicator的实现（nccl提供ncclCommSplit()接口）。vllm-ascend上提供的PyHcclCommunicator甚至只实现了all_reduce()和broadcast()两个接口，基本处于残废状态。

sglang的statelessProcessGroup情况跟vllm类似，而且还缺少npu的实现。

现在有2种方案：

1. 引入vllm的PyNcclCommunicator，补上缺失all_gather_object()，barrier()，修改ps.py避免使用new_group()，通过创建第二个通信域来代替new_group()

2. 在checkpoint-engine内重新实现一套集合通信库，可以看下这个PR，目前实现了checkpoint-engine使用的所有torch.distributed特性，但是缺少nccl的实现，计划参考vllm的PyNcclCommunicator。

@weixiao-huang @specture724

[x1314aq]

看了下，vllm的statelessProcessGroup缺少一些torch.distributed的特性，主要是new_group()，all_gather_object()，barrier()这三个。

all_gather_object()和barrier()这两个可以用已有的集合通信函数包装一下实现，但new_group()比较困难，除非直接修改PyNcclCommunicator的实现（nccl提供ncclCommSplit()接口）。vllm-ascend上提供的PyHcclCommunicator甚至只实现了all_reduce()和broadcast()两个接口，基本处于残废状态。

sglang的statelessProcessGroup情况跟vllm类似，而且还缺少npu的实现。

现在有2种方案：

1. 引入vllm的PyNcclCommunicator，补上缺失all_gather_object()，barrier()，修改ps.py避免使用new_group()，通过创建第二个通信域来代替new_group()
2. 在checkpoint-engine内重新实现一套集合通信库，可以看下这个PR，目前实现了checkpoint-engine使用的所有torch.distributed特性，但是缺少nccl的实现，计划参考vllm的PyNcclCommunicator。

@weixiao-huang @specture724

目前看下来，方案一比较稳妥，在现有的基础上增加功能就行，后续增加的这部分功能也可以回合到vllm和vllm-ascend社区。

[weixiao-huang]

其实我感觉主要目的是不要太复杂就行，之前用 nccl 也是尽可能设计得简单并且扩展性也好，引入 PyNcclCommunicator 看起来好像只是重写了部分 nccl 的逻辑？方便说一下引入 PyNcclCommunicator 是如何解决两组相对隔离的资源共同组成 group 的呢？

[hewr2010]

@x1314aq 这个库最好不跟某一个框架做绑定，我会觉得允许第三方把自己的实现注册上来是兼容性比较好的选择。
具体来说，vllm 和 sglang 的 PyNcclCommunicator 几乎没有区别，vllm-ascend 的 PyHcclCommunicator 也是类似的情况，可以插件化 patch 或者各自提 PR 把接口映射出来。
ckpt-engine 仍然默认提供 torch.distributed 的选择就好

[hanhan-networking]

其实我感觉主要目的是不要太复杂就行，之前用 nccl 也是尽可能设计得简单并且扩展性也好，引入 PyNcclCommunicator 看起来好像只是重写了部分 nccl 的逻辑？方便说一下引入 PyNcclCommunicator 是如何解决两组相对隔离的资源共同组成 group 的呢？

简单来说其实就是用另一套集合通信库避免和torch.distributed的冲突。cpkt engine作为子模块引入到其他系统时，如果有原系统也是通过torch的init_process_group构建的通信域，那么两组资源只能分别看到自己的通信域，例如训练一个通信域，推理一个通信域，而彼此看不到对方，但是ckpt engine需要看到全局资源，故而无法正常运行。而此时，如果我们引入StatelessProcessGroup，相当于ckpt engine自己独立构建通信域，此时原系统两组资源可以不改任何逻辑正常跑。下面引用一下StatelessProcessGroup的create函数注册，对于理解可能有帮助：

    A replacement for 'torch.distributed.init_process_group' that does not
    pollute the global state.
    
    If we have process A and process B called  'torch.distributed.init_process_group'
    to form a group, and then we want to form another group with process A, B, C,
    D, it is not possible in PyTorch, because process A and process B have already
    formed a group, and process C and process D cannot join that group. This
    function is a workaround for this issue.

    'torch.distributed.init_process_group' is a global call, while this function
    is a stateless call. It will return a 'StatelessProcessGroup' object that can be
    used for exchanging metadata. With this function, process A and process B
    can call 'StatelessProcessGroup.create' to form a group, and then process A, B,
    C, and D can call 'StatelessProcessGroup.create' to form another group.

[hanhan-networking]

@x1314aq 这个库最好不跟某一个框架做绑定，我会觉得允许第三方把自己的实现注册上来是兼容性比较好的选择。 具体来说，vllm 和 sglang 的 PyNcclCommunicator 几乎没有区别，vllm-ascend 的 PyHcclCommunicator 也是类似的情况，可以插件化 patch 或者各自提 PR 把接口映射出来。 ckpt-engine 仍然默认提供 torch.distributed 的选择就好

嗯嗯，是的，目前我们也是这么做的，这几天在gpu和npu上测试完备后就会提交pr