【技术博客】面向大规模的联邦学习：系统设计

摘要

联邦学习是一种分布式的机器学习方法，可以对大量分散在移动设备上的数据进行训练，而在实现时，则会遇到许多问题。因此，如何设计一个系统这个问题就会自然而然产生。本文基于 Tensorflow ，介绍基于移动设备的联邦学习的系统设计，概述一些挑战和解决方法，并探讨一些未解决的问题和未来的方向。

1 简介

联邦学习基础设施建设的基本设计真正的重点还是在于异步与同步训练算法。

虽然之前在深度学习中使用了异步算法，达到了非常不错的效果—— DistBelief ，但是现在有着一个持续的面向同步、大批次的训练趋势。 Federated Averaging 也随之产生。同时 Differential privacy 、 Secure Aggregation 本质上也需要一些的同步概念。

因为这些原因，所以将会专注于对同步回合的支持，同时通过随后描述的几种技术来减轻潜在的同步开销。 因此，该系统被设计适合运行大批量 SGD 风格的算法以及 Federated Averaging 。

主要解决的问题：

• 设备在以复杂的方式（例如，时区依赖性）并本地数据分布相关的可用性
• 设备连接不可靠，执行中断
• 在可用性各不相同且设备存储和计算资源有限的情况下跨设备执行锁步执行的业务流程。

2 协议

2.1 基本概念

协议中的主要参与者为 devices（当前为安卓手机）和 FL server （基于云的分布式服务）。

FL population: 拥有全局唯一名称，标识正在解决的学习问题或应用程序。

FL task: 针对 FL population 的特定计算，例如要使用给定超参数执行的训练，或对本地设备数据上的训练模型进行评估。

devices 会向 server 发送它已经准备好为给定的FL population 运行 FL task 的信息。

当几万个 devices 在一定时间内对服务器声明了它的可用性，服务器会通常会选择其中的几百个，让它们执行特定的 FL task （为什么是几百个？之后会讨论）该称此为设备和服务器之间的一个回合。 在整个回合期间，设备会保持与服务器的连接。

FL plan: 包含 TensorFlow graph 和 如何执行的指令

FL server 会告诉被选定的设备 FL plan ，当回合被建立起之后，FL server 会向每个参与者发送当前的全局模型参数和任何其他必要的FL checkpoint（TensorFlow会话的序列化状态）。然后，每个参与者都基于全局状态及其本地数据集执行本地计算，并将更新以FL  checkpoint 的形式发送回服务器。 服务器将这些更新合并到其全局状态，然后重复该过程。

2.2 过程

通信协议使设备能够在回合之间推进 FL population 的全局单例模型，其中每个回合均由 figure 1 所示的三个阶段组成

选择  符合标准（正在充电并且已经连接上不计费的网络时）的 device 会周期性地，通过打开双向流来声明服务器。 该流用于跟踪活动性和协调多步通信。 服务器根据某些目标（例如参与设备的最佳数量）选择连接设备的子集（通常每轮参与数百个设备）。 如果未选择参与设备，则服务器将以指示信息进行响应，以在稍后的时间点重新连接。

配置  基于所选设备选择的聚合机制（Secure Aggregation）配置 server , server 将 FL plan 和带有全局模型的 FL checkpoint 发送到每个设备。

报告  server 等待参与设备报告更新。 收到更新后，服务器将使用 Federated Averaging 对它们进行汇总，并指示报告设备何时重新连接（另请参见第2.3节）。 如果有足够的设备及时报告，则该回合将成功完成，服务器将更新其全局模型，否则将放弃该回合。

该协议对没有及时报告和没有反应及时有一定的容忍度。

2.3 速度控制

速度控制是一种流量控制机制，可调节设备连接方式。它能使 FL server 缩小规模以处理较小的 FL populations 以及 扩大到非常庞大规模的 FL populations 。

速度控是制基于 server 的简单机制，可向设备建议重新连接的最佳时间窗口

在 FL populations 较小的情况下，速度控制能被用作确保足够数量的设备能够主动的连接 server 。对任务处理速度和 Secure Aggregation 协议中的安全部分较为重要。服务器使用无状态概率算法， 不需外额外的设备/服务器交流去重新连接到拒绝设备

在 FL populations 较大的情况下，速度控制被用来随机化计划设备的登陆时间，避免 thundering herd 效应。并指示设备根据需要连接，以运行所有计划的FL task。

