許嘯宇:從內部研發到開源開發之路|OneFlow U

語言: CN / TW / HK

許嘯宇,一流科技研發工程師,現主要從事框架開發工作。2017年,從北京郵電大學碩士畢業後,他去微軟亞洲研究院實習,並在當時的導師袁進輝手下接觸了系統研發工作。這段經歷為他後來的工作埋下了伏筆。

畢業後,他先在騰訊做了一段影片推薦演算法工作,而後轉向了推薦系統開發。工作兩年多,他開始想進入一個成長期的技術領域,在與OneFlow創始人袁進輝的交流後,2020年7月成為OneFlow框架的開發者

本文為許嘯宇自述。

 

1

從演算法工程師轉向系統開發

 

2016年底,我在微軟亞洲研究院跟袁老師前後做了大概三個月的實習。在那裡,我第一次接觸了比較基礎的大型系統研發的工作,對它的結構和設計窺見了一眼。相對於“怎麼實現一個功能”,袁老師更關注“最優的設計應該是什麼樣的”,這個對我影響很大。

正式畢業後,我選擇離開北京到了深圳工作,在騰訊做影片推薦工作。記得剛進公司時,有個事業群的推薦演算法比賽,其他小夥伴搞特徵很厲害,我琢磨了一下不用公司訓練平臺的XGBoost,而是拿記憶體佔用少、速度快的LightGBM自己搭訓練工具。這樣單機我們能用更快速度、更多資料去跑任務,小夥伴的特徵工程配合這個工具,我們只是參與了一下,沒想到拿了冠軍。

後來這個訓練工具在小組內逐漸就替換了平臺部那邊的XGBoost訓練工具。曾經有共享這個工具的想法,但內部沒有跨組共享的氛圍,後來就不了了之。

我的興趣開始從演算法轉到了系統開發,所以找機會轉到了推薦引擎開發的工作。我感覺演算法有很多黑盒部分,而系統則基本是白盒的。我當時所在專案維護第三方元件的方式比較特別,裡面大部分的基礎元件都不是二進位制檔案或者第三方庫連結,而是C++原始碼,它們不少是騰訊前輩員工積累的內部實現原始碼,因為沒有開源倉庫共享的氛圍而採用了原始碼Copy的共享方式,這也是一種特別的“開源”吧。所以幾乎可以看到所有基礎工具的實現,也可以根據自己需要做修改,只是無法很好地跨組織做元件的更新、交流。

我開始主要使用和維護一些模組,比如索引的容錯、用RCU無鎖Map縮減記憶體消耗、統一本地和遠端的索引抽象,後來我的前導師給了一個機會,獨立從0到1上線了一個服務。當時的程式碼支撐了很大的流量,但是基本只有3-5個人在維護。唯一一個跨組和部門共享的程式碼是當時我和我的Leader定的一個統一推薦協議,它逐漸被N個推薦服務和N個業務方作為協議介面。

剛畢業時,我主要考慮回南方,以及擴充套件下視野。工作兩年多後,我的想法變成了找個不太成熟的領域深入進去。這時,機緣巧合地遇到袁老師來深圳出差,所以就認真考慮了他在推動的OneFlow。

我在騰訊推薦工作中的認識是,深度學習/機器學習這樣有學習能力的軟體已經像資料庫一樣無處不在了。Oracle資料庫已經發布了40年,開源的TensorFlow才釋出了5年,深度學習/機器學習軟體還有很長的未來。另外,我去讀了PyTorch的部分原始碼,發現是可以讀懂的。

問了兩、三個朋友,他們都說OneFlow技術過硬,但都擔心創業期的OneFlow會死掉。這是客觀存在的風險,但我暫時擱置了這個問題,而基於另外三點優勢做出了選擇:

1、OneFlow在做硬核技術,個人和工作內容只要在不斷成長就好;2、要合作的小夥伴是不是你想與之為伍的,我當時認識兩個OneFlow的同事,我認為是的(現在也是如此);3、我相信袁老師能搞定未來新出現的挑戰。

 

2

對抗內卷、開放改進的開源文化

 

