"导读：本文将分享百度在互联互通方面的思考与实践。主要内容包括：互联互通原理介绍和方案金科科技联盟方案情况和进展开源协同联邦HIGHFLIP方案两种方案之间的讨论和思考分享嘉宾｜陈治宇百度资深工程师编辑整理｜钟理远信集团出品社区｜DataFun 01/互联互通原理介绍和方案在做 ...."

Fork me on GitHub

AIPreacher
AI发布小助手
百度 • 0 回帖 • 154 浏览 • 11 个月前

百度关于互联互通的思考与实践

以下文章来源于 https://zhuanlan.zhihu.com/p/624866380

导读： 本文将分享百度在互联互通方面的思考与实践。主要内容包括：

互联互通原理介绍和方案
金科科技联盟方案情况和进展
开源协同联邦HIGHFLIP方案
两种方案之间的讨论和思考

分享嘉宾｜陈治宇百度资深工程师

编辑整理｜钟理远信集团

出品社区｜DataFun

01/互联互通原理介绍和方案

在做互联互通的之前，我们对各家的联邦学习平台做了一个比较深入的调研，对它们的原理进行了深入分析。联邦学习平台总体上可以分成四个层次，包括应用层、调度层、算法层以及安全算子层。

在上图的左侧，我们把它的每一个模块划分、组件都抽象出来。通过一些基础的分析和研究，我们对联盟学习的原理有了一个比较深入的理解。根据原理，我们提出了基于当前互联情况的互联互通方案。

互联互通的方案按照对接原理，可以分为白盒互通、灰盒互通和黑盒互通。

白盒互通方案，认为需要一个完全的开放公开的工作原理和细节。也说是两方对接的过程中，可能需要对对方的算法的实现，以及其系统性的原理，有比较深入的理解，两方把协议进行对齐。
黑盒互通则相反，不需要去理解其原理，而是将联邦学习平台作为一个整体来看，不需要看到内部的实现原理。
一些厂商还提出了灰盒互通的概念，它介于白盒和黑盒之间，这里就不展开讲了。

百度在对原理进行了分析之后，提出了另一种互通方案的分类方式，按照对接层次来分，包括底层互通和顶层互通两类。

底层互通，类似于白盒互通，比较直接和简单。比如a和b之间可能是两个完全异构的系统，要把它们直接连接起来，就需要把每个层次之间的传输定义出来，包括应用层、调度层、算法层和算子层。每个层级之间东西向协议传递的信息需要明确，才能完成互通。

在实际操作过程中，还有另一种方案，是顶层互通。相比于底层的方式，顶层互通是把这些底层的各个功能暴露在最上层，由最上层来完成互联。相对于底层互通来讲，顶层互通并不需要对底层的各个原理和各个通信协议进行复杂的对齐，而是简化为只需要顶层接口的对齐就可以了。

02/金科科技联盟方案情况和进展

底层互通方案，以金科联盟现在做的方案为例。

百度在技术上主要是负责金科联盟方案的调度层和算法容器加载，这也是金科联盟这套互通方案比较核心的一个点。金科联盟的方案属于底层方案，需要把每层的通信，包括之间的传输和南北向的传输都有比较明确的定义。在过程中，百度也有一些对接的经验和技术。我们把这些技术放到了算法加载的方案之中。然后让它形成一个比较通用细化的一个互通方案。

在定义算法容器上，看起来比较简单，但是如果深入思考，会发现并不简单。我们在过程中也遇到了很多挫折。

容器的设计不是一个一时静态的过程，它并不是只是一个标准，而是一系列的随着时间进行更新和迭代的标准。设计一个容器会有一个发展的过程。发展以后新出现的容器对老的容器要满足一定的兼容性，这样才能保证协议或整个系统的持续性发展。另外，在沟通过程中，我们发现各家已经有很多的算法实现，这些算法实现有的是在容器中，有的并不是一个独立的容器，而是一个进程或者是一个代码组件。我们希望在流程中能更简单，不希望在迁移的过程中，让整套系统变得有很多依赖。其次约束也尽可能低，各家的差异性是比较大的，所以在容器中，最好能做到算法对周边容器无感知。以前的算法迁移到现有的容器之中，还能继续运行起来，并且能不断兼容以前的版本，是很有挑战的一个点。

容器包括瞬时容器和常驻容器两种。我们在分析和调研过程中发现这两种情况占的比例都挺多的。为了满足大多数的情况，我们选择了瞬时容器作为目前主要的定义方式，当然也有常驻容器。