速度限制还考虑了昼夜振荡活跃设备的数量，并且能够调整相应的时间窗口，避免在高峰时段过度运行，并且不在在其他时段影响FL性能。

3 设备

基于设备的学习主要是还是在于设备要维持一个本地收集数据的仓库，用作模型训练和评估。应用会通过提供给他们的 API 将它们的数据存储为一个 example store 提供给 FL runtime 。应用程序应该限制这个的总存储空间，并自动在数据时间到期之后删除旧数据。资料储存在设备上可能受到恶意软件攻击或手机的物理损坏，所以应用程序遵循数据的安全性守则，包括静态加密数据平台。

当 FL server 发布任务时，FL runtime 访问对应的 example store 计算模型更新或评估所保留数据的模型质量

总的流程包括以下步骤：

程序配置  一个FL runtime 是通过提供 FL population 名字和注册它的 example store 生成的。训练时最重要的要求是用户设备上的（ML）模型要避免任何对用户体验的负面影响，包括对数据使用或电池寿命的影响。FL runtime 请求作业调度程序仅调用手机空闲时间段，充电并连接到手机时的工作不限流量的网络。一旦启动手机， 这些条件不再满足时，FL runtime 将中止，释放分配的资源。

任务调用 作业调度程序在一个单独的过程中调用后，FL runtimes 访问 FL server 以宣布已准备好为给定的 FL population 运行任务。 服务器决定是否有任何 FL task 空余于分配，并且将返回 FL plan 或建议的时间以稍后再试。

报告 执行 FL plan 后，FL runtime 将计算的更新和指标报告给服务器，并清除所有临时资源。

多租户我们的实现提供了多租户架构，支持在同一应用程序（或服务）中对多个 FL population 进行训练。 这样可以在多个训练活动之间进行协调，从而避免了一次同时进行的多个训练任务使设备过载。

认证 设备应该是匿名参与 FL。 在不验证用户身份的情况下，需要防御攻击，以免影响的FL结果。 可以通过使用 Android 的远程证明机制（ Android Documentation ）来做到这一点，该机制有助于确保只有真正的设备和应用程序才能参与 FL ，并提供了一些防范措施，以防止受到感染的设备造成数据中毒。其他形式的模型操纵-例如使用不妥协的手机操纵模型的内容农场，也是我们在本文范围内未解决的潜在关注领域。

4.服务器

FL server 的设计是由必须能在在多个数量级的人口规模和其他规模上运行而驱动的。 该服务器必须能够正确处理 FL population，FL population 的大小范围从数十个设备（在开发过程中）到数亿个，并且能够处理回合，参与者人数从数万个设备到数万个不等。 同样，在每个回合中收集和传达的更新的大小范围可以从千字节到数十兆字节。 最后，根据设备的空闲时间和充电时间，进出任何给定地理区域的流量在一天中可能会发生巨大变化。

4.1 Actor 模型

FL server 是围绕 Actor 编程模型设计的。 Actor 是并发计算的通用原语，它使用消息传递作为唯一的通信机制。每个参与者都严格顺序地处理消息/事件流，从而形成一个简单的编程模型。 运行相同类型的 actor 的多个实例可以自然地扩展到大量处理器/机器。 参与者可以做出本地决策，将消息发送给其他参与者或动态创建更多参与者。 根据功能和可伸缩性要求，可以使用显式或自动配置机制将参与者实例共处一地位于同一进程/机器上，或分布在多个地理区域中的数据中心中。 仅在给定的 FL task 持续时间内创建并放置参与者的细粒度短暂实例，即可进行动态资源管理和负载平衡决策。

4.2 架构

Coordinators 是使全局同步和同步进行回合的顶级参与者。有多个 Coordinators ，每个 Coordinators 负责管理一个设备的 FL population 。 Coordinators 在共享锁定服务中注册其地址和它所管理的 FL population ，因此，系统中其他参与者（尤其是 Selector ）可以访问到的每个 FL population 始终只有一个所有者。 Coordinators 接收有关每个 Selector 连接了多少设备的信息，并根据计划的 FL task 指示它们接受多少设备参与。 Coordinators 产生Master Aggregator 来管理每个 FL task 的回合。

Selector 负责接受和转发设备连接。 它们定期从 Coordinators 接收有关每个FL population 需要多少个设备的信息，它们来决定是否接受每个设备。 在生成 Master Aggregator 和一组 Aggregator 之后， Coordinators 指示 Selector 将其连接的设备的子集转发给 Aggregator ，从而无论有多少可用设备，Coordinators 都能有效地将FL task 分配给设备。 该方法还允许 Selector 全局分布（靠近设备），并限制与远程 Coordinators 的通信。

