dyweb / papers-notebook

:page_facing_up: :cn: :page_with_curl: 论文阅读笔记(分布式系统、虚拟化、机器学习)Papers Notebook (Distributed System, Virtualization, Machine Learning)
https://github.com/dyweb/papers-notebook/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3ATODO-%E6%9C%AA%E8%AF%BB
Apache License 2.0
2.13k stars 244 forks source link

Applied Machine Learning at Facebook: A Datacenter Infrastructure Perspective #41

Open gaocegege opened 6 years ago

gaocegege commented 6 years ago

https://research.fb.com/publications/applied-machine-learning-at-facebook-a-datacenter-infrastructure-perspective/

From ScorpioCPH@

这是 Facebook 发表在 CCF A 类期刊 HPCA 上的一篇论文, 介绍了 Facebook 在 ML at Scale 上的一些探索, 很值得一读.

at15 commented 6 years ago

senior system alchemy

gaocegege commented 6 years ago

International Symposium on High-Performance Computer Architecture (HPCA)

gaocegege commented 6 years ago

Facebook 截止到 2017 年 12 月已经有了 2 billion 的用户, 与此同时机器学习也被应用于多种场景下:

ML 内部使用一览

这一章介绍了 Facebook 内部的一些应用和轮子

应用场景

screenshot from 2017-12-28 13-52-49

ML 内部轮子

Facebook 有一个内部的平台, FBLearner, 可以管理整个机器学习任务的全生命周期. 它分为三个工具, 并且会有一个自己的调度器, 在 CPU 和 GPU 上进行调度. 三个工具分别是:

FBLearner Feature Store

一个专门负责生成 feature 的工具, 内部还有一个 marketplace, 不同团队可以分享 feature, 有点不懂是什么意思..

FBLearner Flow

Flow 负责的就是训练的过程, 看描述应该也是类似 DAG 图的方式去定义然后执行的.

FBLearner Predictor

Predictor 有点像 TensorFlow Serving 做的事情, 但是它可以直接作为一个 lib 集成在特定的后端服务里, 因此也不是完全一样.

FBLearner 已经 port 了两个框架: PyTorch 和 Caffe2. 其中 Caffe2 是给 production 用的, PyTorch 是给 research 用的. 与此同时, Facebook 为了解决模型在不同框架间传递转换的问题, 自己定义了一个标准 Open Neural Network Exchange(ONNX), ONNX 被用来把 research 框架 PyTorch 的模型转换为 Caffe2 的模型.

机器学习中的资源问题

这一章主要介绍了在机器学习的两个环节, 训练和预测中对资源的不同要求.

Facebook 的硬件资源 (有点看不懂)

首先介绍了了 Facebook 的 CPU 以及 GPU 机器的组成, 对于 CPU 机器, 论文举了一个例子, 是 2U 的机架, 一个机架上可以放三个 sleds, 其中每个 sled 有两种选择:

对于 GPU 机器, Facebook 有一种服务器规格 Big Basin, 它是用 8 个 NVIDIA Tesla P100 GPU(现在是 V100 了) 通过 NVLink 的方式拼起来的一个 mesh.

论文还介绍了 Big Basin 相比于前一代 GPU 服务器的提高, 这里就不讲了. 所有的服务器设计都开源在了 Open Compute 项目中.

离线训练的资源问题

因为资源的异构性, 就导致了很多复杂的问题. 在 Facebook 内部, 有一些服务是只跑在 GPU 上的, 有一些是跑在 dual-socket server 上的, 还有像 Facer 这样的有两个训练的过程, 第一个阶段是每个月会训练一个比较 general 的人脸识别, 这是在 GPU 上去做的, 第二个阶段是针对不同用户的, 在 single-socket server 上训练的过程. 具体使用资源的频率以及类别如表格:

screenshot from 2017-12-28 15-06-10

除了 CPU GPU 的问题, 还有内存, 硬盘, 网络的问题. 一般来说内存是一定够用的, 而数据则会导致一些 preference, 这就要求数据能够进行很好的 transfer. 对于网络, 很值得参考的一点是在分布式训练的场景下, Facebook 觉得基于以太网的网络对于提供线性扩展的能力来说已经够用了, 换句话说, 网络不会成为线性扩展的瓶颈. 他们用 GPU server 的50G以太网卡, 能够在没有机器间同步的情况下扩展对 vision 模型的训练. 当然模型太大肯定还是有问题.

在线预测的资源问题

这一块没什么亮点, 就是因情况而异, 另外就是随着高性能的移动硬件的流行, 直接在用户的硬件上运行模型也是很好的, 这也是你为什么手机用电越来越快的原因 :-)

数据中心规模的机器学习

首先一点就是数据跟模型的问题, 在数据中心, 数据都是非常大的. 为了解决数据的问题, Facebook 分离了数据跟训练, 有一些机器, 被叫做 reader 会读数据然后喂给 trainer 机器. reader 和 trainer 都是可以横向扩展的. 为了解决网络问题也有一些没有详细说的优化: compression, scheduling algorithms, data/compute placement, etc.

这里就提到了削峰填谷的问题, 如何能让机器学习任务利用起非高峰时刻 Facebook 冗余的计算资源, 是一个问题. 另外文中提到了灾难恢复对高频更新的离线训练也很重要的原因, 但没什么值得写在这里的.

未来展望

首先, 提到了计算方面的事情, 卷积和中等规模的矩阵运算是深度学习里很关键的运算方式, 因此如何优化他们是很有研究意义的. 文中说特殊的矩阵运算引擎或者处理器会加速这一块.

另外就是模型压缩, 这部分还需要再看看, 现在对机器学习还不熟悉, 看不太明白如何去做.

最后, 文中提到了一个特性:

Synchronous SGD requires an all-reduce operation. An interesting property of all-reduce, when performed using recursive doubling (and halving), is that bandwidth requirements decrease exponentially with the recursion levels.

这鼓励了分层的设计, 文中阐述了一种 super nodes + local nodes 的 hybrid 的思想然后说这方面的研究最近很多, 目前还不了解.

at15 commented 6 years ago

优秀策策.... 读策策的notes, meta-reading