大规模联邦学习：谷歌的系统设计

大规模联邦学习：谷歌的系统设计

摘要：联邦学习是一种分布式机器学习方法，可对大量分散数据进行模型训练。我们已在TensorFlow的基础上为移动设备领域的联合学习构建了可扩展的生产系统。在本文中，我们描述了由此产生的高级设计，概述了一些挑战及其解决方案，并探讨了未解决的问题和未来的方向。

1. Introduction

联合学习（FL）是一种分布式机器学习方法，可以对驻留在移动电话等设备上的大量分散数据进行训练。FL是“将代码带入数据，而不是数据带入代码”这一更通用方法的一个实例，它解决了隐私，所有权和数据本地性的基本问题。FL的一般描述由McMahan & Ramage(2017)其理论已在) McMahan等.中被提出

联合学习基础结构的基本设计决策是集中于异步还是同步训练算法。许多深度学习的成功工作都使用了异步训练，最近出现了同步大批量训练的趋势，甚至在数据中心也是如此。联合平均算法采取类似的方法。此外，有几种方法可以增强FL的隐私保证，包括差异性隐私和安全聚合，实际上需要在一组固定的设备上进行某种同步，因此学习算法的服务器端仅消耗来自许多用户的更新的简单集合。由于所有这些原因，我们选择专注于对同步回合的支持，同时通过我们随后描述的几种技术来减轻潜在的同步开销。因此，我们的系统适合运行大批量SGD风格的算法以及Federated Averaging，这是我们在生产环境中运行的主要算法；伪代码在附录中给出B 。

在本文中，我们报告了在手机（Android）领域中此类算法的系统设计。这项工作仍处于初期阶段，我们还没有解决所有问题，也无法对所有必需组件进行全面讨论。相反，我们试图勾勒出系统的主要组成部分，描述挑战并确定未解决的问题，希望这将有助于激发进一步的系统研究。

我们的系统允许使用手机上存储的数据训练深度神经网络，通过TensorFlow框架。这些数据将永远不会离开设备。权重与联合平均在云中结合在一起，构建了一个全局模型，该模型被推回手机进行断言（inference）。安全聚合的实现可确保在全球范围内不会检查来自电话的个人更新。该系统已被应用于大规模应用中，例如电话键盘领域。

我们的工作解决了许多实际问题：

设备可用性以复杂的方式（例如，时区依赖性）与本地数据分布相关；

设备连接不可靠，执行中断；

在可用性各不相同的设备之间协调执行锁-同步执行；

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

这些问题在通信协议，设备和服务器级别得到解决。我们已经达到了成熟的状态，足以在生产环境中部署该系统并解决数以千万计的实际设备中的应用学习问题，我们预计将有数十亿台设备使用。

1. 联邦学习协议

正在上传…重新上传取消

• • 筛选设备参与FL服务，拒绝的设备稍后再次询问
  • 服务器从永久存储器中读取模型的检查点
  • 发送模型和配置信息至被选择的设备
  • 在线的设备进行本地训练，报告更新模型
  • 服务器在更新到达时将其聚合到全局模型中
  • 服务器将全局模型检查点写入永久存储器

FL server ：是基于云分布的服务器

FL task ：是 FL population （联邦学习集群）的学习任务：如给定超参数进行训练；对本地设备数据上的训练模型进行评估

Round ：服务器会在特定时间段内，从成千上万个设备中选取一个子集（包含几百个设备）来完成特定的FL task。每一次服务器发起询问称为一轮。设备在每轮中要保持连接

FL checkpoint：本质上是TensorFlow会话的序列化状态。（保存模型并不限于在训练模型后，在训练模型之中也需要保存，因为TensorFlow训练模型时难免会出现中断的情况，我们自然希望能够将训练得到的参数保存下来，否则下次又要重新训练。）这种在训练中保存模型，称之为保存检查点。

服务器告诉选定的设备以FL计划运行的计算，该数据结构包括TensorFlow图和如何执行该计划的指令。一轮建立后，服务器接下来向每个参与者发送当前的全局模型参数和任何其他必要的状态作为FL检查点。然后，每个参与者都基于全局状态及其本地数据集执行本地计算，并将更新以FL checkpoint的形式发送回服务器。服务器将这些更新合并到全局状态，然后重复该过程。

三个主要阶段：Selection Configuration Reporting

