机器学习系统(MLsys)综述:分布式、模型压缩与框架设计

2020 年 2 月 21 日 极市平台

加入极市专业CV交流群,与10000+来自腾讯,华为,百度,北大,清华,中科院等名企名校视觉开发者互动交流!

同时提供每月大咖直播分享、真实项目需求对接、干货资讯汇总,行业技术交流。关注 极市平台 公众号 ,回复 加群,立刻申请入群~


作者:PRO Pentium
知乎链接:https://zhuanlan.zhihu.com/p/104444471
本文已由作者授权转载,未经允许,不得二次转载。


最近在试着寻找ML + sys可做的方向,发现涉及到的坑太多了,有点眼花缭乱的感觉......不如写点东西总结一哈,帮自己理一下思路。

个人感觉MLsys不能算是一种方向,而是一种思路。比如对于system研究者来说,可以把ML作为我们开发的系统要适配的一种benchmark,就像transaction对于数据库、某种文件场景对于File System的意义一样。这样一想可做的空间就宽广多了。就算ML哪天又进入寒冬,之前所学的技术也仍然是可持续的。传统的system研究者也应该适应这个潮流,不能简单的把MLsys一律归为大水漫灌..

有很多topic我也是初次接触,还不是很熟悉。如有错误还请批评指点~

本文结构:

1 分布式机器学习

1.1. 分布式ML系统设计

1.2 Edge Computing

1.3 大量计算资源的Scheduling / device placement

1.4 communication相关

1.5 其他sys for ML可做的坑

2. 深度学习模型压缩/加速

2.1 通过Quantized(量化)降低计算精度要求

2.2 新硬件 / DL Acclerator

2.3 矩阵算子优化

3. 深度学习框架/系统设计

3.1 Deep Learning Framework

3.2 Inference / Model Serving

3.3 深度学习编译器

4. 用ML优化传统的system问题

5. 其他


1. 分布式机器学习(Distributed DNN Training)


这个又可以分为两个方面:from ML / system perspective。安利一下刘铁岩老师的《分布式机器学习》这本书([ch_]表示引用这本书中的一些章节),还有UCB cs294 19fall的这一节。

ML

从ML的角度做,主要是发明或改进分布式训练算法[ch4] [ch5],保证在分布式加速的同时,仍然能达到原来的学习效果(loss/accuracy)。因此很多工作也被投在像ICML、NIPS这种专业ML会议上。主要用到的方法包括优化(optimization)和统计学习理论(statistical learning theory)。

还有一类工作涉及到如何把单机算法改造成分布式[ch9],比如同步/异步SGD等。这里主要涉及到的问题是如何降低分布式环境下的通信开销,提高加速比。

System

还有一个就是从System的角度做。从分布式计算的角度来看,可以把相关工作分为以下几类:

  1. 对于计算量太大的场景(计算并行),可以多线程/多节点并行计算,多节点共享公共的存储空间。常用的一个算法就是同步随机梯度下降(synchronous stochastic gradient descent),含义大致相当于K个(K是节点数)mini-batch SGD [ch6.2]


  2. 对于训练数据太多,单机放不下的场景(数据并行,也是最主要的场景),需要将数据划分到多个节点上训练。每个节点先用本地的数据先训练出一个子模型,同时和其他节点保持通信(比如更新参数)以保证最终可以有效整合来自各个节点的训练结果,并得到全局的ML模型。[ch6.3]


  3. 对于模型太大的场景,需要把模型(例如NN中的不同层)划分到不同节点上进行训练。此时不同节点之间可能需要频繁的sync。这个叫做模型并行。[ch6.4]


  4. Pipeline Parallelism:这是去年(SOSP19 PipeDream)才出现的概念,参考这里的第90、95页 以及这里的简介。Pipeline Parallelism相当于把数据并行和模型并行结合起来,把数据划分成多个chunk,也把训练模型的过程分成了Forward Pass和Backward Pass两个stage。然后用流水线的思想进行计算。


