面向大规模联邦学习系统设计

本次分享一篇关于大规模联邦学习系统设计的文章《Towards federated learning at scale: System design》。基于TensorFlow为移动设备领域的联邦学习构建了一个可扩展的生产系统。本文中，我们描述了系统的顶层设计，概述了该领域现有的问题及其解决方案，并对未来的发展方向进行了展望。

原文链接： 

https://arxiv.org/abs/1902.01046

1 INTRODUCTION

联邦学习基础设施的一个基本设计决策是关注异步还是同步训练算法。本质上需要在一组固定设备上实现同步。因此，学习算法的服务器端只消耗来自许多用户的更新的简单聚合。由于所有这些原因，我们选择将重点放在对同步轮的支持上，同时通过我们随后描述的几种技术来减少潜在的同步开销。

本文实现：

• 利用Tensorflow对存储在手机上的数据进行深度学习训练

• 权重在云中利用联邦学习进行聚合，并将该模型推送回收机

本文解决的问题：

• 以复杂方式(例如，时区相关性)与本地数据分布相关的设备可用性；

• 不可靠的设备连接和中断的执行；

• 跨不同可用性的设备协调锁定步骤执行；

• 有限的设备存储和计算资源。

2 PROTOCOL（协议）

2.1 Basic Notions（基本概念）

协议的参与者：设备（Android手机）和FL云服务器。

1、在每轮通讯中，服务器告诉选择的设备使用FL计划运行什么计算——一个包含TensorFlow图和如何执行它的指令的数据结构。

2、一旦建立了一轮，接下来服务器将向每个参与者发送当前的全局模型参数和任何其他必要的状态作为FL检查点(本质上是TensorFlow会话的序列化状态)

3、每个参与者根据全局状态及其本地数据集执行本地计算，并以FL检查点的形式向服务器发送更新。

4、服务器将这些更新合并到其全局状态中，并重复该过程。

2.2 Phases（阶段）

该通信协议使设备能够在轮之间推进FL种群的全局、单例模型。整个协议由以下三个部分构成：

• 选择

服务器根据某些目标(如参与设备的最佳数量)选择连接设备的子集(通常每轮有数百个设备参与)。如果未选择设备参与，服务器会在稍后的时间点以重新连接的指令进行响应。

• 配置

服务器是根据所选设备选择的聚合机制来配置的(例如，简单聚合或安全聚合)。服务器将FL预计计划和带有全局模型的FL检查点发送到每个设备。

• 报告

服务器等待参与的设备报告更新。使用Fed-Avg聚合，并指示报告设备何时重新连接。如果有足够多的设备及时报告，则该轮将成功完成，服务器将更新其全局模型，否则该轮将放弃。

如图，未及时报告或未对服务器的配置作出反应的分散设备将被简单地忽略。

2.3 Pace Steering（速度转向）

速度转向是一种流量控制机制，调节设备连接的模式。它使FL服务器既能处理小的FL种群，也能处理大的FL种群。速度转向是基于服务器向设备建议重新连接的最佳时间窗口的简单机制。

在FL数量小的情况下，使用速度转向来确保有足够数量的设备同时连接到服务器。这对于任务进度速度和安全聚合协议的安全属性都很重要。在FL数量大的情况下，避免"惊群（Thundering Herd）"问题，并指示设备根据运行所有已安排的 FL task 所需的频率进行连接，但不能超过此频率。

起搏控制还考虑到活动设备数量的日振荡，并能够相应地调整时间窗口，从而避免高峰时段的过度活动，并且不会影响一天中其他时间的FL性能。

3 DEVICE

这一部分描述了参与 FL 的设备的软件架构。

• Example Store: 存储数据。本文建议限制 Example Store 的大小，并且如果合适的话，自动删除超过预定存储时长的数据。

• FL Runtime: 计算模型更新或对模型质量进行评估。如上图所示，控制流组成如下：

Programmatic Configuration：一个应用程序通过提供一个 FL population 名称并注册它的 example store 来配置 FL runtime。要求作业调度器（job scheduler）只在手机空闲、充电并连接到未收费的网络（如WiFi）时开始作业。Job Invocation: 在作业调度器的调用下，FL runtime 会向服务器宣告它已经准备好为给定的 FL populations 运行任务。Task Execution：如果设备被选中，FL runtime 接收 FL plan，查询应用程序的 example store，以获取 FL plan 所要求的数据，并计算模型更新。Reporting: 在FL plan 执行后，FL runtime 向服务器报告计算所得的更新，并清理临时资源。

