Pentium.Labs

System全家桶：https://zhuanlan.zhihu.com/c_1238468913098731520

导航

Paper Reading_System for ML

读paper药不能停啊...

 

Mark一个MLsys大神的Blog

再Mark一个大神的笔记

 

 

Distributed ML 

Scaling Distributed Machine Learning with the Parameter Server

https://blog.csdn.net/stdcoutzyx/article/details/51241868

.

 

 

Decentralized ML

Decentralized distributed deep learning in heterogeneous WAN environments

这篇文章的idea一目了然：在geo-distributed的节点上进行Decentralized DL

这个场景下的Decentralized DL是有很多问题要解决的：

  1. WAN网络带宽很有限
  2. 节点之间计算能力差异很大，容易导致训练变慢，甚至不coverage

本文感觉没有提出啥自己的idea......就总结了下面几个方法，然后implement了一个framework：

  • automatically adjust: 
  • 1) the frequency of parameter sharing
  • 2) the size of parameters shared depending on individual network bandwidth and data processing power
  • 3) introduces a new scaling factor to control the degree of contribution to parameter updates by considering the amount of data trained during unit time in each device.

本文主要参考了Ako这篇文章，他们通过sharing partial parameters来减少了通信开销。

好水啊。。。

Link：

https://www-users.cs.umn.edu/~chandra/tfako/home.html

 

Ako:  Decentralised  Deep  Learning with  Partial  Gradient  Exchange

23333

 

DLion: Decentralized Distributed Deep Learning in Micro-Clouds

在Distributed DL中，一个很常见的场景就是要在edge侧（Edge Device表示性能和稳定性都不太好的设备，比如用流量上网的手机）得到一些新的数据，然后去refine一个之前已经train好的model（incrementalor online deep learning over newly generated data in real-time）。但是广域网是很慢的，如果要所有edge把数据传给一个总服务器要耗费很大的带宽，而且现在手机的性能已经有点够用了，所以我们希望搞个decentralize的DL framework，直接在edge侧就解决问题。

相对于纯Decentralize DL的工作，本文提出了一个micro-cloud的概念：micro-clouds—small-scale clouds deployed near edge devices in many different locations（用于给本地的一小部分edge服务，感觉有点类似CDN的意思？），然后重点关注如何在micro-cloud内部去实现Distributed DL。micro-cloud内部具有如下特点：每个node的性能（计算资源）有差异；网络情况有差异；micro-cloud的总量是很大的，而且分布在不同地区。本文就要针对这三个问题，既要提高速度也要提高accuracy，然后还得handle system scalability。

  • ch3.1：每个node的性能（计算资源）有差异，那么每个node根据自己的能力来设置batch size就完了。另外还应用了三种learning rate的调节方式。
  • ch3.2：为了保证性能，node之间的数据通信涉及到交换weights和gradient。然后我们需要实时根据网络情况（controlling the quality of data and considering the available network bandwidth）来调整通信策略。这个又要考虑以下几个因素：
    • when-to-do: when to exchange data, e.g., more frequently early or late in training, or periodically
    • what-to-do: whether to exchange whole or partial data
    • whom-to-do: whether to exchange data with all workers or a subset of workers
    • how-to-do: whether to exchange data synchronously or asynchronously
    这些是通过一个system parameter来调节的。然后Fig4和Fig5展示了不同策略的实验效果。
  • ch3.3：在system scalability这里，我们要考虑的是在WAN环境下，不同micro-cloud之间的通信问题啦，这个涉及到broadcast gradient。本文选择了只在两个micro-cloud之间通信，而不是直接broadcasting。然后根据micro-cloud各自的特征来选择谁是sender/receiver：性能好的batch size大（ch3.1），会有更多的informative gradient，所以作为sender。反之就作为receiver。micro-cloud之间的通信也采用ch3.2里提到的方法。

Future work：

  1. 用更大的scale来实验
  2. data migration：低性能的node上可能数据多。在migrate和load balancing（ch3.1）之间要有个tradeoff
  3. 考虑edge device的电量消耗问题

 

 

Federate Learning

DeCaf: Iterative Collaborative Processing over the Edge

