在钛媒体Pro专业用户和付费用户专享的“钛坦白”在线课堂第33期，我们再次请来三位钛客分享对机器学习的思考 。本期钛客之一、百度资深工程师、Paddle API重构设计负责人于洋，从事百度深度学习平台PaddlePaddle开发工作。加入百度后一直从事深度学习系统的研发，主要负责深度学习系统的性能优化和功能开发工作。2016年获得百度年轻高潜人才（YTP）项目成员以及百度最佳个人。

本文节选自于洋在钛坦白的分享。如果您还不是钛媒体Pro用户，希望查看钛坦白所有干货，进入钛坦白九个专业群交流，并查看更丰富的专业数据和信息，可点击：https://www.tmtpost.com/pro 注册。

以下根据于洋在钛坦白的分享实录整理：

大家晚上好，我是来自于百度深度学习实验室的于洋，在百度主要从事百度深度学习系统PaddlePaddle的开发，今天给大家带来的分享题目是《深度学习系统本身所面临的一些挑战》。

先思考一个AI落地的真实问题

AI已经是一个很火的话题，但是AI如何在中小企业落地，其实牵扯到很多现实的问题。比如一个最简单的问题，如何通过语音来控制电视，我们认为有四种解法：

1、用AI HUB，也就是说将神经网络的模型放到一个芯片或者是一个很小的机器里让这个机器去控制电视。这个AI Hub不应该放到电视。例如Amazon Alexa或者Google Home。二者虽然实现了声控，但是人可能在屋里到处走动，不是身在何处都能唤醒Alexa的。

但这么做其实不是特别经济，因为如果要让AI去控制电视的话，首先每一台电视都要具有神经网络的预测功能，同时当用户的真实数据预测完之后，神经网络也要去根据用户的新数据去重新训练模型，让模型更好。这就要求一个芯片既具备神经网络的推断能力，又具备训练能力。

2、提供一个深度学习的API给大家，比如百度提供一个深度学习训练和预测的平台。大家愿不愿意把自己的数据放到百度或者谷歌的云盘里，让百度给大家提供机器学习训练预测的API呢？

我想这在很多场景下是不现实的。第一个原因是，用户要学会用API就很难，要在IoT上调用API更难。另一个原因是，在百度PaddlePaddle团队和其他企业进行交流的时候发现，大部分企业都想用的是私有云。不使用公有云的理由其实不是成本，主要还是公有云可能带来的数据安全问题，因为对于企业来说真正有价值的东西其实是训练数据。

3、企业自己搭一个AI的专用集群，或者说买一百台GPU机器只去跑深度学习的训练，这样做是不是可行的呢？我想也是不可行的，因为专用的AI集群的GPU是非常昂贵的，大体上，租用一个AWS GPU instance一年的费用和买一台一样。而专用集群的集群利用率并不会非常高，因而很不划算。至于专用集群的利用率为什么不会很高，我们稍后再讲。

4、PaddlePaddle提出的目标是做一个通用的AI集群。通用的意思是AI集群里既可以跑神经网络的训练任务也可以跑其他的任务，对于各项任务既可以跑生产环境的作业，也可以跑实验性作业。这样一来，一个企业里各个业务的各个团队都可以使用同一个机群，甚至如果部署到云上可以使不同企业一起用一个机群。你不用的时候我用，你的作业用GPU同时我的在用磁盘，从而使得机群的总体利用率大幅提升。

选择专用集群还是通用集群？

下面这张图是谷歌Deepmind的AlphaGo所使用的资源使用情况。可以看到，在最后分布式的时候使用了280块GPU：

下图是百度的GPU训练机器，我们的一台机器就可以支持16块GPU显卡，最多可以扩展到64块显卡：

所以这种深度学习的专用集群地球上没有几个企业能真正玩得起。比如说百度的机器翻译系统，在我们组训练的时候，可能会用32块K40的GPU做十天左右的训练；谷歌的机器翻译用了96块K80做GPU训练；AlphaGo其实用了50块GPU训练了一个月。这些昂贵的使用成本是初创企业所不能承受的，也是不应该承受的。

为什么像百度、谷歌或者微软之类的大公司可以承受这样成本呢？其实原因还是比较简单的，在这些公司，深度学习在产品线里应用是比较广的。比如大部分的百度产品线都使用了PaddlePaddle，利用深度学习提升这些产品的功能和用户体验。

