独家解读 | 滴滴机器学习平台架构演进之路

现在很多互联网公司都有自己的机器学习平台，冠以之名虽然形形色色，但就平台所要解决的问题和技术选型基本还是大同小异。

所谓大同是指大家所要处理的问题都相似，技术架构和选型也差不太多，比如都会使用 GPU 集群、采用 Spark 或 K8s 平台等。所谓小异是指各家规模不同，各家都在结合自己的情况、所处的阶段并根据自己的特点解决平台化的问题。

滴滴机器学习平台的治理思路主要是：减少重复、提高效率。本文将对滴滴的机器学习平台进行全面解读，重点分享机器学习平台不同阶段所要解决的问题，以及解决问题的思路和技术方案。希望能够对大家有所帮助。

机器学习平台1.0：从“作坊”向“集中化”过渡

滴滴的机器学习平台建设开始于2016年，当时滴滴内部各算法团队逐步开展机器学习、深度学习等AI相关的研究和实践应用，这类算法大都属计算密集型应用，一般都会使用单价较昂贵的GPU服务器。但随着业务的开展，各算法团队仅针对各自的问题做规划，由此导致了一种小作坊式的生产局面。作坊式生产方式在早期有其积极的一面，能够保证创新的灵活性，但是越往后，这种小作坊式算法生产模式的局限就越明显：资源缺乏统筹调度，无法形成规模化效应，大量重复性工作，自拥算力有限。逐渐增多的这种小作坊式生产方式致使整体投入产出的效益大打折扣。滴滴机器学习平台在这种背景下应运而生，这个阶段也主要致力于解决这些问题。

这期间机器学习平台所采用的架构和技术选型主要针对作坊式生产方式的问题来展开，也就是提高复用性和规模化能力。

首先要解决的问题就是统一资源管理，这个“统一”要解决包括线下和线上两类问题。线下“统一”的问题着重解决GPU的服务器选型、测试、引入、上线等的集中化。这类集中化一方面提高了服务器引入的上线质量；另一方面相比于作坊式模式，由于有GPU相关专业人员参与进来，GPU的选型也避免了一味追新的盲目性和发散性；再者，由于集中化能够和公司整体大局结合起来，从而可以做最优化的选型和引入方案。

线上“统一”需要解决的问题细分为资源管理问题和任务调度问题，使资源使用方能够用即申请，完即释放，从而盘活整个资源大池，对平台要求则需要做到资源的隔离和管理。

这个阶段需要解决资源统一管理后如何避免重复性工作的问题。此时所谓的避免重复性，意在让各个算法业务不需重复诸如Caffe、TensorFlow、PyTorch等运行环境的构建，而是要一次构建所有用户都可用。这对平台来讲，需要做到应用环境管理、用户自定义环境、快速环境部署。

厘清这些需求之后，结合当时的技术环境和成熟度来看及以上的基本要求，平台选择当下盛行的Docker来兼做环境的管理、资源的弱隔离和任务的调度；但由于此时支持GPU资源调度的资源管理器乏善可陈，所以我们选择对Yarn做了扩展以支持GPU资源维度上的资源管理和任务调度，环境上平台同时提供Notebook、Jupyter的交互接口给用户。

统一资源管理、环境管理后，不得不面对的问题是多个资源节点间数据共享的问题，用户在当前资源释放后申请新资源时往往对之前的数据有依赖。多节点数据共享在作坊式时期受限于单个的规模，问题不会十分突出，但是集中化之后随用户增多就会逐渐尖锐起来乃至是个大的技术挑战。因为：1. 机器学习的任务计算特点依赖于GPU的高速计算，它们对数据访问延迟有一定要求，这要求必须有足够高的IO带宽做支持；2. 用户数量增加，对存储带宽的需求会变的非常大；3. 对存储系统来说，支持POSIX接口的要求使得现有技术方案大大减小，另外也需在高可靠性、高性能以及成本之间做折中。

滴滴机器学习平台在存储系统上的尝试还是借用传统超算使用的PFS作为整个数据存储的一级，底层网络基础设施使用高带宽的以太网络，使用RoCE协议做RDMA的支持，并往这个方向演进。

总的来看，这个阶段所面对的问题以内部问题为主，从作坊式到集中化生产的发展阶段，要解决的相关重复性的问题也比较简单。其中有些问题本质属于集中化后产生的问题，但是解决思路还是作坊式的，技术选型上的局限性也没有完全暴露出来。

机器学习平台2.0：平台发展

随着作坊逐渐消失，机器学习平台作为一种集中化的生产方式呈现给公司所有算法团队。平台功能开始完整和完善，监控体系，运维体系，更加精细化的资源隔离、管理及优化；根据用户不同的任务性质也提供了不同性质的任务支持。

