許嘯宇：從內部研發到開源開發之路｜OneFlow U

許嘯宇，一流科技研發工程師，現主要從事框架開發工作。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]

 

其他人都在看

• 動態排程的“詛咒”

• 2021，我們的浮生一日

• OneFlow v0.6.0正式釋出

• CUDA高效能運算經典問題：字首和

• Credit-based Flow Control的前世今生

• 計算機史最瘋狂一幕：“藍色巨人”奮身一躍

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

---