大家如果调试过深度学习任务就可以很明显知道， 深度学习任务是有一定的资源使用周期的。比如在实验刚刚开始的时候，用户可能从大量的数据中采样出来一个小的样本集合，在这个小的样本集合里调通一个比较好的模型。在这个阶段里，机器的使用量其实是不大的，可能只有单台机器或者几块显卡。之后，为了验证这个模型的效果，可能会将全量的数据进行线下的训练，也就是用一个专用的深度学习集群去做训练，在这个阶段可能会提交几十到上百个计算机机器的训练任务，这些机器每一台都可能有数块显卡。

用户的模型在线下训练中得以验证正确，在大数据集上可以再对模型进行一些精细化调整，从而将模型打造成可以用来做线上预测的状态。线上预测时使用的机器数量明显要少于训练时的机器数量，这是因为预测的时候，其实不需要将神经网络的前馈和反馈全跑一遍，也不需要去反复的跑训练集。

在这个预测模型上线之后，收集到用户提供的新的数据和真实的反馈。我们将这些日志进行收集，从而进行一些增量训练，进而让我们的模型越来越好。在增量训练之后，就是更新预测模型，预测和增量训练的再一个循环过程。

可以看到一个初创企业如果只有少数的几个深度学习任务，由于深度学习任务的周期性，专用的深度学习集群一定不会有非常高的使用率，大体上能有20%的使用率就已经很不错了。但像在百度、谷歌之类的大公司，有各种各样的产品线，这些产品线都需要使用深度学习进行一些提升，所以这些任务虽然有周期性，但是任务和任务之间发生的时间是不同的，所以就形成了各个任务之间的一个叠加效应。

我看群里面大家基本上都是相关领域的研究者或者创业创新的人员。针对创业创新的人员，其实部署一个专用的AI集群成本是非常高的，然而使用率是非常低的。专用的AI集群在我们看来只适合于大型的互联网公司，而且这个互联网公司要有多种多样的AI业务，如果有少量的AI业务的公司或者是初创型企业，我们推荐使用通用集群去做深度学习的训练集群。

PaddlePaddle从专用集群到通用集群的改变

PaddlePaddle在去年9月份开源之前也是运行在百度内部的一个专用AI集群中。 在这个集群里面，它的机器都是同构的，也就是说大家的CPU型号包括显卡的型号都是一样的，也是基于MPI进行调度，内网运行环境也是隔离的，也是稳定的。所以在去年9月PaddlePaddle开源之前，百度对PaddlePaddle的要求只有一个，就是尽量快，在尽量短的时间内完成更多的任务。PaddlePaddle还有一个特点是因为百度本身是一个搜索企业，PaddlePaddle为了服务百度更多的产品线，它在自然语言处理方面打造得会更好。

PaddlePaddle的运行效率可谓是刻在PaddlePaddle基因里的一件东西，我们在开源之后，和Caffe还有TensorFlow做了一些benchmark，结果如下面三张图所示。PaddlePaddle和其他框架在单显卡上的速度都差不多，但是在多显卡的速度上，Caffe是明显要慢的，Tensorflow和PaddlePaddle其实在多显卡的聚合上也差不多，PaddlePaddle会稍微快一点。但是在LSTM上，PaddlePaddle可以显示出明显的优势，如下图可以看出，PaddlePaddle在单显卡的时候就已经比Tensorflow在LSTM网络结构里要快一些，LSTM在4GPU下，可以看到PaddlePaddle实际上比Tensorflow要快很多。

但是单纯的单机和集群跑得快，已经不是PaddlePaddle现阶段的目标。因为我们相信，只有在通用集群上跑得更快，才能服务更多的中小企业，也才能够让更多的人接受PaddlePaddle，也才能够给社会带来更大的价值。

通用AI集群应该怎么搭建？

专用集群其实是更常见的一种集群配置模式。比如说我们公司有存储的需求，我就配置一个Hadoop集群去使用HDFS，有线下处理的需求，我再用Hadoop的Map-Reduce集群去做线下处理。对于网站的话，网站前端大家会配置一个nginx集群，再使用kalfka将网站的一些日志收集下来，再给AI处理。

