滴滴机器学习平台架构演进

前言：如今不少互联网公司都有本身的机器学习平台，冠以之名虽然形形色色，但就平台所要解决的问题和技术选型基本仍是大同小异。所谓大同是指你们所要处理的问题都类似，技术架构和选型也差不太多，好比都会使用 GPU 集群、采用 Spark 或 K8s 平台等。所谓小异是指各家规模不一样，各家都在结合本身的状况、所处的阶段并根据本身的特色解决平台化的问题。滴滴机器学习平台的治理思路主要是：减小重复、提升效率。本文将对滴滴的机器学习平台进行全面解读，重点分享机器学习平台不一样阶段所要解决的问题，以及解决问题的思路和技术方案。但愿可以对你们有所帮助。

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

滴滴的机器学习平台建设开始于2016年，当时滴滴内部各算法团队逐步开展机器学习、深度学习等 AI 相关的研究和实践应用，这类算法大都属于计算密集型应用，通常都会使用单价较昂贵的 GPU 服务器。但随着业务的开展，各算法团队仅针对各自的问题作规划，致使了一种小做坊式的生产局面。

做坊式生产方式在早期有其积极的一面，可以保证创新的灵活性，可是越日后，这种小做坊式算法生产模式的局限就越明显：资源缺少统筹调度，没法造成规模化效应，大量重复性工做，自拥算力有限。逐渐增多的这种小做坊式生产方式导致总体投入产出的效益大打折扣。

滴滴机器学习平台在这种背景下应运而生，这个阶段也主要致力于解决这些问题。这期间机器学习平台所采用的架构和技术选型主要针对做坊式生产方式的问题来展开，也就是提升复用性和规模化能力。

首先要解决的问题就是统一资源管理，这个“统一”要解决包括线下和线上两类问题。

线下“统一”的问题着重解决 GPU 的服务器选型、测试、引入、上线等的集中化。这类集中化一方面提升了服务器引入的上线质量；另外一方面相比于做坊式模式，因为有 GPU 相关专业人员参与进来，GPU 的选型避免了一味追新的盲目性和发散性。

再者，集中化可以和公司总体大局结合起来，从而能够作最优化的选型和引入方案。

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

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

厘清这些需求以后，结合当时的技术环境和成熟度来看及以上的基本要求，平台选择当下盛行的 Docker 来兼作环境的管理、资源的弱隔离和任务的调度。

但因为此时支持 GPU 资源调度的资源管理器乏善可陈，因此咱们选择对 Yarn 作了扩展以支持 GPU 资源维度上的资源管理和任务调度，环境上平台同时提供 Notebook、Jupyter 的交互接口给用户。

统一资源管理、环境管理后，不得不面对的问题是多个资源节点间数据共享的问题，用户在当前资源释放后申请新资源时每每对以前的数据有依赖。

多节点数据共享在做坊式时期受限于单个的规模，问题不会十分突出，可是集中化以后随用户增多就会逐渐尖锐起来乃至是个大的技术挑战。由于：

机器学习的任务计算特色依赖于 GPU 的高速计算，它们对数据访问延迟有必定要求，这要求必须有足够高的 IO 带宽作支持；
用户数量增长，对存储带宽的需求会变的很是大；
对存储系统来讲，支持 POSIX 接口的要求使得现有技术方案大大减少，另外也需在高可靠性、高性能以及成本之间作折中。

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

机器学习平台架构-Yarn

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

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

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

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

每种性质的任务都有各自重复的具体形式，好比用户在模型生产后要部署模型服务就须要解决服务的 HA、负载均衡等生产服务问题，每个在线模型都要解决这类问题。

再好比，用户训练时每每须要调参，而这些参数都是同形的，只是数值上的变化，这种值上的变化后就是一个个独立任务，须要用户提交任务的流程，这也是重复性的工做。

再好比，用户在运行多机多卡时须要参数服务器，低效的参数服务器把大量的时间浪费在通讯上，这种浪费会加剧用户资源使用上的重复；与这种重复形式类似的，还有模型服务要上线，为了知足服务的延迟、QPS、资源的约束，须要作从服务、到深度学习框架、再到计算库的全栈优化，基本上，大部分模型上线也须要经历这个优化过程。

针对上述新出现的问题，平台须要更增强大的资源管理和任务调度能力。

在上一时期选用做为资源管理和任务调度器的 Yarn 开始呈现出疲态，具体表如今 K8S 日臻成熟，与 Docker 的结合更加合理和完整，并可以整合多种维度的资源，使用 K8S 为解决模型服务的自动化部署提供了环境和条件，也下降了服务的运维成本。

综合 K8S 和 Yarn 各自的利弊，滴滴机器学习平台开始由 Yarn 架构向 K8S 建构迁移。

机器学习平台架构-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（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 界面以提升用户使用各类学习技术的效率，也会继续沉淀更多的具体服务，好比：人脸比对、语音识别、翻译等等。

若是您对滴滴云GPU云主机、弹性推理服务（EIS）、机器学习平台等产品、技术解决方案感兴趣，欢迎访问滴滴云官网。