進擊的PyTorch,和它背後的開源領袖

語言: CN / TW / HK

十年間,從Torch進化到PyTorch,再到近期落地Linux基金會,PyTorch從一個無心插柳的專案逐漸演變為最有影響力的開源專案之一。它究竟是如何一步步成長起來的?背後有那些與眾不同的故事?

OneFlow社群編譯整理了Linux基金會對PyTorch創始人Soumith Chintala的最新採訪以及他此前分享的關於PyTorch的開源歷程,從中我們會看到一個開源專案的蛻變和社群構建經驗,以及PyTorch社群領袖所信奉的開源之道。

翻譯|胡燕君、賈川、程浩源

1

歸入Linux基金會

時至今日,PyTorch已“落地”Linux基金會,成為其主要專案之一。

Meta造就了PyTorch,後者的生態也為Meta帶來了巨大品牌價值。當PyTorch成為最流行的外部技術棧,Meta僱傭新員工時就不需要對其進行內部技術棧培訓,同時,許多硬體供應商從一開始就支援PyTorch,所以當Meta購買新硬體時可以有更多選擇,也無需等待硬體與Meta內部軟體棧進行整合。

如今,PyTorch歸入Linux基金會後也會給生態中的大型企業帶來好處。畢竟,企業在投資某一項技術時需要考慮許多因素,比如,競爭對手是否也在開發這項技術,還有地緣政治等因素。

過去的三年裡,Microsoft、Amazon和Google一直在為PyTorch做貢獻,即便Google的TensorFlow是PyTorch的競爭對手。大約一年半前,Microsoft執行長Satya Nadella在演講中公開表示,Microsoft十分喜歡並且正在大力投資PyTorch。

不過,新的治理結構將保證PyTorch在技術方面不會被某一家企業左右。未來,PyTorch各個部分和模組的維護人員將保持不變。在PyTorch專案中,擁有程式碼提交許可權的只有個人而非任何公司。

2

PyTorch的開源旅程

回顧PyTorch的開源之路,從一開始,我們就想做符合個人興趣的事,在開源方面尤其如此。

大多數開源專案不只是從“我們需要擁有10000名使用者”開始的,那沒有意義,開源歷程實際上要更加充滿活力。

通常,我們試圖將它與更廣泛的興趣或需求相聯絡。只有當許多想要共度光陰的人都感興趣時,想法和專案才會自然地成長。也有極少數例外,例如巨頭企業會推出具有龐大營銷計劃的自上而下的產品。

大多數小型開源專案,經過足夠地努力和投入後,都會考慮增長問題。那時,他們已經確定了核心利益和理念,這是他們的技術和文化底蘊的基礎。接下來,他們想知道他們是否正在盡其所能來銷售、營銷和發展這個專案。

PyTorch的發展至今,我認為在理念/原則、眼界和風險、衡量指標、專案擴張這四方面的認知和實踐發揮了很大作用。

理念/原則

當我們考量一個專案時,它可能是一個以技術為中心的專案,比如試圖宣揚多面體(polyhederal)優化思想的Tensor Comprehensions,或者一個像Torch-7這樣以使用者為中心的專案,它宣揚的是易用性思想,無需關心哪些技術或思想而只追求可以讓你輕鬆使用。

2010/2011年左右,我開始參與Torch的開發。隨著時間的推移,我在Torch社群交到了朋友,理解了他們作為一個整體所代表的隱含原則。開源,就像政治一樣,在關係和原則方面可能非常不明確——並非每個人都支援同一件事。

因此,多年來,我開始理解並欣賞Torch是一款以使用者為中心的產品,它具有即時模式、易於除錯、清晰明瞭。它的目標使用者是一些較為熟悉程式設計問題的人,他們能夠理解效能等問題,如果需要的話,還可以寫一個C函式並快速與之繫結。

當我們編寫PyTorch時,我意識到在一個有活力的開源社群中,並不是每個人都支援同一個原則。Torch社群中有幾個非常重要的成員反對支援Python,儘管我們以使用者為中心的觀點允許我們朝著這個方向前進。然後,我們必須做出推動他們向前走還是丟下他們的決定。這些都是艱難的決定,因為沒有正確的答案,領導者必須迅速地做出主觀判斷。

