# 拉賈特·蒙加：TensorFlow > TensorFlow 負責人講述這一框架的誕生背景、工程架構與大規模機器學習系統的構建經驗。 - 原標題：Rajat Monga: TensorFlow - 期數：特別節目 - 釋出日期：2019-06-03 - 嘉賓 / 主題：拉賈特·蒙加與 TensorFlow - 網頁版：https://lex.qiaomu.ai/tw/ep/rajat-monga/ - 官方頁面：https://lexfridman.com/rajat-monga/ - 精讀字數：約 6602 字（閱讀約 15 分鐘） > 本文為 lex.qiaomu.ai 基於原始訪談的 AI 改寫中文精讀，非官方翻譯；引用請註明出處並連結網頁版。 2015 年 11 月，Google 把內部最核心的機器學習系統連同大量工程積累一起放到了 GitHub 上。一家市值數千億美元的公司，把自家最難被複制的技術免費送出去，當時在矽谷幾乎找不到第二個案例。 推動這個決定的人之一是 Rajat Monga。他從 2011 年 Google Brain 成立時就在場，後來負責領導 TensorFlow 團隊，把一套內部系統變成了今天這個橫跨雲端、手機、瀏覽器的生態。在這場對話裡，他談到了那個開源決策的完整邏輯、TensorFlow 2.0 背後的權衡，以及一個很多人好奇的問題：Google 到底圖什麼？ ## 最初的目標只有一個：把算力堆上去，看效果會不會變好 Google Brain 成立的第一年，目標單純得近乎樸素。Rajat 說，當時要驗證的命題就是一句話：擴大算力、擴大資料規模，模型表現會不會隨之提升。 這句話現在聽起來像常識，2011 年可完全不是。深度學習的潛力還沒被廣泛認可，學術界有興趣，但談不上狂熱。Google 手裡同時握著兩樣別人沒有的東西，超大規模通用算力和海量資料。Andrew Ng 和 Jeff Dean 想做的，就是把這兩樣東西跟深度學習的研究接上，看看會發生什麼。 答案來得比預想快。Rajat 提到兩個早期成果。語音識別是一塊，團隊跟 Google 語音研究組緊密合作，把神經網路塞進了實際系統。影象是另一塊，就是那篇被大量引用的論文，用大規模無監督學習訓練出能識別貓的網路。 > 第一年我們就拿到了一些早期的勝利，這總是好事。（Rajat Monga） 勝利之後是規模上的狂飆。從幾十臺機器到幾百臺，再到上千臺。Rajat 說，他們甚至跑過規模達到一萬臺機器的訓練任務。這些實驗證明了一件事：在 Google 的體量下，深度學習不但跑得動，還會切實影響一批產品。 語音是第一個，圖片是第二個，然後是相簿，再往後是更多產品線。 **到了 2014 年，外部環境也變了。**學術界開始大規模討論深度學習，熱情和方向都在快速升溫，雖然資源和資料仍然跟不上大公司。Rajat 說，團隊意識到這件事不會只發生在 Google 內部。Google 也許暫時領先，但要做的事情太多，一家公司做不完。 ## 開源那個決定，背後有一段 Hadoop 的教訓 2014 年夏天，TensorFlow 的前身 DistBelief 開始重構。到當年年底，團隊已經基本確定要走開源這條路，於是從一開始就按開源的假設去做設計。 Rajat 說這個想法最早來自 Jeff Dean，支撐它的邏輯有兩層。 研究層面很直接。Google Brain 本身就是研究組織，研究成果要發表，要推動整個領域往前走。深度學習之所以發展這麼快，很大程度上就是因為大家願意分享。軟體是研究的載體，軟體自然也該分享。 工程層面的邏輯更值得說。Rajat 講了一段很多人不知道的歷史。Google 內部做過很多優秀系統，也發表過論文，但後續的故事往往是這樣：有人拿著論文自己實現了一套，做得還行，然後這套東西就成了行業標準。Hadoop 是最典型的例子，它脫胎於 Google 發表的 GFS 和 MapReduce 論文，實現水平卻遠不如 Google 內部的版本。 結果就是一個尷尬的局面。Google 手裡握著更好的技術，卻不得不為別人實現的、質量差一截的系統提供相容 API。 > 我們想，能不能做出更好的東西，真正幫到社群，同時也推動一個好的標準往前走。（Rajat Monga） 這個判斷的分量在於它承認了一個殘酷現實：在基礎設施領域，贏家往往由使用人數決定，技術優劣排在後面。與其讓一個更差的實現成為事實標準，不如自己把最好的實現拿出來，讓它成為標準。 2015 年 11 月，TensorFlow 正式開源。這件事後來被很多人視為軟體工程史上的一個分水嶺：一家大公司主動把包含大量智慧財產權的核心專案開放出來，等於向全世界宣佈，開放創新這條路走得通。 ## 選擇計算圖的理由，和 PyTorch 逼出來的 Eager Execution 設計 TensorFlow 時，團隊做過一個關鍵決定：用計算圖表達模型。 這個選擇在當時幾乎順理成章。DistBelief 本身就有類似圖的結構，只不過更接近一條直線，不像 TensorFlow 那樣是通用圖。更重要的原因在 Google 一直很在意的生產環境，即便在 DistBelief 時期，也有大量模型跑在實際業務裡。 設計過程中，團隊確實試過純 Python 的方案，寫起來簡單得多。可問題立刻冒出來：沒有圖，分散式怎麼部署？不同裝置之間怎麼排程？ > 這大概就是讓天平傾斜的原因，最終我們選擇了圖。（Rajat Monga） 這個決定在隨後幾年帶來了巨大成功，也帶來了持續爭議。計算圖讓 TensorFlow 在分散式訓練和生產部署上佔盡優勢，但它的抽象方式跟普通程式設計師的思維方式差得很遠，寫起來彆扭。PyTorch 走的是另一條路，從第一天起就明確只服務研究場景，不需要考慮生產部署，直接用動態圖，程式碼寫出來就是普通的 Python。 Rajat 對這場競爭的態度相當坦率。他說 PyTorch 團隊有後發優勢，能看到前人踩過的坑，也能專注在特定方向上把事情做到極致。這種競爭反過來促使 TensorFlow 團隊重新審視那個被擱置過好幾次的問題：要不要支援動態執行？ > 競爭很有意思。這是我們已經想過很多次的事情，某一天我們說，好吧，這件事看起來可以做好了，那就再試一次。（Rajat Monga） 2019 年釋出的 TensorFlow 2.0，預設就是 Eager Execution。計算圖還在，只不過藏到了後臺，只在需要效能最佳化的時候才介入。**Rajat 承認，如果 PyTorch 不在，這個轉變可能會來得更晚。** ## 把 Keras 拉進來，一次出人意料的整合 TensorFlow 壯大之後，一個來自外部的問題變得越來越尖銳：到底該用哪個 API？ 當時 Google 內部同時存在好幾個高層 API，社群還各自搭了封裝。使用者面對的局面極其混亂，一個模型可能在這個 API 裡有、在那個裡沒有，選哪個全憑運氣。Rajat 說，社群反覆問同一個問題：我們該用哪一個？ 2.0 的核心目標之一就是解決它：只能留一個。 最後被選中的是 Keras。這個決定當時相當出人意料，因為 Keras 原本是獨立專案，作者 François Chollet 在加入 Google 之前就把它做了出來，最初的後端是 Theano，後來才加上 TensorFlow。從任何角度看，這都不像 Google 自家該優先推的東西。 整合的過程也很有意思。Chollet 加入 Google 後去了研究團隊，繼續做研究、寫論文，同時利用晚上和週末維護 Keras。Rajat 說，他甚至是在 Chollet 入職好幾個月之後，才知道這個人已經在 Google 了。 後來兩邊聊了聊，發現彼此想做的事情高度一致：讓儘可能多的開發者輕鬆上手。於是 Chollet 轉到 TensorFlow 團隊，原計劃只是協作一個季度，結果一待就是兩年。 > 把兩件本來可以對齊的事情放在一起，是很有意思的。（Rajat Monga） 這個決策的收益在後來的版本里非常明顯。初學者和大多數企業使用者拿到的體驗是，用 Keras 在 TensorFlow 上做遷移學習，幾行程式碼就能跑通，糾結 API 選擇這件事從此消失了。 ## 4100 萬次下載背後的社群工程 訪談裡提到一組數字：TensorFlow 當時被下載 4100 萬次，累計約 5 萬個提交、接近 1 萬個 pull request、1800 名貢獻者。 Rajat 說，他當年完全沒想過能到這個量級。當時能想象的只是未來會有很多人做這件事，問題是怎樣讓別人做得起來。 增長真正開始顯現是在開源之後。他意識到深度學習擴張的速度遠超預期，而 TensorFlow 恰好站在了一個能承接這種擴張的位置上。 社群不會自己長出來。他提到幾個關鍵動作，其中最重要的是文件。TensorFlow 剛釋出時，文件質量比所有同類專案高出一大截，原因很簡單：那些專案都是學術專案，作者根本沒把文件當回事。 文件帶來的效果是結構性的。深度學習從此不再只是研究者的玩具，一個完全沒有機器學習背景的人，也能照著文件把東西跑起來，做出點有意思的東西。使用者基數由此發生了質變。 > 人們喜歡我們的文件，因為它比當時其他所有東西都好一大截，那些都是學術專案，沒人會去想文件這件事。（Rajat Monga） 另一個動作是流程建設。Rajat 說，過去一年團隊花了很多力氣提升透明度，建立特別興趣小組，讓外部貢獻者知道專案往哪走、怎麼參與、提案流程是什麼。這些事在只有兩個開發者的專案里根本不用考慮，到了這個體量就繞不開。 還有一個容易被忽視的飛輪：有人在 TensorFlow 上實現了一個新架構，效果不錯，放到 GitHub 上，別人拿去改，又做出新東西。**這種自發的正反饋，才是社群能自我繁殖的根本原因。** ## 企業要穩定，研究者要自由 Rajat 把使用者分成截然不同的兩類，這兩類人的需求幾乎對立。 研究者要靈活性，要能表達各種瘋狂的想法，要跟得上每週都在變的新架構。企業要的東西相反：穩定、簡單、能一直跑下去。 他舉了一個很具體的例子。現在還有很多人在用三年前、四年前的模型。Inception 已經好幾歲了，照樣有大量的人在用，而且他們覺得挺好。這些人不需要最後那一點效能提升，他們要的是東西能穩定工作。 > 有很多人在用那些模型，他們沒問題，他們不需要最後那一點效能或質量，他們要的是穩定，是能直接用的東西。（Rajat Monga） 這解釋了 TensorFlow 為什麼在學術界被 PyTorch 追趕的同時，在企業市場依然穩固。真正跑在生產環境裡的系統，換代週期比論文慢得多。 不過 Rajat 也糾正了一個常見誤解。很多人以為深度學習最主流的應用是拿 ResNet 做遷移學習，那確實是最容易演示的場景，幻燈片上很好看。企業真正在做的事情樸素得多：他們有結構化資料，想做預測，以前用線性迴歸、邏輯迴歸、梯度提升樹，現在換成深度學習，效果可能確實更好，但遠沒有那麼炫。 他還提到一個更前置的問題。很多傳統行業的公司來問他怎麼用機器學習，聊到最後發現根本問題在別處：資料沒整理好，流程沒數字化。他的建議通常是先把最基本的東西跑通，再談最佳化。 > 我經常跟人說，別一上來就想著最新最花哨的模型，先把最基礎的東西做出來，然後再改進。（Rajat Monga） ## 2.0 的野心：清理 API 只是表面，拆解核心才是重點 2.0 對外最直觀的變化是 API 變乾淨了，Eager Execution 成了預設，Keras 成了推薦入口。Rajat 說，這些清理帶來的真正好處藏在後臺。 過去用計算圖，效能可以很好，前提是你花時間調。現在 API 收斂了，絕大多數人會用同樣的方式寫程式碼，團隊就能針對這條主路徑做深度最佳化，很多效能直接開箱即得，單機和分散式都是如此。 另一件更重要也更難的事，是拆解那個龐大的單體系統。 TensorFlow 的核心倉庫裡塞著執行引擎、CPU/GPU 後端、分散式排程，全部編譯成一個庫，彼此之間沒有清晰介面。這種設計在早期算優勢，跑得快，改起來方便。到了第四個年頭，它變成了負擔。 > TensorFlow 一開始是個非常單體的系統，某種程度上現在還是。核心部分依然很大、很單體。怎麼用更清晰的介面把它拆開，是我們擴充套件規模的關鍵挑戰之一。（Rajat Monga） 拆解的目標是讓外部組織更獨立地參與進來。硬體廠商想接入自己的晶片，像 IBM 這樣的公司想在特定方向做最佳化，自動駕駛公司有自己的叢集和網路方案。目前這些事也能做，只是很彆扭。有了乾淨的介面，各方就能各自演進，整個生態的擴充套件性會完全不同。 Rajat 用一個很形象的比喻形容這件事的難度：車還在跑的時候換發動機。 ## 相容性是債，也是一份承諾 4100 萬次下載背後，是全世界無數跑在生產環境裡的系統。這些系統一跑就是好幾年，不會因為框架升級就停下來。這意味著任何破壞性改動都要付出真實代價。 Rajat 承認這筆賬很重。他把這件事看成一次權衡：短期看，相容性會拖慢某些事情；長期看，它帶來的整體價值要大得多。因為這不只關乎昨天那個人寫的程式碼，更關乎明天那個人願不願意進來。**一個承諾不隨便破壞你程式碼的框架，本身就是一種吸引力。** 他自己在設計新東西時，用的是另一套方法。 > 做新東西的時候，你要先在腦子裡用一張白紙去設計，然後再想辦法讓其他所有東西也能跑起來。如果你設計的時候不敢想白紙，你永遠到不了一個好地方。（Rajat Monga） 先理想化地設計，再回來處理相容。一開始就讓歷史包袱把設計壓扁，順序就反了，而順序一反，好東西就出不來。 ## 團隊、超級明星與招聘 TensorFlow 的體量已經到了一個人做不了決策的程度。Rajat 說，早期設計方向他參與得比較深，現在生態裡推各自領域的人太多，比如 Martin Wicke 長期負責開源相關的工作。靠一個 BDFL 式的角色來管理這個規模，已經不現實。 聊到團隊，他的判斷標準很清晰。第一條是凝聚力，一個人再強，能做的事情也有限，團隊產出要大於個體之和。第二條是動機，一個人是不是真的在乎自己在做的東西。 > 就算是最初級的工程師，如果他對自己要做的事情沒有動力，那不管他多聰明，都很難做得好。（Rajat Monga） 招聘裡也有體現。Google 的面試流程除了考察技術能力，還有專門評估文化契合度的環節。TensorFlow 這種快速迭代的專案，需要能適應快節奏的人；專案逐漸成熟之後，又需要願意為質量較真的人。這兩種特質有時候會衝突，找到平衡點本身就是篩選的一部分。 關於超級明星，他的態度很明確：可以很強，但必須能和團隊協作。如果不合適，再大的個人價值也成問題。 ## 搜尋廣告那幾年，學到的是邊界 在接手 TensorFlow 之前，Rajat 在 Google 的搜尋廣告團隊待過。他把這個業務理解為搜尋的延伸：目標是把世界上的資訊變得可獲取，商品和服務也屬於資訊。 他提到一個細節。廣告系統在展示前會設一條質量門檻，達不到就不展示，哪怕這樣會損失收入。這套機制背後的邏輯是，廣告只有在真正對使用者有價值的時候才該出現。 他對廣告行業的問題也看得很清楚。一個網站反覆彈窗擋住內容，使用者當然煩。他希望在打擾和有用之間找到平衡，因為內容和服務本身要靠變現維持。 關於未來，他不認為網際網路會全面轉向付費。廣告模式會長期存在，但過去幾年確實有越來越多人願意為價值付費：Netflix、YouTube 訂閱、新聞網站的付費牆。他自己也能感受到這種變化，包括自己的付費習慣。他期待的是一種混合模型，先免費試用，再為更深的價值付費。 ## 給初學者的路徑，和給從業者的判斷 訪談最後，Rajat 給初學者的建議非常樸素：開啟官網，點進教程和指南，直接進 Colab，不需要安裝任何東西，瀏覽器裡就能跑。 背後是雲帶來的結構性變化。課堂和學生面對的最大門檻從來都是環境配置，算力排在後面。Colab 把這一步徹底抹掉了。免費額度當然有限，用完就得付費，這套邏輯跟前面聊的付費訂閱遵循同樣的規則。 至於硬體，他的觀察是個人裝置的算力一直在漲，今天手機的算力可能是當年第一臺桌上型電腦的若干倍。雲端負責起步和探索，本地裝置負責日常和隱私敏感的場景，兩條路會同時存在。 整場對話下來，有一條線索貫穿始終。TensorFlow 每一次重大選擇，幾乎都不是技術最優解，約束條件下的權衡才決定了方向。選計算圖，因為放不下生產部署；選 Keras，因為生態需要一個統一入口；保留相容性，因為幾千萬次下載背後是真實的業務系統；拆解單體架構，因為生態需要更多人參與。 這些決定的共同點是，它們都在為別人把事跑起來讓路，技術本身的優雅反而排在後面。 - 剛開始接觸深度學習，別急著搭環境。開一個 Colab notebook，用 Keras 載入預訓練模型做一次遷移學習，先把從資料到預測的完整流程跑通，比讀十篇綜述有用。 - 做企業落地時，先檢查資料本身有沒有結構化和數字化。很多專案卡住的地方是資料沒就位，跟演算法選型關係不大。 - 選框架前先想清楚自己的場景偏向研究還是生產。要頻繁試新架構、寫得順手，就看動態圖優先的方案；要長期穩定執行、需要分散式和成熟的 serving 鏈路，就看生態完整度。 - 帶技術團隊時，除了考察硬技能，專門留時間判斷對方對這件事有沒有真實興趣。技能可以補，動機補不了。 - 維護有外部使用者的開源專案，儘早把文件和貢獻流程做起來。文件在早期是成本最低、回報最高的投入，它決定你的使用者基數能不能發生質變。 - 設計新版本時，先在紙上按理想狀態設計，再回頭處理相容。順序反過來，好設計永遠出不來。