和DeepSpeed兼容

[feifeibear]

派大星的使命通过开源让PTM训练民主化，因此我们必须要让deepspeed的接口足够简单，并保证精度和某个广受认可的训练框架一致。广受认可的框架有几个选项

1. PyTorch ZeroRedundancyOptimizer
2. Zero系列 DeepSpeed

我们可以选择融入到deepspeed的生态中，具体来说就是精度和DeepSpeed对齐，尽可能小改动的去把派大星的弄到deepspeed里面去，有如下原因

1. deepspeed是目前PTM训练的无法绕开的baseline，不仅有多篇顶级会议论文发表，用户如果寻求PTM训练时，优先会尝试DeepSpeed。
2. deepspeed是微软内部大团队开发的，不仅涉及并行训练，还有量化稀疏，推理加速等一些工具选择。融入这个生态，意味着我们也可以享受这些技术的进步，复用deepspeed的功能组件。

[zhuzilin]

我的想法大致是这样的。

回顾 deepspeed 的 zero 系列，其中心是和 data parallel 绑定的。

• 最初的 Zero 提出了 Zero-DP 和 Zero-R，前者就是把 allreduce 拆分成 reduce-scatter + allgather，从而缩减优化器状态，后者则是拆分存储 activation，在反向重计算的时候再 allgather。这两部分都提到了可以 offload 到 CPU 上，但是应该是整体搬运，甚至是在训练前就配置好参数的。
• 之后提出的 Zero-Offload 提出的重点是更新参数的计算放在 CPU 上也行，从而把除了模型参数以外的部分都放在 CPU 上。
• 最后的 Zero-Infinity 则是走回最初的 Zero，进一步升级，把模型拆分好后直接存在硬盘(NVMe)上，然后前向计算的时候 allgather。

这里面第一篇和第三篇都是和数据并行强绑定的，核心是通信优化；而只有第二篇是从单机出发，核心是存储，然后提到可以兼容 ZeroDP。所以虽然 Zero-Offload 也是 Zero 系列的一员，但是和他的兄弟们可能没有那么亲，是可以单独取出来的技术方案。

而派大星实际上是 Zero-Offload 的极致加强版，动态地管理存储状态，从而在单卡上可以尽可能地提升模型的规模（或者固定模型的执行效率）。所以我觉得其实派大星和 Zero 系列的关系其实是替代 Zero-Offload，并和 Zero 正交。至于 Zero-Infinity，我觉得这种会用 NVMe 的方案是不是真的有实用价值还有待观察...

根据这个原因，我觉得我们其实没有必要把派大星合进 deepspeed 中，只需要为用户准备好“在用了 deepspeed(Zero) 的情况下该怎么引入派大星”的方案就行了。这样方便把派大星把显存管理这个事儿做到极致，做成一个功能精确且精美的库。

另外，从工程角度看，我个人感觉 deepspeed 还是比较像是学术型的项目，里面的工程设计并不是很好...（比如说一个 get_args 当全局变量满天飞...）也没有做好对外的接口。我比较担心我们没法把派大星做成一个 deepspeed 的插件，而是要维护一个派大星版的 deepspeed，那样的维护工作量就比较大了。

我也不太清楚 deepspeed 是不是已经形成生态了，对于其中的一些和大模型相对分离的功能，我觉得很有可能会被其余的算法库甚至是 pytorch 官方复现，以一个更简单的方式供用户使用。

[feifeibear]

我的想法大致是这样的。

回顾 deepspeed 的 zero 系列，其中心是和 data parallel 绑定的。

• 最初的 Zero 提出了 Zero-DP 和 Zero-R，前者就是把 allreduce 拆分成 reduce-scatter + allgather，从而缩减优化器状态，后者则是拆分存储 activation，在反向重计算的时候再 allgather。这两部分都提到了可以 offload 到 CPU 上，但是应该是整体搬运，甚至是在训练前就配置好参数的。
• 之后提出的 Zero-Offload 提出的重点是更新参数的计算放在 CPU 上也行，从而把除了模型参数以外的部分都放在 CPU 上。
• 最后的 Zero-Infinity 则是走回最初的 Zero，进一步升级，把模型拆分好后直接存在硬盘(NVMe)上，然后前向计算的时候 allgather。

这里面第一篇和第三篇都是和数据并行强绑定的，核心是通信优化；而只有第二篇是从单机出发，核心是存储，然后提到可以兼容 ZeroDP。所以虽然 Zero-Offload 也是 Zero 系列的一员，但是和他的兄弟们可能没有那么亲，是可以单独取出来的技术方案。

而派大星实际上是 Zero-Offload 的极致加强版，动态地管理存储状态，从而在单卡上可以尽可能地提升模型的规模（或者固定模型的执行效率）。所以我觉得其实派大星和 Zero 系列的关系其实是替代 Zero-Offload，并和 Zero 正交。至于 Zero-Infinity，我觉得这种会用 NVMe 的方案是不是真的有实用价值还有待观察...

根据这个原因，我觉得我们其实没有必要把派大星合进 deepspeed 中，只需要为用户准备好“在用了 deepspeed(Zero) 的情况下该怎么引入派大星”的方案就行了。这样方便把派大星把显存管理这个事儿做到极致，做成一个功能精确且精美的库。

另外，从工程角度看，我个人感觉 deepspeed 还是比较像是学术型的项目，里面的工程设计并不是很好...（比如说一个 get_args 当全局变量满天飞...）也没有做好对外的接口。我比较担心我们没法把派大星做成一个 deepspeed 的插件，而是要维护一个派大星版的 deepspeed，那样的维护工作量就比较大了。

我也不太清楚 deepspeed 是不是已经形成生态了，对于其中的一些和大模型相对分离的功能，我觉得很有可能会被其余的算法库甚至是 pytorch 官方复现，以一个更简单的方式供用户使用。

讲的有道理，那我们就参考deepspeed，不去整合它把。可能PatrickStar也会没人用，但是一个chunk-based memory-manager或者一个chunk-based communication library可活下来。我们再开发过程中可以把这些模块逐步拆出来维护。

[feifeibear]

https://github.com/feifeibear/HybridPS/blob/main/tests/test_bert.py#L136
这个接口可以简化成
model, optimizer = initialize_engine( model_provider= model_def_func(), config = a config json or a config file, which defines hyper params and a optimizer)