江苏龙网

  1. 主页 > 生活百科 > >

30名工程师，历时1300天打造，又一“国产”AI框架开源了( 二 )

AI框架


另外，就是要解决编程效率问题，怎么让多机多卡分布式编程更容易，也是OneFlow多机多卡体验的一部分 。
为了满足这个目的，OneFlow趟出了一条其他框架还没有走的路，也就是静态调度和流式执行 。
CSDN：静态调度和流式执行怎么解决问题的？
袁进辉：这跟深度学习算法和异构计算特点相关 。深度学习的任务负载特征跟以前Haddop，Spark面临的计算不一样 。以前很多任务是批式处理，处理整体数据，计算粒度很大，但深度学习是随机梯度下降算法，是非常多小粒度的计算构成，接近流式计算，大数据系统里的Flink、Storm也是流式系统，与那些批式处理系统不一样 。
底层支撑硬件也不一样，深度学习包含大量稠密计算，非常适合高度并行的加速卡，广泛地依赖于异构计算，既有CPU也有加速卡，不是以前的纯CPU集群，GPU等加速器处理更快 。所以，每一片任务过来，都是百毫秒甚至在几毫秒以内差不多就完成了 。
一个作业重包含数十万非常小的转瞬即逝的任务，每个任务粒度非常低，如果系统里面有一丁点不顺畅，可能就成为整个系统的瓶颈，因为所有的小任务都需要等着调度器做决策 。
怎么解决这个问题？我们的思路是根据深度学习本身的特点，发掘出调度规律，让系统在计算发生之前提前得到很多调度的规律的和策略，这种情况下就能把所谓的运行时的那种额外的开销就降到尽可能的低，几乎降到可忽略不计，这就能克服异构的流式计算里非常严峻的挑战 。
流式执行是做什么？在这种任务里的多个卡之间频繁的数据搬运，对整个计算任务来说也是一个非常显著的开销，那流式系统就能提前通过整体规划，在每一次计算发生之前，就把所需要的数据参数都提前取到，通过流水线把数据搬运和计算做完全地重叠 。如果是以前那种批式处理的大数据系统，就没法做到 。
所以，OneFlow的思路就是做一个偏静态调度和流式执行的系统 。
CSDN：针对多机多卡的问题，除了OneFlow提出的解决路径，市面上其他框架怎么做的？
袁进辉：在多机多卡任务上，还有解决那些复杂的超大模型场景上的探索，整个行业是比较初级的 。像PyTorch只关注易用性的话，重点都是在单卡上，即使做多卡也是最简单的all reduce，调一下英伟达的NCCL库就好 。
因为近期有一些大模型出来，模型并行、流水并行的方式，整个行业才开始关注，包括google做的GPipe, Mesh-Tensorflow，还有华为MindSpore对这类模型进行探索，但大部分也仅仅是做一个插件，很难加入主干代码，要实现正确且高效是非常难的 。
不谦虚地说，在解决多机多卡问题上，其他框架和OneFlow可能是一两年的差距 。
CSDN：按你说的，多机多卡算是强需求，其他框架怎么一开始就没考虑到这一点？
袁进辉：这是个好问题，有多方面的因素 。一是大部分用户没有那么大规模的计算资源，有多机多卡的都是土豪，大部分用户面临的任务或场景还没到多卡的规模；二是从模型发展的情况来说，超大模型趋势是近期出现的，早期，大家的认知就是做数据并行就够了，也不是那么难 。
三是不同的团队有不同策略，多机多卡属于公认的技术难题，但摘果子的时候大家肯定先摘低垂的果子，所以有的框架可能先做最广大用户看中的一些东西，把多机多卡的优先级往后移了，比如PyTorch一开始主打易用性，TensorFlow后来做多机多卡的加速比收益很低，很难用，但不妨碍它捕获大量的用户；四是，多机多卡需要GPU服务器之间有非常高速的带宽，这需要一些特殊的软件和硬件技术，像支持RDMA的以太网等技术还有普及的过程 。
CSDN：能支持超大模型，是OneFlow创业初期就有的判断还是后期偶然的顺势而为？
袁进辉：这也是个很好的问题 。这个判断是创业初期就有的，但产生这个想法很具有偶然性 。
有时候别人也问我，为什么你最先想到搞这种并行，我就回复，我提前预测到这是个刚需，是迟早会发生的事情，因为底层芯片中，单个芯片的计算力是有物理限制的，你必须通过互联方式等才可能解决 。
在2008~2011年在清华计算机系做博士后时，对使用机器学习方法理解人脑神经网络结构的形成感兴趣 。
2013年，我在微软研究院，这时深度学习已经热起来，就想把我博士后的课题“理解神经网络为什么work”做下去，到现在这个问题还没有令人满意的理论结果，以及为什么CNN这种从人脑结构中启发得到的网络，在应用上效果这么好？要研究这个理论味道十足的问题，那时就会面临一个挑战，理解参数量巨大的神经网络背后的机制，其实计算空间参数量巨大 。


推荐阅读


上一篇：苦尽甘来不改本色,云南白族三道茶介绍

下一篇：何为十八层喝茶,喝茶当心