经历了前一个阶段，虽然有效降低了作坊生产的重复性工作，但也几乎是必然的产生了一些新形态的重复工作。用户接入的增多，用户任务的性质也多样化，有些是实验性质的、有些是在线生产任务、有些是单卡任务、有些是多卡多机的训练任务，等等。

每种性质的任务都有各自重复的具体形式，比如用户在模型生产后要部署模型服务，就需要解决服务的HA、负载均衡等生产服务问题，每一个在线模型都要解决这类问题；再比如，用户训练时往往需要调参，而这些参数都是同形的，只是数值上的变化，这种值上的变化后就是一个个独立的任务，需要用户提交任务的流程，这提交流程也是重复性的工作；再比如，用户在运行多机多卡时需要参数服务器，低效的参数服务器把大量的时间浪费在通信上，这种浪费会加重用户资源使用上的重复；与这种重复形式相似的，还有比如模型服务要上线，为了满足服务的延迟、QPS、资源的约束，需要做从服务、到深度学习框架、再到计算库的全栈优化，基本上，大部分模型上线也需要经历这个优化过程。

针对上述新出现的问题，平台需要更加强大的资源管理和任务调度能力。在上一时期选用作为资源管理和任务调度器的Yarn开始呈现出疲态，具体表现在K8s日臻成熟，与Docker的结合更加合理和完整，并能够整合多种维度的资源，使用K8s为解决模型服务的自动化部署提供了环境和条件，也降低了服务的运维成本，综合K8s和Yarn各自的利弊，滴滴机器学习平台开始由Yarn架构向K8s建构迁移。

针对用户同形调参的效率问题，平台对用户的Python代码做语义分析以自动识别出哪些参数可能会是需要调整的参数，用户只需要设置值域和步距就可以自动获取整套参数的模型训练任务以及最终的结果。

针对多机多卡训练效率问题，平台结合自己的硬件特点和通信模式特点，开发了滴滴参数服务器。滴滴参数服务器采取环状结构，实现了高效的RDMA通信的Allreduce算法。环状结构而非中心集中的server-client模式，消除了网络传输可能的带宽竞争和网络拥塞。底层自研的高效RDMA通信库，规避了设备厂家提供用户态 Verbs 内部分性能损失，重写的底层通信库实现了 sig/read 及 post/recv 两种模式，尽量规避了RDMA固有的通信开销，充分挖掘了硬件的属性来提高性能。另外，自研的Allreduce算法巧妙重叠了计算和传输，尽量减少了不必要的内存拷贝来减少额外代价，并充分考虑了GPU拓扑、CPU亲和性等硬件属性来提高性能。

在机房40G带宽的RoCE v2 RDMA网络实际测试中，对比业界的OpenMPI和Nvidia的NCCL2方案，滴滴参数服务器有明显优势。

针对模型服务部署和优化，平台结合自己的场景特点开发了DDL（DiDi Deep Learning） Serving服务框架、IFX框架和Autotuning优化库，极大的加速了模型上线部署和优化过程。DDL Serving独创自适应的batch机制，优化RPC协议，解决Tensorflow Serving的缺陷，相比于Tensorflow Serving性能对比加速如下：

DDL Serving框架服务本身不再成为整个服务链路中的瓶颈点，对于一些轻量模型可以有3倍的性能提升，包括RT和QPS的提升, 而对于一般模型，性能热点落在深度学习框架层。

因此，针对框架层，我们自主研发了深度学习框架IFX，并同时适配于GPU服务器和移动端平台。在GPU服务器上，由于CUDA存在context管理的问题，所以我们设计实现了一种GPU上的并发机制，有效地绕开了这些问题所带来的额外开销，另外对大量的OP做了优化，使得IFX的性能远高于Tensoflow乃至TensorRT ；IFX针对移动端的不同硬件配置，比如：流水线长度、顺序乱序、超标量等特点进行指令重排、访存优化，结合业务的计算特点，使得IFX的性能取得不俗的表现：

在IFX的优化过程中，大量的重复工作基本在Tuning Blas计算，由于硬件架构不同，不同模型的计算量、计算访存比、计算访存模式都不同，在极高性能要求下都需要综合这些具体的情况做针对性的优化。这些优化都很底层，并且调优都相对繁琐，对于上层服务用户来讲，不必关心这些底层细节。

为解决这类问题，平台开发了Autotuning工具链，包括Kepler、Pascal、Volta 架构的原生汇编器。对于用户来讲，只需要把GPU上的二进制代码发给平台，平台就可产生在该GPU平台上几乎是最优，也就是当前最高性能优化后的二进制代码。滴滴机器学习平台团队也是目前除了NV 以外，自己掌握 NV GPU 原生汇编器支持版本最多，对 NV GPU 微架构最了解的。

