“实践是检验真理的唯一标准”，联邦学习谈概念的文章已经很多，今天我们来从实践中聊几个实事求是的问题。

联邦学习领域已有众多论文支撑，但在实践中，因为涉及到多学科的交叉，真正能落地应用的平台，少之又少。所以市面上虽有三四十家做联邦学习的公司，但是能真正亮相产品仅有七八家。这应该是一个比较正常的现象，因为联邦学习工程落地所面临的挑战远远比理论复杂。

断点训练

断点训练 是指联邦学习过程中“训练可暂停”，如果发生多方之间的网络异常造成超时，待网络恢复正常后，联邦学习模型可从上次的断点开始继续训练，而避免重新开始。

这在我们的客户实际环境中非常重要，因为多方机构之间进行联合建模，无法预见和避免网络之间连接不稳定，一旦发生断网，普通的time out机制容易让学习过程超时或者异常退出。可能各家联邦学习平台的产品大多进行了网络不稳定的报警，这种处理是比较简单粗糙的，做一个心跳机制，不间断地去测试多方之间的网络情况，并发出日志报警。但是这种简单的处理方式只能帮助定位联邦学习建模过程出现的异常。试想，如果客户花了2小时眼看模型马上训练出来，进度条到99%的时候，突然time out了，是不是想死的心都有？这在用户体验上是极其不友好的。

下面我给出一种基于监控回调的处理方案：

加速训练 是指对联邦学习算法的提速，联邦学习还未在数据应用市场大规模使用的原因之一是建模速度，相比传统的本地建模，目前联邦学习所消耗的时间是传统方式的十倍甚至百倍。

分布式的机器学习面临最大的挑战是网络间的通信和节点的计算开销，这就好比本来在一个存储计算环境里能完成的机器学习建模，现在要用联邦（分布式）的方式，将算法平铺到网络上。联邦学习平台工程化的适合，需要非常关注算法流程的最优化设计。我们且认为当前学术水平下的算法理论已经在一个比较稳定的水平，那么联邦学习的计算总量不变，工程师需要重点考虑如何平衡训练过程的开销。在实践过程中，我们重点考虑4个方向的训练加速：

加密算法的加速：

比如利用GPU，将加密算法尽量打散做并行，尽量减少GPU和CPU之间的交互频次；

学习算法的加速：

比如我们在设计联邦学习机器学习算法的时候，尽量做到子模块的低耦合，理清楚子模块的依赖和并行关系，对算法流程进行深度的重新编排；

节点通信的加速：

这是非常重要的，基于流程的依赖关系，最大化地减少通信次数，这个需要不断优化，甚至是在同步异步的使用上；

代码的加速：

成千上万次的循环，我们倾向用更底层的语言来构建算子，比如 C++，这更有助于我们是用一个float还是用double来定义循环体里面的参数，因为你一定要相信，短一点的字符串、少一次循环体，都可能在整个联邦学习建模开销上带来一个数量级的提升。（代码工程是一个细腻的活，特别是对联邦学习而言，请你细品。）

集群训练

集群训练 是指联邦学习“机器可扩张”，通常联邦学习依赖比较高的配置，而且学习是不是能顺利、快速完成很大程度上依赖于服务器资源是否能满足给定的样本数量、特征维度数量。

举个例子，我们用40核128G配置的机器，测试100,000样本800特征的规模，设置迭代5次，采用比较常用的逻辑回归算法，耗时在100分钟左右。这个结果在目前国内主流的几个联邦学习平台上算是表现比较出色的。但是，联邦学习的时耗会随着样本规模的扩大呈现非线性增长，这是一个很大的挑战。负责learning的机器即使用最高配置，也会面临机器性能的天花板。

联邦学习平台必须支持简易的机器横向扩展，就像hadoop面向大数据行业的初衷就是“不够了，加一台”就可以支持更大数据的存储和运算。我并不觉得这个技术工程框架上会有多复杂，因为像Hadoop、Spark这些比较成熟的框架已经可以支持到分布式计算，我们完全可以用这类技术结合联邦学习算法的具体设计，将本地单节点的算法写到并行计算里面去，这部分核心的工程代码就是MapReduce~~~重构联邦学习算法，重写MapReduce函数。

插一句，之前提过的一个概念，未来的算力也许是面向领域的智能算力，而不仅仅是提供一堆机器，提供智能算力的云计算公司，会更AI、更贴近业务。

乘风更需破浪

联邦学习在今年的金融科技行业，可以用火爆来形容，真正落地的屈指可数，这是互联网技术的浮躁一面，也许我是技术出身，我更看好能在工程实践上踏踏实实做好产品的企业。借用最近流行的一个词汇——“乘风破浪”，来总结这篇文章，最为合适不过（更多前沿资讯请关注微信公众号“hellompc”）。