另外,分布式ML本质上还是分布式系统嘛,所以像传统分布式系统里的一些topic(比如一致性、fault tolerance、通信、load balance等等)也可以放到这个背景下进行研究。

最近挖的比较多的坑大致涉及以下几个点:

1.1. 分布式ML系统设计

[ch7.3] 最著名的就是几大分布式DL模型:Parameter Server / AllReduce等。

个人感觉这里面一个可以挖的坑是Decentralized Training。地里一位大佬也在做这个方向。

1.2 Edge Computing

很多ML模型是需要在手机上运行的(比如毁图秀秀)。针对这一场景,一个是要对手机这种低功耗设备对ML model进行裁剪加速(后面会提到),还有一个要做的就是运行在多个device上的分布式ML。

这里有个最近非常火的概念:Federated Learning。其实本质还是炒数据并行的冷饭...不过应用场景比较不一样。FL更多是为了Privacy的考虑,而分布式加速训练在这里倒是个次要目标。FL还涉及到了模型聚合[ch8],也就是如何把多个device本地训练出的模型合并到一起。

1.3 大量计算资源的Scheduling / device placement

UCB的CS294 19spring对这一节有过介绍。

这里的计算资源的数量级是很大的......比如工业界会有万台CPU服务器 / 上千台GPU服务器搭建的DL平台。这个小方向要解决的问题就是如何充分利用它们的性能。比如在阿里PAI组的JD里就有这么一条:“设计探索高效的分布式Placement算法,以更系统化的方式来解决大规模深度学习高效训练的问题”。

这方面比较早的工作大概是这篇paper(http://www-users.cselabs.umn.edu/classes/Spring-2019/csci8980/papers/device_placement.pdf),说的是如何为TensorFlow计算图里的不同算子分配不同的device,最后用强化学习实现了这个目标。这个工作看起来有点prototype,但提出了一个新的思路。另外还有很多猛如虎的类似Train XX model in y minutes的工作。这种就不仅是placement好就能完成的了,还需要涉及系统拓扑的设计、降低communication开销等等。

对于集群调度,工业界的一个热点是使用容器平台(例如k8s)来运行分布式机器学习应用。虽然k8s本身就有容器集群调度的功能,但为了让它更好地适应ML的workload,人们开发了一些新的轮子,比如针对TensorFlow(Parameter Server模型)和PyTorch的KubeFlow。还有用k8s来跑AutoML的katib。学术界对这方面的一个研究热点是GPU集群调度,在下面2.2节会介绍。

1.4 communication相关

[ch3.5] [ch7]介绍了一些宏观上的通信模型,但深入进去还有很多可搞的坑。传统搞网络/分布式系统的组比较契合这个小方向。

例如我校的分布式组原来有一些geo-distributed system的工作,现在也可以往ML上装。

1.5 其他sys for ML可做的坑

工业界的一个ML pipeline不仅仅是训练,还涉及到很多其他的坑。这些是目前被挖的还比较少的:

  • 存储 / Data Management:


    • 1) 训练数据的规模是很大的。如何为ML设计一个专用的文件系统(类似大数据界的HDFS)或者数据库来加速读数据呢?类似的工作有管理ML model的ModelDB. 
    • 2) 在ML framework中,以及Parameter Server中,需要用一个KV storage system来存储参数。可不可以针对ML的场景优化这个KV存储系统呢?关于这个可以参考neopenx大神的blog。

2. 深度学习模型压缩/加速


这方面和architecture结合比较紧密。CS229有这一节,也可以参考NIPS19上的这个talk。

