PatrickStar
PatrickStar copied to clipboard
Tencent
我们真的需要模型并行（MP）么？
MP的风潮是Megatron-LM引入到PTM训练中的，通过对transformer的实现插入定制的集合通信操作，实现了模型切分。 模型并行有很多诟病，
- 在FWD和BWD都有大量的activations全局通信，通信量和batch size成正比。不仅通信量大于DP，还限制了batch size从而限制MP训练的计算负载规模，影响了计算性能（越大batch计算效率越高）。
- MP需要对model定义代码进行定制修改。因此DeepSpeed的Example中也是在Megatron-LM基础上改的。有一些工作尝试简化这个修改工作，比如Mesh-TensorFlow和阿里巴巴的Whale，PyTorch似乎没有相关工作。如果从刷性能角度，这样并无大碍。如果从使用角度，算法同学不会接受的，因为推理端的代码还需要把自定义并行算子转化成PyTorch串行的。
- 在HP（异构并行），MP，PP，DP等组合下，MP的用法已经非常局限，并有被替代之势。DeepSpeed吧MP被安排在节点内并行，PP和DP用在节点间。HP+DP的引入，让GPU内存墙被进一步打破，模型并行的主要优势正在被HP和ZeroDP代替，以后节点内是否继续用MP都不一定。
MP and PatrickStar
在PatrickStar中，显存的最大消耗量和chunk size有关，即使不使用异构存储空间，把所有chunk都放在gpu中，model data的尺寸也是原来的1/N，和MP消耗类似。PatrickStar和PP兼容即可，不需要兼容MP。 之前Zero-Offload会去兼容MP，这是很奇怪的。阅读代码，我觉得是因为Zero3的通信用了非常差的设计，需要临时在gpu分配world_size*tensor_numel大小的临时buffer，加上预取的存在，可能同时分配了多个这样的buffer，尤其对于embedding layer这种大参数层，可能会爆炸内存，因此需要用MP减少单个进程的tensor_numel。
模型并行这里我认同您的观点。Mesh-Tensorflow 这样的方案会比较难推给用户，可能短期内只需要有 Megatron-LM 的那种针对 transformer 的切分方式就够了。
不过最后的 chunk 那里的 1/n 我没太懂，是说每个参数都切分完放在各自进程内的 chunk 中，在使用的时候先 allgather 吗？
模型并行这里我认同您的观点。Mesh-Tensorflow 这样的方案会比较难推给用户，可能短期内只需要有 Megatron-LM 的那种针对 transformer 的切分方式就够了。
不过最后的 chunk 那里的 1/n 我没太懂，是说每个参数都切分完放在各自进程内的 chunk 中，在使用的时候先 allgather 吗？
是的，我觉得用zeroDP没必要用MP了。当然很多人不一定认同，还有很多人靠N-D并行吃饭
嗯，这个主要考虑需求吧。如果需求就是单纯的垒 transformer 最多能垒多少，那 MP 还是有优势的，毕竟只有 MP 可以拆分参数部分。但是如果考虑的是一般用户的应用，zeroDP 即插即用，要方便太多了
其实我觉得派大星和 MP 也不是矛盾的...用派大星劫持一下 Megatron-LM 的存储，不就相当于完成了 MP 了吗？所以我感觉和 deepspeed 中的 zero 一样，派大星的功能也是可以和 Megatrol-LM 这样的方案正交的。（可能额外需要把 allgather 改成 chunk 的 allgather 就是了）
加MP从实现角度肯定是没问题的，但是我们要考虑性价比的问题，在足够的人力和时间下，我们肯定也会把4D，5D都做出来。 我们现在任务是要梳理出一个优先级，把精力优先投入到最优利于用户使用和性能提升的技术上。
我觉得MP很鸡肋，我刚刚用DeepSpeed跑了一些实验结果 可以观察6B mp2的数据，和DP对比，性能下降很严重 【腾讯文档】PatrickStar_V100_profiling https://docs.qq.com/sheet/DYWhORUNtREd1aGt0