本月初，Kubernetes在其官网上宣布了百度的PaddlePaddle成为目前唯一官方支持Kubernetes的深度学习框架。PaddlePaddle是百度于2016年9月开源的一款深度学习平台，具有易用，高效，灵活和可伸缩等特点，为百度内部多项产品提供深度学习算法支持。两个开源项目的结合意味着深度学习对于广大开发者正变得“触手可及”。还有呢？ AlphaGo 围棋之战引燃了人工智能，也激发了技术圈的研究热情；江湖传言其单个训练作业要依赖数千个GPU，而更有人猜测规模恐怕远超于此，纵然Google对其使用的集群规模等技术细节三缄其口，也没有阻挡住技术人探索的脚步。机器 / 深度学习作为人工智能领域中的重要分支，有着如 TensorFlow、Torch、Theano、Caffe等不少的开源项目，PaddlePaddle（PArallel Distributed Deep LEarning）是百度于2016年9月开源的一款深度学习平台，具有易用，高效，灵活和可伸缩等特点，为百度内部多项产品提供深度学习算法支持。
这套打磨逾三年的技术，需要在大规模集群上进行分布式作业。如何启动系统并将分散的资源和众多的学习任务良好匹配是一个无法回避的技术问题。问题总是相似的，容器技术也面临着如何简单地管理好分散的物理计算资源这个难题。解决方案之一Kubernetes是Google为生产环境设计的开源的容器管理调度系统。
本月初，Kubernetes在其官网上宣布了百度的PaddlePaddle成为目前唯一官方支持Kubernetes的深度学习框架。两个开源项目的结合意味着深度学习对于广大开发者正变得“触手可及”。为什么会有这样的组合？PaddlePaddle on Kubernetes的意味着什么？如何看待深度学习拥抱容器技术？带着这些问题InfoQ采访了博客文章的原作者百度王益和CoreOS李响探求更多的技术内容，同时还采访了Kubernetes Project Manager、HyperHQ项目成员 张磊，本文整理自三位嘉宾的采访素材。
在人工智能专家王益博士看来，现代的人工智能是建立在大数据基础之上的，而大数据的主要来源有两个：互联网服务的log（记录用户行为）以及通过各种crawler采集的外部数据。在具体落地上，对于工业级应用，需要把从Web服务到内外部数据收集和处理的整个通道，都与AI建设在一个机群上，才能实现高效的知识提取，然后将结果反馈从而提升服务质量。
在百度，分布式深度学习平台PaddlePaddle在徐伟博士的带领下经过三年多研发和打磨，已经应用于包括搜索、翻译、电商和计算基础架构等方面共五十余个应用，该项目现已开源。王益在成为百度PaddlePaddle团队负责人之后，非常希望该项目可以更容易地部署与运行。
王益在与李响等容器专家们的交流讨论之后，PaddlePaddle on Kubernetes项目于2016年10月拉开帷幕。
Kubernetes可谓容器生态圈的当红明星，业界甚至有人断言 “Kubernetes已经赢得了容器生态的圈地战争”；在李响看来，Kubernetes将会是今后的云管理平台的统治者。
PaddlePaddle on Kubernetes也恰好符合于Kubernetes社区所喜闻乐见的，后者希望将一些流行的应用在Kubernetes上原生运行起来，可以让更多人感受到Kubernetes的神奇之处。
Kubernetes 把很多分散的物理计算资源抽象成一个巨大的资源池，它利用这些资源来帮助用户执行计算任务。对于用户来说，操作一个分散的集群资源可以像使用一台计算机一样简单。
对于这个项目，Kubernetes 主要负责将学习任务分配到集群的物理节点上进行运算；如果遇到任务失败的情况，Kubernetes 会自动重启任务。
具体而言，技术层面需要通过实现fault-tolerable的训练——AI作业在进程数量发生变化的时候不要暂停或者失败——来实现机群里各个作业的auto-scaling。Kubernetes可以把很多并发进程组织成service，并且实现auto scaling——白天用户数量多的时候，增加Web service里的进程数，减少AI作业的进程数。晚上减少Web service里的进程数，释放资源给AI作业。
除了Kubernetes之外，还有Mesos、Fleet和Swarm等容器调度方案。目前还没有一个开源深度学习框架和Kubernetes深度结合，那为什么百度选择了Kubernetes呢？
在王益看来，现有容器调度方案们各有千秋，但是PaddlePaddle兼容Kubernetes是开源社区用户的选择。
PaddlePaddle最初在百度的集群上运行。但是PaddlePaddle并不依赖特定的并行计算平台——只要有办法在一个平台上启动PaddlePaddle，就可以运行分布式训练作业。百度的大数据团队（BDG）的同学们做了一套PaddlePaddle on Spark系统，确保PaddlePaddle和Spark的兼容。而PaddlePaddle on Kubernetes 要感谢社区贡献了。
到目前为止，PaddlePaddle on Kubernetes的结合工作也不是百度的PaddlePaddle开发团队做的，而是由CoreOS公司的etcd项目负责人李响、百度上海JPaaS团队的周倜、陈国彦、CISCO硅谷办公室的tech lead陈曦以及百度美研ADU团队的王鹤麟做的。同时，PaddlePaddle正在和Kubernetes社区合作这项工作，王益称期待尽快给大家带来一个惊喜。
5 为什么社区技术人如此喜爱Kubernetes？ 在容器圈专家张磊先生看来，相对而言，Kubernetes确实是最好的技术选择。
单纯就离线计算业务而言，“老”项目Mesos在大数据领域被大规模应用多年，固然有着明显的优势。但是，要更好地支持深度学习框架作业，Mesos的资源管理和调度能力只能说是锦上添花的功能。
能不能将框架的作业和任务模式，同“容器”这个全新的部署概念匹配起来，才是现阶段最重要的。毕竟，如果框架连正常运行起来都很困难，再好的资源利用率提升机制也没有用武之地。在这一点上，Kubernetes应该说是现有的容器管理项目中做的最好的。
就比如前面已经说过它的Pod设计，就能很好地跟Paddle的作业模型匹配：一个Pod里放两个容器，分别是参数服务器（parameter server）和训练器（trainer）。这个匹配并非巧合，而是因为Kubernetes从一开就认为容器之间往往存在像这样紧密的协作关系，这是“lesson learned from Borg”。只不过在过去，大家都只关注在容器里运行简单Web服务的时候，才会认为Pod“没什么用”。
除了Pod，Kubernetes提出的比如Replica（容器副本），Job（计算型任务），StatefulApp（有状态应用）等诸多已经被业界采纳为标准的编排概念，都体现出了这个项目在容器作业管理方面独到的技术视野（虽然还一度被国内用户诟病为理念太超前），这一点上其它项目与Kubernetes之间存在着follower和leader的差距。实际上，Kubernetes不仅简单地解决了容器业务部署和运行的问题，它还关注如何帮助用户构建容器化分布式服务这个问题，对于在容器化道路上尚需要“摸着石头过河”的用户来说，这是非常重要的。
相比之下，Docker的集群模式（Swarm模式）关注的范畴要小很多，相当于Kubernetes在应用管理方面的一个子集。它的关注重点之一是用户友好，但也为此牺牲了不少可扩展性。对于开发者而言，比如做一个PaaS，这是够用并且很方便的，但是如果要依赖于它作为基础设施、甚至在它之上再构建另一套更复杂的系统，这个集群模式就比较难胜任了，如果这中途还需要自己定制和扩展的话，会更加困难重重。
不过Kubernetes也还存在不足：首先，作为一个正在快速演进的项目，Kubernetes本身有很多特性亟待完善，说的直白一点就是潜在的坑还是很多的，这也是采用新技术的必然代价。好在Kubernetes的社区足够繁荣，一定程度上能够弥补一些。其次，相比于Swarm模式的用户友好程度，Kubernetes的Geek气息依然太浓，很多时候需要用户自己拿主意（比如“故意”不提供内置的跨主网络和分布式存储方案）。
总体上看，要支持PaddlePaddle、Tensorflow这样非云原生应用（多容器协作，甚至有状态）项目，Kubernetes目前是个最佳的选择。
PaddlePaddle on Kubernetes项目的消息一经发布，技术圈内反响强烈。容器圈专家张磊先生，他告诉InfoQ早期的小道消息是在InfoQ的CNUTCon全球容器技术大会2016（注：王益、李响和张磊三位大牛均为大会的讲师，技术圈的学习交流社交哦~）的讲师晚宴获知的。当时对Kubernetes的roadmap有了很多讨论，后来百度JPaaS组负责了项目的实施。
在张磊看来，这次PaddlePaddle与Kubernetes框架的深度集成算得上一个里程碑事件。容器与容器编排管理技术在过去两年里的迅猛发展跟去年人工智能集中式的爆发终于产生了深度的化学反应，也让我们看到一套完善的容器编排与调度体系确实能够为技术人员带来更多价值，而非“空有热度”。这一点是非常重要的，容器热潮的兴起，源自于对的云原生应用（比如轻量级的Web服务）的完美支持，但容器云技术能否最终落地，还取决于它能不能对非云原生应用（传统服务、复杂应用）有良好的支持和扩展，深度学习框架正是非云原生应用的一个典型案例。
事实上，2016年人工智能热点爆发的一个强有力推动者正是同样源自Google的Tensorflow项目，它也很早就进行了同Kubernetes的集成工作。只不过由于师出同门，Tensorflow集成的案例说服力一般。但是现在我们再参考Paddle的集成工作，我们不难看到容器编排和调度平台对于这类框架的一些独有优势。
这个轻量级不只只是跟OpenStack比，而是因为哪怕是虚拟机，我们也可以通过HyperContainer的方式接入Kubernetes，继续对用户提供秒级的响应能力。这种敏捷性是至关重要的，我们通常都喜欢把容器跟CI/CD联系在一起，说能够快速迭代交付云云。实际上，深度学习的训练过程，才是真正对“快速迭代”有着关键需求的作业方式，在这一点上，容器的轻量级特性就凸显出来了。
深度学习框架的最终目的是提供AI服务，而不是做“挖矿机”，所以任何一个从业者都不可能像比特币那样不计成本的投入计算资源。相比于使用物理机或者虚拟化来做计算任务的管理，容器这种操作系统层面的进程封装已经被证明能够大大提高作业的部署密度，而Borg等知名项目所提供的理论支持，也对基于容器做资源利用率的进一步提升指明了方向。
深度学习框架不同于常规Web服务，它有着自己独有的作业组织和部署模式，一个作业往往需要多个任务协作完成，这就对下层的容器编排和调度系统的设计提出了更高的要求。Kubernetes项目使用Pod这个概念使用户能够使用一组容器来完成一组相互协作的任务的编排。这套组织和调度容器的理论被业界成为为容器设计模式，这是基于容器支持深度学习框架另一个独有的优势，用虚拟机或者裸机都很难模拟。
这个不多说了，容器对于构建可扩展的分布式服务的便利程度已经被国内外企业实践过了。
容器管理技术的普及也就最近几年的时间，Kubernetes也是非常年轻的项目，无论跟哪个深度学习框架都不可能100%贴合。接下来容器管理平台要着重解决的包括：
当前Kubernetes的Job特性虽然在容器管理领域内算得上是佼佼者，但是跟已经成熟多年的大数据框架相比还差距甚远的。这一部分的功能进一步完善、甚至能直接对接大多数计算框架已经是板上钉钉的事情。
Kubernetes对GPU支持的投入力度一直很大，目前也走在容器管理领域的前列。但GPU支持对于主流容器技术来说也只是刚刚起步，相比于物理机器和容器对CPU资源管理的完善程度，容器平台在GPU设备管理、GPU资源共享、多GPU支持、OpenCL等GPU框架支持上还有非常多的空白需要填补。目前这些都已经出现在Kubernetes的路线图上。
Kubernetes在资源管理模型设计上继承于Borg，但是相比于前辈强大的资源分配和共享机制，现有的模型在支持计算型任务还很初步，也不能实现离线业务和在线业务高效混部、抢占，也不支持动态的资源边界。所以这一部分的优化空间还是非常大的，对于进一步提升深度学习作业的效率也非常重要。
9 PaddlePaddle on Kubernetes项目技术细节 兜兜转转讲了很多宏观的内容，那么现在让我们看看项目的技术细节吧。
PaddlePaddle是一个诞生在工业界的系统，从一开始就强调支持分布式训练。
在PaddlePaddle诞生的年代里，并没有今天这么多的开源深度学习框架。所以PaddlePaddle的很多设计，在当时都是领先的。其中一些重要的设计决定直到今天都是很独特的。
PaddlePaddle有parameter server，但是设计思路和Google在DistBelief论文中描述的parameter server很不一样。DistBelief中的parameter server主要是为了能训练很大的模型（model parallelism）而设计的。每个trainer进程和每个parameter server进程都只拥有模型的一块（一部分）。PaddlePaddle的parameter server也支持这样的使用模式，但是这么大的模型并不常见，所以parameter server的使用模式更经常是用来加速网络通信。在这种使用模式下，每个trainer都有整个模型，但是每个parameter server只拥有模型的一部分。
通信模式如这篇博客中图一所示。
http://blog.kubernetes.io/2017/02/run-deep-learning-with-paddlepaddle-on-kubernetes.html
百度经过证明，认为这种通信模式和HPC中经过多年来持续优化的ring-based AllReduce算法的效率是一样的。而且当模型的梯度矩阵比较稀疏的时候，甚至效率更高。
之前在百度里很多训练作业的配置是：trainers进程和parameter servers进程的数量一样。但是其实不一定要是是一样的。百度希望努力做到根据机群的实际情况，自动动态启动或者杀死一些进程，使得作业的效率在规定的硬件使用下最高。Kubernetes负责将学习任务分配到集群的物理节点，并且在任务失败时，实现自动对任务进行重新启动。
目前主流的开源深度学习框架都没有动态任务分发机制，而PaddlePaddle也还不能实现动态的协调和容错。
非动态的映射有两个缺点：
整体学习任务有可能被延迟甚至终止
在并发规模不是很大的时候，数据分片到trainer的静态映射是没问题的。但是当训练规模变大，或者训练在通用机群（general-purpose clusters）上进行的时候，经常会碰到有些trainer被更高级别作业挤压杀死的情况。此时，其他trainer（或者parameter servers）如果要等待所有trainer的gradients的话，训练作业就陷入死结（halt）了。
资源利用率不能达到最优化
在学习过程中即使有更多的资源可以使用，也不能动态的增加资源。
王益称PaddlePaddle已经有一个design doc来实现任务的动态分配——引入一个master进程，负责把逻辑数据分片分发给“活着的”trainers进程。这个设计同时考虑到如何用类似Google MapReduce框架的做法，实现训练作业的“不死”——即便一些trainers或者parameter servers被杀了（抢占了），训练作业也能继续进行，只是速度稍慢。当机群上其他高优先级作业结束之后，Kubernetes会增加作业里的trainers数量，此时作业的进行速度也就自然更快了。
李响称希望今后利用 etcd 这样的分布式协调系统来专门为 PaddlePaddle 设计一个全局动态管理者组件。这个组件可以帮助 PaddlePaddle 动态地调节资源使用，在集群中有剩余资源的情况下增多学习者，对完成的部分任务设置检查点等等。
对百度而言，PaddlePaddle的目标从来都不是一统江湖，他们认为只有通过鼓励新的创新不断出现，才能维护好整个深度学习社区的健康。这样PaddlePaddle也才有机会借鉴和学习新的创新思路。PaddlePaddle只有一个版本，内外部都使用开源版本。百度不会做openwashing（伪开放）。
当然，没有完美的系统。和很多项目一样，PaddlePaddle面临着不断增加新功能和维持好代码的精炼简洁之间的矛盾。百度告诉InfoQ通过借鉴Keras、mxnet、和DyNet的长处，最近在重构PaddlePaddle的API，接下来要重构分布式计算方法。希望持续保持好PaddlePaddle的健康状态，并期待三月初给大家带来一个更加易学易用的PaddlePaddle。
PaddlePaddle on Kubernetes这个项目的执行，是社区的功劳，而并非百度PaddlePaddle团队成员的工作。PaddlePaddle社区会努力和Kubernetes进一步深化合作，把深度学习对机群管理的需求不断提给Kubernetes社区，帮助Kubernetes在支持Web服务和数据处理之后，也支持好AI。
对于 PaddlePaddle 和 Kubernetes 融合这个项目来说，在当下更关注的是对开发者友好，因为在初级阶段，需要的是更快速地迭代开发普适的功能，而不是局限于去支持现有特定的企业级应用。当项目收获到越来越多开发者反馈的时候，逐渐成熟并具备强稳定性时，才会考虑根据企业具体情况增加功能。
王益，现任百度深度学习研究院资深科学家，超大规模人工智能系统专家。曾是硅谷AI创业公司Scaled Inference创始科学家，LinkedIn高级主任数据科学家，腾讯社交广告技术总监，Google研究员。2012年开发的Peacock系统是语意理解系统的世界纪录保持者，利用三千CPU从数百TB数据中归纳和理解一百万小众语意。
李响，CoreOS分布式项目主管，开源项目etcd作者。目前负责Kubernetes、etcd等分布式系统相关项目在CoreOS的开发工作，主要兴趣在于分布式一致协议、分布式存储、分布式系统调度等。
张磊，HyperHQ项目成员，Kubernetes Project Manager和Feature Maintainer。曾任浙江大学科研人员并著有技术书籍《Docker容器与容器云》。目前主要关注大规模容器集群管理和虚拟化容器运行时技术。
在线峰会免费报名：阿里开源项目最佳实践
阿里在线峰会，来自淘宝、天猫、阿里云、蚂蚁金服的8位项目核心成员，现场剖析阿里开源项目背后的技术实践，分享绝对干货的开源经验。
识别文章底部二维码或者点击「阅读原文」免费报名。报名只需两步哦。
今日荐文
点击下方图片即可阅读
管理与技术未必不可兼得，一个20年IT老兵的码农生涯