对DL model进行压缩主要考虑两个角度:减少计算量(例如conv层的计算量) / 内存占用(NN的参数数量)。不仅要考虑ML上的metric,也要考虑system层面的performance(例如latency / throughput / 功耗。有时候这些比ML模型的accuracy还重要)。具体的方式大概有以下几种:

  • 1. Architectural Compression

    • Layer Design -> Typically using factorization techniques to reduce storage and computation

    • Pruning(剪枝) -> Eliminating weights, layers, or channels to reduce storage and computation from large pre-trained models. 减少卷积核大小 / 通道数等等

  • 2. Weight Compression

    • Low Bit Precision Arithmetic -> Weights and activations are stored and computed using low bit precision

    • Quantized(量化) Weight Encoding -> Weights are quantized and stored using dictionary encodings.


很多相关的工作是在ML的角度来压缩模型的(也就是Arch Compression,特别是针对CNN和RNN。比如很著名的MobileNet)。这里我们先(kan)略(bu)过(dong),来看从System的角度是如何加速的。

2.1 通过Quantized(量化)降低计算精度要求

量化的含义是将卷积层(the weights and / or activations of a CNN)通常要用到的32位浮点数用更低位的数来表示,如int32, int16, int8等等,来降低资源占用(float32无论是计算还是存储都是很吃资源的..)。量化之后无疑会损失一部分精度,但神经网络对噪声并不是特别敏感,因此控制好量化的程度之后对ML任务的影响可以很小。

一种常用的量化方法是train in floating point and then quantize the resulting weights,训练时还是用float32(因为要涉及到反向传播和梯度下降,全是int就很难搞了..),但在inference的阶段就可以加速啦。一个直观的方法是事先找好一般网络参数的min / max值,然后将训练好的网络参数乘一个scala factor来映射到[MIN_INT, MAX_INT]区间内的整数存起来。在inference时先按int来计算,最后结果再转换回float32。这一过程中其实加速了大量的卷积计算。

混合精度计算:上面讲的方法是用在inference阶段的,其实在模型训练时也可以用类似的方法来加速,只不过再用int就不大行了。一种比较新的方法是用float16(也就是俗称的半精度),fp16占用空间是单精度(fp32)的一半,双精度(double,也就是fp64)的1/4。

量化的具体实现方法可以参考这里:https://zhuanlan.zhihu.com/p/58182172。NVIDIA专门推出了针对inference阶段量化加速的工具包TensorRT

2.2 新硬件 / DL Acclerator

在纯硬件方面针对DL workload的工作也有很多,这里来看几个parallel相关的技术。最近Data-Level Parallelism不仅在深度学习中,在其他一些领域(比如数据库)也有了越来越多的应用。

1)CPU: 尽管GPU已经成了深度学习计算的标配,有时候仍然是需要CPU运算的。例如要在手机等辣鸡设备上进行inference。

SIMD: SIMD的含义是同一条指令在多个数据流上操作,和在向量处理器中一样。在具体实现中(例如SSE指令集)是把一个128位SSE寄存器(这是新增加的SIMD专用寄存器,和早期借用FPU寄存器的MMX不同。在SSE指令集中是增加了8个这种寄存器)划分成4个块,同时存放4个float32单精度浮点数,4个块可以同时进行运算(有多个运算单元,作用于不同的地址),这样就提高了并行度。

后来的SSE2 / SSE3 / SSE4 / AVX指令集在此基础上又增加对float64 / 更多运算的支持,以及扩展了SIMD专用寄存器的位数,但本质上还是一样的。  另外,SIMD带来的并行和超标量处理器的并行性(一个周期issue多个指令,用于instruction level parallelism)不是一个概念。非超标量处理器也可以SIMD,而超标量处理器可以更并行issue多个SIMD操作。

VLIW: 和一次issue多条指令,然后靠硬件进行ILP调度(也叫动态多发射。需要硬件实现乱序执行、分支预测等操作)的超标量处理器不同,VLIW(Very Large Instruction Width,采用这种技术的处理器也叫做静态多发射处理器)的含义是一次只issue一条可以完成多个操作的复杂长指令(也叫发射包,其实从软件的角度看是多条指令的集合)。因此一条指令的位宽可以很大。VLIW是通过编译器来进行指令级并行调度的(比如一个常用的方法是循环展开,通过识别出可并行的重叠跨循环体指令块来实现ILP)。

