谷歌、微軟、Facebook 等傳統(tǒng)的人工智能技術(shù)巨頭之外，百度近來也加入到了技術(shù)開源的浪潮之中，繼 PaddlePaddle 之后，百度又宣布開源了一項(xiàng)深度學(xué)習(xí)基準(zhǔn) DeepBench。

       開源地址：https://github.com/baidu-research/DeepBench

1.DeepBench

       DeepBench 是一個(gè)開源的基準(zhǔn)工具，用來測量深度神經(jīng)網(wǎng)絡(luò)訓(xùn)練中的基礎(chǔ)操作的表現(xiàn)。使用神經(jīng)網(wǎng)絡(luò)庫，這些操作在不同的硬件平臺被執(zhí)行。如今測試基準(zhǔn)工具 DeepBench 在 github 上已經(jīng)開源。

      DeepBench 的主要目標(biāo)是 benchmark 對深度學(xué)習(xí)在不同硬件平臺上而言很重要的運(yùn)算。盡管深度學(xué)習(xí)背后的基礎(chǔ)計(jì)算已經(jīng)被很好的理解了，但在實(shí)踐中它們被使用的方式驚人的不同。例如，矩陣相乘運(yùn)算基于被相乘矩陣的大小和 Kernel 實(shí)現(xiàn)，可能是 compute-bound，也可能是 bandwidth-bound, 或者 occupancy-bound。因?yàn)槊總€(gè)深度學(xué)習(xí)模型帶著不同的參數(shù)使用這些運(yùn)算，面向深度學(xué)習(xí)硬件和軟件的優(yōu)化空間還是很大的，也是不足的。

      DeepBench 試圖解決這個(gè)問題，「在被用于訓(xùn)練深度神經(jīng)網(wǎng)絡(luò)時(shí)，在基礎(chǔ)運(yùn)算上哪種硬件提供最好的表現(xiàn)？」我們在低層次上詳細(xì)說明了這些運(yùn)算，建立深度學(xué)習(xí)處理器的團(tuán)隊(duì)很適合在硬件模擬中使用 DeepBench。

1.1 DeepBench 適合用在哪里？

       深度學(xué)習(xí)生態(tài)系統(tǒng)包含不同的模塊。我們想要強(qiáng)調(diào) DeepBench 適合用于該生態(tài)系統(tǒng)的哪部分。在下面的圖表中，描述了關(guān)于深度學(xué)習(xí)的軟件和硬件組件。在最頂端是百度的 PaddlePaddle、Theano、TensorFlow、Torch 等這樣的深度學(xué)習(xí)框架，這些框架使得我們能夠建立深度學(xué)習(xí)模型。它們包含層（layer）這樣的基礎(chǔ)建筑模塊，可通過不同的方式連接從而創(chuàng)造模型。為了訓(xùn)練這些模型，框架使用英偉達(dá)的 cuDNN 和英特爾的 MKL 這樣的基礎(chǔ)神經(jīng)網(wǎng)絡(luò)庫。這些庫執(zhí)行矩陣相乘這樣的用來訓(xùn)練深度學(xué)習(xí)模型的運(yùn)算。最后，在英偉達(dá) GPU 或英特爾 Xeon Phi 處理器這樣的硬件上訓(xùn)練這些模型。

      DeepBch 使用神經(jīng)網(wǎng)絡(luò)庫 benchmark 基礎(chǔ)運(yùn)算在不同硬件上的表現(xiàn)。它對建立應(yīng)用的深度學(xué)習(xí)框架或深度學(xué)習(xí)模型沒用。我們不能測量使用 DeepBench 訓(xùn)練整個(gè)模型所需要的時(shí)間。為不同應(yīng)用建立的模型的表現(xiàn)特性彼此間差別很大。因此，我們要 benchmark 涉及到深度學(xué)習(xí)模型訓(xùn)練中的潛在運(yùn)算。benchmark 這些運(yùn)算有助于提高硬件供應(yīng)商的 意識，也有助于軟件開發(fā)者了解深度學(xué)習(xí)訓(xùn)練的瓶頸。

1.2 方法論

      DeepBench 包括一系列的基礎(chǔ)操作（稠密矩陣相乘、卷積和通信）以及一些循環(huán)層類型。在開源的代碼中有一個(gè) Excel 表格描述了所有的大小。

      前向和后向的運(yùn)算都會被測試。該基準(zhǔn)的第一代版本將注重在 32 位浮點(diǎn)算法中的訓(xùn)練表現(xiàn)。未來的版本可能擴(kuò)展到注重推理工作負(fù)載（inference workloads）和更低精度的算法。

      即使存在更快的獨(dú)立庫或公開了更快的結(jié)果，我們也將使用供應(yīng)商提供的庫。大部分用戶將默認(rèn)使用供應(yīng)商提供的庫，而且這種庫更代表用戶的體驗(yàn)。