最近有一个很火的概念叫做Federated Learning：意思就是在不能接触到数据（因为可能涉及用户隐私）的情况下来训练ML model。那么在geo-distributed以及edge computing的场景下，就需要在不能将用户数据从edge侧传到central服务器的前提下analysis data（there is a need for approaches which enable analytics without transferring the raw data out of the edge devices.）。本文的idea就是解决在edge设备上performing ICP computation时，如何处理geo-distributed的edge device的drop out率太高等问题，并设计了一套计算框架。

（ICP的含义[ch3.1]：Iterative Collaborative Processing(ICP) involves performing a set of computations in multiple iterations.    ML中的training就是一种典型的ICP。比如在典型的参数服务器系统中，中心服务器上维护一套中心的parameter，各个edge负责用本地的数据训练自己的individual parameter，再和central进行同步。）

Related work中涉及到如下几个方面：1).Distributed ML system有很多，最著名的是parameter server，但它是centralized。2).Geo-distributed的系统也有很多，但针对ML workload的研究还不多。3).Federated ML的框架也有一些，但没有考虑edge computing中的一些场景：比如edge device经常会drop out（没电了或者关流量了）。　　　　【所以知道idea都是怎么憋出来的了吧？】

我们这个system是一个星型拓扑的结构：所有edge连接到central controller上，但其实edge之间也可以P2P的通信。所有edge把本地计算结果推给controller，controller更新model parameter，再更新所有edge上的parameter。这个system要实现以下几个feature：

  • 1. Proactive（主动的） Monitoring and Prediction
    • edge设备的计算资源是很奇怪的（high variations in resource availability over time in edge environments），因此我们需要对edge device的资源（比如cpu使用率、剩余电量、网速等）进行实时监控，在后面会用到这些监控数据。这个就是很工程的东西了...安个鲁大师就行了hhhh
    • 另外还可以通过记录过去的resource utilization pattern，来试着预测未来的resource availability。有些related work表明这玩意其实也是可以ML的...（the application usage on mobile devices indeed exhibits temporal patterns）。
  • 2. Adaptive Tuning
    • 在controller向edge分发计算任务后，edge就开始计算啦，当然这个也是会被controller指定一个deadline的。为了确保every edge device finishes the model update within the deadline stipulated by the controller，有些edge device可能等不及处理完所有的数据，就要把结果发给central了（based on the resource availability, we can choose a subset of data points to iterate through）。当然这个subset的percentage的选择也是很有讲究的，需要在保证能赶得上deadline的情况下，选择尽量多的percentage（因为数据多的训练效果肯定好嘛，参考Fig2）
    • 那么这个percentage怎么选呢？可以构建一个resource-computation profile，意思就是根据当前device的resource availability来选择这个percentage。构建这个profile也是个很工程的东西（大体意思和鲁大师跑个分差不多......）
    • 本文中使用了一个比较基本的方法：在计算的过程中，根据已经计算了的数据量和已用时间，来推算deadline前还能处理多少数据。实验证明这个方法还可以。
  • 3. Fault Tolerance and Load Balancing
    • 前面说过数据太少的时候，训练出来的模型的quality是不大能用的。那么如果当前设备的available resource实在太少（比如快没电了），完成不了多少运算了，就需要直接放弃这个设备（也就是drop out），然后migrating the task to another edge device。但是在Federated Learning的场景下，migrate也要考虑用户数据的隐私问题。因此提出了下面的概念：Trusted Device Set。
    • Trusted Device Set：每个设备都可以指定自己的一个Trusted Device Set，表示数据可以在这些设备之间进行migrate（比如一个人有很多个手机、电脑、平板）。当某个设备发现自己蹦跶不了多久了，需要migrate时，就像trust set里的设备发出请求，然后在respond了的设备中选择一个migrate成本最小的进行migrate。因为local dataset一般是很小的，所以这个开销也不会很大。
    • 另外，在load balancing中，可能也会涉及到migration。比如把负责太重的device上的workload移到它的trust set中负载较轻的设备里。

本文以SVM为例测试了整个framework的效果。

 

 

Towards Federated Learning at Scale: System Design 

联邦学习是一个最近提出的概念。大概意思就是：假设A和B各自有不同数据，由于隐私需要他们的数据都不能公开，但A、B各自训练的小模型都不大好。因此他们希望结合AB双方的数据，来训练一个比较好的大模型。

