当前位置:主页 > 数据驱动 >

百度深度学习平台PaddlePaddle框架解析

 发布时间:2018-04-25 来源:

PaddlePaddle 的迭代速度非常快,同时也广受社区的关注。刚开源的时候,PaddlePaddle 的设计思想是基于Layer的设计。后来推出了“v2”和“Fluid”两次迭代:其中 v2增加了 operators 的概念,把 layers “打碎”成更细粒度的 operators,同时支持更复杂的网络拓扑“图”;Fluid 类似 PyTorch,但是不依赖 Python 的控制流(if-else、for等),而是提供自己的解释器甚至编译器,因此不受限于 Python 的执行速度。

我们今天就从PaddlePaddleFluid讲起,随后讲述为了能更方便利用集群而提供的在浏览器端训练的PaddlePaddleCloud,也着重讲解集群训练的原理、配置、和实验结果,也就是PaddlePaddleEDL部分。最后,讲解PaddlePaddleVisualDL,这个非常强大的训练日志解析和可视化工具。

 

PaddlePaddleFluid

 

PaddlePaddleFluid提供类似于高级语言中的控制流结构(例如while 、 if 、if-else、 for等),不仅能利用编译优化技术保证计算性能,提升使用者的开发效率。

PaddlePaddleFluid 的设计思路非常领先,不再沿用层(layer)结构和操作(operator)结构的模式。也就是说不再有“模型”的概念,也就不再有“图”(graph of operators)或者“串”(sequence of layers)。而只有“程序”的概念。同时,程序是可以导出一个图的,从程序中可以导出成 ONNX 文件格式的模型。

深度学习基础架构是最快速发展的技术之一,在四年之内,已经发明了三代技术。从下表可以看出,深度学习技术架构设计的方向正是逐渐摆脱模型的。

百度深度学习平台PaddlePaddle框架解析

基于Python语言强大的生态,PyTorch 和 Eager Execution 中的控制流都是用的 Python,但面临的一个瓶颈是Python 执行速度慢且难以提速。解决 PyTorch 和 Eager Execution 程序的执行速度受限于 Python 的执行速度的问题,Fluid有一个比 PyTorch 和 Eager Execution 更激进的技术思路。在Fluid的设计上,执行会把编写的Python 程序输出成一个 protobuf message,随后调用 Fluid 解释器(而不是 Python 解释器)来解释执行这个 protobuf message。Fluid 解释器极大地加快了执行图的速度。同时,在编译执行的方式上 ,通过写一个 transpiler 把 protobuf message翻译成 C++ 程序,然后用 nvcc、icc、gcc 编译成二进制代码,可以直接运行在服务器和手机上。


 

PaddlePaddleCloud

 

PaddlePaddle 有一个 Web-based IDE,支持使用者在浏览器用 JupyterNotebook 编程来开发 AI 应用,随后可以把程序发送到云端(Kubernetes 集群上)调试或者运行,程序运行时的输出会实时地显示在浏览器里。这样使用者就不需要在个人电脑和集群等多个编程环境之间切换并且维护多个环境的版本和配置的一致性,极大地提升了工作效率。

 

PaddlePaddleEDL

 

PaddlePaddle EDL 对标的是 Google KubeFlow。PaddlePaddle EDL通过与 Kubernetes 合作来实现弹性作业调度,是全球首个支持弹性作业调度的开源 AI 云解决方案。

尽管现在很多深度学习应用用一个几台机器的小集群就可以解决,但是 随着数据量的增加和AI应用场景的不断扩大,例如Web scaled 应用(广告、搜索、推荐等),以及通过传感器采集海量数据的无人车,都需要大规模深度学习计算能力的。

这里主要为了解决深度学习面临的两大挑战。其一是需要大量的计算能力。研究室和公司经常构建由SLURM,MPI或SGE管理的GPU集群。这些集群要么运行一个提交的作业(假定它需要的比闲置的资源要少)或者将作业挂起一段难以预估的时间。但是这种方法有个缺点:在有99个可用节点和一个需要100个提交作业的任务时,作业必须等待而不能运行。

PaddlePaddle EDL弹性调度体现在可以空闲的时候一个训练作业多用一些资源,忙碌的时候少用一些,但是资源的变化并不会导致作业失败;这是优于KubeFlow的特点之一。同时,EDL也弹性调度其他作业(比如 Nginx、MySQL 等),从而极大地提升集群总体利用率。[2]这样在公有云和私有云上的推广和部署时,就很容易节省几倍的机器,为公司一年节省的计算成本可以高达百万、甚至数百万美元。

另一个挑战是,工业用户倾向于将深度学习作业作为完整数据管道的子集阶段,例如日志采集器等。这种通用集群需要基于优先级的弹性调度。比如网络开销较高的时间段内深度学习任务少运行,在网络流量较低时优先进行深度学习任务。这就需要了解全局的情况,并协调与各种工作有关的进程的数量。

 

PaddlePaddleEDL的测试实验

 

面对上述这两种挑战,PaddlePaddle作业都可以轻松应对进程数量忽高忽低的变化。这里有Fluid EDL的两种测试用例:

  1. Kubernetes集群只运行PaddlePaddle作业;
  2. 集群运行PaddlePaddle和Nginx作业。

在第一个测试中,我们开始了20个PaddlePaddle作业,间隔10秒。每个作业有60个trainers和10个参数服务进程,并将持续数小时。我们重复实验20次:关闭Fluid EDL 10次,打开Fluid EDL 10次。在下图中,实线对应于前10个实验,其余的是虚线。在图的上半部分,我们看到未处理作业的数量在没有EDL的情况下单调递增。但是,当EDL打开时,资源将平均分配给所有作业。Fluid EDL杀死了一些现有的进程,为新的其他任务腾出空间,并在晚些时候任务开始运行。在这两种情况下,集群都被平等利用(见图的下半部分)。

百度深度学习平台PaddlePaddle框架解析

在第二个测试中,每个实验都运行了400个Nginx Pods,其优先级高于6个PaddlePaddle作业。最初,每个PaddlePaddle工作有15个trainers和10个参数服务。我们每90秒杀死100个Nginx Pods,直到剩下100个,然后我们开始将Nginx工作的数量每90秒增加100个。下图的上半部分显示了这个过程。图中的中间显示,Fluid EDL通过减少Nginx Pods来自动启动一些PaddlePaddle进程,并在稍后增加Nginx Pods来杀死PaddlePaddle进程。结果,该集群维持在90%左右的利用率,如图所示。当Fluid EDL被关闭时,没有PaddlePaddle进程自动增加,并且利用率随着Nginx Pods数量的变化而波动。

百度深度学习平台PaddlePaddle框架解析

PaddlePaddleEDL的设计和实现

 

那上面这种深度学习服务和其它云端服务共享计算资源的过程,以及各个任务的优先级动态地调整和伸缩的过程,从而充分地利用集群CPU/GPU是如何实现的呢?

EDL和HPA

文章评论

互联网 自媒体专栏 智能硬件 资本动态 移动互联网 游戏 数据驱动 滚动新闻 O2O 访问移动版
Copyright © 2002-2013 搞数码网 版权所有  电话:0510-898978789 邮箱:89898989@qq.com 地址:北京市新会金水岸国商大厦B-6-B