英偉達GTC大會談GPU未來：實現機器學習和資料庫的融合

選自The Next Platform

機器之心編譯

參與：微胖、黃小天、吳攀

對於工作，有一個合適的工具當然好；但是把一個工具應用於多個工作且效用更佳，這更好。這就是為什麼通用的基於 X86 的計算接管數據中心的原因之一。通過受限範圍或者只是把原來有的應用程序單獨放在替換平台上，規模經濟獲得了出乎意料的效率。

十多年前，把計算任務從 CPU 卸載到 GPU 加速器的想法從學術界脫穎而出，並且相對更快的高性能計算社區和 GPU 製造商英偉達擴展了現有的 Fortran 和通常用於 CPU 並行超級計算機的 C++ 框架，這樣可以大大拓展計算容量，所得到的系統也會有更好效果。不久之後，有可能使用相同的機械來進行模擬和模型所需的計算，也可以進行渲染來可視化這些模擬和模型的結果。正如我們所知，超級計算機進化的下一步是在機器學習中編排（weave）以分析模擬和模型的結果，並據此做預測。因此一個應用程序將有三個不同、相互交織的層，且全部運行在相同的加速單元上。

資料庫和分析領域也進行著一場類似的革命，它由 GPU 驅動，某些情況下也會用到 FPGA 加速器。在 GPU 採用傳統的高性能計算方法的幾年之後，谷歌、Facebook、百度等巨頭公司的主導研究者發現了一個運行神經網路軟體的方法，該方法在上世紀 80 年代已被提出，用於解決 GPU 加速系統中大量並行樣式的圖像識別問題，；該方法最終創造出了可在圖像分任務中優於人類的軟體。在過去的五年中，機器學習框架中的最先進技術獲得了極速發展，圖像識別技術也被用於文本、語音、視頻識別及翻譯服務，而翻譯不僅僅限於語言之間，還包括從語音到文本的轉換，或者圖像、視頻到文本的轉換，且這些轉換的精確度相當驚人。

結果就是，在 HPC 驅動以及機器學習的爆發之下，英偉達 2008 年成立的 Tesla GPU 早期計算業務如今規模擴大了 4 倍，並在今年 2 月英偉達 2017 財年第 4 季度的最後達到了 12 億美元的年銷售額（annual run rate）。英偉達的業務是如此之好以至於其競爭對手 AMD 最終一起推出了 Radeon Instinct GPU 計算平台和 ROCm 軟體平台，它們不僅支持 OpenCL 卸載到 Radeon GPU，還具備在 AMD 自身的 Radeon motor 上為其 GPU 模擬英偉達 CUDA 並行編程環境的能力。

而現在，另一個應用正在成為 GPU 上的加速工作負載，它是關係型資料庫（relational database），且處在大多數業務系統的核心，具有像 HPC 模擬、建模與機器學習這樣的規模問題，這種問題可通過 GPU 的並行特性及其非常高的內存帶寬而解決。我們已經記錄了 GPU 加速資料庫兩大主要供應商——Kinetica（以前被稱為 GPUdb）和其新興挑戰者 MapD——的興起，但這一領域還有其他供應商，比如 Sqream、BlazingDB、Blazegraph 和 PG-Strom。並不清楚資料庫加速是否會一直像傳統 HPC 模擬、建模或者機器學習那樣驅動同樣的 GPU 單元。後兩者幾乎帶動了英偉達 Tesla GPU 計算收入的一半。但這也有機會成為該業務的另一個重要部分，尤其是在這樣的系統上：既可以使用標準 SQL 查詢方法咀嚼大型數據集，也可以在同一個單元上可視化這些查詢的結果。

本周，英偉達在聖荷西舉行的 GTC 大會之前，我們與 MapD 和 Kinetica 談到了把新興 GPU 資料庫與企業環境中的機器學習框架進行混合的可能性，這兩個工作負載不僅共享同樣的 GPU 單元，而且還像 HPC 空間中的模擬、可視化和機器學習所做的那樣相互反哺。

MapD 創始人 Todd Mostak 告訴 The Next Platform 說，「這將是一個大趨勢。如果我們有資料庫、可視化和 GPU 機器學習，為什麼不使它們一起工作？人們一直希望在 MapD 之上運行 TensorFlow，或者甚至在數據上運行回歸以連接點，而無須離開 GPU 生態系統。現在，人們正在使用 Spark，它是好的，因為它連接到了 Hadoop；但是要使用這些公司使用的數據集來獲得任何一種性能，他們必須大規模地進行擴展，然後將結果從集群中的 CPU 移到 GPU。但是如果你把一切保留在 GPU 之中，並從 GPU 生態系統的不同部分傳遞結果，這將是一個巨大的勝利。」

在 GPU 加速的資料庫與依賴 GPU 來顯著提升性能的機器學習框架之間的搭配中，還有一個問題仍待解決，即數據如何存儲在機器的集群中。你是否在一個 CPU-GPU 集群中有一個用於運行資料庫的分區，還有另一個分區用來運行 TensorFlow、Torch、Caffe、Theano 和 CNTK 這樣的機器學習框架？還是說你實際上想將機器學習演算法所用的數據就存在 GPU 資料庫中？

