Uber 機器學習平臺 — 米開朗基羅

lsvih發表於2017-09-25
機器學習

Uber 機器學習平臺 — 米開朗基羅

Uber 工程師們一直致力於開發各種新技術，以讓客戶得到有效、無縫的使用者體驗。現在，他們正在加大對人工智慧、機器學習領域的投入來實現這個願景。在 Uber，工程師們開發出了一個名為“米開朗基羅”（Michelangelo）的機器學習平臺，它是一個內部的“MLaaS”（機器學習即服務）平臺，用以降低機器學習開發的門檻，並能根據不同的商業需求對 AI 進行擴充與縮放，就有如客戶使用 Uber 叫車一樣方便。

米開朗基羅平臺可以讓公司內部團隊無縫構建、部署與執行 Uber 規模的機器學習解決方案。它旨在覆蓋全部的端到端機器學習工作流，包括：資料管理、訓練模型、評估模型、部署模型、進行預測、預測監控。此係統不僅支援傳統的機器學習模型，還支援時間序列預測以及深度學習。

米開朗基羅在 Uber 投產約一年時間，已經成為了 Uber 工程師、資料科學家真正意義上的“平臺”，現在有數十個團隊在此平臺上構建、部署模型。實際上，米開朗基羅平臺現在部署於多個 Uber 資料中心並使用專用硬體，用於為公司內最高負載的線上服務提供預測功能。

本文將介紹米開朗基羅以及其產品用例，並簡單通過這個強大的 MLaaS 系統介紹整個機器學習工作流。

米開朗基羅背後的動機

在米開朗基羅平臺出現前，Uber 的工程師和資料科學家們在構建、部署一些公司需要，並且能根據實際操作進行規模擴充的機器學習模型時，遇到了很多挑戰。那時他們試圖使用各種各樣的工具來建立預測模型（如 R 語言、scikit-learn、自定義演算法等），此時工程團隊會構建一些一次性的系統以使用這些模型進行預測。因此，在 Uber 內能夠在短時間內使用各種開源工具構建出框架的資料科學家與工程師少之又少，限制了機器學習在公司內的應用。

具體來說，那時沒有建立一個可靠、統一、pipeline 可複用的系統用於建立、管理、訓練、預測規模化資料。因此在那時，不會有人做出資料科學家的桌上型電腦跑不了的模型，也沒有一個規範的結果儲存方式，要將幾個實驗結果進行對比也是相當困難的事情。更重要的是，那時沒有一種將模型部署到生產環境的確定方法。因此，大多數情況下都是相關的工程團隊不得不為手中的專案開發定製的服務容器。這時，他們注意到了這些跡象符合由 Scully 等人記錄的機器學習的反模式一文的描述。

米開朗基羅旨在將整個團隊的工作流程和工具標準化，通過端對端系統讓整個公司的使用者都能輕鬆構建、執行大型機器學習系統。但是工程師們的目標不僅限於解決這些直觀的問題，更是要創立一個能與業務共同發展的體系。

當工程師們於 2015 年年中開始構建米開朗基羅系統時，他們也開始解決一些規模化模型訓練以及一些將模型部署於生產環境容器的問題。接著，他們專注於構建能夠更好進行管理、共享特徵 pipeline 的系統。而最近，他們的重心轉移到了開發者生產效率 — 如何加速從想法到產品模型的實現以及接下來的快速迭代。

下一節將通過一個樣例來介紹如何使用米開朗基羅構建、部署一個模型，用於解決 Uber 的某種特定問題。雖然下面重點講的是 UberEATS 中的具體用例，但是這個平臺也管理著公司裡其他針對多種預測用例的類似模型。

用例：UberEATS 送餐到家時間預估模型

UberEATS 在米開朗基羅中有數個模型在執行，包括送餐到達時間預測、搜尋排行、搜尋自動完成、餐廳排行等。送餐到達時間預測模型能夠預測準備膳食、送餐以及送餐過程中的各個階段所需的時間。

圖 1：UberEATS app 提供了估測外賣送達時間的功能，此功能由基於米開朗基羅構建的機器學習模型驅動。

