introduction

介绍传统框架的缺点，没有考虑并行，引出后面要讨论并行的问题

深度学习模型变得越来越复杂，越来越大。现存的深度学习框架面对训练大型的深度学习模型也出现了一些挑战，早期的设计没有预料到新出现的需求，比如大模型的PP。

介绍并行，以及其他工作的做法，说明他们的缺点，引出要解决的问题。

取决于神经网络结构和硬件配置，各种并行策略找到了他们的最佳途径。数据并行尤其适合少量参数的深度学习模型（少于1千万参数），一旦梯度/参数反向传播和通信相互掩盖，就可以实现近似线性加速。模型并行和pipeline并行适用于参数明显更多的模型，可能在单设备上无法容纳，或者数据并行的通信代价太高。stanza和DLPlacer训练卷积层采用数据并行，其他层使用模型并行。OptCNN在多个相同设备上通过沿着batch和channel维度切分算子来并行模型训练。TOFU利用partition-n-reduce方法来切分一个单独的算子为子算子，并将子算子部署在多个GPU上，FlexFlow搜索 SOAP空间来利用算子内外的并行性。
一个分布式DL框架应该可以为所有选择的并行策略自动的生成物理执行计划，最小化用户编程影响。更高级别的要求是框架可以自动为所有的NN结构和硬件配置组合找到最好的并行策略。然而，现存的DLC框架甚至无法达到第一个目标，例如灵活地支持多种并行策略。这是我们这篇文章要解决的主要问题，重新设计一个新颖的分布式训练框架。

阐述其他工作都是基于已有的框架进行二次开发，存在局限性

一些新兴的开源项目开发专用的系统或者自定义的库来更好地支持模型或者PP。例如HugeCTR为最流行的模型支持模型并行。Megatron和DeepSpeed支持大型的NLP预训练模型并行。InsightFace训练大尺寸人脸识别模型时使用模型并行。然而这些系统都是为了特定应用而设计的，并不能通用。
Wrappers or plugins在一些主流的DL框架中被使用为了更好地支持更多复杂的并行策略。Mesh——TF在TF的基础上提供一些API给开发者去表示广泛的并行计算pattern。GPip在TF和TORCH上训练大型DNN使用跨分布式设备的pipeline来解决单设备上内存容量有限的问题。FairScale集成了Megatron-LM and DeepSpeed的技术在pytorch上进行模型并行或者流水线并行。这些框架都是最初没有预见这些复杂的并行性需求，做这些增量的改进通常会产生不可忽略的系统开销，并且需要用户进行大量的工程性优化。

介绍论文主要内容

如果能够提前与预知大型AI模型的快速发展，那么分布式编译器的通用设计和有效实现将是什么？系统可以更简单么？在这篇文章中，我们探索了这种可能性，并提出OneFlow，一个从0开始构建的新颖的DNN训练框架。OneFLow包含从编译器到基于actor模型的运行时。采用SBP抽象，允许各种数据并行和模型并行的混合，比现在的框架更加简单的方式。actor模型提供了一种简洁的运行时机制来管理复杂的依赖关系(资源受限，数据移动，分布式训练中的计算)
通过大量的实验证明了oneflow在训练各种大型的DNN模型方面都是通用且高效的，相比于目前最好的系统。结果表明，相比于在现有框架上进行二次开发的库，oneflow这种简单且通用的实现可以与之持平或者更好一点。

background and motivation

主要介绍技术基础

DNN通常被表示为逻辑计算图，然后被手工编程或者编译器自动转换为一个物理计算图，在runtime阶段由一些优化kernels组成。分布式训练引入了一些必须的通信算子来进行设备之前的数据交换。设备间的带宽仍然比设备内的小1-2数量级。然而一个分布式DLC框架应该将数据移动和计算同等重视。

Distributing the Workload in Spatial Domain

Spatial Scheduling 详细说明了如何将ops跨多设备展开，图1介绍了在一个混合并行的例子中一个一个手工放置通信算子是一个工作量很大的事情，当一个新的模型出现时这种复杂的并行性策略制定又是很麻烦的

Distributing the Workload in Temporal Domain

Temporal Scheduling ，DL中的数据流时间策略涉及到安排算子的执行，尤其是为了最大化硬件利用率和系统吞吐。最好的性能提升的机会通常出现在将计算和通信相互掩盖的情况下。

Managing the Complex Dependencies

Dependencies caused by resource sharing

Dependencies caused by data movement

summary

介绍oneflow 编译期和runtime的内容