专用集群的架构就是把几个事情分别部署在不同的机器里，这些机器是相互隔离，不能互相访问的。这样做的好处其实是显而易见的，因为不同应用分别跑在不同的物理机里，可以避免不同应用之间的相互影响，但是坏处也很明显，就是成本会很高，每个集群其实物理硬件的利用率是不够的。

下面我以一个语音识别服务举例，说明一个通用AI集群应该怎么搭建。

下图是一个通用集群的简单示意图，这个集群里有很多GPU的服务器，也有很多CPU的服务器，他们都部署在一个集群里。在这个集群的机器之上运行着Kubernetes。Kubernetes是一个谷歌开源的分布式的操作系统。在2007年的时候，谷歌就使用集群操作系统Borg，通过混合部署各种来源的各种任务，将CPU的利用率一直维持在75%到80%左右。而Kubernetes开发之前是Borg开发团队中的一部分，Kubernetes的设计继承了Borg项目多年总结的经验，是目前最先进集群操作系统。

这对企业的成本是一个极大的降低。之前我们说过普遍专用集群的资源利用率大概在20%左右，如果我们使用一个集群操作系统去管理集群的任务，那么硬件利用率可以提升到75%到80%左右，这样一个通用集群就相当于普通的四个左右的专用集群。

通用集群数据还是存储在HDFS上，在HDFS上有一些有标签的数据，这些数据送给PaddlePaddle做线下训练。在这个系统的前端就是一个语音识别的服务，用户去提交自己的语音后返回一段文字。在这个前端语音识别API里用户实时提交的语音数据就形成了一个实时的日志，这个日志就会被其他的进程收集下来，比如使用Kalfka进行收集，再去做一些线上的预处理，进而将这些数据继续传递给PaddlePaddle做训练。这样PaddlePaddle既可以支持线下的大批量的数据训练，也可以支持线上的实时的数据训练。

在目前众多的深度学习平台里似乎没有一个平台再去考虑如何在通用集群里更好地进行训练。这是因为大部分的深度学习平台都是大企业开发的，在大企业中，通用集群的训练对他们来讲并不重要，但这对初创企业是至关重要的。

通用集群对深度学习系统的挑战

挑战主要有这么几方面：

• 通用集群首先会将任进程成很多的组，每组构成一个Job，这些作业中，有的是Web 服务，有的是流式数据处理作业，还有深度学习作业；
• 这个集群需要做到服务隔离、多用户，因为这个集群上跑了众多的任务，一个任务挂掉不可以让其他的任务有任何的问题，并且由于这个集群是直接的线上集群，所以它的稳定性要求还是非常高的；
• 这个集群需要有一定的优先级调度的能力，比如他需要首先保证线上任务的稳定性，但是也需要在机器空余的时候可以去做低优先级的任务，比如实验性质的任务；
• 在这种集群里，可以对硬件进行高效的利用，比如说一个Hadoop任务，比如说HDFS可能更需要的是磁盘的IO或带宽，但是对于深度学习任务来讲可能更多需要CPU的计算能力和GPU的计算能力，他们就可以调度到同一个物理节点上；
• 这个集群还需要有自动伸缩的功能，比如在白天，活跃用户众多，集群会用尽量少的节点做深度学习的训练，而用更多的节点去做深度学习的预测或者是一个web服务进程。但是在晚上，我们的用户又比较少，闲置的机器就可以去做更多的机器学习的训练任务，让模型变得越来越好；
• 深度学习系统必须有一定的错误容忍能力，也就是说在运行过程中，我们可以杀死任意多的训练节点，将机器腾出来保证其他的任务运行。这里就涉及到一个问题，传统上很多研究人员以为减少一个作业的运行时间就是提升效率，而实际上真正的优化目标应该是让更多研究人员能并行工作，让机群总是“累着” —— 这样来提升团队和公司效率。

以上内容希望能够让大家明白，PaddlePaddle为什么要做通用集群下的可伸缩训练。

PaddlePaddle的规划和目标

PaddlePaddle开源了以后，和作为百度内部的一个项目有非常大的差别，我们从原来只追求高性能和功能，渐渐的要过渡到下图所示的几个目标。我们所有的事情只有一个最重要的点，也就是中间的那个橘色的方块，我们希望让大家的业务变得awesome，变得非常炫，非常给力。我们评价PaddlePaddle“给力”的标准不是发了多少论文、被多少媒体提及，而是解决用户痛点，让用户爽。