預測外賣的送達時間（ETD）並不是一件簡單的事情。當 UberEATS 使用者下單時，訂單將被送到餐廳進行處理。餐廳需要確認訂單，根據訂單的複雜度以及餐廳的繁忙程度準備餐品，這一步自然要花費一些時間。在餐品快要準備完畢的時候，Uber 外賣員出發去取餐。接著，外賣員需要開車到達餐廳、找到停車場、進餐廳取餐、回到車裡、開車前往客戶家（這個步驟耗時取決於路線、交通等因素）、找到車位、走到客戶家門口，最終完成交貨。UberEATS 的目標就是預測這個複雜的多階段過程的總時間，並在各個步驟重新計算 ETD。

在米開朗基羅平臺上，UberEATS 資料科學家們使用了 GBDT（梯度提升決策樹）迴歸模型來預測這種端到端的送達時間。此模型使用的特徵包括請求資訊（例如時間、送餐地點）、歷史特徵（例如餐廳在過去 7 天中的平均餐食準備時間）、以及近似實時特徵（例如最近一小時的平均餐食準備時間）。此模型部署於 Uber 資料中心的米開朗基羅平臺提供的容器中，通過 UberEATS 微服務提供網路呼叫。預測結果將在餐食準備及送達前展示給客戶。

系統架構

米開朗基羅系統由一些開源系統和內建元件組成。主要使用的開源元件有 HDFS、Spark、Samza、Cassandra、MLLib、XGBoost、TensorFlow。在條件允許的前提下，開發團隊更傾向於使用一些成熟的開源系統，並會進行 fork、定製化，如果有需求的話也會對其進行貢獻。如果找不到合適的開源解決方案，他們也會自己構建一些系統。

米開朗基羅系統建立與 Uber 的資料及計算基礎設施之上，它們提供了一個“資料湖”，其中包含了 Uber 所有的事務和日誌資料。由 Kafka 對 Uber 的所有服務日誌進行採集彙總，使用 Cassandra 叢集管理的 Samza 流計算引擎以及 Uber 內部服務進行計算與部署。

在下一節中將以 UberEATS 的 ETD 模型為例，簡單介紹系統的各個層次，說明米開朗基羅的技術細節。

機器學習工作流

在 Uber，大多數的機器學習用例（包括一些正在做的工作，例如分類、迴歸以及時間序列預測等）都有著一套同樣的工作流程。這種工作流程可以與具體實現分離，因此很容易進行擴充以支援新的演算法和框架（例如最新的深度學習框架）。它還適用於各種不同預測用例的部署模式（如線上部署與離線部署，在車輛中使用與在手機中使用）。

米開朗基羅專門設計提供可擴充、可靠、可重用、易用的自動化工具，用於解決下面 6 步工作流：

  1. 管理資料
  2. 訓練模型
  3. 評估模型
  4. 部署模型
  5. 預測結果
  6. 預測監控

下面將詳細介紹米開朗基羅的架構是如何促進工作流中的各個步驟的。

管理資料

找出良好的特徵經常是是機器學習最難的部分，工程師們也發現整個機器學習解決方案中最費時費力的部分就是構建及管理資料管道。

因此，平臺應提供一套標準工具以構建資料管道，生成特徵，對資料集進行標記（用於訓練及再訓練），以及提供無標記特徵資料用以預測，這些工具需要與公司的資料湖、資料中心以及公司的線上資料服務系統進行深度的整合。構建出來的資料管道必須具有可縮放性以及足夠的效能，能夠監控資料流以及資料質量，為各種線上/離線訓練與預測都提供全面的支援。這些工具還應該能通過團隊共享的方式生成特徵，以減少重複工作並提高資料質量。此外，這些工具應當提供強有力的保護措施，鼓勵使用者去採用最好的方式使用工具（例如，保證在訓練時和預測時都採用同一批次生成的資料）。

米開朗基羅的資料管理元件分為線上管道和離線管道。目前，離線管道主要用於為批量模型訓練以及批量預測作業提供資料；線上管道主要為線上、低時延預測作業提供資料（以及之後會為線上學習系統提供支援）。

此外，工程師們還為資料管理層新加了一個特徵儲存系統，可以讓各個團隊共享、發現高質量的資料特徵以解決他們的機器學習問題。工程師們發現，Uber 的許多模型都是用了類似或相同的特徵，而在不同組織的團隊以及團隊裡的不同專案中共享特徵是一件很有價值的事情。

圖 2：資料預處理管道將資料存入特徵庫以及訓練資料倉儲中。

離線部署