Selection：定期地选择符合标准的设备（例如，充电并连接到未计量的网络；请参见第6节）。3）（通过打开双向流）签入服务器。该流用于跟踪活动性和协调多步通信。服务器根据某些目标（例如参与设备的最佳 数量）选择连接设备的子集（通常每轮参与数百个设 备）。如果未选择参与设备，则服务器将以指示信息进行响应，以在稍后的时间点重新连接。（在目前的实现中，选择是通过简单的储层采样完成的，但是该协议适用于更多的复杂性）

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

Reporting：服务器等待设备报告更新。接收到更新后，服务器会使用联合平均对它们进行汇总，并指示报告设备何时重新连接。如果有足够的设备及时报告，则该回合将成功完成，服务器更新全局模型，如果没有足够的设备及时报告则放弃该回合。

不及时报告或对服务器的配置没有反应的闲散设备将被忽略。该协议对此类丢失有一定的容忍度，这可以根据FL任务进行配置。

选择和报告阶段由产生灵活的时间窗口的一组参数指定。例如，在选择阶段，服务器会考虑设备的目标计数，超时和运行回合所需的目标计数的最小百分比。选择阶段一直持续到达到目标计数或发生超时为止；在后一种情况下，将根据是否已达到最低目标数开始或放弃回合

步速控制

步速控制是一种流量控制机制，可调节设备连接的方式。它使FL服务器可以按比例缩小以处理较小的FL集群，也可以按比例放大至非常大的FL集群。

步速控制基于服务器的简单机制，可向设备建议重新连接的最佳时间窗口。设备尝试以符合资格的方式尊重这一点。

对于FL集群参与者较少的情况，将使用步速控制来确保有足够数量的设备同时连接到服务器。这对于任务进度和安全聚合协议的安全属性都非常重要。服务器使用无状态概率算法，不需要额外的设备/服务器通信来建议重新连接到被拒绝设备的时间，以便随后的设备加入可以同时到达。

对于数量大的FL集群，使用步速控制来随机分配设备签入时间，避免“thundering herd”（大量进程进程响应）问题，并指示设备根据需要频繁连接以运行所有计划的FL任务，但不能执行更多任务步速转向还考虑了活动设备数量的昼夜振荡，并能够相应地调整时间窗口，避免了高峰时段的过度活动， 并且在一天中的其他时间不会损害FL的表现

1. 设备端部署

正在上传…重新上传取消

本节介绍了参与FL的设备上运行的软件体系结构。这说明了我们的Android实现，但请注意，此处所做的体系结构选择并非特定于平台。

在设备上学习的首要任务是维护本地收集的数据的存储库，以进行模型训练和评估。应用程序负责通过实现我们提供的API，将其数据作为示例存储提供给FL运行。应用程序示例商店可以是一个SQLite 数据库，它记录了显示给用户的动作建议以及这些建议是否被接受。我们建议应用程序限制示例存储的总存储空间，并在适当的预定到期时间后自动删除旧数据。我们提供实用程序来简化这些任务。设备上存储的数据可能易受恶意软件或手机物理拆卸等威胁，因此我们建议应用程序遵循设备上数据安全性的最佳做法，包括确保以我们推荐的方式对静态数据进行加密。

当FL服务器提供任务时，FL运行时将访问适当的示例，存储以计算模型更新或评估所保留数据的模型质量。图2 显示了示例存储与FL运行时之间的关系。

APP Process：实现提供的API并将数据作为示例存储在Example Store中

Example Store：是一个SQLite 轻量型关系数据库，记录了用户的动作习惯

我们建议应用程序限制examples store 中的存储量，设置适当的时间段删除旧数据

FL Runtime: 在设备端的FL执行环境中，FL运行时将访问适当的存储示例来计算模型更新或者评估所保留数据的模型的质量。

控制流包括以下步骤：

程序化配置：应用程序通过提供FL填充名称并注册其示例存储来配置FL运行时。 这样可以使用Android的JobScheduler调度FL运行时的定期作业。 在最终用户的设备上训练机器学习（ML）模型的最重要要求可能是避免对用户体验，数据使用或电池寿命造成任何负面影响。FL运行时要求作业调度程序仅在 手机处于闲置状态，正在充电，并且已连接至非计量网络，例如WiFi。 一旦启动，如果不再满足这些条件，则FL运行时将中止，释放分配的资源。