• Multi-Tenancy: 我们的实现提供了一个 multi-tenant 架构，支持在同一个应用程序（或服务）中对多个 FL populations 进行训练。该架构允许在多个训练活动之间进行协调，避免设备被许多同时进行的 training sessions 所超载。

• Attestation: 我们希望设备能匿名参与 FL，这就排除了通过用户身份验证它们的可能性。在不验证用户身份的情况下，我们需要防止来自非真实设备的攻击影响 FL 的结果。

4 SERVER

FL服务器的设计是由需要操作多个数量级的人口规模和其他维度所驱动的。

• 服务器必须使用规模从数十个设备(开发期间)到数亿个设备的FL种群，并能够处理参与者数量从数十个设备到数万个设备的轮数。
• 此外，在每一轮中收集和通信的更新的大小可以从千字节到几十兆字节不等。

• 最后，根据设备空闲和充电的时间，进出任何特定地理区域的流量可能会在一天内发生巨大变化。

4.1 Actor Model

FL服务器是围绕Actor编程模型设计的，参与者是使用消息传递作为唯一通信机制的并发计算的通用原语。

每个参与者严格按顺序处理消息/事件流，从而得到一个简单的编程模型。运行同一类型的多个参与者的实例可以自然地扩展到大量的处理器/机器。在响应消息时，参与者可以做出本地决策，向其他参与者发送消息，或者动态地创建更多参与者。根据功能和可伸缩性需求，可以使用显式或自动配置机制，将参与者实例共同位于同一进程/机器上，或者分布在多个地理区域的数据中心上。

4.2 Architecture

• Coordinators：最高级别的参与者，它使全局同步和推进回合步调一致。服务器中有多个 Coordinators，每个 Coordinator 负责一个 FL population 的设备群。协调员接收有关每个选择器连接了多少设备的信息，并根据计划的FL任务指示他们接受多少设备参与。

• Selectors：负责接受和转发设备连接。他们定期从协调员那里收到有关每个FL群体需要多少设备的信息，他们使用这些信息来做出是否接受每个设备的本地决策。在产生主聚合器和一组聚合器之后，协调器指示选择器将其连接的设备的子集转发到聚合器，从而允许协调器有效地将设备分配给FL任务，而不管有多少设备可用。

• Master Aggregators：管理每个FL任务的轮次。为了根据设备数量和更新大小进行扩展，它们会做出动态决策，以生成一个或多个工作委派给的聚合器。

一轮的信息在被主聚合器完全聚合之前不会写入持久存储。具体来说，所有的参与者都将他们的状态保存在记忆中，并且是短暂的。临时参与者通过消除通常由分布式存储引起的延迟来提高可伸缩性。

4.3 Pipelining

虽然每一轮的 Selection、Configuration 和 Reporting 阶段是线性顺序的，但 Selection 阶段并不依赖于前一轮的任何输入。我们的系统架构支持这种流水线，而不增加额外的复杂性，因为并行性是通过选择器角色连续运行选择过程而实现的。

4.4 Failure Modes

在所有失败的情况下，系统将继续取得进展，要么完成当前回合，要么从之前承诺的回合的结果重新开始。在许多情况下，失去一个演员并不会妨碍这一轮的成功。例如，如果Aggregator或Selector崩溃，只有连接到该actor的设备会丢失。如果Master Aggregator失败，它管理的当前一轮FL任务将失败，但随后将由协调器重新启动。最后，如果协调器死亡，选择器层将检测并重生它。因为Coordinators是在共享锁定服务中注册的，所以只会发生一次。

5 ANALYTICS

在设备和服务器之间的交互中有许多因素和故障保护措施。此外，许多平台活动发生在我们既不能控制也不能访问的设备上。因此，我们依靠分析来了解该领域的实际情况，并监控设备的健康统计数据。在设备方面，我们执行的是计算密集型操作，必须避免浪费手机的电池或带宽，或降低手机的性能。为了确保这一点，我们将几个活动和健康参数记录到云中。例如:训练被激活的设备状态，运行的频率和时间，使用的内存，检测到的错误，使用的手机型号/ OS / FL运行时版本等等。我们还为训练回合中的每个状态记录一个事件，并使用这些日志生成发生在所有设备上的状态转换序列的ASCII可视化。在服务器端，我们类似地收集信息，例如每个训练回合有多少设备被接受和拒绝，回合各个阶段的时间，上传和下载数据的吞吐量，错误等等。

END

译者简介：

齐天宇，北京理工大学自动化学院智能信息与控制研究所二年级研究生。主要研究兴趣包括机器学习、联邦学习、隐私保护。知乎：一朵小脑花。

▼

往期回顾#

▼

欢迎投稿

邮箱：[e-mail]

参与更多讨论，请添加小编微信加入交流群