Uber 的事務與日誌資料會“流入”一個 HDFS 資料湖中，可以使用 Spark 和 Hive SQL 的計算作業輕鬆呼叫這些資料。平臺提供了容器與計劃任務兩種方式執行常規作業，用於計算專案內部的私有特徵或將其釋出至特徵儲存庫（見後文）與其他團隊共享。當計劃任務執行批量作業或通過別的方式觸發批量作業時，作業將被整合傳入資料質量監控工具，此工具能夠快速回溯找出問題出在 pipeine 中的位置，判明是原生程式碼的問題還是上游程式碼的問題導致的資料錯誤。

線上部署

線上部署的模型將無法訪問 HDFS 儲存的資料，因此，一些需要在 Uber 生產服務的支撐資料庫中讀取的特徵很難直接用於這種線上模型（例如，無法直接查詢 UberEATS 的訂單服務去計算某餐廳某特定時間段平均膳食準備時間）。因此，工程師們將線上模型需要的特徵預計算並儲存在 Cassandra 中，線上模型可以低延遲讀取這些資料。

線上部署支援兩種計算系統：批量預計算與近實時計算，詳情如下：

  • 批量預計算。這個系統會定期進行大批量計算，並將 HDFS 中的特徵歷史記錄載入進 Cassandra 資料庫中。這樣做雖然很簡單粗暴，但是如果需要的特徵對實時性要求不高（比如允許隔幾小時更新一次），那麼效果還是很好的。這個系統還能保證在批處理管道中用於訓練和服務的資料是同批次的。UberEATS 就採用了這個系統處理一部分特徵，如“餐廳過去七天的膳食平均準備時間”。
  • 近實時計算。這個系統會將相關指標釋出至 Kafka 系統，接著執行 Samza 流計算作業以低時延生成所有特徵。接著這些特徵將直接存入 Cassandra 資料庫用於提供服務，並同時備份至 HDFS 用於之後的訓練作業。和批量預計算系統一樣，這樣做同樣能保證提供服務和進行訓練的資料為同一批次。為了避免這個系統的冷啟動，工程師們還專門為這個系統製作了一個工具，用於“回填”資料與基於歷史記錄執行批處理生成訓練資料。UberEATS 就使用了這種近實時計算 pipeline 來得到如“餐廳過去一小時的膳食平均準備時間”之類的特徵。

共享特徵庫

工程師們發現建立一個集中的特徵庫是很有用的，這樣 Uber 的各個團隊可以使用其他團隊建立和管理的可靠的特徵，且特徵可以被分享。從大方向上看，它做到了以下兩件事情：

  1. 它可以讓使用者輕鬆地將自己構建的特徵存入共享特徵庫中（只需要增加少許後設資料，如新增者、描述、SLA 等），另外它也能讓一些特定專案使用的特徵以私有形式儲存。
  2. 只要特徵存入了特徵庫，那之後再用它就十分簡單了。無論是線上模型還是離線模型，都只要簡單地在模型配置中寫上特徵的名稱就行了。系統將會從 HDFS 取出正確的資料，進行處理後返回相應的特徵集既可以用於模型訓練，也可以用於批量預測或者從 Cassandra 取值做線上預測。

目前，Uber 的特徵庫中有大約 10000 個特徵用於加速機器學習工程的構建，公司的各個團隊還在不斷向其中增加新的特徵。特徵庫中的特徵每天都會進行自動計算與更新。

未來，工程師們打算構建自動化系統，以進行特徵庫搜尋並找出解決給定預測問題的最有用的特徵。

用於特徵選擇及轉換的領域特定語言（DSL）。

由資料 pipeline 生成的特徵與客戶端服務傳來的特徵經常不符合模型需要的資料格式，而且這些資料時常會缺失一些值，需要對其進行填充；有時候，模型可能只需要傳入的特徵的一個子集；還有的時候，將傳入的時間戳轉換為 小時/天 或者 天/周 會在模型中起到更好的效果；另外，還可能需要對特徵值進行歸一化（例如減去平均值再除以標準差）。

為了解決這些問題，工程師們為建模人員創造了一種 DSL（領域特定語言），用於選擇、轉換、組合那些用於訓練或用於預測的特徵。這種 DSL 為 Scala 的子集，是一種純函式式語言，包含了一套常用的函式集，工程師們還為這種 DSL 增加了自定義函式的功能。這些函式能夠從正確的地方取出特徵（離線模型從資料 pipeline 取特徵值，線上模型從客戶請求取特徵值，或是直接從特徵庫中取出特徵）。