这些“重复问题”随着集中化和平台化产生，也在平台化的环境下使得解决这些“重复”变得有意义。集中化、平台化带来的第二个好处便是在此基础上，通用性的需求逐渐会沉淀为平台的服务。比如相似检索的需求在滴滴地图的POI优化、人脸检索、视频图像内容检索等业务场景中都是共性需求，因此平台会获得足够的业务信息来开发这种平台级的服务，而在作坊式时代很难获得这类跨业务场景的需求而自发的沉淀出平台服务，大多还是自扫门前雪。

机器学习平台2.1：内外云平台成形

集中化生产后的第二个影响，随着平台能力的增加以及孵化落地算法逐步丰富，加上滴滴内部数据、AI工程和算法逐步积累成熟，机器学习平台的功能、定位也变得多样化。除了服务好滴滴内部机器学习平台用户，进一步夯实资源调度、任务管理、监控运维等能力外，平台开始承接内部能力对外输出的职能，期间机器学习平台和滴滴云着手在公有云上打造从底层资源到上层平台、从公有云到私有云的解决方案。

机器学习内部的集中化生产也给滴滴机器学习平台能力的输出做了储备，但外部客户的技术产品要求相对更复杂。这个复杂首先体现在产品要求的多层次性：有对资源乃至对硬件的直接要求、有对具体服务的需求、也有例如在私有云中对平台能力的需求；其次, 产品考量因素的多维性：资源的性价比往往只是一方面，安全性、稳定性、与其他基础设施的整合能力等也都是影响用户决策的因素；最后，横向各友商竞品的对比。

所有这些问题都是滴滴机器学习平台对外服务碰到的问题，但是这些问题不可能做到“毕其功于一役”，都是分阶段分步骤，有侧重的解决此间的问题。第一步要解决的是基础问题，如何透出能力，如何保证客户的安全性，如何在前两个能力的基础上，尽最大力减少外部用户的重复性工作（用户使用的成本）和滴滴机器学习平台的重复性工作（产品性价比）。

GPU资源：减少资源的重复性工作

相比于内部的用户，外部用户使用资源需要有一个安全的隔离环境，仅用Docker的弱隔离方式无法给用户提供安全且隔离的环境。所以滴滴云上GPU云资源使用KVM和GPU透传的方式把GPU资源透传给用户。滴滴机器学习平台技术团队对GPU的使用颇有心得，团队成员也是早期一批在工业界尝试GPU的团队，积累了丰富的GPU使用一线的知识和经验，而且这些在滴滴内部被佐证十分有效，从GPU资源、拓扑和相关配套上都特别花心思，所以相同GPU型号，用户往往可以获得更好的性能，对比如下图。这部分的沉淀也减少了外部用户在探索使用GPU过程中的重复性工作，降低了使用的隐性成本。

弹性推理服务（EIS）：减少服务部署优化的重复

所有的算法模型最终都需要用于生产服务，国外有很多PAML平台能够部署机器学习模型服务，机器学习平台在滴滴云上也提供了一种模型部署服务——EIS（弹性预测服务）。EIS服务根植于内部使用的DDL Serving服务，但因在云上服务我们对一些理念的坚持，所以大家可能会产生我们有“起大早赶晚集”的疑问，诚然，EIS在滴滴内部以DDL的形式出现的相对不算晚，但这一块的服务市场现在只能说是刚刚起步，产品的差异化和多样化会是必然的趋势，对用户来讲也有更好更大的选择空间。

目前，市面上大大小小提供PA服务的厂商大都有各自的特点，但总的来说他们对这个产品的定位依然仅是作为资源产品的辅助角色，着重为用户解决资源和部署问题。这种辅助角色，有他的好处，主要包括：一是模式简单，把服务转化为最小粒度资源开销，按最小单位资源消耗来计费；二是对基础设施的能力要求降低，简化为资源开销，本质上只是多了一种资源的售卖形式；三是服务厂商的工作最小化，虽然用户可以选择多种资源，并且每种资源的都有各自理论上的计算能力，用户怎么利用好这些资源是用户自己的事情。

这个模式的问题在于服务商虽然为客户解决了一部分问题，但是对用户实际的服务部署考虑仍然不周。为什么？原因在DDL描述中也提到过，模型服务部署服务都需要用户自己优化服务以满足RT、QPS的要求，更进一步说，成本如何最优化，用户使用云服务，成本几乎是必然会面对和慎重考虑的。

