下载链接

0x00 摘要

在TensorFlow的基础上为移动设备领域的联邦学习构建了一套可扩展的生态系统。

KEY WORDS: synchronous,Android

0x01 介绍

联邦学习是一种分布式机器学习，其目的是去中心化、合理利用用户手机等设备上的数据。联邦学习系统的设计首选要面临的选择是参数的同步更新或异步更新，现在的方向是选用同步更新进行大批量的训练。联邦学习另外一个需要考虑的是隐私保护，常用的是差分隐私保护、安全聚合。

本文选择的是同步更新，基于安卓手机领域的。目前仍处于初级阶段，还存在需要问题需要解决。

本文解决的问题：

  • 与本地数据相关的设备可用性（例如，关于时间）
  • 不稳定的设备连接&执行被中断
  • 在可用性不同的设备之间进行锁步执行的协调
  • 设备有限的存储和计算资源

我们已到了可以将系统部署到生产的环节，能用于千万设备的场景，未来能到十亿级别的设备量。

0x02 协议

1 基础概念

协议的参与者是设备（本文指安卓手机）与FL服务器。

设备：向服务器声明可以执行FL任务。

FL集群：拥有全局唯一标识，用于标志特定的学习任务或问题（如，图像识别、文本翻译等）。

FL任务：由FL集群下发，用于训练超参或用本地数据评估模型。

FL计划：一种数据结构，存储TensorFlow执行图和执行指令。

大致过程如下：

  • 在一个时间窗口内，可能有上万的设备可用，服务器会从中选取百十个设备执行FL任务，这是设备与服务器的结合点。（在整轮过程中，设备会和服务器一直保持连接）
  • 服务器选择要参加任务的设备，连接一旦建立好，就就下发全局模型参数和其他必要状态作为FL检测点（通常为TF的模型序列化）
  • 设备用全局模型和本地数据进行训练，将更新以FL检测点的形式发送至服务器。
  • 服务器进行全局模型的更新。

2 协议流程

协议过程如下：

安全聚合部分在第六节详述。NOTE：所有的网络传输都是加密的。

选择

满足条件的设备会与服务器创建双向数据流，用于活性检测和协调多步通信。

服务器会根据条件选择部分设备参与训练。

没选中的设备，下一轮重新发送连接。

配置

根据聚合机进行服务器的配置。

服务器将FL计划和FL检测点发送至设备。

报告

当服务器收到更新时会用FedAvg进行聚合，并告知设备何时重连。

在一轮中没有收到足够的更新，该轮会被抛弃。

在图一中，掉队的设备不会报告也不会被配置，只是服务器忽略。此协议对这种丢失存在一定的容忍度，可以根据FL任务配置。(后面用到的方法是在Selection阶段选取130%的设备参加)

选择和报告阶段受一些参数确定，这些参数能产生灵活地时间窗口。这些参数可以是计划参与设备数目、超时阈值、最小数目等。比如选择阶段会持续到设备数目足够或发生超时错误，若为后者则会根据是否到达最小数目决定此轮是否开始或抛弃。

3 步速控制

步速控制用于控制设备的连接。它能使FL服务器缩小范围处理小规模FL集群，也能扩大范围处理大规模FL集群。

步速控制向设备建议重连的最佳时间窗口。设备应该接受此标准。

小规模

用于确保同时连接服务器的设备数足够多。这对任务执行和安全聚合都十分重要。服务器会给被拒设备建议重连的时间，避免随后的登记同时到达。

大规模

用于随机化设备登记的时间，避免“惊群效应”，指示设备连接频率足够完成FL任务，不能连接过多。

其他

会考虑活跃设备随一天时间的变化，相关地调整时间窗口，避免在使用高峰期是执行训练任务，也不会降低其他时间段的FL性能表现。

0x03 设备

本节详述运行在设备端的软件架构，此文是Android手机，但架构是通用的。

设备的主要任务是维持用于模型训练或评估的本地数据仓库。

App的主要任务是利用我们提供的API端口在FL执行过程中为其提供可用数据。

我们建议限制数据存储大小并自动清理过时数据、另外数据在本地要加密存储。

控制流程如下：

程序配置

App通过提供 FL集群名称和样例存储来初始化FL执行态。==》可以利用Android的JobScheduler 来完成。

FL执行态只允许在设备满足条件时唤醒作业，一旦不满足条件立即中断执行。

作业调度