此外，DSL 表示式是模型配置的一部分，在訓練時取特徵的 DSL 與在與測試時用的 DSL 需要保持一致，以確保任何時候傳入模型的特徵集的一致性。

訓練模型

目前平臺支援離線、大規模分散式訓練，包括決策樹、線性模型、邏輯模型、無監督模型（k-means）、時間序列模型以及深度神經網路。工程師們將定期根據使用者的需求增加一些由 Uber AI 實驗室新開發的模型。此外，使用者也可以自己提供模型型別，包括自定義訓練、評價以及提供服務的程式碼。分散式模型訓練系統可以規模化處理數十億的樣本資料，也可以處理一些小資料集進行快速迭代。

一個模型的配置包括模型型別、超參、資料來源、特徵 DSL，以及計算資源需求（需要的機器數量、記憶體用量、是否使用 GPU 等）。這些資訊將用於配置執行在 YARN 或 Mesos 叢集上的訓練作業。

在模型訓練完畢之後，系統會將其計算得到的效能指標（例如 ROC 曲線和 PR 曲線）進行組合，得到一個模型評價報告。在訓練結束時，系統會將原始配置、學習到的引數以及評價包括存回模型庫，用於分析與部署。

除了訓練單個模型之外，米開朗基羅系統還支援對分塊模型等各種模型進行超參搜尋。以分塊模型為例，以分塊模型為例，系統會根據使用者配置自動對訓練資料進行分塊，對每個分塊訓練一個模型；在有需要的時候再將各個分塊模型合併到父模型中（例如，先對每個城市資料進行訓練，如果無法得到準確的市級模型時再將其合併為國家級模型）。

訓練作業可以通過 Web UI 或者 API 進行配置與管理（通常使用 Jupyter notebook）。大多數團隊都使用 API 以及流程管理工具來對他們的模型進行定期重訓練。

圖 3：模型訓練作業使用特徵庫與資料訓練倉庫中的資料集來訓練模型，接著將模型存入模型庫中。

評估模型

訓練模型可以看成是一種尋找最佳特徵、演算法、超參以針對問題建立最佳模型的探索過程。在得到用例的理想模型前，訓練數百種模型而一無所獲也是常有的事。雖然這些失敗的模型最終不能用於生產，但它們可以指導工程師們更好地進行模型配置，從而獲得更好的效能。追蹤這些訓練過的模型（例如誰、何時訓練了它們，用了什麼資料集、什麼超參等），對它們的效能進行評估、互相對比，可以為平臺帶來更多的價值與機會。不過要處理如此之多的模型，也是一個極大的挑戰。

米開朗基羅平臺中訓練的每個模型都需要將以下資訊作為版本物件儲存在 Cassandra 的模型庫中：

  • 誰訓練的模型。
  • 訓練模型的開始時間與結束時間。
  • 模型的全部配置（包括用了什麼特徵、超參的設定等）。
  • 引用訓練集和測試集。
  • 描述每個特徵的重要性。
  • 模型準確性評價方法。
  • 模型每個型別的標準評價表或圖（例如 ROC 曲線圖、PR 曲線圖，以及二分類的混淆矩陣等）。
  • 模型所有學習到的引數。
  • 模型視覺化摘要統計。

使用者可以通過 Web UI 或者使用 API 輕鬆獲取這些資料，用以檢查單個模型的詳細情況或者對多個模型進行比較。

模型準確率報告

迴歸模型的準確率報告會展示標準的準確率指標與圖表；分類模型的準確率報告則會展示不同的分類集合，如圖 4 圖 5 所示：

圖 4：迴歸模型的報告展示了與迴歸相關的效能指標。

圖 5：二分類模型報告展示了分類相關的效能指標。

視覺化決策樹

決策樹作為一種重要的模型型別，工程師們為其提供了視覺化工具，以幫助建模者更好地理解模型的行為原理，並在建模者需要時幫助其進行除錯。例如在一個決策樹模型中，使用者可以瀏覽每個樹分支，看到其對於整體模型的重要程度、決策分割點、每個特徵對於某個特定分支的權重，以及每個分支上的資料分佈等變數。使用者可以輸入一個特徵值，視覺化元件將會遍歷整個決策樹的觸發路徑、每個樹的預測、整個模型的預測，將資料展示成類似下圖的樣子：