Master Aggregator 管理每个 FL task 的轮次。 为了根据设备的数量进行缩放并更新大小，它们会做出动态决策，以产生一个或多个委派工作的 Aggregators。

在 Master Aggregator 完全聚合之前，不会将一轮信息写入持久性存储。 所有参与者都将自己的状态保存在内存中。 临时参与者通过消除通常由分布式存储引起的延迟来提高可伸缩性。内存中聚合还消除了针对数据中心内针对每个设备更新的持久日志的攻击的可能性，因为不存在此类日志。

4.3 Pipelining

一轮中的 Selection 、 Configuration 和 Reporting 都是顺序的，而选择阶段则不依赖于前一轮的任何输入。 通过与下一轮协议的配置/报告阶段并行运行下一轮协议的选择阶段，可以实现延迟优化。 系统架构可在不增加额外复杂性的情况下实现此类流水线操作，因为仅通过 Selector actor 连续运行选择过程即可实现并行性。

4.4 Failure Modes

在有失败情况下，系统都将继续运行，要么完成当前回合，要么从先前提交的回合的结果重新开始。 在许多情况下，一个 Actor 的失效不会阻止这一回合的成功。 例如，如果某个 Aggregator 或 Selector 崩溃，则仅会丢失连接到该参与者的设备。 如果 Master Aggregator 失败，则它管理的当前一轮 FL task 将失败，但随后将由 Coordinators 重新启动。 最后，如果 Coordinators 死亡，Selector 层将检测到并重新生成它。 因为 Coordinators 是在共享锁定服务中注册的，所以这只会发生一次。

5 Analytics

设备和服务器之间的交互有很多因素和故障保护措施。此外，许多平台活动都发生在既无法控制也无法访问的设备上。

因此，需要依靠分析来了解现场实际发生的情况，并监视设备的运行状况统计信息。在设备方面，我们执行计算密集型操作，并且必须避免浪费手机的电池或带宽，或降低手机的性能。为了确保这一点，我们将几个活动和运行状况参数记录到云中。例如：激活训练的设备状态，运行的频率和时间，使用的内存量，检测到的错误，使用的手机型号/ OS / FL运行时版本，等等。这些日志条目不包含任何个人身份信息（PII）。它们被汇总并显示在仪表板中以进行分析，然后馈入自动时间序列监视器，从而触发有关重大偏差的警报。