Mostak 說，一種方法是使用 GPU 資料庫作為記錄（record）的存儲位置，而且即使數據在該資料庫中不是以張量格式存儲的，該資料庫也可以進行調整使其輸出那種格式並將其傳遞給 TensorFlow 這樣的框架。然後人們可以使用簡單的老式 SQL 來查詢該資料庫以獲得數據的一個子集，然後將其放入到機器學習框架中。

他補充說：「我們一直都會看到這種情況。公司需要將數據的子集放進它們的訓練演算法中，而且需要做得非常快。」另一種方法實際上是將本地的機器學習格式放進資料庫本身，因為它們確實期望有結構化的數據，而不只是點擊流和圖像數據的 core dump 或任何對象存儲（object store）中東西。Mostak 解釋說，張量基本上就是一個向量，以類似於縱列資料庫格式的方式表示，所以這裡已經有非常好的適配了。

這些天來，GPU 資料庫製造商 Kinetica 的 CEO 兼聯合創始人 Amit Vij 也在思考人工智慧（AI）和商業智能（BI）的交匯。他認同公司正部署以訓練機器學習模型的嚴重依賴 GPU 的系統與 Kinetica 等公司開發的 GPU 加速的資料庫具有完全一樣的架構。超大規模用戶（hyperscalers）已經在從消費者角度來對待這一問題了，它們正在努力分類我們的貓片和家庭視頻；但 Kinetica（之前名為 GIS Federal）具有更加嚴肅的背景。

「因為有軍方孵化的背景，所以我們已經將機器學習和圖像識別技術用於無人機追蹤的實體上，提取特徵後返回基地以識別（車輛和其他內容）。」Vij 說，「我們已經有了一個 GPU 加速和分布式資料庫，可以將人工智慧和 BI 集成在一個平台上。」

你可以在同一個 GPU 集簇上運行 Kinetica 和框架，比如 TensorFlow、Caffe 或 Torch，不過為了方便工作量管理，最好分區運行資料庫和機器學習工作負載（這和 MapD 上面所談到的不一樣，你要試著在 GPU 內存上保存所有的東西，從那裡讀取內容）。區分開人工智慧和 BI 工作負載後，就能避免系統超負荷運行，兩個不同的工作負載也不會相互負面影響。

Kinetica 也有一個容器環境，每種工作負載可分別向上向下擴展到集群上，以動態虛擬方式並肩運行。Kinetica 可以在內存中（或者 CPU 或者 GPU）存儲幾十億行數據，還有用戶定義功能，可以用存儲在大型資料庫的表格中的數據訓練 TensorFlow 以及其他機器學習框架。比如，金融服務公司可以存儲幾個月甚至幾年的股票行情數據，根據各種與股票價格相關的既定外部條件，預測分析股票價格（這也是 Kinetica 部署使用案例之一）。

總的說來，那些正在將資料庫和機器學習工作負載混搭起來的早期用戶，他們用於機器學習的機器比用於資料庫處理的機器還要多。典型的 Kinetica 集群部署為 40 到 60 個節點，盒子里有很多 GPU，可以形成相當好的集群來運行機器學習演算法。特別是用 MPI 協議延展的機器學習框架，就像俄亥俄州大學研究人員採用的方法那樣，或者其他人使用的辦法，比如 Facebook 處理已經開源的 Caffe2 框架的方法。雖然公司可以在雲端部署 Kinetica，但是，我們更傾向於在這一前提下進行部署：金融服務、軍方、製造管理方面的數據敏感性是給定的。而且鑒於這一既定事實：取決於 GPU 加速資料庫的應用通常都是關鍵任務，不能降速，用戶通常會部署雙活高可用性集群。

為了讓人工智慧和 BI 集成更加容易，Vij 說 Kinetica「深度對齊」TensorFlow 框架，在 Kinetica 資料庫框架中，張量被作為首先考慮的因素並以數據格式存儲下來。這個任務並不困難。最初的 GPUdb 資料庫就是當時所謂的 GIS 聯盟創造的——現在，公司和產品都叫 Kinetica——一開始被作為地理時空引擎，然後它又用 JSON 來表徵一個點、線或者多邊形，對於一個 GPU 資料庫來說，有一個樸素的目標最合適不過了，因為它正在矩陣上運行。

Vij 說，「我把這看作一個方案想法，其中所有的東西像一個蘋果產品，通過單一技術進行封裝，最終為終端用戶輕鬆部署。並且不僅我們強化技術，用戶也會。資料庫管理者、機器學習專家和數據科學家不必熟練掌握 5 到 10 種不同的技術；他們也不必親自使用開源框架，況且這些框架多是批量導向。我們由於所有這些堆棧而成為了分布式 GPU 管道，且開發者將我們用作資料庫平台，而無須把數據從一項技術移動到另一個。」

沒有人具備時間、金錢或者意向來完成所有的數據移動。因此，關於資料庫和機器學習的融合平台將是一個很好的案例。大多數公司不滿於為甲骨文資料庫及其擴展或者等價的 IBM 和微軟資料庫服務支付高額費用；但現在，這已成為過去。