- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2022-04-30來源:陪你共撐帆瀏覽數:465次
總有人會問為什么會有這么多的編程語言,其實大體也是因為語言的不斷進化,在不同場景下做了不同的權衡。
導讀:機器學習框架這個詞包含的點和面比較多,各種流派也發展了很多年,有各種不同理解。今天簡要結合我的個人經歷,分享下我對框架的看法,為論壇后面的內容拋磚引玉。主要包括以下兩部分:
BIDMach介紹 關于工業級框架的思考 01BIDMach:一個不尋常的機器學習框架BIDMach是我在學校期間參與的一個開源框架項目,這個小而緊湊的框架五臟俱全,很多設計取舍又跟主流框架不太一樣。因此我將順著對BIDMach的介紹,來探討下一個框架到底需要哪些必要組件。
1、BIDMach簡介
BIDMach是2012年在伯克利BID實驗室研發的一個開源機器學習框架。
(參見https://github.com/BIDData/BIDMach)
不同于一般的主流框架,它除了最底層用JNI調用CUDA/MKL之外,其前后端都統一到了Scala語言。諸如內存管理、計算管理、圖計算等都是用Scala寫的,是一個簡潔且清晰統一的代碼框架。之所以選用Scala,是因為其有很新的語言特性,它可以像C++一樣靈活,像Java一樣具有很強的可維護性,也同時具有像Python一樣的交互編程特性。
正如下面的一段代碼一樣,通過Scala的語法糖,可以定制出類Matlab的編程語法,可讀性非常強。

2、BIDMach架構
下面是BIDMach整體的架構:

BIDMach的整體設計分三層,下層關注于底層硬件的性能并統一封裝為矩陣運算和Actor間的通信操作;中間層是各種機器學習算法的計算圖封裝,而最上層則是面向用戶設計的交互式機器學習工具。此外,BIDMach以從上到下的整體Co-design為核心設計思想,在性能方面用Roofline Model優化到硬件的極限,在可用性方面需要有交互和可視化呈現結果以及提供交互式的調參等功能。而框架的語言統一和架構精簡,讓我們從上到下做到整體協同優化變得格外容易。
3、框架要考慮什么
從對BIDMach的描述,讓我們來看看一個框架到底要考慮哪些內容呢?首先,對于一個框架,我們談論的是:“至少它能解決我們的問題!”否則它就不是一個可用的框架了。而有了基本功能之后,更進一步,框架的可用性和性能都是我們需要去考慮的。可用性是指前端語言的設計和后端架構的設計,它將影響工程師研發和框架二次開發的效率。性能指硬件的高效性,包括編譯優化以及芯片上的優化,它將影響程序的執行效率。

可用性和性能似乎覆蓋了大部分對框架的訴求,也會讓人覺得框架這個問題已經被解決得很好了。而當我來到公司之后,我發現其實可能框架遠不止這些事情。一般來說,類似tensorflow/pytorch這樣的深度學習框架,實際上是提供了一個可微計算圖引擎,他們可以非常方便地構建一個可微的函數(如下圖所示),然后基于數據去最小化損失函數,這種抽象使得深度學習變得非常簡單和可行易用。
但是到了工業界,實際的機器學習問題遠不止這么簡單,我們要重新思考一下框架的職責。框架是只需要專注于做損失函數優化就可以呢?還是會有很多其它事情也要去負責呢?比如圖中所示的x、y樣本數據本身的生成就是一個很大的問題:比如樣例生成或者特征萃取。而且在互聯網應用中,我們往往需要從流式的數據流中實時地完成x、y的生成。

另一方面,到了工業界中,訓練和推理很可能是要被分開去做的。因為在推理的時候你只需要處理一個固定的計算圖,這就存在很多優化的空間。如果一定要把訓練和推理一體化,就可能帶來很多系統上的難點,所以主流的做法是會把推理和訓練分開。此外,用戶點擊率模型的模型參數往往會很大,模型又要求實時更新,工業應用中又還有資源調度的問題等等。這里面很多問題都是和框架本身的設計或是接口設計息息相關。
所以實際情況是,如果把框架的概念從一個單點應用擴展到一個可用的工業界框架后,就會包含很多模塊:樣本的處理、特征的處理、離線訓練和在線推理,各種數據接口,一致性保障、資源管理和整個實驗平臺等等一系列工具。這些東西可能從廣義來講都算是框架中的一部分。可能做框架的同學不一定同意我的觀點,但TensorFlow和Pytorch等框架如何與外界生態進行橋接確實是需要我們去思考的問題。
用于工業的MLSys@Alimama
通過上面的討論,會引出這樣一個問題:到底如何去維護這樣一個復雜的工業級系統?
這里有兩點經驗值得分享,一個還是Co-design協同設計的概念。我們需要站在框架和算法的中間節點去整體看待這個問題。比如探討算法的一些需求是如何在現有框架上能以更高性價比實現,以及探討框架的進一步優化路徑如何符合算法的發展趨勢。

而這就會引發另一個有意思的現象:框架與算法共同進化。框架和算法實際上是相輔相成,是共同進化迭代的一個過程。我們在整理廣告組過去4-5年的經歷的時候發現:這個演化過程確實是有周期性的。
工程框架的發展是跟整個算法的紅利包括跟整個業務的發展都有關聯的。算法側提出了一個新的結構,框架就需要去做適配和推理優化。框架的革新又會導致算法工程師可以去嘗試更復雜更加有意思且更有深度的想法。整個過程就是一個共同進化共同演化的過程。正如Hardware Lottery里所說的那樣:“一個研究性想法的取勝是因為當下它更好地適配了已有的軟件和硬件”。反之,一個框架是否被廣泛應用,也是因為它非常好地響應了當前算法的發展趨勢。正如 pytorch 被越來越廣泛地應用,也是因為它更適合用來實驗新的模型結構。

總的來說,當我們談論框架的時候,我們可以有很多個層面去討論這個問題。
首先我們可以從可用性,即考慮單個程序員的編程效率;
第二就是機器性能效率,即如何去做編譯優化,如何做適配,如何去做圖改寫,如何去做調度分配等;
第三是組織效率,即考慮這個框架生產化功能是否完備,是否能提供較好的可擴展性以支持工業界的大規模生產化協同工作;
最后是生態層面,也就是要考慮算法的演化路徑以及未來幾年整個算法的趨勢。框架是否能讓算法不斷嘗試新想法,優化社區的整體效率。

最后再借鑒編程語言的例子做下總結。
總有人會問為什么會有這么多的編程語言,其實大體也是因為語言的不斷進化,在不同場景下做了不同的權衡。可以看到,同樣的原因也正在促使如此多優秀框架的產生,讓整個機器學習的生態蓬勃向前發展!
