很久没有写文章了，倒不是因为懒，而是科研繁忙（狡辩），一方面也是因为自从决定不再重复造轮子后不知道该写一些什么。正好目前手上的项目处于收尾阶段，不如留下一点思考。当然，本人学识浅薄，如有错误还望读者批评指正。

横向联邦中的角色

在最原始的联邦学习（即FedAvg）中，有两个角色最为突出，它们分别是参数服务器（Server）和工作节点（Client），整个联邦过程聚焦于两者之间的数据交换。在这个过程中，需要注意的是Server是单例的，意味着所有Client只与一个Server进行数据交换，这增大了数据传输的成本（考虑到联邦终端大多数可能是移动设备），同时中心化的设计可能存在恶意发起者攻击参与者的问题。考虑到这些问题，一些工作尝试打破原有的横向联邦设计思路，例如增设边缘联邦聚合服务器和去中心化，前者增加了Server而后者直接消灭了Server。这些做法都打破了FedAvg中单个Server的设计。

基于以上讨论，在设计联邦系统的时候我们只需要考虑Server和Client的耦合关系就可以了？我认为答案是否定的——因为还存在一个隐性因素存在，也就是策略（Strategy）。

当然，在工业实践中，Strategy往往是维持不变的。但是作为一个软件系统，在设计之初我们就应该仔细考虑未来拓展的可能性，减少重构代码带来的复杂度与成本。况且在科研实验过程中，往往需要对一个idea进行反复打磨，这之中免不了对代码的反复修改，能够通过良好的抽象设计减少修改成本与减少编码失误带来的时间成本也是十分重要的。在实践中一个Strategy往往对应一组Server与Client的实现，这点在修改了原始联邦学习协议的工作中尤为重要（例如CFL和上文中提到的两种情况）。

究竟是策略依赖设备还是反之？

标题中的设备指Server与Client这种实际的物理设备（Device），其实前一节的最后一段已经提出了我的观点——Device依赖Strategy。其实这种问题在不修改联邦协议的工作中是不存在的，比如FedProx这类仅仅是在Client训练过程中一个正则项的工作，完全可以使用任意传统联邦服务器进行混合训练（也就是本地训练策略不同）。但对联邦协议修改的程度越大，Device对Strategy的依赖也就越大，以至于Client无法混合训练。

以及？

工程实现当然没有如此简单，主要需要考虑的就是辅助工具（Auxiliary），例如日志记录、数据预处理与均衡负载等。这些工具对Strategy的依赖往往较低，但也会存在一定的依赖（例如部分工作在服务器的公有数据集上有处理），而且往往是双向耦合的。在这一部分设计中，可以考虑将其独立出来，抽象成为服务，这样无论是拓展还是修改都优于将其聚入Device的具体实现中。

参考

• Communication-efficient learning of deep networks from decentralized data
• Decentralized Federated Averaging
• FEDERATED OPTIMIZATION IN HETEROGENEOUS NETWORKS
• Clustered Federated Learning: Model-Agnostic Distributed Multitask Optimization Under Privacy Constraints
• Decentralized aggregation for energy-efficient federated learning via D2D communications

行文仓促，部分引用内容有所遗漏，望谅解。