如何评价字节跳动开源的高性能分布式训练框架BytePS？
BytePS就是一种新的实现allreduce的手段（增加bandwidth server，如果我们认为allreduce必须是MPI中的那种实现（多个进程，把每个进程的数据完成累加后又广播给各个进程），那么BytePS就不是allreduce。我倾向于前面那种理解。
我们知道Allreduce可以分成两步ReduceScatter和AllGather两个阶段实现，如果像MPIl的allreduce那样，不借助额外的bandwidth server，那么ReduceScatter和AllGather的通信量和ring allreduce是一样的。
当引入额外的bandwidth server后，ReduceScatter 到bandwidth server上去，再从bandwidth server上AllGather，就可以带来BytePS的好处了，可以把每个worker的数据分成很多段，每一段都经过ReduceScatter和AllGather，前一段的AllGather和后一段的ReduceScatter 恰好反方向，不抢占带宽，可以重叠起来（流水），这样从worker视角来看，需要传输的数据是ring allreduce的一半，而又能把worker的上下行带宽用满，所以理论上BytePS可以比ring allreduce快一倍。（需要注意：1，每一段在做reducescatter 或allgather 时，内部还会分段；2，这种reducescatter 和allgather 的实现会因为bandwidth contention 稍微影响性能。）
这里的关键是：1，引入额外的bandwidth server，2，把ReduceScatter和AllGather 流水起来。
因此，使用BytePS要见到效果，必须引入一些纯CPU节点扮演bandwidth server的角色。这一定程度上相当于给那些带有gpu的worker增加了网卡。但这里需要注意的是，在gpu集群里，worker和worker之间的带宽通常是比较高的，譬如100Gbps，而gpu节点和额外的cpu集群之间的带宽通常没有这么高，可能只有25Gbps，这种情况BytePS 就不是比ring allreduce快一倍，而是慢一倍了，因为在ReduceScatter和AllGather过程只能打满25Gbps的带宽，相比ring allreduce通信量减少一半，带宽减少变成1/4了，反而会慢一倍。
这项工作还是引入一些新的认识（至少对我如此）：以前我也分析过有额外ps的开销，但那时没有想到可以把ReduceScatter和AllGather重叠起来，所以当时的结论是加额外ps，虽然通信量减少一半，但对带宽利用率也变成1/2了，那么和ring allreduce完成时间还是一样的，所以ps没有好处。BytePS通过把ReduceScatter和AllGather流水起来，实现了比ring allreduce快一倍的可能性，这是BytePS的新贡献。
