PyTorch 是深度學(xué)習(xí)領(lǐng)域最受歡迎的框架之一，初始版本于 2016 年 9 月由 Adam Paszke、Sam Gross、Soumith Chintala 等人創(chuàng)建，并于 2017 年在 GitHub 上開源。PyTorch 很簡潔、易于使用、支持動態(tài)計算圖而且內(nèi)存使用很高效，因此越來越受開發(fā)者的喜愛。

7 月 28 日 - 30 日，JuliaCon 2021 線上活動順利召開。在 7 月 30 日的 Single Track 活動環(huán)節(jié)，活動主辦方邀請到了 FAIR 研究工程師、深度學(xué)習(xí)框架 PyTorch 創(chuàng)建者之一 Soumith Chintala。目前，他的研究興趣集中于計算機(jī)視覺、機(jī)器人和機(jī)器學(xué)習(xí)系統(tǒng)。

在他的 Keynote 演講中，Soumith Chintala 回顧了自己從 Torch 發(fā)展至 PyTorch 的心路歷程，以及對開源社區(qū)的看法。他從以下幾個方面進(jìn)行了闡述：

• 理念原則
• 范圍 & 風(fēng)險
• 度量指標(biāo)
• 項(xiàng)目的擴(kuò)展

在正式進(jìn)入到演講主題之前，Soumith Chintala 闡述了他對開源項(xiàng)目的看法，表示大多數(shù)開源項(xiàng)目并不僅僅是從「我們需要擁有 1 萬名用戶」這種預(yù)期開始的。這種預(yù)期沒有意義，開源之旅應(yīng)該更純粹并充滿活力。

在開源領(lǐng)域，我們一開始是基于個人興趣來做事情的。通常來講，只有當(dāng)很多人都對某些想法和項(xiàng)目感興趣并愿意付出時間時，它們才會自然地成長。

此外，就開源項(xiàng)目的發(fā)展規(guī)律而言，大多數(shù)小型開源項(xiàng)目在經(jīng)過足夠的努力和參與后，都會考慮發(fā)展壯大。那時，項(xiàng)目參與者已經(jīng)確定了他們的核心興趣和理念，這也是技術(shù)和文化堆棧的基礎(chǔ)。接下來，他們就會竭盡所能營銷并擴(kuò)展自己的開源項(xiàng)目。從 Torch 到 PyTorch 也遵循這一發(fā)展規(guī)律。

PyTorch 的理念 & 原則

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

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

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

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

在這種情況下應(yīng)該思考什么時候保持固執(zhí)，什么時候保持妥協(xié)。我的觀點(diǎn)是，你必選在理念、原則上保持固執(zhí)，但其他一切都是可以改變的。

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

PyTorch 的范圍 & 風(fēng)險

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

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

然而，一旦我們用 PyTorch 在該市場取得成功，我們的野心就變大了。隨著我們的成長和成熟，我們漸進(jìn)地擴(kuò)大了范圍和抱負(fù)，這接近于規(guī)?；?。

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

• 他們在未來幾年所做的建模將需要更多的靈活性和可調(diào)試性；
• ML 研究市場將繼續(xù)在更先進(jìn)的模型架構(gòu)上進(jìn)行創(chuàng)新，它將成為未來的主流。

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

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

PyTorch 的度量指標(biāo)

除了核心原則和范圍外，我們還希望與客戶建立反饋回路，這是產(chǎn)品開發(fā)的標(biāo)準(zhǔn)操作需求。然后，我們從不同維度對如何跟蹤 PyTorch 進(jìn)行了總結(jié)：

• 它們是可度量的嗎？
• 是否可以很好的進(jìn)行度量？
• 你應(yīng)該度量嗎？
• 如何處理不可度量的區(qū)域？

在我們的 Torch 時代，我們學(xué)到了很多關(guān)于人們?nèi)绾蜗矚g度量事物。例如微基準(zhǔn)、GitHub star 量、特征對比表等。當(dāng)人們在社區(qū)發(fā)布了一些這樣的度量和比較之后，我們不贊同其中的一些測量。但是我們從 Torch 中得到經(jīng)驗(yàn)是過早地度量會對產(chǎn)品造成負(fù)面影響。盡管我們并沒有把度量 Torch 的博客文章寫給競爭對手，但我們一直在努力優(yōu)化這些度量結(jié)果，并對它們做出反應(yīng)，而不是專注于其他更重要的用戶優(yōu)先事項(xiàng)。

所以，當(dāng)我們編寫 PyTorch 時，需要明白兩件事：第一，我們的核心競爭力不是像速度或其他數(shù)據(jù)那樣可以度量的東西，而是我們需要向流暢的用戶體驗(yàn)邁進(jìn)，將靈活性、API 設(shè)計和可調(diào)試性作為首要任務(wù)；其次，我們相信，如果我們不對 PyTorch 的外部度量做出反應(yīng)，我們就可以專注于我們所關(guān)心的東西，即使這會造成短期的變動。