作业调用：作业调度程序在一个单独的过程中调用时，FL运行时将联系FL服务器以宣布已准备好为给定的FL人群运行任务。 服务器决定是否有任何FL任务可用于该人群，并将返回FL计划或建议的时间以便稍后检入

任务执行：如果已选择设备，则FL运行时收到FL计划，查询应用的示例存储计划请求的数据，并计算计划确定的模型更新和指标。

报告：执行FL计划后，FL运行时报告计算到服务器的更新和指标并进行清理任何临时资源。

如前所述，FL计划不专门用于培训，但也可以对评估任务进行编码，从未用于培训的保留数据计算质量指标，类似于数据中心培训中的验证步骤。

我们的设计使FL运行时可以在配置它的应用程序中运 行，也可以在另一个应用程序中托管的集中式服务中 运行。在这两者之间进行选择需要最少的代码更改。 应用程序，FL运行时和应用程序示例存储之间的通信，如图2所示，是通过Android的AIDL IPC机制实现的，该机制可在单个应用程序内以及跨应用程序使用。

多租户：我们的实现提供了多租户架构，支持在同一应用程序（或服务）中对多个FL人口进行培训。 这允许在多个培训活动之间进行协调，避免了一次同时进行的许多培训课程使设备过载。

证明：我们希望设备匿名参与FL，这排除了通过用户身份进行身份验证的可能性。 在不验证用户身份的情况下，我们需要采取防御措施，以防止影响非原始设备的FL结果。 我们通过使用Android的远程证明机制（Android文档）来做到这一点，该机制可确保只有真正的设备和应用程序才参与FL，并为我们提供了一些防范措施，以防止受到感染的设备造成数据中毒（Bagdasaryan等，2018）。 其他形式的模型操纵（例如使用不妥协的手机操纵模型的内容领域）也是我们在本文范围内未解决的潜在关注领域

1. 服务器部署

FL服务器的设计是必须在多个数量级的规模和其他规模上运行而驱动的。FL集群的大小范围从数十个设备（在开发过程中）到数亿个，并且能够处理从几十台设备到几万台设备的轮数。同样，在每轮中收集和传达的更新的大小范围可以从千字节到数十兆字节。最后， 根据设备的空闲时间和充电时间，进出任何给定地理区域的流量在一天之内可能会发生巨大变化。在满足这些要求的情况下，本节详细介绍FL服务器基础结构的设计。

Actor Model

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

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

Architecture

系统中的主要角色如图1所示。3.

（Coordinator协调者：Coordinators是top-level的actor，负责全局同步以及在锁定步骤中推进训练迭代。在Server端有多个Coordinators，每一个都负责一个FL设备集群，每一个Coordinators都注册一个地址以及一个FL集群(FL population)。Coordinator与FL Population形成一一对应的管理结构。

Selector：负责接收和转发设备的连接，同时它也会定期搜集FL 集群的设备信息，并决定是否接受设备。

协调者会生成主聚合器(Master Aggregator)和主聚合器又会向下生成子聚合器(Aggregator)。然后协调者指示Selector将其FL集群子集转接到聚合器。而主聚合器(Master Aggregator)负责管理每个FL任务的迭代周期，它可以根据FL集群和更新提交数量来生成聚合器，以实现弹性聚合计算。）

协调员：是使全局同步和同步前进的顶级角色。有多个协调器，每个协调器负责设备的FL填充。协调者在共享锁定服务中注册其地址和所管理的FL集群，因此，系统中其他参与者可以访问的每个FL集群始终只有一个协调者，尤其是对于选择器来说。协调者接收有关每个选择器连接了多少设备的信息，并根据计划的FL任务指示它们接受多少设备参与。协调者产生主聚合器来管理每个FL任务的回合。

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

在主聚合器将其完全聚合之前，不会将一轮信息写入持久性存储中。具体来说，所有演员都将自己的状态保持在记忆中，并且是短暂的。临时参与者通过消除分布式存储通常引起的延迟来提高可伸缩性。内存中聚合还消除了以每个设备更新的持久日志为目标的数 据中心内攻击的可能性，因为不存在此类日志。

Pipelining

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

Failure Modes