在這種情況下,值得思考何時保持強勢,何時妥協。我的觀點是,你必須固執地堅守你的原則/理念,但其他事情都是可以做出改變的。

這個觀點對推動人們向前走非常有用。隨著時間的推移,PyTorch整合了Caffe2社群和Chainer 社群,並從一開始就與Jax和Swift4TF保持友好關係。推動其他人向前走有巨大的優勢。當社群變得更大,你無疑會得到更廣闊的視野,而專案也會變得更好、更開闊。如果你對核心原則固執己見,那你並沒有背離初心,而只是讓它變得更好。

眼界和風險

除了推動Torch社群發展這一挑戰外,我們面臨的第二個挑戰是,當時最強大的競爭對手TensorFlow據說擁有比我們多10到30倍的開發者。不過,對我們來說真正的好處是,TensorFlow正在努力為所有人提供所有能力。從我們的視角看,這是一個自上而下的計劃性專案,擁有大量資源和廣度。

因此,我們自然而然嘗試採取完全相反的方法,主要是為了在實際條件下求生存以及進行競爭。我們決定,除了關注ML研究人員,讓他們的生活變得美好,我們不會分散注意力到其他任何人。這樣,我們就可以保持專注並以更少的資源交付任務。我們有意縮小範圍,因此承擔了目標使用者比較聚焦帶來的垂直市場風險,但減輕了目標使用者比較寬泛帶來的平行市場風險。但我們只想鎖定目標市場。

然而,一旦PyTorch在垂直市場取得成功,我們的野心就會越來越大。隨著我們不斷成長、成熟,我們慢慢地、漸進性地擴大了視野和雄心。

我們對ML研究人員市場進行了深思熟慮的押注:他們在未來幾年的建模需要更多的靈活性和可除錯性,ML研究人員市場將繼續在更瘋狂的模型架構上進行創新,這將成為未來的主流。

有了這個賭注,我們需要一個結合使用者體驗的非常廣泛的API ,能幫助使用者真正輕鬆地使用和擴充套件該API。基於機器學習社群如何塑造它的未來,我們做出的這個賭注可能因數百萬個原因而失敗。例如,假設我們可能在十年內停止在ResNets上進行創新,那麼廣泛而大型的API需求就會過時,而未來將需要一個更垂直的專注於ResNets的庫(譯者注:這件事是不是正在Transformer上發生?)。

衡量指標

除了核心原則和視野外,我們還希望與客戶建立反饋機制,這是產品開發中的標準操作需求。然後,我們問自己要如何從各個維度去監測PyTorch:它們是否可衡量?它們是否可以很好地衡量?你應該衡量它們嗎?你如何處理不可衡量的區域?

在Torch時代,我們學到了很多關於人們如何喜歡衡量事物,以及其他人如何喜歡將衡量的比較結果奉為圭臬。例如微基準測試、Github標星數量、特徵對比圖表等。

當用戶在社群釋出了一些這樣的衡量指標和比較結果後,我們對其中一些衡量指標感到委屈、惱火。但是,我們從Torch的經驗中得到的認知是,我們要問自己,過早地衡量某些東西會對產品造成怎樣的負面影響。 儘管我們沒有寫衡量Torch的博文展示給競爭對手,但一直在努力優化這些衡量指標並對其做出反應,而不僅是專注於其他對使用者更重要的優先順序功能。

因此,當開發PyTorch時,我們很清楚兩件事:首先,我們的核心能力不是像速度或其他一些統計資料那樣可衡量的東西,但我們需要將靈活性、API設計和可除錯性作為重中之重,向絲滑般流暢的使用者體驗邁進。 沒什麼好的方法可以衡量這一點,我們必須真正適應這種模糊性,並且能夠主觀地不斷重新評估我們是否能夠做好工作的內部訊號。其次,我們相信,如果不對PyTorch的外部衡量指標做出反應,就可以專注於我們所關心的事情,即便這在短期內會造成使用者流失。

