共计 9424 个字符，预计需要花费 24 分钟才能阅读完成。
摘要
联邦学习是一种分布式的机器学习办法，能够对大量扩散在挪动设施上的数据进行训练，而在实现时，则会遇到许多问题。因而，如何设计一个零碎这个问题就会自然而然产生。本文基于 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.