Job scheduler 在调度作业之前（独立的进程），FL执行态告诉服务器现在可以执行FL task。

服务器决定下发task或下次报道的时间。

任务执行

如果设备被选中，FL执行态就会接收FL计划、查询本地数据、计算模型更新和度量。

结果报告

FL计划执行后，会报告更新和度量给服务器，并释放临时资源。

FL计划不仅用于模型训练还用于模型评估。

FL runtime 可以在初始化它的App内执行，也可以在其他App内执行（安卓接口定义语言AIDL、跨进程通信IPC）

多线雇佣

可以在同一App内训练多个FL集群。这需要多个训练活动之间协调，避免设备同时训练过载。

证明

我们希望匿名参与FL，有效保护用户隐私。由于没有认证，需要防范结果破坏者，可以使用 remote attestation mechanism防止数据投毒等。

0x04 服务器

服务器的设计主要考虑大规模的问题，如设备数量的庞大、更新通信的庞大、给定区域某时段的流量突发。

Actor 模型

简介：一个Actor是一个最基本的计算单元，可以接受消息并执行计算。Actors之间相互隔离。Actor存在邮箱机制，可以暂存来不及处理的消息。

Actor作用：

  • Create more actors
  • Send message to other actors
  • Designate what to do with the next message （only change its state when the next message coming）

容错机制：

在执行过程中，存在一个叫supervisor的进程(本质也是Actor)，它用于检测其他Actor是否崩溃，如果存在崩溃的，supervisor会被通知如何处理（即作出反应让其变成一致的状态，最常见的就是初始化状态重启Actor）。

架构

Actors关系如下：

Coordinators：全局同步的管理者、每一个负责一个集群的设备。协调者将其地址与集群登记在共享锁定服务中。Coordinator管理连接Selector的设备，并选择多少用于训练。Coordinator会生成Master Aggregators，令其管理每轮FL task。

Selectors:管理设备的连接。从Coordinator接收所需设备的数目，并决定是否接受每一个设备的请求。当生成Master Aggregator 和Aggregator时，Selector 会将连接信息发送至Aggregators。(这样有利于提高Coordinator热舞分配的效率，而不用在意有多少设备可用)

Master Aggregators:管理每轮FL task，它可以自行决定是否生成更多的Aggregators。(可以放缩设备数目和更新大小)

在Master Aggregator聚合之前，不会有任何信息写入硬盘。所有的Actor状态都是在内存里的，都是临时的。降低分布存储的延迟，提高拓展性。在内存中聚合不会产生日志，有效防止日志攻击。

流水线

选择、配置、报告是顺序执行的。但选择阶段不依赖任何输入，可以与配置、报告阶段并发。

鲁棒性

  • Aggregator、Selector挂掉：只是与之相邻的设备信息损失
  • Master Aggregator 挂掉：当前轮受损，Master Aggregator 会被Coordinator重启。
  • Coordinator 挂掉：会被Selector layer检测到，重新被生成。

0x05 分析

用于分析实际过程中发生什么、设备的状况等。

  • 设备端：会将诸如设备训练时状态、时间、频率、内存占用、发生的错误、所用模型系统等作为日志记录在云端。（不包含任何隐私信息，只用于实时检测）。并用专门的ASCII串表示发生的错误。

  • 服务端：记录每轮多少设备接收/拒绝参加、各阶段的时间占用、上传/下载吞吐量、错误等。

一些问题的出现与设备的健康有关。训练过程不会对用户产生负面影响，功能故障也不会产生。但操作错误会降低设备的效用。使用精准的分析减少对用户的影响。

0x06 安全聚合

主要用于保护数据的隐私、可以防范“诚实但好奇“的攻击者访问内存的聚合数据。

安全聚合是一个四轮交互的协议，四轮分成三个阶段：

服务端接收设备的信息，并根据信息计算独立的秘密发送回设备。

Prepare Phase：（前两轮）在此阶段会生成设备之间的共享秘密。此阶段掉线的设备的数据不会参与更新。

Commit Phase：（第三轮）设备上传加密掩码后的更新。服务端计算更新和。

Finalization Phase：（第四轮）需要足够多的设备披露上阶段掉线设备的掩码，使服务器完成模型聚合。===》恢复阶段

实际情况中，安全聚合的计算开销随着设备数目的增加而成倍增加。为了不限制用户数量，本系统在每个Aggregator上运行一个安全聚合实例。FL task会定义参数k，表示至少安全聚合k组。Master Aggregator会进行最终聚合，不会采用安全聚合。