因此，在 PyTorch 的發(fā)展過程中，我們從未對速度基準(zhǔn)或者 GitHub star 量等不相關(guān)的度量指標(biāo)做出回應(yīng)。作為 PyTorch 的創(chuàng)建者，我們從未提交至 MLPerf 等行業(yè)基準(zhǔn)。這是經(jīng)過深思熟慮的，我們對此做法感到滿意。在做 PyTorch 相關(guān)的演講時，常碰到有人問：「與 X 相比，PyTorch 的速度有多快？」即使我知道 PyTorch 在給定用例上能夠達(dá)到相同甚至更快的速度，但我只會這樣回答：「PyTorch 更靈活，試試吧。」這使得我們專注于自己的核心競爭力。

我們勉強(qiáng)依賴的指標(biāo)是開發(fā)者是否在使用 PyTorch 以及競品框架的使用情況。我們倚重的指標(biāo)不是 GitHub star 量或者微基準(zhǔn)上的性能等，而是 PyTorch 實(shí)際編寫代碼的體驗(yàn)。所以，我們采用的度量指標(biāo)有 GitHub 的全局代碼搜索和 arXiv 引用等，這種做法更準(zhǔn)確地獲知開發(fā)者是否使用 PyTorch。

我們勉強(qiáng)依賴的指標(biāo)是開發(fā)者是否在使用 PyTorch 以及它與我們的競爭對手的相對使用。不是衡量書簽（如 github 星）或微基準(zhǔn)性能的指標(biāo)——而是實(shí)際在其中編寫代碼。因此，我們使用了 Github 的全局代碼搜索（用于導(dǎo)入 torch 和其他東西）和 arxiv 引用等指標(biāo)，它們可以更準(zhǔn)確地描述是否有人真正使用過我們，沒有歧義。

然而，問題在于這些是滯后的指標(biāo)。我們根本不能依靠它們來了解社區(qū)的即時需求，因?yàn)榻桓吨芷诤荛L，大約為 6 個月。

我們也沒有使用指標(biāo)來嘗試近似用戶對其整體體驗(yàn)以及可調(diào)試性和 API 易用性等方面的感受，但確實(shí)從主觀上衡量了這些方法…

在較小的范圍內(nèi)，我所做的基本上是閱讀社區(qū)產(chǎn)生的全部信息，比如 GitHub 問題、論壇帖子、slack 消息、twitter 帖子以及 reddit 和 hackernews 評論等。這些都是非常有用的信號，雖然也充斥著很多不和諧的聲音，但也可以從中了解用戶的一些想法。這些指標(biāo)幫助我們很好地確定了優(yōu)先級，并且我認(rèn)為這是從主觀層面塑造自身產(chǎn)品的好方法。

除了我之外，幾乎所有的核心開發(fā)者都花了很多時間與用戶進(jìn)行互動，因此我們從非常模糊和主觀的視角達(dá)成了大量的共同理解。然而，這種方法并沒有超出一個點(diǎn)。

PyTorch 的擴(kuò)展

隨著項(xiàng)目的擴(kuò)展，我認(rèn)為在 PyTorch 推出的兩年時間里，自己每天的工作已經(jīng)達(dá)到了人體極限。我要在 twitter、Reddit 和 Hacenews 上瀏覽 500 條左右的 GitHub 通知、50 篇左右的論壇帖子、大量的 slack 活動和很多其他的參與。我覺得自己每天工作 15 個小時，每時每刻都筋疲力盡，但實(shí)際上并沒有做太多事情。因此，我想直接將這些繁瑣的工作交給其他更盡力且做得更好的人，這樣我就解脫了。

之后，我的同事 Edward Yang 擁有我沒有的超能力，他接管了整個工作流程，并打算先進(jìn)行觀察，然后再創(chuàng)建了一個更好的擴(kuò)展流程。2021 年 1 月，他撰寫了一篇精彩的博客文章《The PyTorch Ppen Source Process》。我從他做這些事情中學(xué)到了一點(diǎn)，即當(dāng)你達(dá)到一定的規(guī)模，就無法顧全所有事情，必須有明確的優(yōu)先級。

博客地址：http://blog.ezyang.com/2021/01/pytorch-open-source-process/

在項(xiàng)目規(guī)模上需要考慮的另外一件事情是進(jìn)行垂直整合還是水平整合。在 PyTorch 項(xiàng)目上，我們集成了 distributed、jit 和 quantization 包，這些包需要更深的垂直集成，因?yàn)樗鼈兣c前端設(shè)計具有很深的交集。我們還將 torchvision 或 torchserve 等包分支到了各自的 GitHub 庫中，因?yàn)樗鼈儾恍枰芏嗟亩说蕉怂伎肌?/p>

最后想談一談生態(tài)系統(tǒng)的問題。從 PyTorch 開始，我們希望開發(fā)者使用 PyTorch 并向該項(xiàng)目做出貢獻(xiàn)，由此發(fā)展社區(qū)。在整個過程中，我們竭力避免任何形式的激勵措施。因此，在很長一段時間里，我們沒有提供任何獎品、獎金或其他經(jīng)濟(jì)獎勵措施來鼓勵研究者使用 PyTorch。我們的觀點(diǎn)是，一旦引入經(jīng)濟(jì)激勵措施，就會以一種不可逆轉(zhuǎn)的方式塑造社區(qū)文化。

截止 2020 年底，PyTorch 項(xiàng)目的貢獻(xiàn)者大約 1626 人、下游項(xiàng)目 45k + 個，PyTorch 論壇用戶達(dá)到了 34k。

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