所以,在PyTorch的歷史上,我們從來沒有對速度基準或不相關的衡量標準(如Github標星數量)做出迴應。作為PyTorch的作者,我們還沒有提交MLPerf這樣的基準測試。這是經過深思熟慮的選擇,我們對自己的方法非常滿意。

當我作關於PyTorch的相關演講時,通常有人會問“與某框架相比,PyTorch的速度有多快?”即使我知道我們在給定的用例上一樣快或更快,我也會迴避掉這個問題,“PyTorch更靈活,可能在其他地方的效能快了不到 10%,試試PyTorch吧。”這給了我們一種令人難以置信的超能力——專注於核心競爭力,而不會被拖入我們所認為的那些衡量產品的簡單化看法——這是一種根本不重視PyTorch優勢的觀點。

我們謹慎依賴的指標是人們是否在使用PyTorch以及它與競品的相對使用情況,不是衡量Github標星數量或微基準效能的指標,而是衡量在框架中真正寫程式碼這一指標。因此,我們使用了 Github的全域性程式碼搜尋(for import torch和 stuff)和arxiv引用等指標,它們更準確地描述了是否有人真正使用了PyTorch,這無可爭辯。

然而,問題在於這些指標是滯後的。我們根本不能依靠它們來了解社群使用者的即時需求,因為它們大約有6個月的交付週期。

我們也沒有使用指標來嘗試估計使用者對其整體體驗,以及可除錯性和API易用性等方面的感受。但我們確實主觀地對它們進行了衡量......

在較小的視野內,我們所做的基本上是由我閱讀社群裡的全部資訊,包括Github Issues、論壇帖子、Slack訊息、推特帖子、Reddit和Hackernews的評論。是的,儘管有很多無效資訊,但也有很多非常有用的訊號。

這幫助我們很好地確定了任務的優先順序,我認為這是通過主觀判斷打磨產品的好方法。除我之外,幾乎所有的核心開發者都花了很多時間與使用者互動,因此通過非常模糊和主觀的要素,我們達成了很多共同理解的看法。然而,這種方法卻無法突破這一點挑戰。

專案擴張

隨著專案不斷擴張,在PyTorch開源的2年內,我認為自己每天閱讀社群資訊已經達到人類極限了。我會瀏覽大約500個Github的通知、大約50個論壇帖子、大量的slack活動和twitter/Reddit/HN上的活動。我想我每天工作了15個小時,一直覺得筋疲力盡,但實際上沒有做太多其他事情。我的直接想法顯然是把這個轉交給其他人,而我可以緩解一下倦怠感。

我的同事Edward Yang擁有我所沒有的超能力,他承接了這個工作,目的是首先觀察它,然後構建一個更好的過程來對它進行擴充套件。我從他做這件事中得到的一個很好的認知是,一旦達到一定的規模,你就不能瞄準所有事情,必須高度重視任務的優先順序,沒有其他辦法了,就得這樣。不能解決掉Github上的每個問題並不會讓你看起來很殘忍。

在擴張上要考慮的另一件事是,要垂直地整合還是平行地整合。2009年,AMD將他們的晶圓廠部門分拆成一家獨立公司,那時我覺得難以理解。

幾年後,我讀到的一篇文章認為,AMD這樣做是因為晶圓廠(後端)與設計師(前端)合作不佳,並且那裡的垂直整合弊大於利。相比之下,Apple的M1處理器及其神奇地快速實用速度歸功於令人難以置信的良好垂直擴充套件,軟體團隊能夠衡量Apple軟體生態系統中的瓶頸,並找到需要加速的關鍵低級別操作,並且該訊號一路轉換到硬體設計。我不知道這些理論是否正確,但我確實相信,垂直整合做得不好會帶來巨大開銷,做得好會帶來巨大的力量倍增效果,所以應該明智地選擇你要走的路。

在PyTorch上,我們垂直集成了軟體包,例如distributed,jit和quantization,它們需要更深入的垂直整合,因為它們與前端設計有很大的交集。我們將諸如torchvision或torchserve之類的軟體包轉移到它們自己的Github儲存庫中,因為它們不需要那麼多端到端的思想。