0x07 工具&流程

与传统的模型流程不同，模型工程师需要面临以下挑战：

  • 训练实例无法直接检查，在测试和模拟阶段需要工具处理代理数据。
  • 模型不能交互运行、必须编译成Server可以部署的FL plan。
  • 基础架构必须自动验证资源消耗和运行的兼容性。

模型工程师的基本流程如下：

建模和模拟

我们库提供声明联邦学习和评估任务的函数。此类函数作用就是将张量转成度量，在测试阶段用使用test data、实际环境用设备收集的数据。我们的库可以生成FL task，但task不能用test data。task的初始化参数写在Pyhton中。

Plan 生成

Plan会根据工程师的配置和模型自动生成。

Plan由设备和服务器两部分组成：

device：TensorFlow 图、选择标准、执行指令。

server：聚合逻辑算法。

我们的库可以将运行在服务器上的部分剥离出来、运行在设备上。

版本控制、测试、部署

工程师根据版本控制、测试、部署等基础设施实现自动安全检查、解决版本兼容问题。

满足以下条件才会将task转为plan：

  • 可审查
  • 通过模拟后、确定为test的
  • 资源开销在可接受的安全范围
  • 支持已声明的各个版本的TensorFlow

设备不同的TF版本也是需要面临的问题，我们的FL基础可以将FL task转换成兼容TF版本的plan。可以每三个月转换一次计算图，以解决不兼容问题，只有很少一部分需要复杂的解决方法。

指标

每轮结束后，参数和指标会被记录在硬盘上。指标会带有其他数据、包括元数据、FL任务名、轮号等。本FL系统提供了分析工具，将指标加载到Python，以供工程师参考。

0x08 应用

  • 单设备物品排行
  • 键盘输入内容预测
  • 下一单词预测

0x09 配置

一些性能指标与设备状态和网速有关。FL plan、全局模型和更新大小会随不同的app而改变、样本数每轮会有差异，计算复杂度会与样本有关。

跨越几种不同的设备，此系统可处理日活千万设备。实际中，达到一万设备同时训练，并且主要是在夜间执行的。

训练过程：

  • 每轮接收几百个更新就可以完成聚合。（更新足够后，未执行完的设备终止执行）
  • 每轮挂机差不多是6%-10%
  • 实验中选择130% 的设备参与训练（此参数可以微调）

0x0A 相关工作

其他方法

  • Pihur 提出的算法无需在服务器聚合、还有正式的隐私保护。我们服务器的设计已经满足扩展性和隐私保护。
  • Smith、Kamp等算法可用于更高级别的兼容性问题。
  • FL已经被考虑进汽车之间的通信和医疗环境。但我们的系统没有直接应用，但很多方面和生产应用有关。
  • Nishio等人致力于不同的环境场景应用，我们的系统能够实现资源感知选择。

分布式ML

  • 我们提出适用于移动终端的结构方法。
  • 无法像参数服务器一样，实现全局规模的聚合和异步更新，我们需要服务器与一些设备在特定时间利用安全聚合实现同步更新。

MapReduce

FL server==》Reducer、FL devices ==》Mappers。

与传统的MapReduce不同。

？？？(⊙_⊙)?

0x0B 未来方向

Bias

问题：

  • 使用了FedAvg算法，该算法认为所有设备性能是相同的。
  • 大多数地区还没普及unmetered network。
  • 至少最新的Android版本、2G内存

解决方法：

​ 训练过程不做预测，训练完成才用具体指标评估（可以检测设备的偏差导致模型下降的问题）。实际情况中，并未发现，可能与FL集群、应用等相关。如果需要量化这些概率的影响，算法和系统方法可能是未来的工作方向。

Convergence Time

  • 比中心训练收敛慢。
  • 并行聚合只能有效使用100个设备（需要新算法，提高利用率）。
  • 可以用ML调节时间窗口等参数。

Device Scheduling

单节点的多租赁是基于任务队列实现的，这没有考虑用户使用App的频率，结束了对旧数据的训练，而忽视了新生成的数据。

Bandwidth

  • 可能很少的原始数据产生很多需要更新的参数，例如RNN。上传原始数据比较划算，这是带宽与隐私之间的tradeoff。

  • 使用压缩、量化等技术。

Federated Computation

致力于将符合本文基本标准的Federated leanring转换为Federated Computation。现在可见的应用场景是Federated Analytics。

参考