VLIW的本意是希望在编译阶段就识别出程序中的依赖关系(静态调度),得到可以并行执行的发射包,硬件只需要根据调度好的发射包直接执行即可,这样就简化了硬件实现,从而实现更大宽度发射包的并行执行。intel Itanium的IA64指令集就使用了这个技术,但它在当年并没有取得成功。一个重要的原因是它只适合计算密集、算法固定可控的workload。传统的通用应用程序可能很难具备这个属性(有很多run-time才能确定的值,另外cache访问也是不确定的),但深度学习任务具备这些性质。

2)GPU: GPU的本质可以看做SIMT(Single Instruction Multiple Threads)。

GPU集群 :DL框架一般都支持GPU和分布式训练,已经可以在GPU集群环境下运行了,但实际上还存在一些问题导致分布式场景下资源的使用率提不上去:1). CPU和GPU之间memcpy开销太大、2). 参数通信开销太大、3). 显存不够用、4). GPU很难虚拟化(多任务共享)、5).需要针对ML workload的更好的集群调度策略。

对于1和3其实也可以用前面提到的神经网络压缩、模型并行等方法解决;对于2一个解决方案是尽量让计算和通信在时间上重叠起来,参考ATC17的Poseidon;MSR对于5做了很多工作,一方面是对大规模GPU集群上的真实日志数据进行分析,得出了一些经验(发表在ATC19)。另一方面是设计一些更好的scheduling策略,例如OSDI2018的Gandiva(针对DL workload自身的特点来提高GPU集群使用率)和NSDI2019的Tiresias;对于4目前还没啥很好的解决方案,但可以通过一些软调度方案来模拟。

3)系统结构: 这个和纯计算关系不是很大,可能暂时和ML加速也没啥关系(事实上目前在计算机网络研究中用的还多一些)......但对于优化整体性能会有帮助。

NUMA: 当单个CPU性能已经到瓶颈时,多处理器就成了比较好的解决方案。为了方便编程,需要保证能为应用程序提供跨越所有处理器的单一物理地址空间,这种也叫做共享内存处理器(Shared Memory Processor)。SMP又可以分为两种类型:1) 任何处理器访问任何地址的仿存时间都是相同的,叫做统一存储访问(Uniform Memory Access)。2) 对于每个核心,访问某些字会比访问其他字快一些,整个内存空间被分割并分配给不同处理器 / 内存控制器,这叫做非统一存储访问(NonUniform Memory Access,NUMA)。

NUMA虽然看起来复杂,但可以支持更大的规模(更多的核心),并且访问附近的存储器时具有较低的延迟。在过去内存控制器还在北桥的时代,多处理器用的是UMA(所有处理器都通过FSB总线连接北桥,再访问内存)。

后来随着核心越来越多,为提高访存速度,内存处理器被做到了CPU内,每个CPU有(或者很少的几个核心共享)一个内存控制器,然后直连一部分内存空间,这些核心就被归为一个NUMA node。而跨NUMA node之间的内存访问需要走QPI总线。可以参考这里的图解。在一些涉及many core的工作中会经常用到NUMA的概念。

RDMA: 在网络环境中会用到。RDMA全称是Remote Direct Memory Access,用于实现不需要OS参与的远程内存访问(因为message passing through kernel会浪费本来很大的内存和网络带宽)。具体的技术细节可以参考这里。不过最近(Eurosys2019)已经有了应用RDMA来加速分布式机器学习的工作。

4)专用硬件 CPU性能太菜,GPU又太庞大,于是人们开发了AI专用芯片

FPGA: 全称是Field Programmable Gate Array,是可以多次烧写的。因为本质上属于软件所以可以快速开发 / 迭代。

ASIC: 全称是application-specific integrated circuits,出厂后电路就不可以改变了(需要流片)。但是性能比FPGA高。Google的TPU就属于一种ASIC。