我認為,圍繞縱向與橫向整合的決策也嚴重依賴於構建這些事物的人之間的有效頻寬——無論他們在同一家公司內,他們是否在同一時區或同一物理空間,或者他們是否主要通過long-form非同步通訊進行交談——所有這些都定義了垂直整合是否可以有效執行。

另一個關於擴張的話題是不僅要發展專案本身,還要發展專案的生態系統。

正確的激勵措施很重要。從PyTorch開始,我們就希望根據人們是否有興趣使用PyTorch或為PyTorch做出貢獻,我們非常努力地消除其他型別的激勵措施。因此,很長一段時間,我們沒有提供任何獎品、獎金或其他經濟激勵措施來讓開發者使用PyTorch。

我們的觀點是,一旦引入經濟激勵措施,就會以不可逆轉的方式塑造社群文化。 即使是現在,我們有了更大的推廣預算,但除了每年一、兩次的黑客馬拉松大賽,我們都在努力控制這些推廣措施。

我們非常關心的另一個激勵措施是,確保我們給他人成長空間,而不是隻擴張我們自己的勢力範圍。 我們關心與幫助社群成長並率先去填補空白,只有在沒有其他人滿足這些需求的情況下,我們才會有意介入並自上而下地投入相應資源去解決問題。

3

Soumith參與開源的發端

我的整個職業生涯與開源緊密相關,參與開源是為了享受其中的樂趣並追求進步,我在開源領域的影響力幫我贏得了許多工作和晉升機會。

2010年,當我在紐約大學攻讀機器學習方向的碩士時,與自己共事的還有Yann LeCun(2018年圖靈獎得主)。當時,Yann LeCun的博士生Pierre Sermanet是我的導師。Pierre安排我研究一個行人檢測專案,該專案是EBLearn開源庫的一部分。EBLearn是一個面向物件的C++庫,裡面整合了各種機器學習模型,包括由多個異構模組組成的機器學習模型。

參與這個專案是我回饋開源社群的第一步,在印度上學時,我能學習的公開知識就來自那些免費的開源知識,一些有遠見卓識的人決定開源他們所掌握的技術,供更多人學習,這在當時比較少見。

不久後,實驗室迎來一位客人,他帶來了一個誘人的專案。Clement Farabet現在是NVIDIA AI基礎設施副總裁,當時他是Torch7專案的建立者之一,他想讓我試用一下。

Torch7是用Lua語言寫的,我試用後發現,Torch7框架的效率比EBLearn高出許多,而且在一些特定任務上的表現尤其出色。所以我直接選用了Torch7來完成我的NLP課程專案。

在Torch論壇上,我回答了使用者提出的所有問題,還給Torch開發人員傳送了Torch存在的問題和希望具備的功能。

我想集合更多人的力量來改進Torch7,但社群建立者Koray Kavukcuoglu(現DeepMind研究副總裁)和Ronan Collobert(當時就職於Facebook)正忙於各自的工作和生活,所以雖然他們創立了這個專案,但卻沒有時間來解決專案中不斷浮現的問題。

於是,我給他們發了一封郵件,大致內容如下:“你們審查PR的速度太慢,而且從來沒有回覆過問題。我真的很想幫助你們,所以基本上論壇上的問題我都做了回答。你們能在這個專案上多花點時間嗎?"

這大概是十年前的事。他們回覆了,問我想不想接手負責這個專案的維護,我答應了,畢竟我當時已經為這個專案做了很多實際的維護工作。在我接手之前,沒有人像我一樣為Torch7付出這麼多。

2012年,當我從紐約大學畢業時,我所擁有的只有一紙文憑和一個在維護的Torch社群。人工智慧市場還不像今天這樣火爆,我也曾一度找不到工作,需要別人的引薦。

2012年7月,我在MuseAmi公司找到了一份工作,工作內容是為移動裝置構建機器學習和視覺系統,但我對開源社群的貢獻引起了科技巨頭的注意。

如果你是開源社群的貢獻者,就有更多展現自己的機會。當我現在準備招聘人員擴大團隊時,也一定會考察候選人的開源貢獻,選擇那些在開源工作中展現出非凡能力的人。

