跑在Kubernetes上的开源深度学习，百度这次带来了哪些技术看点？

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社区合作这项工作，王益称期待尽快给大家带来一个惊喜。

在容器圈专家张磊先生看来，相对而言，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这个概念使用户能够使用一组容器来完成一组相互协作的任务的编排。这套组织和调度容器的理论被业界成为为容器设计模式，这是基于容器支持深度学习框架另一个独有的优势，用虚拟机或者裸机都很难模拟。

这个不多说了，容器对于构建可扩展的分布式服务的便利程度已经被国内外企业实践过了。