2.3 矩阵算子优化

神经网络中的很多运算本质上就是对矩阵运算,因此可以用一些矩阵乘法优化方案来加速。比如cublas就是封装好的针对矩阵和向量运算的加速库,而对于神经网络加速则会使用cudnn。

算子优化是个非常贴近hardware的工作,对多种设备都人工调优这些算子其实是比较难的。如果能简化一部分工作就最好啦。于是就有了下面会提到的深度学习编译器:

2.4 AutoML

这个严格来说可能不算MLsys了...但它的思路在很多MLsys问题中也会被用到
AutoML最早只能调很有限的几种参数,用的方法也比较暴力(启发式搜索)。后来能调的东西越来越多,方法也更加猛如虎...一个里程碑是NAS,标志着神经网络结构也可以Auto了。

常用的调参方法大致可以分为这几种:

  1. 随机搜索,或者说叫启发式搜索。包括 GridSearch 和 RandomSearch。这种方法的改进空间主要体现在使用不同的采样方法生成配置,但本质上仍然是随机试验不同的配置,没有根据跑出来的结果来反馈指导采样过程,效率比较低。

  2. Multi-armed Bandit。这种方法综合考虑了“探索”和“利用”两个问题,既可以配置更多资源(也就是采样机会)给搜索空间中效果更优的一部分,也会考虑尝试尽量多的可能性。Bandit 结合贝叶斯优化,就构成了传统的 AutoML 的核心。

  3. 深度强化学习。强化学习在 AutoML 中最著名的应用就是 NAS,用于自动生成神经网络结构。另外它在 深度学习参数调优 中也有应用。它的优点是从“从数据中学习”转变为“从动作中学习”(比如某个参数从小调到大),既可以从性能好的样本中学习,也可以从性能坏的样本中学习。但强化学习的坑也比较多,体现在训练可能比较困难,有时结果比较难复现。


之所以把AutoML也列出来,是因为这些方法在下面提到的ML for system问题中会很有用。比如之前做过的AutoTiKV就应用了一种贝叶斯优化方法来调节数据库参数。

cs294中给出了几个可提高的方向:

  • Accelerate data collection and preparation

    • Automatic data discovery

    • Distributed data processing, esp. for image and video data

    • Data cleaning and schema driven auto-featurization

  • Accelerate model selection and hyper-parameter search

    • Parallel and distributed execution

    • Data and feature caching across training runs

  • Provenance

    • Track previous model development to inform future decisions

    • Connect errors in production with decisions in model development


3. 深度学习框架/系统设计


和Distributed Training的区别是这里更关注一些工程上的东西(框架设计、API设计等等)。一个Deep Learning Framework大致需要以下几个元素:

  • 支持各种算子(op) 和 tensor (data)

  • 计算图的定义方式(动态 v.s. 静态)

  • Auto Diff

  • Optimizer(例如Adam)

  • 各种加速和优化的库:cudnn, openblas,mkl等


3.1 Deep Learning Framework

这一节重点关注这几个方向:


1)Differentiable Programming: 如果用过Keras或者PyTorch就会记得它可以简单得像搭积木一样摞一个NN出来,只需要定义一个一个的层(前向传播逻辑)和损失函数就行了。而NN的训练需要Backward Propagation / Forward Propagation,也就是计算微分,运算时framework可以根据定义好的计算图自动求导算梯度。只要可微分就可以保证这个积木能摞出来,然后使用链式法则就可以自动计算微分(Automatic Differentiation)。如果一个语言或者framework具备了Differentiable Programming的性质,就可以更简单的在它上面开发Deep Learning应用(可以类比python手写NN和Keras的区别)。这篇文章对Auto Diff的实现做了很详细的介绍。