同时还在训练回合中记录每个状态的事件，并使用这些日志来生成所有设备之间发生的状态转换序列的ASCII可视化效果。我们在仪表板上以图表形式显示了这些序列可视化的计数，这使我们能够快速区分不同类型的问题。
例如，签入，下载计划，开始训练，结束训练，开始上传，错误的顺序显示为-V[]+*，而较短的序列签入，下载计划，开始训练，错误，错误显示为-V [*。第一个指示模型成功训练，但是结果上传失败（网络问题），而第二个指示模型加载后立即进行训练（模型问题）。
在服务器端，也可以类似地收集信息，例如每轮培训可以接受和拒绝多少台设备，该回合各个阶段的时间安排，就上传和下载数据而言的吞吐量，错误等等。

要让联邦训练不会影响用户体验，因此设备和服务器功能故障都不会立即产生负面影响。但是，如果无法正常运行，则可能会导致导致设备效率降低的次要后果。对用户而言，设备实用程序是关键任务，降级难于查明且易于错误诊断。使用准确的分析来防止联邦训练对用户的设备效用产生负面影响，这构成了我们工程和降低风险成本的重要部分。

6 Secure Aggregation

安全聚合（Secure Aggregation）
安全的多方计算协议，该协议使用加密使服务器无法检查单个设备的更新，而仅在收到足够数量的更新后才显示总和。 我们可以将 Secure Aggregation 部署为 FL service 的隐私增强功能，通过确保单个设备的更新（即使在内存中）也保持加密状态，从而防止数据中心内的其他威胁。 正式而言，Secure Aggregation 保护免受可能访问 Aggregator 实例内存的的攻击者的攻击。 而且重要的是，模型评估， SGD 或 Federated averaging 所需的唯一汇总便是总和。

Secure Aggregation 是一个四轮交互协议，可以在给定 FL round 的报告阶段中启用。在每个协议回合中，服务器从 FL round 中的所有设备收集消息，然后使用设备消息集计算独立的响应以返回到每个设备。该协议旨在对在协议完成之前掉线的大量设备保持鲁棒性。前两轮构成“准备”阶段，在该阶段中，将建立共享机密，在此期间，退出的设备将不会在最终聚合中包含其更新。第三轮构成一个“提交”阶段，在此阶段中，设备将上传经过密码屏蔽的模型更新，而服务器将累积这些屏蔽更新的总和。完成此回合的所有设备都将其模型更新包含在协议的最终聚合更新中，否则整个聚合将失败。协议的最后一轮构成了终结阶段，在此阶段中，设备揭示了足够的加密机密，以允许服务器揭露聚合模型更新。并非所有已提交的设备都需要完成此轮；只要开始进行协议的足够数量的设备在完成阶段中幸存下来，整个协议便会成功。

Secure Aggregation 的几项成本随用户数量成倍增加，最显着的是服务器的计算成本。 实际上，这将 Secure Aggregation 的最大大小限制为数百个用户。 为了不限制可能参与每一轮联邦计算的用户数量，在每个Aggregation 参与者上运行一个 Secure Aggregation （请参见图3），以将来自该聚合器设备的输入聚合为一个中间值； FL task 定义了一个参数 k ，以便将所有更新安全地聚集在大小至少为 k 的组上。 然后，Master Aggregator 将中间 Aggregator 的结果进一步汇总为该轮的最终汇总，而无需进行 sercure Aggregation。

7 Tools And Workflow

与集中收集数据的标准模型工程师工作流相比，设备上的训练提出了许多新颖的挑战。 首先，个别训练示例不可直接观察，需要工具才能在测试和模拟中使用代理数据（第7.1节）。 其次，模型不能交互运行，而必须编译为FL plan 以通过FL server 进行部署（第7.2节）。 最后，由于 FL plan 在实际设备上运行，因此基础架构必须自动验证模型资源消耗和运行时兼容性（第7.3节）。 使用 FL 系统的模型工程师的主要开发人员使用的是一组 Python 界面和工具，用于通过FL server 定义，测试和部署基于 TensorFlow 的 FL task 并将其部署到移动设备中。 FL 的模型工程师的工作流程 figure 4 所示，并在下面进行描述。

7.1 Modeling and Simulation

模型工程师开始可以定义 FL task，这样就可以使用python运行给定的FL population。模型工程师可以使用提供给工程师的 TensorFlow 函数声明联邦学习和评估任务。这些函数主要用来匹配 input tensor 到 output 的指标例如 loss 和 accuracy 。
在开发期间，模型工程师可以使用样本测试数据或其他代理数据作为输入。 部署后，输入将通过 FL runtime 从设备上的示例存储中提供。

模型基础设施的作用是使模型工程师能够使用的库来构建和测试相应的 FL task ，从而专注于其模型而不是语言。 FL task 根据工程师提供的测试数据和期望进行了验证，其本质类似于单元测试。最终需要 FL task 测试才能部署以下第7.3节所述的模型。
任务的配置也使用 Python 编写，包括运行时参数，例如在一轮中的最佳设备数量以及模型超参数（如学习率）。 FL task 可以按组定义：例如，根据学习率评估网格搜索。当在 FL population 中部署多个 FL task 时，FL service 将使用动态策略在其中进行选择，该策略允许在训练和评估单个模型之间进行交替，或者在模型之间进行A / B比较。
最初的超参数探索有时是在使用代理数据的模拟中完成的。代理数据的形状与设备上的数据相似，但来自不同的分布——例如，来自 Wikipedia 的文本可以视为在移动键盘上键入的文本的代理数据。我们的建模工具允许将FL任务部署到模拟的 FL server 上，并模拟一组大型云作业，以模拟大型代理数据集上的设备。模拟执行与我们在设备上运行的代码相同的代码，并使用模拟与服务器通信，模拟可以扩展到大量设备，有时用于在FL现场改进代理数据之前对代理数据进行模型预训练。

7.2 Plan Generation

每个 FL task 都与一个 FL plan 相关联。plan 是由模型工程师提供的模型和配置的组合自动生成的。通常，在数据中心训练中，FL plan 中编码的信息将由编排 TensorFlow graph 的 Python 程序表示。但是，我们不直接在服务器或设备上执行Python。 FL plan 的目的是描述独立于Python的所需编排。
FL plan 由两部分组成：一部分用于设备，另一部分用于服务器。 FL plan 的设备部分包括：TensorFlow graph 本身，示例存储中训练数据的选择标准，有关如何批处理数据以及在上运行多少个时期的说明。设备，图中节点的标签代表某些计算，例如加载和保存权重等。服务器部分包含聚集逻辑，该聚集逻辑以类似方式进行编码。我们的库自动将提供的模型计算的一部分从服务器上运行的部分（聚合）中分离出来，该部分的计算在设备上运行。

7.3 Versioning, Testing, Deployment

在联邦系统中工作的模型工程师能够高效，安全地工作，每天启动或结束多个实验。但是，由于每个 FL task 都可能占用 RAM 或与运行的TensorFlow版本不兼容，因此工程师依靠 FL 系统的版本控制，测试和部署基础结构来进行自动安全检查。除非满足某些条件，否则服务器不会接受已转换为 FL task 的FL plan 进行部署。首先，它必须是根据可审核的，经过同行审查的代码构建的。其次，它必须为通过模拟的每个FL task 捆绑测试数据。第三，测试期间消耗的资源必须在目标人群预期资源的安全范围内。最后，FL任务测试必须传递 FL task 支持的 TensorFlow 运行时的每个版本，这通过在Android模拟器中测试FL任务的计划进行了验证。
版本控制是设备上机器学习的特定挑战。与通常可以根据需要重建 TensorFlow 运行时和图形的数据中心训练相反，设备运行的 TensorFlow 运行时版本可能比当今建模者生成的 FL plan 要早几个月。例如，旧的运行时可能缺少特定的 TensorFlow 运算符，或者运算符的签名可能已以不兼容的方式更改。 FL 基础结构通过为每个任务生成版本化的FL plan 来解决此问题。每个版本化的FL plan 都通过转换其计算图从默认的（未版本控制）FL plan 派生而来，以实现与已部署的 TensorFlow 版本的兼容性。版本化和未版本化的计划必须通过相同的发布测试，因此在语义上是等效的。我们遇到了大约三个不兼容的更改，这些更改可以每三个月通过图形转换进行修复，而较小的数字则需要复杂的解决方法才能解决。

7.4 Metrics

一旦接受了 FL task 以进行部署，就可以为设备检入提供适当的（版本化）计划。 FL round 结束后，该回合的汇总模型参数和度量将写入模型工程师选择的服务器存储位置。 物化模型指标带有附加数据，包括元数据，例如源 FL task 的名称，FL task 内的 FL round 以及其他基本操作数据。 指标本身是通过近似的订单统计信息和诸如均值之类的时刻在一轮内设备报告的摘要。 FL 系统为模型工程师提供了分析工具，可将这些指标加载到标准 Python  数值数据科学软件包中以进行可视化和探索。

8 Applications

• On-device item ranking
• Content suggestions for on-device keyboards
• Next word prediction

9 Operational Profile

简要概述已部署的 FL 系统的一些关键操作指标，这些指标运行了一年以上的生产工作负载。这些数字仅是示例，因为尚未将 FL 应用于多种足够多的应用程序集可提供完整的特性描述。此外，所有数据都是在运行生产系统的过程中收集的，而不是出于控制目的而在明确控制的条件下收集的。这里的许多性能指标取决于设备和网络速度（可能因地区而异）。 全局模型和更新大小（因应用程序而异）；每轮样本数和每个样本的计算复杂度。
FL 系统，以随 FL population 的数量和规模弹性扩展，可能达到数十亿。当前，该系统正在处理每天活跃设备大约1000万个的 FL 累积数量，跨越几种不同的应用程序。
如前所述，在任何时间点，由于设备的合格性和节奏控制，只有一部分设备连接到服务器。鉴于此，实际上，我们观察到多达1万台设备同时参与。值得注意的是，参与设备的数量取决于一天中的（本地）时间（ figure 5 ）。设备更有可能在晚上闲置并充电，因此更有可能参与其中。对于以美国为中心的人群，我们观察到在24小时内参与设备的数量少与高4倍的差异。

平均而言，由于计算错误，网络故障或合格性变化而导致设备丢失的部分在6％至10％之间变化。 因此，为了补偿设备丢失并允许丢弃闲散者，服务器通常选择目标设备数量的130％进行初始参与。 可以基于设备报告时间的经验分布和要忽略的散乱目标数量来调整此参数。

10 Future Work

• Bias
• Convergence Time
• Bandwidth
• Federated Computation

参考文献

[1] Bonawitz K, Eichner H, Grieskamp W, et al. Towards federated learning at scale: System design[J]. arXiv preprint arXiv:1902.01046, 2019.