所以，从这个点来看，PA服务提供商以资源为主，服务为辅的模式的缺点也显而易见： 一，最小粒度资源的粒度对模型服务来说，粒度依旧比较粗，如若使用到GPU，问题更加突出；二，资源的理论计算能力对用户来讲往往仅是个理论数字，受限于硬件的限制和客户自己的技术能力，客户往往并不能充分利用PA厂商提供的资源的计算能力，而一般利用率都有限，这实际使用和标称的理论数字之间的资源费用实际是由用户买单的，而更甚者，对用户来讲这里有两部分工作是重复的：资源的使用优化的重复，服务部署的运维相关工作的重复。

根据我们内部用户和一些外部用户的经验，服务最核心的技术指标是QPS和RT，进而才是满足这两个指标情况下的部署成本和使用成本。而这些成本的降低则必须在尽可能减少用户的重复工作和“实用实销”的基础上，除了一般服务部署需要的HA和运维支持外，EIS从技术架构设计上侧重于解决这两方面问题。

从RT来讲：用户服务RT的开销受限于网络链路和实际前向计算的开销，为了减少网络链路的开销，滴滴云花了不少时间，在公有云上实现了纯公有云化的Gateway，这一方面用于支持用户自定义的鉴权等操作，另一方面也最小化网路跳数以降低网络的开销，保证用户服务的RT；从QPS来讲，EIS使用滴滴机器学习平台的DDL Serving作为服务引擎框架，使用DDL Serving的用户可以忽略底层硬件的细节，从而可以避免用户重复地去做服务框架层面的已知的优化工作，这样也为实现用户“实用实销”提供了条件。可以通过以下的架构图了解：

要做到“实用实销”，还有一个非常关键的环节就是需要知道用户的模型实际的计算需求量，以及某一种硬件下的计算利用率。我们开发了一个自动压测模块，用户提供模型和部署输入就可以获得使用DDL Serving在某种硬件下的计算性能，进一步回归出某种RT性能要求下的QPS能力。对用户来讲，用户折算出业务需总的QPS后按QPS横向扩容即可，相当于用户只负担了实际消耗的计算性能的那部分资源，这比之前的模式是更加细粒度的资源控制。

用户优化上的重复性工作的减少，如之前讲过的除了服务框架的优化外，还有一部分优化是花在计算性能的优化上，但计算性能的优化往往取决于程序的计算特性和相关的硬件特性，并且每种模型都有各自的特点，这部分工作EIS也提供了Autotuning的优化服务，用户需要提供他的二进制代码，通过Autotuning服务后会产生某种模型和框架下在指定硬件下几乎是最优的性能代码。

Autotuning服务除了能降低重复基础的和琐碎的优化工作外，也能够提升用户模型服务RT和每QPS实际资源消耗资源。目前EIS已经接入滴滴内部大量的业务，其整个功能模块图如下。因为一些限制，对外部客户，当前滴滴云EIS服务还是通过提交工单接入的方法，用户自助的方式马上会上线。

简枢：降低用户重复平台建设

同EIS一样，机器学习平台级产品在内部积累了丰富的一线平台经验，基于此，机器学习平台在滴滴云上开发了平台级产品简枢。简枢包装了多种平台能力，弱隔离方案的资源管理、多种任务管理、监控报警、在线服务快速部署等，能够帮助其他公司在平台化过程中少踩坑，快速具备平台能力，提高生产效益。

未来展望

对于机器学习来讲，计算力仍然是最具革命性的力量，正如2011年开始的这波深度学习浪潮的助力正是GPU一样，未来计算力还是工程层面的制约力。正如Jeff Dean所言“事实证明，我们真正需要的是超过现在100万倍的计算能力，而不仅仅是几十倍的增长。”因此，对平台来讲，如何更好的管理不断爆发式增加的计算力、如何有效的释放出这些计算力，如何驾驭好这些计算力仍然需要平台不断的探索、实践、技术升级等等。

所有平台的生命力源自于生产效率的综合提高，降低整体成本。对于滴滴机器学习平台而言，内部第一目标是要降低滴滴在使用最新的机器学习、深度学习、强化学习等技术上能够保证整体效率和成本控制，同时兼顾创新的活力；对于外部来讲，秉承持续为客户创造价值的理念，深化云平台产品的各项产品功能、质量和成本，为客户打造物美价廉的技术产品。

机器学习平台3.0

具体来说，滴滴机器学习平台要实现3.0阶段，也即从硬件选型到基础设施到上层整个软件栈，能够做到内外统一架构，降低内外两部分的重复性工作。同时会从AI解决问题的效率和规模两方面着手，在平台上提供更丰富的功能，比如开发算法市场、模型市场、数据市场、GUI界面以提高用户使用各种学习技术的效率，也会继续沉淀更多的具体服务，比如：人脸比对、语音识别、翻译等等。