導讀 本文將分享百度在互聯互通方面的思考與實踐。主要內容包括：
1. 互聯互通原理介紹和方案
2. 金科科技聯盟方案情況和進展
3. 開源協同聯邦HIGHFLIP方案
4. 兩種方案之間的討論和思考
分享嘉賓｜陳治宇 百度 資深工程師
編輯整理｜鍾理 遠信集團
出品社群｜DataFun
01
在做互聯互通的之前，我們對各家的聯邦學習平臺做了一個比較深入的調研，對它們的原理進行了深入分析。聯邦學習平臺總體上可以分成四個層次，包括應用層、排程層、演算法層以及安全運算元層。
在上圖的左側，我們把它的每一個模組劃分、元件都抽象出來。透過一些基礎的分析和研究，我們對聯盟學習的原理有了一個比較深入的理解。根據原理，我們提出了基於當前互聯情況的互聯互通方案。
互聯互通的方案按照對接原理，可以分為白盒互通、灰盒互通和黑盒互通。- 白盒互通方案，認為需要一個完全的開放公開的工作原理和細節。也說是兩方對接的過程中，可能需要對對方的演算法的實現，以及其系統性的原理，有比較深入的理解，兩方把協議進行對齊。
- 黑盒互通則相反，不需要去理解其原理，而是將聯邦學習平臺作為一個整體來看，不需要看到內部的實現原理。
- 一些廠商還提出了灰盒互通的概念，它介於白盒和黑盒之間，這裡就不展開講了。
百度在對原理進行了分析之後，提出了另一種互通方案的分類方式，按照對接層次來分，包括底層互通和頂層互通兩類。底層互通，類似於白盒互通，比較直接和簡單。比如a和b之間可能是兩個完全異構的系統，要把它們直接連線起來，就需要把每個層次之間的傳輸定義出來，包括應用層、排程層、演算法層和運算元層。每個層級之間東西向協議傳遞的資訊需要明確，才能完成互通。在實際操作過程中，還有另一種方案，是頂層互通。相比於底層的方式，頂層互通是把這些底層的各個功能暴露在最上層，由最上層來完成互聯。相對於底層互通來講，頂層互通並不需要對底層的各個原理和各個通訊協議進行復雜的對齊，而是簡化為只需要頂層介面的對齊就可以了。
百度在技術上主要是負責金科聯盟方案的排程層和演算法容器載入，這也是金科聯盟這套互通方案比較核心的一個點。金科聯盟的方案屬於底層方案，需要把每層的通訊，包括之間的傳輸和南北向的傳輸都有比較明確的定義。在過程中，百度也有一些對接的經驗和技術。我們把這些技術放到了演算法載入的方案之中。然後讓它形成一個比較通用細化的一個互通方案。在定義演算法容器上，看起來比較簡單，但是如果深入思考，會發現並不簡單。我們在過程中也遇到了很多挫折。
容器的設計不是一個一時靜態的過程，它並不是只是一個標準，而是一系列的隨著時間進行更新和迭代的標準。設計一個容器會有一個發展的過程。發展以後新出現的容器對老的容器要滿足一定的相容性，這樣才能保證協議或整個系統的持續性發展。另外，在溝透過程中，我們發現各家已經有很多的演算法實現，這些演算法實現有的是在容器中，有的並不是一個獨立的容器，而是一個程式或者是一個程式碼元件。我們希望在流程中能更簡單，不希望在遷移的過程中，讓整套系統變得有很多依賴。其次約束也儘可能低，各家的差異性是比較大的，所以在容器中，最好能做到演算法對周邊容器無感知。以前的演算法遷移到現有的容器之中，還能繼續執行起來，並且能不斷相容以前的版本，是很有挑戰的一個點。
容器包括瞬時容器和常駐容器兩種。我們在分析和調研過程中發現這兩種情況佔的比例都挺多的。為了滿足大多數的情況，我們選擇了瞬時容器作為目前主要的定義方式，當然也有常駐容器。常駐型的容器是我們最早提出來的。容器啟動起來，會變成一個服務。然後由多種不同的任務去調節演算法容器。同時把自己的能力暴露給註冊和發現服務，這樣形成一個常駐執行的容器方式。但是在我們的調研過程中發現，這種方式可能比較複雜。因為它會牽扯到很多的介面，在定義過程中，很難達成有效的一致性。所以我們在多輪分析後，又逐步把我們的方案轉向成為瞬時化的容器。瞬時化的容器比常住的容器更為簡單，使容器的輸入資料和輸出資料變得更清晰。它在執行過程中的演算法引數，都可以當作系統的輸入資訊。容器內部的資訊，我們定義成為自描述的資訊，又同時暴露給支撐系統。透過相互靜態的單輪的互動方式來實現靜態容器的定義。即可達到啟動、執行一次就銷燬。同時在容器內部，我們不做過多的介面定義，讓這整個容器內部跟現有的容器是幾乎沒有差別的，從而讓對映象約束達到最小。
我們把所有容器內部的約束條件做了一些規範。同時把輸入資料分成描述部分和執行部分，以及執行態部分。把這些資訊又歸結到應用現在容器本身自有的一些特性，主要是用於記憶體式的方式，透過label和環境變數的方式來進行傳遞。整體上容器本身沒有太多自定義的路徑和自定義的介面，所以整個容器是比較簡單的。除了金科聯盟的底層互聯的方案外，我們同時也在演進頂層的互聯方案，我們提出的是一種叫做 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 社群中公佈了一部分。百度做的互聯互通的工作，與金科聯盟有一定的互補關係。金科聯盟現在做的方案是一個偏底層的互通協議，百度做了一個頂層的協議，合在一起形成了一個總體上的互聯互通方案。我們認為目前的底層互通方案複雜性較高，需要很多廠商配合。它會是一個未來的發展方向，但是在當前的商業中，仍然需要偏頂層的通訊協議。頂層互通協議相對比較簡單，其思想主要是將聯邦平臺當作整體去考慮，犧牲一些部署空間來換取易用性和快速響應的實施。它的好處是可以更簡單地部署，並且在不同平臺重複使用相同的運算元。但它結構上會比較複雜，會有比較大的推動成本。總體上，底層和頂層都只是交換點位置上的不同，以及應用時機的不同。它們之間是互補的關係，需要合在一起去使用。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70027824/viewspace-2949455/，如需轉載，請註明出處，否則將追究法律責任。