2)Embedded Domain Specific Languages: DSL的概念我们都知道,比如SQL就是数据库系统中的DSL,但这已经相当于一个全新的语言了。Embedded DSL是在现有语言上(例如Python)针对某个特定任务做的扩展。比如为了让Python做矩阵计算更方便发明了numpy;为了进行机器学习就有了TensorFlow / PyTorch等等。Embedded DSL的作用是完成 Linear Algebra -> Pipelines -> Differentiable Programs 的转化。

3)根据计算图的定义方式, 可以分为Declarative Abstraction(Embedded DSL先生成静态计算图,类似编译执行 define-and-run,例如Tensorflow、Caffe)和Imperative(Embedded DSL生成动态计算图并直接输出结果,类似解释执行 define-by-run,例如PyTorch、Tensorflow Eager)

对于具体的DL框架来说,虽然很多公司都开始自研框架了,但最流行的基本就TensorFlow、PyTorch、mxnet等等那几家了。不过最近又出现了分布式强化学习框架Ray,也具有很好的落地潜能。

3.2 Inference / Model Serving

之前关注了很多训练ML模型中会遇到的问题。但实际应用场景里,inference(直接使用训练好的模型predict)的次数会比training多很多,因此inference的性能也很重要。

Inference可以再分为以下两种:

  • Offline: Pre-Materialize Predictions:所有可能的query都是已知的,就事先predict好存起来。一般没有这么玩的...

  • Online: Compute Predictions on the fly:根据用户的输入实时predict。这才是最常见的场景


一个典型的ML inference pipeline大致涉及到以下工序:

  • input data

  • -> Preprocessing(比如图片要resize)

  • -> model prediction(有时候会同时用很多model,还要ensemble起来)

  • -> 输出结果,有时候还要处理一下


这个pipeline的衡量指标包括Latency、Throughput等(和传统的system问题一样呀)。cs294里列出了几个最近的工作,个人感觉这里可做的坑不多....大多是修修补补。

3.3深度学习编译器