2020年7月,我來到了OneFlow。到OneFlow的前半年多,出於工作和興趣需要,我做了很多開源實現的調研。之前也看過《計算機程式的構造和解釋(SICP)》,上個月讀了《黑客:計算機革命的英雄》,瞭解到了開源文化的本源。

如果讓早期的IBM那種商業公司的工程師來主導軟體世界,那麼現在估計只有拿到“計算機執業證”、打著領帶的人才能進入體量巨大的機房,寫下受保密協議約束的私有程式碼。我們遠在中國,估計只能看到各種軟體的二進位制檔案。軟體有什麼新進展,我幾乎是無法很快知道的。我看不到LightGBM的程式碼,可能也比較難接觸到一個靠譜的RCU實現,我們的推薦服務可能不會存在,因為沒有這麼一個繁榮的軟體市場。

“對計算機的訪問(以及任何能幫助我們認識世界的實物)應該是完全不受限制的。任何人都有上手嘗試的權利。”這是最早接觸計算機的MIT Hacker開創的開放、改進的文化,他們在早期就通過共享軟體、程式碼、文件,來對抗封閉、內卷的文化。

要讓其他人舒服的使用你創造的工具,理解你的實現。理解了的人會批評和改進,那麼軟體和知識就有了生命力,能夠不斷變得更好。工具的作者也在批評和改進中得到不斷地進步。

現在,我們在OneFlow的工作,程式碼都是GitHub公開的,一些早期的工作計劃討論也基本是全公司可見的。我最近主要參與動靜轉換和靜態執行相關的工作,說下最近一個多月具體做的幾個Feature吧:

一個是靜態圖執行的自動化單測。 其他同事做了個有趣的工作,一段Torch風格的程式碼,每個函式執行時,實際會兩遍函式,一遍Torch的函式、一遍OneFlow Eager函式,對比結果後就能驗證和Torch結果的一致性。我在這裡又拓展了一點,從一段程式碼中想辦法找到需要靜態執行的物件,構造出OneFlow Graph的執行函式並執行,這樣就能同時驗證靜態圖的結果了。寫一行Op測試的程式碼,它內部實際會按三種模式執行,這種hack極大提高了單測用例的實現效率。 

一個是提高debug便利性 ,從CPython直譯器中獲取Python程式碼的函式呼叫棧資訊,記錄到C++層的Operation的元資訊中。這樣OneFlow的圖執行模式nn.Graph在構圖、編譯圖、執行圖時,如果程式在C++層掛掉了,可以方便的定位出其原本對應的Python程式碼檔案、行位置,提高debug效率。

一個是ZeRO記憶體優化在靜態圖nn.Graph的復現 ,主是把資料並行中模型更新部分的冗餘視訊記憶體佔用給簡化掉。DeepSpeed寫了N千行的程式碼實現了這個功能,OneFlow因為有SBP的推理機制和基於計算圖程式設計的機制,所以只需要對計算圖中的引數的資料分佈做下改寫,再增加些調整執行順序的控制邊,就能達到目的。熟練SBP,對計算圖程式設計更加了解的話,對程式做分散式優化是事半功倍的。不過,需要對系統內建的機制有比較多的瞭解,所以有一些學習成本。

上面的這些工作,我去讀了OneFlow小夥伴對物件執行的hack、讀了CPython直譯器對呼叫棧的記錄、讀了DeepSpeed的程式碼,和小夥伴做設計討論,最後加上了自己的理解進行了實現,這些實現都在OneFlow倉庫可見。

另外,這裡無法體現的是我們對設計的爭吵,包括一些關鍵介面,我們曾經對線了一個星期才達成一致。現在看來,當時討論時把後來很多可能會碰到的坑都考慮到了,真是值得。

從之前的內部開發逐漸轉變到了現在的開源開發的方式,我感覺和其它開源軟體的關係更近了,可以看到、跟進、推進一些最新的東西。如果你對開源開發也感興趣,歡迎加入我們的OneFlow專案,跑OneFlow的demo、提issue、修bug、review我們的PR,或者直接加入我們,一起做提高開發者效率和機器效率的工具[email protected]

 

其他人都在看

歡迎下載體驗OneFlow新一代開源深度學習框架:https://github.com/Oneflow-Inc/oneflow/


本文分享自微信公眾號 - OneFlow(OneFlowTechnology)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。