圖 6：使用強大的樹視覺化元件檢視樹模型。

特徵報告

米開朗基羅提供了特徵報告，在報告中使用區域性依賴圖以及混合直方圖展示了各個特徵對於模型的重要性。選中兩個特徵可以讓使用者看到它們之間相互的區域性依賴圖表，如下所示：

圖 7：在特徵報告中可以看到的特徵、對模型的重要性以及不同特徵間的相關性。

部署模型

米開朗基羅支援使用 UI 或 API 端對端管理模型的部署。一個模型可以有下面三種部署方式：

  1. 離線部署。模型將部署於離線容器中，使用 Spark 作業，根據需求或計劃任務進行批量預測。
  2. 線上部署。模型將部署於線上預測服務叢集（叢集通常為使用負載均衡部署的數百臺機器），客戶端可以通過網路 RPC 呼叫發起單個或批量的預測請求。
  3. 部署為庫。工程師們希望能在服務容器中執行模型。可以將其整合為一個庫，也可以通過 Java API 進行呼叫（在下圖中沒有展示此型別，不過這種方式與線上部署比較類似）。

圖 8：模型庫中的模型部署於線上及離線容器中用於提供服務。

上面所有情況中，所需要的模型元件（包括後設資料檔案、模型引數檔案以及編譯好的 DSL）都將被打包為 ZIP 檔案，使用 Uber 的標準程式碼部署架構將其複製到 Uber 資料中心的相關資料上。預測服務容器將會從磁碟自動載入新模型，並自動開始處理預測請求。

許多團隊都自己寫了自動化指令碼，使用米開朗基羅 API 進行一般模型的定期再訓練及部署。例如 UberEATS 的送餐時間預測模型就由資料科學家和工程師通過 Web UI 控制進行訓練與部署。

預測結果

一旦模型部署於服務容器並載入成功，它就可以開始用於對資料管道傳來的特徵資料或使用者端發來的資料進行預測。原始特徵將通過編譯好的 DSL 傳遞，如有需要也可以對 DSL 進行修改以改進原始特徵，或者從特徵儲存庫中拉取一些額外的特徵。最終構造出的特徵向量會傳遞給模型進行評分。如果模型為線上模型，預測結果將通過網路傳回給客戶端。如果模型為離線模型，預測結果將被寫回 Hive，之後可以通過下游的批處理作業或者直接使用 SQL 查詢傳遞給使用者，如下所示：

圖 9：線上預測服務及離線預測服務使用一組特徵向量生成預測結果。

引用模型

在米開朗基羅平臺中可以同時向服務容器部署多個模型。這也使得從舊模型向新模型進行無痛遷移以及對模型進行 A/B 測試成為可能。在服務中，可以由模型的 UUID 以及一個在部署時可指定的 tag（或者別名）識別不同的模型。以一個線上模型為例，客戶端服務會將特徵向量與需要使用的模型 UUID 或者 tag 同時傳送給服務容器；如果使用的是 tag，服務容器會使用此 tag 對應的最新部署的模型進行預測。如果使用的是多個模型，所有對應的模型都將對各批次的資料進行預測，並將 UUID 和 tag 與預測結果一同傳回，方便客戶端進行篩選過濾。

如果在部署一個新模型替換舊模型時用了相同的事物（例如用了一些同樣的特徵），使用者可以為新模型設定和舊模型一樣的 tag，這樣容器就會立即開始使用新模型。這可以讓使用者只需要更新模型，而不用去修改他們的客戶端程式碼。使用者也可以通過設定 UUID 來部署新模型，再將客戶端或中介軟體配置中舊模型的 UUID 換成新的，逐步將流量切換到新模型去。

如果需要對模型進行 A/B 測試，使用者可以通過 UUID 或者 tag 輕鬆地部署競爭模型，再使用客戶端服務中的 Uber 實驗框架將部分流量導至各個模型，再對效能指標進行評估。

規模縮放與時延

由於機器學習模型是無狀態的，且不需要共享任何東西，因此，無論是線上模式還是離線模式下對它們進行規模縮放都是一件輕而易舉的事情。如果是線上模型，工程師可以簡單地給預測服務叢集增加機器，使用負載均衡器分攤負載。如果是離線預測，工程師可以給 Spark 設定更多的 executor，讓 Spark 進行並行管理。