從2013年開始,我成為Torch的官方維護人員,隨後我正式加入Facebook。從Torch到構建PyTorch的過程挺戲劇化的,當時我和幾名全職員工一起搭建Torch,包括構建新功能、處理已知issue、完善新的軟體堆疊、進行層升級等。通過解決專案中的問題,我深入地瞭解到使用者需要什麼。

Facebook是人工智慧領域三大研究公司之一,當時使用Torch的使用者有一千人左右,雖然仍只是一個小型社群,但比起我最初使用Torch時僅有20個使用者,顯然壯大了很多。

2015年末,Google Brain團隊開發的TensorFlow橫空出世。TensorFlow擁有世界級工程師,成熟的文件體系,還有真正的營銷部門、品牌部門等資源。相比由研究生們構建的Torch、Caffe和Theano框架,TensorFlow更像一個專業產品。

我曾像試用Torch一樣試用TensorFlow,想看看它是否可以成為Torch後續的發展方向。TensorFlow明顯和Theano的模型相似,可在其中用Python編寫一個符號化元程式,然後每個部分都在單獨的虛擬機器中進行編譯。編譯器必須非常強大,才能實現更有效的創新。但如果需要進行堆疊跟蹤,你將無法理解堆疊跟蹤報告,因為它不是純程式語言,它會形成另一個難以追蹤的通訊層,這會帶來麻煩。

在各種元件中,我們曾把指令碼語言置於首要關鍵問題,但這種想法是錯的。

我們團隊中大多數成員都認為我們需要重構Torch,但不是重走TensorFlow的路徑,而是要構建一種更現代、更可用、質量更高的產品,應在生產效率上有不同的側重。我們相信我們可以講述一個更好的產品故事。

PyTorch的模型非常簡單,沒有超程式設計。舉個例子,假設你在iPad的空白屏上用智慧筆寫字,而智慧筆可以將你所寫的內容翻譯成不同的程式或系統。所以你不僅要考慮寫的是什麼,還要考慮另一個系統如何解釋它,這會在抽象層面產生脫節。

我們做PyTorch時的想法是,只要構建了強大的基礎元件,並進行適當優化,那麼就不需要獨立的複雜引擎,人們只需要進行編碼,就可以使其快速執行。

我和大部分Torch社群的成員都認為,開發者的意圖必須得到保護,不能受框架的影響,這意味著要給程式設計師更多的權力。

PyTorch的建立者來自Torch社群。PyTorch原始論文的第一作者Adam Paszke當時在波蘭讀本科。他找到了我,說他正在找實習,問我有沒有實習渠道。我說我們空閒時一直在做PyTorch,你可以以實習生的身份加入我們。所以我、Adam還有Sam Gross(現任職於Meta)三個人開始全職開發PyTorch。此外還有18名成員,他們基本上都是在晚上哄孩子睡覺後,立即開啟電腦投入到PyTorch的研發工作中。就這樣,PyTorch誕生了。

想法決定方向,工具則是到達目的地的車輪。每隔幾年,行業就需要新的工具來探索未知的領域,所以我們必須不斷升級工具。

回頭來看,我為PyTorch制定的路線非常務實。我相信科學的發展是有機的,產品如何發展取決於行業的方向。現在,人工智慧行業發展迅速,行業所需理想工具的特點也不斷變化。我相信,這個行業每隔五六年就會需要一種新的工具。

自2012年以來AI一直高速發展,我感到非常高興。過去每隔三年就有人說AI行業不行了,但事實證明這都沒有發生。我認為,起碼在未來三到五年內,AI的發展都不會放緩,我們也將繼續為AI行業出力。

(來源:1. https://soumith.ch/posts/2021/02/growing-opensource/;

2.https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5jYXB0aXZhdGUuZm0vdW50b2xkLXN0b3JpZXMtb2Ytb3Blbi1zb3VyY2U?sa=X&ved=0CAMQ4aUDahcKEwiYpP65tYX6AhUAAAAAHQAAAAAQAQ)

歡迎下載體驗 OneFlow v0.8.0 最新版本:
https://github.com/Oneflow-Inc/oneflow/