1.3. Entry

      我們正在釋放在 4 個(gè)硬件平臺上的結(jié)果：英偉達(dá)的 TitanX、M40、TitanX Pacal 和英特爾的 Knights Landing。硬件供應(yīng)商或獨(dú)立用戶可運(yùn)行大致的基準(zhǔn)，并將結(jié)果輸入到表格中。

2. 運(yùn)算的類型

2.1 稠密矩陣相乘

      稠密矩陣相乘存在于大部分深度神經(jīng)網(wǎng)絡(luò)中。它們被用于執(zhí)行全連接層和 vanilla RNN，以及為其他類型的循環(huán)層建立基石。有時(shí)它們也被用作快速執(zhí)行新類層（在這里面自定義的代碼不存在）的方式。

      當(dāng)執(zhí)行 GEMM 運(yùn)算 A * B = C 時(shí)，A 和 B 中的一個(gè)或兩個(gè)都能被隨意的換位。描述一個(gè)矩陣問題的常用術(shù)語是 triple（M,N,K）, 該術(shù)語描述了矩陣的大小。

2.2 卷積

      卷積構(gòu)成了網(wǎng)絡(luò)中在圖像和視頻操作上的絕大多數(shù)的浮點(diǎn)計(jì)算，也構(gòu)成了語音和自然語言模型網(wǎng)絡(luò)中的主要部分，從模型表現(xiàn)角度來看，它可能也是唯一最重要的層。

      卷積有 4 或 5 維的輸入和輸出，為這些維提供了大量可能的排序。在改基準(zhǔn)的第一代版本，我們只考慮了在 NCHW format 中的表現(xiàn)，即數(shù)據(jù)是在圖像、特征映射、行和列中展示的。

      有很多計(jì)算卷積的技術(shù)對不同大小的過濾器和圖像來說都是很好的選擇，包括：direct approaches、基于矩陣相乘的方法、基于 FFT 的方法以及基于 Winograd 的方法。在該基準(zhǔn)的第一代版本，我們沒考慮不同方法的準(zhǔn)確率，因?yàn)槠毡楣沧R是 32 位浮點(diǎn)計(jì)算對它們每個(gè)方法而言都是足夠準(zhǔn)確的。

2.3 循環(huán)層（recurrent layers）

      循環(huán)層總是由之前的運(yùn)算與一元（unary）或二元（binary）運(yùn)算這樣的簡單計(jì)算結(jié)合而成的——這些簡單運(yùn)算不是計(jì)算密集型的，通常只需占據(jù)總體運(yùn)算時(shí)間的一小部分。然而，在循環(huán)層中，GEMM 和卷積運(yùn)算相對較小，所以這些更小運(yùn)算的成本變得有極大影響。如果開始計(jì)算就有一個(gè)很高的固定成本，那上述內(nèi)容就尤其準(zhǔn)確。也可以為循環(huán)矩陣使用額外的存儲格式，因?yàn)檗D(zhuǎn)換成一個(gè)新的存儲格式的成本可被分?jǐn)偟窖h(huán)計(jì)算的許多步驟上。如果能做到這一點(diǎn)，那么從一個(gè)自定格式轉(zhuǎn)換或轉(zhuǎn)換成一個(gè)自定義格式的時(shí)間應(yīng)該被包含在整體時(shí)間之內(nèi)。

       在一個(gè)時(shí)間步驟內(nèi)和跨序列的時(shí)間步驟上，這些因素會導(dǎo)致很多優(yōu)化的可能性，因此測定運(yùn)算的原始性能并不一定能夠代表整個(gè)循環(huán)層的的性能。在這樣的基準(zhǔn)上，我們僅關(guān)注一個(gè)循環(huán)層，即使還存在其它更多的優(yōu)化機(jī)會（如果考慮它們的層疊（stack））。

      輸入的計(jì)算不應(yīng)該被包含在用于循環(huán)層計(jì)算的時(shí)間內(nèi)，因?yàn)槠淇梢宰鳛橐粋€(gè)大的乘法計(jì)算，然后被實(shí)際的循環(huán)運(yùn)算所消化。所以在 h_t = g(Wx_t + Uh_t-1) 中，Wx_t 對于所有 t 的計(jì)算時(shí)間不應(yīng)被包含在循環(huán)層的時(shí)間內(nèi)。

      反向計(jì)算應(yīng)該在考慮權(quán)重而非輸入的基礎(chǔ)上計(jì)算更新（update）。所有的循環(huán)工作完成以計(jì)算權(quán)重更新，所以同時(shí)考慮輸入來計(jì)算更新會掩蓋我們想要測定的內(nèi)容。

      vanilla RNN 的非線性應(yīng)該是一個(gè) ReLU。LSTM 的內(nèi)在非線性應(yīng)該是標(biāo)準(zhǔn)運(yùn)算——門（gate）是 S 型函數(shù)，激活（activation）是雙曲正切函數(shù)。LSTM 不應(yīng)該有窺視孔連接（peephole connections）。