通用集群下的可伸缩PaddlePaddle只是我们目标里的一部分，希望大家能够持续关注PaddlePaddle的进一步发展。

在这里我也想介绍一些我们其他的工作，比如说我们写了一本深度学习实战手册，目前已经写完了八章，点击链接前往：http://book.paddlepaddle.org/ 在这个手册里，我们举了八个例子，教大家深度学习应该怎么入门和怎么在真实的场景中使用。

每一个例子都是精心设计过的，比如说其中的一章情感分类。所谓情感分类就是将一个文本分类成正向情感还是负向情感，实际上就是一个简单的文本分类问题。单纯套用文本分类的模型，我们可以去解决如下图所列各种各样的问题。

PaddlePaddle作为一个年轻的开源深度学习系统，也面临着非常多的挑战。我们会以更加开放的心态来迎接所有的挑战。PaddlePaddle作为一个开源软件，所有的开发，包括设计和讨论全在Github进行，目前已经有不少百度之外的团队参与到开发中来了。其中有从事AI的公司，也有做分布式操作系统技术的公司。大家一起在Github上借review设计和提交代码讨论交流。

我们也希望可以看到更多的企业构建出更多支持AI的通用集群，帮助越来越广泛的企业将他们的业务变得更好，更awesome。同时PaddlePaddle作为源于百度企业里的深度学习框架，我们也会促进开源尽量多的工业界成熟模型，来帮助更多其他企业来提升自己的业务。

钛坦白群友互动：

1.请问人工智能公众服务如何保障用户的隐私和数据安全？

于洋：我其实也不是这方面的专家，我谈一下自己的想法。就PaddlePaddle而言，我们的策略是提供一个能够在私有云或者说在本地直接部署的PaddlePaddle，这样用户就不需要将敏感的数据传递给PaddlePaddle这个平台。有一些论文给出的方案，是将深度学习训练直接部署在手机上，将增量训练好的模型上传给服务器，这样用户的数据就不需要从手机去上传到服务器，而是直接在手机上进行训练优化。

2.如何保障训练服务对并发任务的资源配置的公平性？

于洋：现在有一些开源的集群操作系统，比如Kubernetes使用这些集群操作系统，我们可以直接去调度CPU数和GPU数，也就是计算资源的数量，这样每个用户都可以有自己的一个配额。当用户的配额超过了他应该用的配额的时候，他的任务就只能等待，当用户的配额小于他实际上使用的配额，他就有可能会被调度，这些调度策略现在有非常成熟的开源平台，都可以提供。

3.训练的硬件高投入在本地部署时有办法解决吗？

于洋：训练硬件的高投入我觉得还是有办法解决的，解决的办法就是我前面说的，将这个企业的大部分机器都放在一个特别大通用集群里，这个集群既可以跑深度学习的任务，也可以跑其他的比如说web服务之类的东西。这样深度学习的机器虽然说你买GPU很贵，但是他平时也可以被其他的任务所利用，不会完全浪费。

4.配额靠经济杠杆在多用户间协调吗？有没有定价策略，中小企业用得起吗？

于洋：我记得亚马逊的公有云，也就是AWS上面应该是提供竞价实例的，也就是说大家一块去拍卖一个机器，谁出的价高谁就可以在这个时间段去用这个机器。这样经济杠杆就起作用了。

（本文独家首发钛媒体，根据百度资深工程师、Paddle API重构设计负责人于洋在钛坦白上的分享整理）

………………………………

钛坦白第33期，AI已来之机器学习2，今晚7点继续！

地点：钛坦白 | 人工智能（微信群）

报名听课、交流：

钛坦白目前有医疗健康、人工智能、文娱社交、VR/AR、区块链、支付创新、体育、云计算、SaaS等九个专业群。

1、钛媒体Pro专业版用户，可以点击链接https://www.tmtpost.com/pro，登录账号，在线免费、任意选择自己要进入的群，按提示操作；

2、非钛媒体Pro专业版用户，可以添加微信号taitanbai0，在通过好友后，发99元红包给小钛，你将有权利从九个群中任选一个群进入，长期听课、交流。请告诉小钛你要进入哪一个群，然后等待小钛拉你入群~

推荐钛客、赞助、合作：

请与钛坦白负责人佳音联系，邮箱jiayinge@tmtpost.com