眾所周知，深度學習框架 PyTorch 的前身是 Torch，從 Torch 發展到 PyTorch，創建團隊都做了哪些努力，又遇到了哪些挑戰呢？在近日結束的 JuliaCon 2021 活動中，PyTorch 創始人 Soumith Chintala 做了 Keynote 演講，分享了一路走來的成長曆程和經驗教訓。
PyTorch 是深度學習領域最受歡迎的框架之一，初始版本於 2016 年 9 月由 Adam Paszke、Sam Gross、Soumith Chintala 等人創建，並於 2017 年在 GitHub 上開源。PyTorch 很簡潔、易於使用、支援動態計算圖而且記憶體使用很高效，因此越來越受開發者的喜愛。
7 月 28 日 - 30 日，JuliaCon 2021 線上活動順利召開。在 7 月 30 日的 Single Track 活動環節，活動主辦方邀請到了 FAIR 研究工程師、深度學習框架 PyTorch 創建者之一 Soumith Chintala。目前，他的研究興趣集中於計算機視覺、機器人和機器學習系統。
在他的 Keynote 演講中，Soumith Chintala 回顧了自己從 Torch 發展至 PyTorch 的心路歷程，以及對開源社群的看法。他從以下幾個方面進行了闡述：
在正式進入到演講主題之前，Soumith Chintala 闡述了他對開源項目的看法，表示大多數開源項目並不僅僅是從「我們需要擁有 1 萬名使用者」這種預期開始的。這種預期沒有意義，開源之旅應該更純粹並充滿活力。
在開源領域，我們一開始是基於個人興趣來做事情的。通常來講，只有當很多人都對某些想法和項目感興趣並願意付出時間時，它們才會自然地成長。
此外，就開源項目的發展規律而言，大多數小型開源項目在經過足夠的努力和參與後，都會考慮發展壯大。那時，項目參與者已經確定了他們的核心興趣和理念，這也是技術和文化堆棧的基礎。接下來，他們就會竭盡所能營銷並擴展自己的開源項目。從 Torch 到 PyTorch 也遵循這一發展規律。
當考慮一個項目時，它可能是以技術為中心的項目，比如對張量的理解，又比如以使用者為中心（例如 Torch-7）的項目，它們傳播的是易用性理念，而不關心什麼技術或想法能讓研究者更容易使用。
我在 2010/2011 年開始與 Torch 合作，並在 Torch 社群交了許多朋友，理解了他們作為一個整體所代表的隱含原則，和政治一樣，開源在關係和原則上的定義是相當模糊的。
因此，多年來，我逐漸理解並欣賞到 Torch 是一款以使用者為中心的產品，它具有即時模式、易於偵錯、不受影響等特性。Torch 的目標使用者是一些熟悉程式設計的人，這些使用者能夠理解效能等問題，可以根據工作需要，他們能夠編寫一個 C 函數並快速地將其繫結進去。
當我們編寫 PyTorch 程式時，我意識到在一個有機的開源社群中，並不是每個人都支援相同的原則。我們在 Torch 社群中有一些非常重要的成員反對 Python，儘管我們以使用者為中心的觀點允許我們朝著這個方向前進。然後，我們必須做出決定是帶他們一起發展還是把他們留下。這些都是困難的決定，因為沒有正確的答案，只能領導者必須迅速做出的主觀判斷。
在這種情況下應該思考什麼時候保持固執，什麼時候保持妥協。我的觀點是，你必選在理念、原則上保持固執，但其他一切都是可以改變的。
這一觀點非常有用，隨著時間的推移，PyTorch 帶來並集成了 Caffe2 社群和 Chainer 社群，並與 Jax 和 Swift4TF 保持友好關係。PyTorch 社群變得越來越大，在這個社群中你可以得到更廣闊的視角，隨著時間的推移，這些視角會使項目變得越來越好。如果你堅持自己的核心原則，你就不會真的在你最初的願景上妥協，只會讓它變得更好。
推動 Torch 社群發展是一個挑戰，除此以外，面臨的另一個挑戰是 TensorFlow ，據瞭解 TensorFlow 擁有比 PyTorch 多 10 到 30 倍的開發人員。不過，TensorFlow 正在努力為所有人提供便利，這對 PyTorch 研究者來說是非常有益的。此外，TensorFlow 是一個自上而下計劃的項目，需要大量的資源。
所以，我們很自然地採取了完全相反的方法，主要是為了在現實的條件下生存和競爭。我們決定，除了 ML 研究人員，我們不關注任何人。這樣，我們就可以集中精力，用更少的資源完成任務。我們有意縮小範圍，因此承擔了更多的垂直風險，但同時減少了水平風險。我們只是想確定我們的潛在市場。
然而，一旦我們用 PyTorch 在該市場取得成功，我們的野心就變大了。隨著我們的成長和成熟，我們漸進地擴大了範圍和抱負，這接近於規模化。
在這裡，介紹一下需要承擔的風險，以及它的影響。我們在 ML 研究市場上做了一個賭注：
因此，有了這個賭注，我們需要一個非常廣泛的 API 結合使用者體驗，以真正輕鬆地使用和擴展該 API。基於 ML 社群如何塑造它的未來，我們所做的這個賭注可能無法實現，原因有很多。
在我的演講中，你可以聽到我對這個主題的更多看法，以及我對未來 ML 框架的看法。
除了核心原則和範圍外，我們還希望與客戶建立反饋迴路，這是產品開發的標準操作需求。然後，我們從不同維度對如何跟蹤 PyTorch 進行了總結：
它們是可度量的嗎？
是否可以很好的進行度量？
你應該度量嗎？
如何處理不可度量的區域？
在我們的 Torch 時代，我們學到了很多關於人們如何喜歡度量事物。例如微基準、GitHub star 量、特徵對比表等。當人們在社群釋出了一些這樣的度量和比較之後，我們不贊同其中的一些測量。但是我們從 Torch 中得到經驗是過早地度量會對產品造成負面影響。儘管我們並沒有把度量 Torch 的部落格文章寫給競爭對手，但我們一直在努力優化這些度量結果，並對它們做出反應，而不是專注於其他更重要的使用者優先事項。
所以，當我們編寫 PyTorch 時，需要明白兩件事：第一，我們的核心競爭力不是像速度或其他資料那樣可以度量的東西，而是我們需要向流暢的使用者體驗邁進，將靈活性、API 設計和可偵錯性作為首要任務；其次，我們相信，如果我們不對 PyTorch 的外部度量做出反應，我們就可以專注於我們所關心的東西，即使這會造成短期的變動。
因此，在 PyTorch 的發展過程中，我們從未對速度基準或者 GitHub star 量等不相關的度量指標做出迴應。作為 PyTorch 的創建者，我們從未提交至 MLPerf 等行業基準。這是經過深思熟慮的，我們對此做法感到滿意。在做 PyTorch 相關的演講時，常碰到有人問：「與 X 相比，PyTorch 的速度有多快？」即使我知道 PyTorch 在給定用例上能夠達到相同甚至更快的速度，但我只會這樣回答：「PyTorch 更靈活，試試吧。」這使得我們專注於自己的核心競爭力。
我們勉強依賴的指標是開發者是否在使用 PyTorch 以及競品框架的使用情況。我們倚重的指標不是 GitHub star 量或者微基準上的效能等，而是 PyTorch 實際編寫程式碼的體驗。所以，我們採用的度量指標有 GitHub 的全局程式碼搜尋和 arXiv 引用等，這種做法更準確地獲知開發者是否使用 PyTorch。
我們勉強依賴的指標是開發者是否在使用 PyTorch 以及它與我們的競爭對手的相對使用。不是衡量書籤（如 github 星）或微基準效能的指標——而是實際在其中編寫程式碼。因此，我們使用了 Github 的全局程式碼搜尋（用於匯入 torch 和其他東西）和 arxiv 引用等指標，它們可以更準確地描述是否有人真正使用過我們，沒有歧義。
然而，問題在於這些是滯後的指標。我們根本不能依靠它們來了解社群的即時需求，因為交付週期很長，大約為 6 個月。
我們也沒有使用指標來嘗試近似使用者對其整體體驗以及可偵錯性和 API 易用性等方面的感受，但確實從主觀上衡量了這些方法…
在較小的範圍內，我所做的基本上是閱讀社群產生的全部資訊，比如 GitHub 問題、論壇帖子、slack 訊息、twitter 帖子以及 reddit 和 hackernews 評論等。這些都是非常有用的訊號，雖然也充斥著很多不和諧的聲音，但也可以從中瞭解使用者的一些想法。這些指標幫助我們很好地確定了優先順序，並且我認為這是從主觀層面塑造自身產品的好方法。
除了我之外，幾乎所有的核心開發者都花了很多時間與使用者進行互動，因此我們從非常模糊和主觀的視角達成了大量的共同理解。然而，這種方法並沒有超出一個點。
隨著項目的擴展，我認為在 PyTorch 推出的兩年時間裡，自己每天的工作已經達到了人體極限。我要在 twitter、Reddit 和 Hacenews 上瀏覽 500 條左右的 GitHub 通知、50 篇左右的論壇帖子、大量的 slack 活動和很多其他的參與。我覺得自己每天工作 15 個小時，每時每刻都筋疲力盡，但實際上並沒有做太多事情。因此，我想直接將這些繁瑣的工作交給其他更盡力且做得更好的人，這樣我就解脫了。
之後，我的同事 Edward Yang 擁有我沒有的超能力，他接管了整個工作流程，並打算先進行觀察，然後再創建了一個更好的擴展流程。2021 年 1 月，他撰寫了一篇精彩的部落格文章《The PyTorch Ppen Source Process》。我從他做這些事情中學到了一點，即當你達到一定的規模，就無法顧全所有事情，必須有明確的優先順序。
部落格地址：http://blog.ezyang.com/2021/01/pytorch-open-source-process/
在項目規模上需要考慮的另外一件事情是進行垂直整合還是水平整合。在 PyTorch 項目上，我們集成了 distributed、jit 和 quantization 包，這些包需要更深的垂直整合，因為它們與前端設計具有很深的交集。我們還將 torchvision 或 torchserve 等包分支到了各自的 GitHub 庫中，因為它們不需要很多的端到端思考。
最後想談一談生態系統的問題。從 PyTorch 開始，我們希望開發者使用 PyTorch 並向該項目做出貢獻，由此發展社群。在整個過程中，我們竭力避免任何形式的激勵措施。因此，在很長一段時間裡，我們沒有提供任何獎品、獎金或其他經濟獎勵措施來鼓勵研究者使用 PyTorch。我們的觀點是，一旦引入經濟激勵措施，就會以一種不可逆轉的方式塑造社群文化。
截止 2020 年底，PyTorch 項目的貢獻者大約 1626 人、下游項目 45k + 個，PyTorch 論壇使用者達到了 34k。
即使是現在，即使我們的項目有了更多預算，但是除了每年一兩次的黑客馬拉松比賽，我們並不會在這方面投入太多。我們非常關心的另一個激勵因素是為其他人提供更大的發展空間，而不是自己包辦一切。我們會著力幫助社群成長，並首先填補一些空白，只有當沒人能夠滿足一些需求時，我們才會介入並自上而下投入時間和精力解決問題。