2.4. All-Reduce

      現(xiàn)在的神經(jīng)網(wǎng)絡(luò)通常在多 GPU 或多系統(tǒng)與 GPU 并行的情況下訓(xùn)練，這主要有兩個(gè)技術(shù)分類：同步和異步。同步技術(shù)依賴于保持參數(shù)和所有模型實(shí)例的同步，它通常要保證在優(yōu)化步驟執(zhí)行前，所有模型實(shí)例有一些梯度的備份。最簡單運(yùn)行這些計(jì)算結(jié)果的 Message Passing Interface (MPI) 被稱為 All-Reduce。有很多可以執(zhí)行 All-Reduce 的方法，我們可以依靠數(shù)字的排列、數(shù)據(jù)的大小和網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)來執(zhí)行。這種基準(zhǔn)測試的方式在執(zhí)行時(shí)是沒有限制的，所以它的結(jié)果是不確定的。異步的方法則非常的不同，在這個(gè)版本的基準(zhǔn)測試中我們不會測試這些方法。

      為了評估 All-Reduce，我們使用了下面的庫和基準(zhǔn)：NVIDIA's NCCL Ohio State University (OSU) Benchmarks

      NCCL 庫包括一組標(biāo)準(zhǔn)的通信程序。這個(gè)庫支持在單個(gè)節(jié)點(diǎn)任意數(shù)量的 GPU 運(yùn)行，并且它能在單個(gè)或多個(gè)進(jìn)程中運(yùn)行，但 NCC 程序不支持多節(jié)點(diǎn)下的 All-Reduce。為了能夠在多節(jié)點(diǎn)下評估 All-Reduce，我們使用了 OSU 下的 benchmark。我們在三個(gè)執(zhí)行過程中 (NCCL single process, NCCL MPI, OpenMPI) 報(bào)告了最短的延遲。

Nvidia 8 GPU 系統(tǒng)的拓?fù)浣Y(jié)構(gòu)

       每個(gè)節(jié)點(diǎn)都有兩個(gè) GPU 插槽，而每個(gè)插槽都有一個(gè) PCIe root complex。每個(gè)節(jié)點(diǎn)都有兩個(gè) GPU 插槽，而每個(gè)插槽都有一個(gè) PCIe root complex。每一套插槽都有兩個(gè) PLX 開關(guān)，它們通過 16 個(gè) PCIe v3 的 lanes 各自連接到 CPU 插槽中。每個(gè) PLX 插槽有兩個(gè) GPU，所有的 GPU 通過 16 個(gè) PCIe v3 的 lanes 進(jìn)行同時(shí)通信。這兩個(gè) CPU 插槽通過 Intel 的 QPI 連接，而跨界點(diǎn)的互聯(lián)則是通過 InfiniBand FDR。下圖顯示了一個(gè)原理圖的節(jié)點(diǎn)，在圖中，所有的設(shè)備均由同一個(gè)虛線框內(nèi)的 PCL root 連接。

       英特爾 Xeon Phi 和 Omni-Path 系統(tǒng)的拓?fù)浣Y(jié)構(gòu)

       MPI_AllReduce 時(shí)間是在英特爾 Xeon Phi 7250 處理器上測定的——在英特爾內(nèi)部的帶有 fat-tree 拓?fù)涞?Intel® Omni-Path Architecture (Intel® OPA) series 100 fabric 結(jié)構(gòu)的 Endeavor 集群上，使用了 Intel MPI 5.1.3.181。

3. 結(jié)果

      在這部分，我們記錄了一些運(yùn)算的表現(xiàn)。下面這些結(jié)果是隨機(jī)挑選的，它們只是為了演示幾個(gè)應(yīng)用的運(yùn)算表現(xiàn)。下面的結(jié)果僅包括了特定操作和參數(shù)下最快的處理器的時(shí)間和浮點(diǎn)運(yùn)算速度。完整的結(jié)果可以在庫里查看。

      這些軟件庫（例如 cuDNN 和 OpenMPI）和一些硬件系統(tǒng)的細(xì)節(jié)同樣在 github 的庫里適用。如有問題，請隨時(shí)和我們聯(lián)系。

      一旦更多硬件平臺的結(jié)果被發(fā)現(xiàn)可以適用，它們都會被加到庫里面來。我們也歡迎所有硬件廠商為此貢獻(xiàn)結(jié)果。

3.1. GEMM Results

3.2. Convolution Results

3.3. Recurrent Ops Results

      周期性的操作內(nèi)核僅能在 NVIDIA 的硬件上運(yùn)行，而周期性的標(biāo)準(zhǔn)檢查程序也將很快可以在 Intel 的硬件上運(yùn)行。在今年十月份我們將會得到這些結(jié)果。

3.4. All-Reduce Results

      因?yàn)槲覀儍H僅只有一個(gè) Pascal GPU，所有我們不能在 NVIDIA's TitanX Pascal GPU 運(yùn)行 All-Reduce benchmark。