常驻型的容器是我们最早提出来的。容器启动起来，会变成一个服务。然后由多种不同的任务去调节算法容器。同时把自己的能力暴露给注册和发现服务，这样形成一个常驻运行的容器方式。但是在我们的调研过程中发现，这种方式可能比较复杂。因为它会牵扯到很多的接口，在定义过程中，很难达成有效的一致性。所以我们在多轮分析后，又逐步把我们的方案转向成为瞬时化的容器。

瞬时化的容器比常住的容器更为简单，使容器的输入数据和输出数据变得更清晰。它在运行过程中的算法参数，都可以当作系统的输入信息。容器内部的信息，我们定义成为自描述的信息，又同时暴露给支撑系统。通过相互静态的单轮的交互方式来实现静态容器的定义。即可达到启动、运行一次就销毁。同时在容器内部，我们不做过多的接口定义，让这整个容器内部跟现有的容器是几乎没有差别的，从而让对镜像约束达到最小。

这里提到了最小化约束容器的概念。

我们把所有容器内部的约束条件做了一些规范。同时把输入数据分成描述部分和运行部分，以及运行态部分。把这些信息又归结到应用现在容器本身自有的一些特性，主要是用于内存式的方式，通过label和环境变量的方式来进行传递。整体上容器本身没有太多自定义的路径和自定义的接口，所以整个容器是比较简单的。

03/开源协同联邦 HIGHFLIP 方案

除了金科联盟的底层互联的方案外，我们同时也在演进顶层的互联方案，我们提出的是一种叫做 HIGHFLIP 的顶层互通方案。

这一方案的互联是在其应用层，而不是在底下的每一层。HIGHFLIP是一个顶层通信协议，主要应用场景是在商业领域，对现有的联邦学习平台不做系统性或较大范围的改造。

所以 HIGHFLIP 的主体服务和联邦学习通信的改造并不需要对联盟学习软件内部做修改。在联盟学习软件内部的一些对外的调用，也只是利用现有的插件系统来完成。所以 HIGHFLIP 的协议更为轻量化，对现有系统的修改会更少一些。

HIGHFLIP 互通的优势在于它是一个弱侵入式的方案，并不需要对一个系统做大的结构性的对齐。更易于现有的不同版本的软件实现互通，同时它也比较容易接入，整体上只需要完成一个适配器和一个插件就可以了。对于比较简单的一些联邦学习的平台互通，接入成本只需要大概一人月基本就能完成。它的成本相对比较低，并且对于闭源更为友好。并不需要对现有的联邦学习的软件、插件系统做修改，也不需要对原理做深入的理解。只要接口对上就可以使用了，所以它能应用在大多数商业产品之中。

我们希望 HIGHFLIP 协议能实现几种标准：

第一个是能达到接口上的标准化的通信，我们使用了 gRPC 作为标准的互通协议，来实现两个节点之间的沟通性。同时我们定义了 ProtoBuf 协议，来完成标准化的大的作业的对齐。同时有了标准的单个定义之后，我们还可以应用到最后的模型标准之中。我们统一使用了 ONNX 作为它的模型的参考。可以把现有的标准作业之中的定义融入到 ONNX 标准之中，也是我们未来要推进的一个工作。联盟学习的软件，它生成的模型可以与现有的深度学习模型和激励学习模型归结到一起，也是一个未来目标。

HIGHFLIP 更为轻量化。Alice 和包裹结构是个异构的平台，我们并不希望去把两方的通信协议完成一个直接的转换和对齐，而是部署了另外一个节点。通过 HIGHFLIP 通信的协议，把它要做的事情告诉中间节点，由中间节点来完成翻译和代理的工作，最后再跟 Bob 进行通信。这样的好处在于，Alice 和 Bob 有了真正业务上的通信。但并不需要对两方进行比较大的改造。很简单地通过桥接转接的方式，就能完成互联互通。这样就大大降低了互通的成本和闭源软件应用的阻碍。HIGHFLIP 另一个特点是，因为其统一了互通的通讯方式，所以 Alice 可以同时绑定其它家的软件的算子，让不同软件的算子能在同一个代码中进行结合使用。这样就实现了一加一大于二的绑定和扩展的能力。这也是 HIGHFLIP 的另一个特性。

目前 HIGHFLIP 是在一个开源协同内部共同维护的。联盟中有百度、FATE、腾讯和京东。预计会于 2023 年在 github 上完全开源出来。并且同时会在 FATE 1.9 中完成 HIGHFLIP 的适配工作。目前已经在 FATE 社区中公布了一部分。