联邦学习是要解决这个问题： 它希望做到各个企业的自有数据不出本地，而后联邦系统可以通过加密机制下的参数交换方式，即在不违反数据隐私法规情况下，建立一个虚拟的共有模型。这个虚拟模型就好像大家把数据聚合在一起建立的最优模型一样。但是在建立虚拟模型的时候，数据本身不移动，也不泄露隐私和影响数据合规。这样，建好的模型在各自的区域仅为本地的目标服务。在这样一个联邦机制下，各个参与者的身份和地位相同，而联邦系统帮助大家建立了“共同富裕”的策略。 这就是为什么这个体系叫做“联邦学习”。

因为数据是分散在各地的，联邦学习天然的自带分布式属性。本文通过一个例子来关注联邦学习系统的system design，目的是对于很多手机上的data训练一个global的模型，同时要保证这些data不能离开手机本地。The weights are combined in the cloud with Federated Averaging。Federated Learning System的大致流程如下：

 

  • (1)、Device们联系FL Server，申请加入当前轮的FL job。但是Device太多啦，目前只能先接受一部分Device。剩下的下一轮再说。（这个选择策略参考ch2.2的selection部分）
  • (2)(3)、FL Server从persistent store（可以理解成server的硬盘）读取模型，然后将current global model parameters打包成FL checkpoints，发给参与本次任务的device们。
  • (4)、所有的device使用收到的model和本地的data，在本地进行training（performs a local computation based on the global state and its local dataset）。完了之后将更新后的FL checkpoints发回FL server。
  • (5)、FL server根据devices发来的checkpoints进行incorporate（比如使用Federated Averaging），更新global的模型。然后GOTO (1)开始下一轮的job。

Fault tolerance：在(4)中没有按时向FL server返回checkpoints的device会被直接丢弃。而在(1)的select阶段中， 也会有一个timeout或者counter之类的约束规则。

Flow control：ch2.3

接下来分别来看两个重要的部件：Device（ch3）和Server（ch4）。这两节讲的比较工程化......

  • Device：Device上要存储本地的training data。还要通过一个schedule来控制启动training。
  • FL Server：FL server的实现基于Actor Programming Model，这是一种并发编程中的常用模型，用于处理系统中不同部件的通信和并发控制。整个结构如图Fig3所示。
    • Selector：负责直接和device通信。device请求加入时也是和selector联系，selector选好设备后forward给Aggregator。selector相当于公司的HR...
    • Aggregator：又分为master aggregator和aggregator，用于管理FL task中的每一轮。相当于公司里的一个个部门
    • Coordinator：负责控制整个FL训练的流程。比如要决定需要多少device然后报告给selector。然后让Aggregator来具体管理FL task。相当于公司的老总...

