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 也遵循這一發展規律。

PyTorch 的理念 & 原則

當考慮一個項目時，它可能是以技術為中心的項目，比如對張量的理解，又比如以用戶為中心（例如 Torch-7）的項目，它們傳播的是易用性理念，而不關心什么技術或想法能讓研究者更容易使用。

我在 2010/2011 年開始與 Torch 合作，并在 Torch 社區交了許多朋友，理解了他們作為一個整體所代表的隱含原則，和政治一樣，開源在關系和原則上的定義是相當模糊的。

因此，多年來，我逐漸理解并欣賞到 Torch 是一款以用戶為中心的產品，它具有即時模式、易于調試、不受影響等特性。Torch 的目標用戶是一些熟悉編程的人，這些用戶能夠理解性能等問題，可以根據工作需要，他們能夠編寫一個 C 函數并快速地將其綁定進去。

當我們編寫 PyTorch 程序時，我意識到在一個有機的開源社區中，并不是每個人都支持相同的原則。我們在 Torch 社區中有一些非常重要的成員反對 Python，盡管我們以用戶為中心的觀點允許我們朝著這個方向前進。然后，我們必須做出決定是帶他們一起發展還是把他們留下。這些都是困難的決定，因為沒有正確的答案，只能領導者必須迅速做出的主觀判斷。

在這種情況下應該思考什么時候保持固執，什么時候保持妥協。我的觀點是，你必選在理念、原則上保持固執，但其他一切都是可以改變的。

這一觀點非常有用，隨著時間的推移，PyTorch 帶來并集成了 Caffe2 社區和 Chainer 社區，并與 Jax 和 Swift4TF 保持友好關系。PyTorch 社區變得越來越大，在這個社區中你可以得到更廣闊的視角，隨著時間的推移，這些視角會使項目變得越來越好。如果你堅持自己的核心原則，你就不會真的在你最初的愿景上妥協，只會讓它變得更好。

PyTorch 的范圍 & 風險

推動 Torch 社區發展是一個挑戰，除此以外，面臨的另一個挑戰是 TensorFlow ，據了解 TensorFlow 擁有比 PyTorch 多 10 到 30 倍的開發人員。不過，TensorFlow 正在努力為所有人提供便利，這對 PyTorch 研究者來說是非常有益的。此外，TensorFlow 是一個自上而下計劃的項目，需要大量的資源。

所以，我們很自然地采取了完全相反的方法，主要是為了在現實的條件下生存和競爭。我們決定，除了 ML 研究人員，我們不關注任何人。這樣，我們就可以集中精力，用更少的資源完成任務。我們有意縮小范圍，因此承擔了更多的垂直風險，但同時減少了水平風險。我們只是想確定我們的潛在市場。

然而，一旦我們用 PyTorch 在該市場取得成功，我們的野心就變大了。隨著我們的成長和成熟，我們漸進地擴大了范圍和抱負，這接近于規模化。

在這里，介紹一下需要承擔的風險，以及它的影響。我們在 ML 研究市場上做了一個賭注：

• 他們在未來幾年所做的建模將需要更多的靈活性和可調試性；
• ML 研究市場將繼續在更先進的模型架構上進行創新，它將成為未來的主流。

因此，有了這個賭注，我們需要一個非常廣泛的 API 結合用戶體驗，以真正輕松地使用和擴展該 API。基于 ML 社區如何塑造它的未來，我們所做的這個賭注可能無法實現，原因有很多。

在我的演講中，你可以聽到我對這個主題的更多看法，以及我對未來 ML 框架的看法。

PyTorch 的度量指標

除了核心原則和范圍外，我們還希望與客戶建立反饋回路，這是產品開發的標準操作需求。然后，我們從不同維度對如何跟蹤 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 的擴展

隨著項目的擴展，我認為在 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。

即使是現在，即使我們的項目有了更多預算，但是除了每年一兩次的黑客馬拉松比賽，我們并不會在這方面投入太多。我們非常關心的另一個激勵因素是為其他人提供更大的發展空間，而不是自己包辦一切。我們會著力幫助社區成長，并首先填補一些空白，只有當沒人能夠滿足一些需求時，我們才會介入并自上而下投入時間和精力解決問題。