这里值得提一下TVM。这篇文章(https://www.pdl.cmu.edu/PDL-FTP/Database/sigmod18-ma.pdf)对TVM进行了非常详细的介绍。

简单的说TVM是在把训练好的ML model部署在不同设备上时用的,重点关注的是Inference而不是Training(也就是推理引擎)。在这一过程中,模型本身可能用了不同的framework来写(比如tensorflow / PyTorch / MXNet,本质区别在于使用的算子类型可能不一样),而要部署到的设备也可能有不同的硬件架构(比如x86 / ARM / GPU / FPGA)。inference的过程也就是将framework X写出来的model放在硬件Y上运行的过程,这一过程和编译器是非常相似的(将语言X写的程序编译到硬件Y上运行),这也就是深度学习编译器的含义。

为了设计一个高效的深度学习编译器,TVM借鉴了传统编译器LLVM的设计思想:抽象出编译器前端[ 高级语言C/java -> IR ],编译器中端[ 优化IR,这种是不同编译器平台共享的 ],编译器后端[ IR -> 目标硬件上的binary ]等概念,引入IR (Intermediate Representation。深度学习问题中可以将计算图作为IR,称为Graph IR)。这样不同硬件/framework都对标同一套IR,就避免了需要对每种硬件和framework排列组合适配的问题。TVM主要解决的是后端的问题[在目标硬件上高效运行IR]。而前端的问题[生成和优化IR]就交给深度学习框架们完成(针对这一步,在TVM stack中提供了NNVM,作用是represent workloads from different frameworks into standardized computation graphs。

TVM是和硬件深度集成的,也就是需要针对每种硬件平台实现相关的AI算子(类似NVIDIA GPU上的cuDNN)。然而人工调优这些算子的实现是很费精力的(特别是要针对不同形状的业务模型),这里面也有一些knob需要调整。为了让这个过程也能ML化,于是后来有了AutoTVM。

cs294 sp19还提出了几个可能的future work:

  • - Compilers are great at Ahead of Time scheduling, what about Just-In-Time scheduling?

  • - Any way we can share GPU in predictable way and maximize utilization for DNN inference?

  • - Can we optimize for “fitness” of the kernel when it’s executed along with other kernels instead of its latency?


4. 用ML优化传统的system问题


这里面的花样就更多了...在上学期Jon的ML system课上有过较详细的接触。大部分是用ML去优化一个传统system问题中,一些需要人工经验调整、或者说可以从历史情况learn到一些东西的模块。比如数据库参数、操作系统页表、数据库索引等等。一个模块可以被ML化的前提是它必须是empirical的,参考它在页表(OS的工作集原理)、数据库(DBA是个很吃经验的活...)中的应用。如果人工都看不出来啥规律就别指望它能ML了。

一般认为用ML优化system的思想是起源于Jeff Dean在NIPS2017的workshop。这方面的工作很多发表在纯system的顶级会议以及下属的AI for xxx workshop上,另外一些AI会议的workshop也会收录一些这方面的工作,比如nips 2018的MLsys workshop。从2017年开始已经有很多坑被做过了,但个人感觉还是有一些搞头的。感觉可以从下面两个角度再来搞:

1)同样的scenario,使用更合适的ML算法。注意这里是更合适,而不是更高大上猛如虎。


比如这篇ML+Database的paper(https://www.pdl.cmu.edu/PDL-FTP/Database/sigmod18-ma.pdf),使用了LSTM来预测未来的workload pattern,还要用GPU训练,但生产环境上要求数据库服务器也安个显卡是不现实的。工程上的一个解决方案是搞个集中式的训练集群(类似OtterTune),在DBaaS的情况下这种方法倒是行得通,但在对外发布的数据库产品中就不行了。


这里感觉可以参考早期AutoML的一些工作,因为它们本质是很类似的(都是调参嘛...)。传统方法有启发式搜索/贝叶斯优化。最近也有很多人用强化学习去搞,但还是存在太吃资源的问题...


2)寻找system界更多可以ML化的场景。这个更适合专业的system researcher来做,对ML倒是略有了解即可。


有一类思路是把ML深度集成到系统设计中,比如Andy在2019年的15-721课上提到过Self-Driving Database的概念,和之前用ML优化数据库的工作不同的是,Self-Driving DB更关注如何把ML和DB深度集成,而不是搞一个又一个外挂的模块了。


一个类似的工作是在OS领域:engineering.purdue.edu/ 。


另外还有个工作是在Key-Value Storage Engine的领域:arxiv.org/pdf/1907.0544。它提出了Design Continuum的概念:存储系统中的很多数据结构本质上是很像的(arise from the very same set of fundamental design principles),例如B+tree, LSM-tree, LSH-table等,但它们却有不同的应用场景(比如KV Store中用LSM就比B+ Tree更合适),很难有一个十全十美的设计。这说明它们有相互替换的空间。这样我们可以将不同数据结构的选择也作为存储系统的一个knob,根据具体workload和硬件的情况来自动选择一个合适的底层数据结构(find a close to optimal data structure design for a key-value store given a target workload and hardware environment)。


一个更宏观一些的思路是做system and algorithm co-design,让任意计算机系统都能和ml深度集成。虽然具体的target system不一样,但其中有很多模块都是类似的(例如training、inference、system monitor等等)。针对这一目标MSR提出了AutoSys,对这些通用模块进行了整合。


5. 其他


  • ML pipeline / lifecycle:ucbrise.github.io/cs294

  • Privacy:ucbrise.github.io/cs294

  • 图神经网络训练系统:msra.cn/zh-cn/news/feat [ATC19 NeuGraph]


需要的技能树


这是从一些公司ML System Research Scientist岗位的招聘要求中整理出来的,更侧重system一些。

System:
  • 工程基础:C/C++、OO programming。阅读源码是个很好的学习方式

  • OS

  • 分布式系统

  • 编译原理。特别是编译器优化技术、LLVM、memory optimization。Parser之类不喜欢也可以不看

  • Computer Architecture。另外还需要了解:1.GPU架构,例如显存分配机制、CPU与GPU交互。2.CPU、存储系统相关的新技术。3.有条件可以了解下深度学习专用硬件。

  • 常见的并行计算框架,例如MPI/OpenMP/CUDA

  • ML framework的底层原理,扒源码

  • 工业界的一些新东西:例如k8s、KubeFlow、ElasticDL


ML:
  • 机器学习基础

  • 常见的分布式机器学习算法、DL模型压缩、模型加速方法(根据具体方向而定)

  • 数理基础不要太菜…不要被人吐槽像没学过高中数学…



-END-


点击   阅读原文 ,可跳转浏览本文内所有网址链接


*延伸阅读



极市平台视觉算法季度赛,提供真实应用场景数据和免费算力,特殊时期,一起在家打比赛吧!



添加极市小助手微信 (ID : cv-mart) ,备注: 研究方向-姓名-学校/公司-城市 (如:目标检测-小极-北大-深圳),即可申请加入 目标检测、目标跟踪、人脸、工业检测、医学影像、三维&SLAM、图像分割等极市技术交流群 ,更有 每月大咖直播分享、真实项目需求对接、求职内推、算法竞赛、 干货资讯汇总、行业技术交流 一起来让思想之光照的更远吧~


△长按添加极市小助手


△长按关注极市平台,获取最新CV干货


觉得有用麻烦给个在看啦~  

登录查看更多
5

相关内容

FPGA加速系统开发工具设计:综述与实践
专知会员服务
65+阅读 · 2020年6月24日
【硬核书】可扩展机器学习:并行分布式方法
专知会员服务
85+阅读 · 2020年5月23日
MIT公开课-Vivienne Sze教授《深度学习硬件加速器》,86页ppt
最新《分布式机器学习》论文综述最新DML进展,33页pdf
专知会员服务
118+阅读 · 2019年12月26日
深度神经网络模型压缩与加速综述
专知会员服务
128+阅读 · 2019年10月12日
分布式入门,怎样用PyTorch实现多GPU分布式训练
机器之心
7+阅读 · 2019年5月3日
神经网络训练tricks
极市平台
6+阅读 · 2019年4月15日
Tensorflow框架是如何支持分布式训练的?
AI100
9+阅读 · 2019年3月26日
硬件加速神经网络综述
计算机研究与发展
26+阅读 · 2019年2月1日
开源神经网络框架Caffe2全介绍
人工智能学家
3+阅读 · 2017年12月11日
CNN模型压缩与加速算法综述
微信AI
6+阅读 · 2017年10月11日
干货|CNN 模型压缩与加速算法综述
全球人工智能
9+阅读 · 2017年8月26日
CNN 模型压缩与加速算法综述
机器学习研究会
16+阅读 · 2017年8月25日
Arxiv
45+阅读 · 2019年12月20日
Optimization for deep learning: theory and algorithms
Arxiv
104+阅读 · 2019年12月19日
Arxiv
17+阅读 · 2018年4月2日
VIP会员
相关VIP内容
相关资讯
分布式入门,怎样用PyTorch实现多GPU分布式训练
机器之心
7+阅读 · 2019年5月3日
神经网络训练tricks
极市平台
6+阅读 · 2019年4月15日
Tensorflow框架是如何支持分布式训练的?
AI100
9+阅读 · 2019年3月26日
硬件加速神经网络综述
计算机研究与发展
26+阅读 · 2019年2月1日
开源神经网络框架Caffe2全介绍
人工智能学家
3+阅读 · 2017年12月11日
CNN模型压缩与加速算法综述
微信AI
6+阅读 · 2017年10月11日
干货|CNN 模型压缩与加速算法综述
全球人工智能
9+阅读 · 2017年8月26日
CNN 模型压缩与加速算法综述
机器学习研究会
16+阅读 · 2017年8月25日
Top
微信扫码咨询专知VIP会员