Secure Aggregation：uses encryption to make individual devices` updates uninspectable by a server.

上面balabala了这么多理论，那么一个FL模型的开发和上线过程是什么样的呢？可以分解为这么几步：

  1. Modeling and simulation：指的是MLE在本地先写好model（个人理解就像平时写个deep learning模型一样）。这里提出了proxy data的概念：MLE用来模拟用户端training data的一些data（Proxy data is similar in shape to the on-device data but drawn from a different distribution – for example, text from Wikipedia may be viewed as proxy data for text typed on a mobile keyboard.）。MLE在开发阶段可以拿这些data来调试自己的模型。同时可以用simulated FL server and devices来模拟FL的场景。
  2. Plan Generation：一个FL Plan可以理解为MLE针对某个任务开发好的FL模型，FL Plan会被部署到device和server上。device端包括tensorflow graph、模型的一些参数（比如batch size、epoch之类）、还有对training data的一些处理规则。而server端包括aggregation logic（用于把各个device的模型拼起来）。

正好学姐让我implement一下......那来看看用tensorflow如何实现吧！https://github.com/pentium3/fl

 

A Survey on Federated Learning Systems: Vision, Hype and Reality for Data Privacy and Protection 

这是这个月刚出的paper，是对现有的FL system做的一个综述，并提出了一些可以挖掘的坑。

现在已经有很多把传统机器学习算法改造到federated learning背景下的工作了（support more machine learning models with different privacy-preserving approaches）。其实Federated并不是一个全新的概念：比如有federated DBMS，表示为某个共同目标一起合作的多个DBMS，重点关注分布式的data management；还有Federated Cloud，表示一群在一起工作的cloud computing services，重点关注resource scheduling；而对于FL system，它的目标则是conduct collaborative machine learning techniques among different organizations under the restrictions on user privacy，重点是secure computation among multiple parties。但它们的本质都是cooperation of multiple independent parties。作者试图利用这些现有的Federated system中的两个性质：Heterogeneity和Autonomy，来从一个新的角度看待FL system。

Heterogeneity：本意是异质性。在FL system中，不同party（可以理解为不同device）之间是存在一些区别的。

1) 各自训练数据的data distribution不同，但这其实可以是一个好事情（The parties can potentially gain a lot from FL if they have various and partially representative distributions towards a specific task.）。另外各自数据的规模也不同，那么就存在一个fairness的问题了：数据多的一方应该benefit more from FL。

            2) 不同party对数据隐私性的要求不同，比如各个国家有不同的数据隐私策略。对于这个topic还很少有人关注，大部分是默认大家的privacy level是一样的。当然这个实现也是比较复杂的。It is very challenging to design an FLS which can maximize the utilization of data of each party while not violating their respective privacy restrictions

3) 不同party的目标目标可能不同。比如银行和保险公司虽然关注的目标不同（哪些客户会贷款 VS 哪些客户会买保险），但它们仍然可以加入同一个FL system。比如可以运用multi-task learning的思想来解决这类问题。

Autonomy：本意是自治性。在这里表示FL system中的每个party都是under independent control的，每个party有权自己决定是否和其它party共享信息。

1) Association Autonomy：每个party有权决定随时加入或者退出FL system（比如设备没电了）。一个party甚至可以加入多个FL system。因此FL system就要考虑fault tolerance和load balance的问题。这点在Google的FL system design中详细介绍了如何实现。

2) Communication Autonomy：每个party可以决定向FL system共享多少信息。因此FL system需要能适配不同的communication scale，同时保证the benefit of the party should be relevant to its contribution。对于每个party来说，share更多的信息可以获得更多收益，但也有泄露隐私的风险。

 

接下来作者介绍了FL system中的几个术语。在ch5和Table1、Table2中，作者按照这个方法论对现有的工作进行了分类总结，另外在ch6中介绍了两个具体的application场景。

  1. Data Distribution：
  2. Machine Learning Models：
  3. Privacy Mechanisms：
  4. Communication Architecture：分为centralized和distributed。在centralized的FL system中，one server is required to aggregate the information (e.g., gradients) from others and send back training result，这个和Google的Towards FL system design [arXiv:1902.01046] 中介绍的架构是一样的。另外还有distributed的FL system，表示the communications are performed among the parties and every party is able to update the global parameters directly。Distributed的FL system显然是很有意义的，但设计起来也很困难，一个难点是如何保证each party is treated nearly equally in terms of communication during the learning process and no trusted server is needed.
  5. Scale of Federation：
  6. Motivation of Federation：

 

最后作者提出了几个现在做的还不太完备，可以接着挖的坑：

  1. （ch7.1.2）支持device的动态加入/退出
  2. （ch7.1.3）支持对不同的device（party）使用不同的privacy restriction，要保证maximize the utilization of data of each party while not violating their privacy restrictions
  3. （ch7.1.4）保证不同device的贡献和收益是fair的，即one party can gain more benefits from the FL System if it contributes more information
  4. （ch7.1.5）设计用于衡量FL system性能的benchmark
  5. （ch7.1.6）需要为FL system设计更好的architecture。特别是考虑如何降低communication cost（所以decentralized或许是一个好idea？）
  6. （ch7.1.7）一些在FL system中进行data management的杂活…
  7. （ch7.1.8）感觉和security有关了。如何防止错误的data影响系统
  8. （ch7.1.9）FL system在移动设备和edge computing场景中会很常用，然而FL system中一些用于保证security和privacy的操作其实是很消耗资源的。那么如何降低资源消耗（computation and energy constraints）就很重要啦。

https://github.com/WeBankFinTech/FATE

 

 

 ...

posted on 2020-04-02 00:19  Pentium.Labs  阅读(462)  评论(0)  编辑  收藏  举报



Pentium.Lab Since 1998