在所有失败情况下，系统都将继续取得进展，要么完成当前回合，要么从先前提交的回合的结果重新开始。在许多情况下，参与者的损失不会阻止这一回合的成功。例如，如果某个聚合器或选择器崩溃，则仅会丢失连接到该参与者的设备。如果主聚合器失败，则它管理的当前一轮FL任务将失败，但随后将由协调器重新启动。最后，如果协调器死亡，“选择器”层将检测到并重新生成它。因为协调器是在共享锁定服务中注册的，所以这只会发生一次。（协调器只能生成一次吗？）

1. 分析

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

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

我们还在训练回合中记录每个状态的事件，并使用这些日志来生成所有设备上发生的状态转换序列的ASCII 可视化（请参见表1 附录中）。我们在仪表板上以图表形式显示了这些序列可视化的计数，这使我们能够快速地区分不同类型的问题。

例如，序列“签入，下载计划，开始培训，结束培训， 开始上传，错误”显示为“ -v [] + *”，而较短的序列“签入，下载计划，开始培训，错误，错误” ”是“ -v [*”。第一个指示模型成功训练，但结果上传失败（网络问题），而第二个指示模型加载后立即进行训练（模型问题）。

在服务器端，我们类似地收集信息，例如每轮训练可以接受和拒绝多少设备，该轮各个阶段的时间安排， 就上传和下载数据而言的吞吐量，错误等等。

自从平台部署以来，我们反复依靠analytics层来发现问题并验证问题是否得到解决。我们发现的一些事件与设备健康有关，例如发现培训本应在不该进行的情况下发生，而其他事件则起作用，例如发现培训参与者的中途退出率远高于预期。

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

1. 安全聚合

安全聚合：是一种安全多方计算协议。

目标：保护免受“诚实且好奇”的攻击者获取子聚合器中的实例

效果：就是使服务器无法检查单个设备的更新，仅在收到足够数量的更新以后才显示总和。

安全聚合（Secure Aggregation），是一种安全的多方计算协议，该协议使用加密使服务器无法检查单个设备的更新，而仅在收到足够数量的更新后才显示总和。我们可以将Secure Aggregation部署为FL服务的隐私增强功能，通过确保单个设备的更新（即使在内存中）也保持加密状态，从而防止数据中心内的其他威胁。

正式而言，安全聚合保护免受可能访问聚合器实例内存的“诚实但好奇”的攻击者的侵害。重要的是，模型评估，SGD或联合平均所需的唯一汇总是总和。

安全聚合是一种四轮交互式协议，可以在给定的报告阶段选择性地启用FL轮。

在每个协议回合中，服务器从FL回合中的所有设备收集消息，然后使用设备消息集计算独立的响应以返回到每个设备。该协议被设计为在协议完成之前对大量设备掉落具有鲁棒性。前两轮构成“准备”阶段，在该阶段中，将建立共享机密，在此期间，退出的设备将不会把他的更新包含在最终聚合中。第三轮构成一个Commit阶段，在此阶段中，设备将上传经过密码屏蔽的模型更新，而服务器则累计屏蔽的更新。完成此回合的所有设备都将在协议的最终汇总更新中包含其模型更新，否则整个汇总将失败。

该协议的最后一轮构成了终结阶段，在此阶段中，设备揭示了足够的加密机密，以允许服务器揭露聚合模型更新。并非所有已提交的设备都需要完成此轮；只要开始进行协议的足够数量的设备在完成阶段中幸存下来，整个协议就会成功。

安全聚合的成本随着用户数量的增加而成倍增加，最显着的是服务器的计算成本。

安全聚合的最大限制为数百个用户。为了不限制可能参加每一轮联邦计算的用户数量，只在子聚合器上使用安全聚合，主聚合器不使用安全聚合。

以将来自该Aggregator设备的输入汇总为中间总数；

FL任务定义了一个参数k，以便将所有更新安全地聚集在大小至少为k的组上。然后，主汇总器将中间汇总器的结果进一步汇总到该轮的最终汇总中。

1. 工具和工作流程

正在上传…重新上传取消

与集中收集数据的标准模型工程师工作流相比，设备上的培训提出了许多新的挑战。首先，个别培训示例无法直接检查，因此需要工具才能在测试和模拟中使用代理数据.其次，模型不能交互运行，而必须编译为FL计划，才能通过FL服务器进行部署。最后，由于FL计划是在真实设备上运行的，因此模型资源消耗和运行时兼容性必须由基础架构自动验证。

模型工程师工作的主要开发人员表面FL系统提供了一组Python界面和工具，用于通过FL服务器定义，测试和部署基于TensorFlow的FL任务并将其部署到移动设备中。

建模与仿真

模型工程师首先定义要在Python中的给定FL集群上运行FL任务。我们的库使模型工程师可以使用工程师提供的TensorFlow函数声明联合学习和评估任务。这些功能的作用是将输入张量映射到输出度量（例如损耗或准确性）。在开发期间，模型工程师可以将样本测试数据或其他代理数据用作输入。部署后，输入将通过FL运行时从设备上的示例存储中提供。

建模基础结构的作用是使模型工程师能够使用我们的库来构建和测试相应的FL任务，从而专注于他们的模型。FL任务根据工程师提供的测试数据和期望进行了验证，其本质类似于单元测试。最终需要进行FL任务测试，以便按以下第2节所述部署模型。7.3.

任务的配置也是用Python编写的，包括运行时参数，例如在一轮中的最佳设备数量以及模型超参数（如学习率）。FL任务可以按组定义：例如，根据学习率评估网格搜索。当在FL人群中部署多个FL任务时，FL服务将使用动态策略在其中进行选择，该策略允许在训练和评估单个模型之间进行交替，或者在模型之间进行A/B比较。

最初的超参数探索有时是在使用代理数据的仿真中完成的。代理数据的形状类似于设备上的数据，但来自不同的分布。例如，来自Wikipedia的文本可能被视为在移动键盘上键入的文本的代理数据。我们的建模工具允许将FL任务部署到模拟的FL服务器上，并模拟一组大型云作业，以模拟大型代理数据集上的设备。仿真执行与我们在设备上运行的代码相同的代码，并使用仿真与服务器通信FL人口。仿真可以扩展到大量设备，有时用于在FL现场改进代理数据之前对代理数据进行模型预训练。

迭代计划

每个FL任务都与一个FL计划相关联。计划是由模型工程师提供的模型和配置的组合自动生成的。通常，在 数据中心培训中， FL 计划中编码的信息将由编排TensorFlow图的Python程序表示。但是，我们不直接在服务器或设备上执行Python。FL计划的目的是描述独立于Python的所需编排。

FL计划由两部分组成：一部分用于设备，一部分用于服务器。FL计划的设备部分包含以 下内容：TensorFlow图本身，示例存储中训练数据的选择标准，有关如何批处理数据以及在设备上运行多少个时期的说明，标签中节点的标签表示某些计算（例如加载和节省权重等）的图形。服务器部分包含聚合逻辑，该逻辑以类似方式进行编码。我们的库自动将提供的模型计算的一部分从服务器上运行的部分（聚合）中分离出来，该部分的计算在设备上运行。

版本控制 测试和部署

在联邦系统中工作的模型工程师能够高效，安全地工作，每天启动或结束多个实验。但是，由于每个FL任务可能都占用大量RAM或与车队上运行的TensorFlow版本不兼容，因此工程师依靠FL系统的版本控制，测试和部署基础结构来进行自动安全检查。

除非满足某些条件，否则服务器不会接受已转换为FL计划的FL任务进行部署。首先，它必须是根据可审核的，经过同行审查的代码构建的。其次，它必须为通过仿真的每个FL任务捆绑测试谓词。第三，测试期间消耗的资源必须在目标人群预期资源的安全范围内和最后，FL任务测试必须传递 FL 任务声称支持的TensorFlow运行时的每个版本，这已通过在Android模拟器中测试FL任务的计划进行了验证。

版本控制是设备上机器学习的特定挑战。与通常可以根据需要重建TensorFlow运行时和图形的数据中心培训相反，设备运行的TensorFlow运行时版本可能比当今建模者生成的FL计划要早几个月。例如，旧的运行时可能缺少特定的TensorFlow运算符，或者运算符的签名可能以不兼容的方式进行了更改。FL基础结构通过为每个任务生成版本化的FL计划来解决此问题。每个版本的FL计划都是通过转换其计算图从默认（未版本控制） 的FL 计划派生而来，以实现与已部署的TensorFlow版本的兼容性。版本化和未版本化的计划必须通过相同的发布测试，因此在语义上是等效的。我们遇到了大约三个不兼容的更改，这些更改可以每三个月通过图形转换进行修复，而较小的数字则需要复杂的解决方法才能解决。

一旦接受FL任务进行部署，就可以为设备检入提供适当的（版本化）计划。FL回合结束后，该回合的综合模型参数和度量将写入模型工程师选择的服务器存储位置。

物化模型指标带有附加数据，包括元数据，如源FL任务的名称，FL任务内的FL轮号以及其他基本操作数据。指标本身是设备中通过近似顺序统计信息和类似均值之类的报告的摘要。FL系统为模型工程师提供了分析工具，可将这些指标加载到标准Python数值数据科学软件包中以进行可视化和探索。

1. 应用领域

联合学习最适用于以下情况：设备上的数据比服务器上存在的数据更相关（例如，设备首先生成数据），对隐私敏感，或者以其他方式不希望或无法传输到服务器。联合学习的当前应用是有监督的学习任务，通常使用从用户活动（例如单击或键入的单词）推断出的标签。

设备上物品的排名移动应用中机器学习的常见用途是从设备上的清单中选择物品并对其进行排名。例如， 应用可能会暴露用于信息检索或应用内的搜索机制导航，例如 在 Google Pixel 设备上搜索设置通过在设备上对这些结果进行排名， 可以消除对服务器的昂贵调用（例如，时延，带宽或功耗维度），并且来自搜索查询和用户选择的任何潜在私人信息都将保留在设备上。每个与排名功能交互的用户都可以成为标记的数据点，因为可以在完整排 名列表的上下文中观察用户与首选项目的交互。

设备上键盘的内容建议设备上键盘的实现可以通过建 议相关内容（例如，与输入文本相关的搜索查询）为用户增加价值。联合学习可用于训练ML模型以触发建 议功能，以及对可在当前上下文中建议的项目进行排名。Google的Gboard移动键盘团队已使用我们的FL系统.

下一词预测Gboard还使用我们的FL平台来训练递归神经网络（RNN）以进行下一词预测. 这个模型，大约有

140万个参数在经过5天的训练后（共处理大约2–3分钟），经过3000次FL轮收敛，之后处理了1.5e6位用户的6e8句。3 与基线n-gram模型相比，它可以将top-1召回率从13.0％提高到16.4％，并且与服务器训练的RNN的性能相匹配，而RNN需要1.2e8 SGD步骤。在实时A / B实验中，FL模型优于n-gram模型和服务器训练的RNN 模型。

1. 运行情况

在本节中，我们简要概述了已部署的FL系统的一些关键操作指标，这些指标运行了超过一年的生产工作负载；附录A 提供其他详细信息。这些数字仅是示例，因为我们尚未将FL应用到足够多样化的应用程序集合 中以提供完整的特性。此外，所有数据都是在生产系 统运行过程中收集的，而不是出于控制目的而在明确 控制的条件下收集的。这里的许多性能指标取决于设 备和网络速度（可能因地区而异）。FL计划，全局模 型和更新大小（因应用程序而异）；每轮和每个样本的计算复杂度。

我们设计了FL系统，以随FL人口的数量和规模弹性扩 展，可能达到数十亿。当前，该系统正在处理每天活 跃设备大约1000万个FL的累积数量，跨越几种不同的应用程序。

如前所述，在任何时间点，由于设备的合格性和速度控制，只有一部分设备连接到服务器。鉴于此，实际上，我们观察到多达1万台设备同时参与。值得注意 的是，参与设备的数量取决于一天中的（本地）时间（请参见图7.5).设备更有可能在晚上闲置并充电， 因此更有可能参与其中。我们已经观察到以美国为中心的人群在24小时内参与设备的数量少与数量高4的差基于以前的工作McMahan等。(2017）和我们针对生产FL群体进行的实验，对于大多数模型来说，每轮FL接收来自数百个设备的更新的大多数模型就足够了（也就是说，我们看到，通过训练更多数量的设备，收敛速度会逐渐降低） 。我们还观察到，平均而言，由于计算错误，网络故障或合格性变化而丢失的设备部分 在6％至10％之间变化。因此，为了补偿设备丢失并允许丢弃闲散者，服务器通常选择目标设备数量的130％ 进行初始参与。可以基于设备报告时间的经验分布和要忽略的散乱目标数量来调整此参数。