線上服務的延遲取決於模型的型別與複雜度以及是否使用從 Cassandra 特徵庫中取出的特徵。在模型不需要從 Cassandra 取特徵的情況下，P95 測試延遲小於 5 毫秒。在需要從 Cassandra 取特徵時，P95 測試延遲仍小於 10 毫秒。目前用量最大的模型每秒能提供超過 250000 次預測。

預測監控

當模型訓練完成並完成評價之後，使用的資料都將是歷史資料。監控模型的預測情況，是確保其在未來正常工作的重要保障。工程師需要確保資料管道傳入的是正確的資料，並且生產環境沒有發生變化，這樣模型才能夠進行準確的預測。

為了解決這個問題，米開朗基羅系統會自動記錄並將部分預測結果加入到資料 pipeline 的標籤中去，有了這些資訊，就能得到持續的、實時的模型精確度指標。在迴歸模型中，會將 R^2/決定係數、均方根對數誤差（RMSLE）、均方根誤差（RMSE）以及平均絕對值誤差釋出至 Uber 的實時監控系統中，使用者可以分析指標與時間關係的圖示，並設定閾值告警：

圖 10：對預測結果進行取樣，與觀測結果進行比較得到模型準確指標。

管理層、API、Web UI

米開朗基羅系統的最後一個重要部分就是 API 層了，它也是整個系統的大腦。API 層包含一個管理應用，提供了 Web UI 以及網路 API 兩種訪問方式，並與 Uber 的監控、報警系統相結合。同時該層還包含了用於管理批量資料管道、訓練作業、批量預測作業、模型批量部署以及線上容器的工作流系統。

米開朗基羅的使用者可以通過 Web UI、REST API 以及監控、管理工具直接與這些元件進行互動。

米開朗基羅平臺之後的構建工作

工程師們打算在接下來幾個月繼續擴充套件與加強現有的系統，以支援不斷增長的使用者和 Uber 的業務。隨著米開朗基羅平臺各個層次的不斷成熟，他們計劃開發更高層的工具與服務，以推動機器學習在公司內部的發展，更好地支援商業業務：

  • AutoML。這是將會成為一個自動搜尋與發現模型配置的系統（包括演算法、特徵集、超參值等），可以為給定問題找到表現最佳的模型。該系統還會自動構建資料管道，根據模型的需要生成特徵與標籤。目前工程師團隊已經通過特徵庫、統一的離線線上資料管道、超參搜尋特徵解決了此係統的一大部分問題。AutoML 系統可以加快資料科學的早期工作，資料科學家們只需要指定一組標籤和一個目標函式，接著就能高枕無憂地使用 Uber 的資料找到解決問題的最佳模型了。這個系統的最終目標就是構建更智慧的工具，簡化資料科學家們的工作，從而提高生產力。
  • 模型視覺化。對於機器學習，尤其是深度學習，理解與除錯模型現在變得越來越重要。雖然工程師們已經首先為樹狀模型提供了視覺化工具，但是還需要做更多的工作，幫助資料科學家理解、debug、調整他們的模型，得到真正令人信服的結果。
  • 線上學習。Uber 的機器學習模型大多數直接受到 Uber 產品的實時影響。這也意味著這些模型需要能夠在複雜、不斷變化的真實世界中執行。為了保證模型在變化環境中的準確性，這些模型需要隨著環境一同進化；現在，各個團隊會在米開朗基羅平臺上定期對模型進行重訓練。一個完整的平臺式解決方案應該讓使用者能夠輕鬆地對模型進行升級、快速訓練及評價，有著更精細的監控及報警系統。雖然這將是一個很大的工程，但是早前的研究結果表明，構建完成線上學習系統可能會帶來巨大的收益。
  • 分散式深度學習。越來越多的 Uber 機器學習系統開始使用深度學習實現。定義與迭代深度學習模型的工作流與標準的工作流有著很大的區別，因此需要平臺對其進行額外的支援。深度學習需要處理更大的資料集，需要不同的硬體支援（例如 GPU），因此它更需要分散式學習的支援，以及與更具彈性的資源管理堆疊進行緊密結合。

如果你對挑戰規模化機器學習有興趣，歡迎申請Uber 機器學習平臺團隊 ！

作者簡介：Jeremy Hermann 是 Uber 機器學習平臺團隊的工程經理，Mike Del Balso 是 Uber 機器學習平臺團隊的產品經理。

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章