转载

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

出品 | 滴滴技术

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

▍ 前言：现在很多互联网公司都有自己的机器学习平台，冠以之名虽然形形色色，但就平台所要解决的问题和技术选型基本还是大同小异。所谓大同是指大家所要处理的问题都相似，技术架构和选型也差不太多，比如都会使用 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 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 的用户可以忽略底层硬件的细节，从而可以避免用户重复地去做服务框架层面的已知的优化工作，这样也为实现用户“实用实销”提供了条件。可以通过以下的架构图了解：

滴滴机器学习平台架构演进要做到“实用实销”，还有一个非常关键的环节就是需要知道用户的模型实际的计算需求量，以及某一种硬件下的计算利用率。