導讀 本文主題為基於 GPU 的超大規模離散模型訓練框架 PaddleBox 和 FeaBox。
文章包括以下幾部分：
1. PaddleBox、FeaBox是什麼
2. 鳳巢 CTR 模型演算法及框架演進
3. PaddleBox：基於 GPUBox 的大規模離散模型訓練框架
4. FeaBox：基於 GPUBox 的一體化特徵抽取框架
5. PaddleBox、FeaBox 在百度的應用情況
分享嘉賓｜焦學武 百度 主任架構師
編輯整理｜胡俊琪
出品社群｜DataFun
01
首先介紹一下什麼是 PaddleBox 和 FeaBox
PaddleBox 是百度打造的一個基於 GPUBox 的大規模離散模型訓練框架。它是業界第一個能夠使用全 GPU 去做大規模離散 DNN 訓練的訓練框架。事實上使用 GPU 去訓練模型很常見，但是目前業界基本上都是採用 GPU 去做 Dense 模型的訓練，Sparse 模型因為它的規模特別大，規模通常有 10 個 T 級別，視訊記憶體存不下。在百度之前還沒有公司將 Sparse 引數放到 GPU 裡去做 GPU 訓練，所以目前百度是相對領先的。目前 PaddleBox 使用一臺機器 GPU 就可以實現千億維特徵、萬維引數的模型訓練。模型體積是 10T 級別的，目前在商業範圍已經覆蓋了排序和召回的所有場景。不僅單機能訓練這麼大的規模，而且可以透過多機去進行橫向擴充套件，以支援更大的模型或者去處理更大的樣本以及進行更快的訓練，透過分散式的 GPU 去做加速。整體來說，PaddleBox 框架具有相比傳統解決方案低成本、高效能、高穩定這些優勢。其中低成本、高效能、高穩定主要是來源於 GPU 的優勢，靈活易用主要是來源於 PaddlePaddle 開源生態。這套方案相比傳統 MPI 的解決方案具備 5～40 倍價效比的提升。PaddleBox 框架主要是用來做大規模的 DNN 訓練。與它配套的另一個是 FeaBox 框架，它也是基於 GPUBox 打造的一套框架，是用來做一體化的特徵抽取。這套框架在業界也是屬於比較領先的一個框架，它採用的是抽取和訓練一體化的方式，跟 PaddleBox 組成一對組合，一邊抽特徵一邊去訓練模型。這樣 PaddleBox 和 FeaBox 一起就可以實現用 GPU 既做模型訓練，又做特徵抽取，從而獲得非常高的價效比提升。鳳巢 CTR 模型演算法及框架演進
在介紹框架之前，首先了解一下百度鳳巢在 CTR 模型方面的一些演算法以及框架的演進。
在國內，百度做大規模離散模型的歷史是非常久遠的。從百度鳳巢誕生那一天起，就有非常強的離散模型特性。因為在鳳巢系統之前百度是用競價排名的系統，即所謂的價高者得，有誰出錢高就出誰的廣告。但是這個對各方都是有損的。對使用者來說因為相關性很低，所以使用者體驗會比較差。對於廣告主，它可能會投放了一些廣告，但展現的並不是他的目標使用者。同時對於百度自身來說，也是影響營收的。因此百度鳳巢從誕生的一天起，它最大的特點就是引入了廣告的質量這一概念，我們希望把質量高的廣告推薦出來，推薦給他所匹配的人群。在 2009 年百度鳳巢誕生最開始用的就是大規模的 LR 模型。LR 模型是非常簡單的，但是百度的 LR 規模特別大，能達到幾百億倍的超大規模。一直持續到 2013 年，都是這類的技術模式。它在演算法層面上採用的是 MPI 並行的 LBFGS 演算法。那之後大規模的模型帶來的功能挑戰給我們迭代帶來比較大的困難，所以我們又開始嘗試連續值 DNN。在 2013 年開始做連續值 DNN，它採用的框架是基於 GPU 的單機的 SGD 最佳化演算法。在 2014 年我們又把前兩階段的工作進行了一些融合，就是大規模並離散的 DNN。DNN 有兩方面的優勢，一方面它有超大的離散能力，同時它又有 DNN 的深度預測能力。這個時候傳統的解決方案已經成為瓶頸，GPU 訓練不了規模太大的模型，因此當時採用的是分散式 CPU 的引數伺服器的並行迭代演算法。到目前它也是業界主流的離散 DNN 的訓練方式。在之後，百度鳳巢不斷的在模型結構，還有各種演算法的最佳化上蓬勃發展，出現了多塔 DNN、序列化建模、路由網路，還有模型量化等各種各樣的創新。在這個時代，我們逐漸走向了使用分散式 GPU 引數伺服器的並行的迭代演算法。分散式 GPU 使得我們可創新的事情越來越多，因為它的算力特別強。
當 2014 年離散 DNN 首次落地的時候，我們採用的是 Abacus 和 Mio 分散式的 MPI 的解決方案。它是我們所知道的國內非常早期的一個落地，且一落地就能夠支援萬億維 10 TB 級別的大規模離散 DNN。模型的訓練在架構上採用的也是分散式 CPU 叢集的解決方案。它是分散式的，可以做模型並行把模型分散到多個 CPU 的節點，能支援更大的規模，同時多個節點也可以加速訓練，使得我們能夠並行地去處理更多樣本。在引數更新上採用的是傳統的 TCP 協議，採用低速的網路進行引數同步。如果是訓練速度不夠，或者說模型規模在加大，我們需要不斷地進行叢集的擴充。到 2019 年，我們開始嘗試使用 GPU 去訓練大規模離散 DNN 模型。我們實現了業界首次使用一臺 GPU 伺服器進行了大規模離散 DNN 模型的 DNN 的訓練，當時成本也大幅降低，降低了 80% 以上的成本。在訓練的組網方式上，我們當時還是採用百度鳳巢一直以來的 Abacus 的組網方式， Abacus 是我們商業部門自研的一套框架，採用 C++ 的方式去自己構建。同時百度因為在不斷建設和推廣 Paddle 生態，所以在 2020 年我們又開始做 PaddleBox。在這個過程中，我們主要做兩方面的工作：一方面是效能和規模方面的工作，我們不斷對框架進行效能最佳化，對異構引數伺服器不斷最佳化，進一步大幅提升了效能。同時我們也可以支援更大的樣本量以及更大規模的模型。另一方面我們又深度融合入 Paddle 開源生態，給開源生態去做各種貢獻，協助 Paddle 團隊最佳化框架，同時給業務部門也帶來了非常實際的一些收益，使得我們的開發效率大幅的提升，可以不斷引入 Paddle 裡面各種各樣的開源演算法，並且透過 Paddle 裡 python 實現 op 的主要方式，我們的演算法創新更快。同時 2020 年我們也開始做 FeaBox，並開始落地，目前在鳳巢已經有很多的落地。這個時候我們就實現了 FeaBox 和 PaddleBox 在一臺 GPU 伺服器上去做一體化的特徵以及訓練，同時我們也支援透過多臺機器去進行線性加速。03
PaddleBox：基於 GPUBox 的大規模離散模型訓練框架
先來介紹一下百度的大規模離散模型的業務背景。鳳巢從模型誕生以來，特徵的體積就特別大。目前我們瞭解到各個網際網路廣告的業務，總體上其 Sparse 模型一般也都是非常大的，通常都是 T 級別的。百度到了 10 TB 級別，有千億特徵。經統計，我們特徵佔比量比較高，是因為廣告場景有各種各樣的 ID 類特徵，包括廣告 ID 、使用者 ID 、物料 ID ，以及這些 ID 的組合，因此會特別大。比如使用者 ID 可能就是 10 億維的，廣告 ID 可能也有類似量級，再結合 query term 的維度去做組合特徵，很容易就會達到百億維，加上各種各樣的特徵，就會到千億維的規模。同時每一維特徵又會有 1 維到 64 維的這樣更高維度的表徵，所以引數量會在萬億維規模之上。
大規模離散模型最大的特點就在於它的離散模型特別大。反而 Dense 是一個比較常見的普通類似全連線網路的網路，Dense 數量級要比 Sparse 要小很多。我們之前一直採用的都是和業界相似的解決方案，都是基於大規模分散式 MPI 叢集的解決方案。上圖是目前業界常採用的一個經典的引數伺服器的架構。我們之前在百度內部也有這套解決方案，比如 Abacus，以及 PaddlePaddle 開源的 PSlib 也是這樣一種架構。這套架構的價值非常大，它是第一個訓練大部分離散 DNN 的解決方案。透過把稀疏引數分散多個儲存節點實現了模型的並行。同時把樣本也分散到多個計算節點上，實現了資料的並行。但是這套架構也存在不足，體現在幾個方面：
（1）首先訓練效能上，因為使用的是 CPU 做訓練，所以算力有限，無法支援現在各種各樣的複雜模型演算法，模型演算法一複雜，速度就不夠。所以多年來，在大規模離散模型的組網上，變式並不多，沒有辦法去設計複雜的網路。不僅單機算力不夠，也很難透過規模的擴容而提升效能。因為它主流的使用方式上通常都是百臺左右或者是 200 臺左右這樣的規模去做模型訓練。一方面它集訓規模的增長無法在效能上做到線性增長，邊界效益獲得的速度不一定快。另外會有更嚴重的一個問題，節點過多，有嚴重的梯度過期的問題。我們曾經測試過，當 MPI 節點規模大於 200 個以上，它的梯度過期就很嚴重了，開始影響效果。如果大於 500 個節點以上，那效果基本是不可接受的。
（2）穩定性方面，既然用 MPI 叢集一定意味著它的叢集要有一定的規模才能訓得動，那這裡就存在穩定性的問題。比如一臺機器，它的穩定率要求是 999，但是 999 是一個很高的數字了，我們並不能保證所有的場景都有這麼高的數字，即使它能夠滿足這個要求，那如果我們使用 200 個節點，任務掛掉的機率是非常高的，有 18% 的機率，任務還是會掛掉。（3）另外一個問題是成本。有一定規模的公司，在模型訓練方面的資源投入都在數萬臺以上。大家都在採用分散式 CPU 解決方案的時候，在其他的一些領域就不斷地開始一些新的硬體。新的硬體迎來了非常快速的發展。首先在 GPU 的效能上，早期的 K40 到最新的 A100，GPU 的效能增長 150 倍；在視訊記憶體容量上，從 K40 的十幾個 G 增長到了 A100 的 80G，增長了 7 倍。NVLink，GPU 互聯的頻寬上也有 10 倍的增長。在 GPU 的硬體、效能、容量、頻寬山都有大幅的提升。同時在其它一些儲存介質上，有多種選擇。比如最大的有硬碟，最小的有各種的 GPU 的 Cache，看起來速度非常高，但是它的容量比較小，大的儲存像 SSD 只有幾個 T。所以我們在儲存階段上也有越來越多選擇，我們可以權衡效能，去選一個合適的介質。同時在多機方面，機器和機器之間的頻寬也增長非常快。因此新硬體的發展使得 GPU 加速成為 AI 行業的趨勢，包括語言、影像、NLP 等各種各樣的領域，已經全面落地。但是 GPU 在大規模離散場景還沒有，沒有人去用 GPU 去處理大規模稀疏模型這樣的事情。所以我們就提出希望能夠打造一個 PaddleBox （它的前身叫 AI box ）以及 FeaBox 這樣的框架，用 GPU 去做大規模離散模型訓練，並且保證高效能、高穩定、低成本。但我們面臨著一些挑戰，其中最核心的就是大規模離散場景的巨大模型。（1）第一個是儲存挑戰，萬億維引數體積，會有 10 TB 級別的正量級。我們要使用 GPU 做訓練的話，首先要把這個模型存進來。GPU 我們最開始用的是 V100，V100 的單卡視訊記憶體只有 32G，兩者相差了三個數量級，所以儲存挑戰特別大，這也是做整個事情大的前提。（2）第二是效能挑戰，一方面我們知道 GPU 是非常擅長矩陣訓練的，它的計算能力主要是體現在矩陣計算的場景。但是稀疏模型，它主要的處理邏輯都是在做稀疏特徵的處理。矩陣運算，比如最大的 70% 以上操作，包括稀疏引數的查詢更新，以及從稀疏到稠密模型的轉換，還有各種各樣的樣本處理，這些操作並不是 GPU 所擅長的。如果用 GPU 能否獲得我們所希望的收益，這是第二個挑戰。（3）第三個是通訊挑戰，如果使用 GPU 就不可能像 CPU 那樣用上百臺機器去做訓練，成本太高了，而且也不一定會有很大的效能提升。因此給我們帶來了通訊方面的一些挑戰，包括樣本處理上驟降的網路卡數。原來我們 100 臺機器有 100 張網路卡，但是現在如果用一臺機器，就只有一張網路卡，能否支援海量樣本的讀取需求是一個巨大的挑戰。另外在模型訓練上，單節點就要承擔非常大的通訊量，而且我們的通訊資料都是一些稀疏特徵，而不是稠密向量。所以很難去用 GPU 的 AllReduce 或者 AllGather 通訊模式。所以在通訊方面上我們一定是要做很多事情去適配我們的場景。百度在這方面還是有一些優勢的，我們是最早採用大規模離散模型去做業務的廣告系統，因此我們在硬體方面有很多積累。我們的基礎架構部研發了 XMan 百度超級計算機，從 2016 年至今已經迭代了四個大的版本，它是 PaddleBox 和 AIBox 的硬體基礎。在 2016 年就誕生了 XMan 1.0，它有很高的計算密度。在 2017 年，XMan 2.0 又支援了更高的散熱效率，包括風冷夜冷等多種散熱模式。2018 年推出了 XMan 3.0，早期的 PaddleBox、 AIBox 版本就是基於 XMan 3.0 去做的。3.0 是一種雙層的設計，是 CPU 節點和 GPU 的伺服器一種結構的設計，方便我們去做 CPU 和 GPU 的合理配比。在XMan 4.0 上這個架構實現了超融合的一些操作設計，實現了更加靈活的異構硬體配比。這裡就不僅是 CPU 和 GPU 的靈活配比，包括一些綁卡的靈活配比還有 SSSD 的靈活配比。還有 PCIE 佈線方面也可以做靈活的調整。所以，我們要做一個極致的訓練框架，一定是軟硬結合的非常緊密的方式，既要去根據硬體結構去做軟體的設計，同時從軟體反過來又去建議硬體的改造，硬體基礎是我們去做高效能的一個大的前提。
我們在做這套系統的過程中，主要經歷了幾方面的工作。首先是實現了一個單機的方案，核心點是打造一個異構的層次化的引數伺服器。這一套方案實現了一臺 GPU 單機八卡就可以實現 10 TB 級別模型的訓練。整體方案如上圖所示，是一個三層的引數伺服器的架構，最底下的是 SSD 的引數伺服器，中間層是記憶體的引數伺服器，上層是分散式的 GPU 稀疏引數服器。這裡面臨的最大挑戰就是儲存，針對儲存我們做了兩個工作：（1）一個是實現了業界第一個分散式的 GPU 稀疏引數伺服器，以及業界第一個 SSD 的超大的稀疏引數伺服器。另外，三層引數伺服器之間可以實行自動化的協同，使得容量提升了兩個數量級。我們這套架構，使得我們的引數伺服器既獲得了容量又獲得了效能。我們用了各種方法最佳化 SSD 的效能，最後把 SSD 的效能提升到了理論瓶頸，即單卡 3GB。（2）第二個工作是，既然是一個分散式的 GPU 引數伺服器，那它一定涉及到很高頻的通訊，所以我們對通訊的效率要求就特別高。我們提出了兩種解決方案，首先是在 XMan2.0 機型上，我們實現了軟體創新。上圖右邊是 XMan 2.0 硬體的佈局示意圖。這套架構存在的一個問題是 GPU 並不是一個全互聯的元件架構，早期並不是所有的 GPU 之間都是有高速的 NVLink 鏈路的。比如我們再接 8 張卡來看，可以看 0 號的網路卡，這張 GPU 卡跟 123 都是有直接的 NVLink 鏈路的，所以這個通訊效能還是非常快的。但是它跟 5 號網路卡之間因為沒有直連，所以當它們兩個之間傳送資料包的時候，會透過 CPU 節點去傳送，也就是說從 0 號節點走紅色的 PCIE 的鏈路，然後傳送到 CPU 1，然後 CPU 1 再透過 QPI 鏈路走到了 CPU 0，再從 PCIE 才能走到 GPU 5。GPU 的算力是非常強的，但是在這個通訊的過程中，要走低速的 PCIE 以及 QPI 的通訊，效能就非常差了。因為 PCIE 的頻寬只有 16G 但 NVlink 的頻寬有 300G，所以整體效能就沒有辦法去發揮。所以我們做了兩跳通訊的方案，就是在 GPU 卡之間做 P2P 通訊的時候，從來都不使用 PCIE 和 QPI ，我們實現了所有的 GPU 節點之間透過 NVLink。這個方案使我們的互動的效能提升了七倍。後期基於需求，硬體又引入了 NVSwitch 全互聯的架構，從硬體層面就實現了 GPU 之間 PC 的高度空間，使效能得到進一步的提升。這個點是我們融入在 XMAN 3.0 的機型上。在其他方面我們也做了這樣的軟硬一體的最佳化，我們會參考硬體的佈局去做各種最佳化，比如在綁核方面，我們就做了跟傳統的 CPU 解決方案完全不一樣的策略。
儘管 GPU 已經足夠快，但是我們還是希望它能夠有更加好的擴充套件方式。所以我們也要實現一個多機方案，以支援更大的場景、更大的樣本以及更快的訓練。事實上我們還沒有碰到無法處理的規模，因為單機已經能夠處理 10 TB ，多機可以處理幾十 TB 甚至上百 TB 的模型。在多機的方案上，我們主要考慮的是兩個點，首先是要做模型並行，因為我們要支援幾十 T 甚至上百 T 的這樣的模型，所以要做模型分庫，把稀疏引數分割到多臺的 PaddleBox 上。包括兩個層面，一個是 SSD 要支援多機，還有一個層面就是說 GPU 也要支援多機。同時我們還要求在不同的機器之間引數和引數要保證完全一致性，這也是模型的一個要求。當然在這方面，從策略角度，GPU 還是比 CPU 要有更高的優勢的。因為採用 GPU 我們可以用 AllReduce 這類的同步訓練，分散式 CPU 只能做非同步訓練，同步訓練可以獲得更好的一個策略效果。所以我們還要做好引數同步。這裡還是有比較大挑戰的，因為機器和機器之間以及 GPU 之間需要進行超高頻的通訊，我們要與其計算能力相匹配，計算能力非常強，所以要求通訊的能力也非常強。有了基本的方案之後，我們要解決的最大的挑戰就是通訊的挑戰。我們在機器之間的通訊方面做了很多工作，比較核心的一個通訊方面的創新是，既然要用 GPU 做高速通訊，那我們從硬體上影響就要升級網路卡拓撲不能採用傳統的 CPU 透過 CPU 的 TCP 通訊，顯然不能滿足我們 GPU 的高算力的需求。升級的網路卡拓撲，在 GPU 上直接安裝網路卡在多機的 GPU 之間直接進行高速通訊，使得我們的通訊效能提升了一個發展級，就是在工程上實現了一些通訊方的工作。同時在演算法上我們要降低通訊資料量。我們在一臺機器內多卡之間去進行梯度聚合，在多臺機器之間又進行了量化通訊，資料量又降低了原來的1/4。
另外我們還做了大量的軟硬協同的效能最佳化，包括流水線架構。大的架構上我們要讓樣本讀取、樣本解析、引數拉取和模型訓練組成一個大的流水線。在每一個大流水線的每一個階段內部我們又做了系列的小的流水線。這樣我們可以實現網路卡、CPU、GPU 還有 SSD 異構硬體的最大化的並行。在硬體層面我們協同基礎架構去進行 CPU、GPU、SSD 網路卡布局的最最佳化的設計，使得我們能夠得到一個極致的效能。
上圖是 PaddleBox 目前的整體架構，剛才我們介紹的主要是引數伺服器部分。我們把三層異構的引數伺服器抽象成了一個 BoxPS 元件，去深度融合到了 PaddlePaddle，成為 PaddlePaddle 的核心元件。同時我們基於 PaddlePaddle 又實現了一系列廣告相關的業務框架，並且目前已經全面落地。同時藉助 PaddlePaddle 開源生態，也為廣告業務做到了很好的賦能。04
FeaBox：基於 GPUBox 的一體化特徵抽取框架
接下來介紹一下我們的特徵處理框架 FeaBox 的工作。特徵調研是一個非常重要的工作。我們需要從海量的資料中提取優質的樣本，去做模型訓練來獲取策略的收益。所以抽取特徵也是測試創新的基礎，它的需求也是非常頻繁的。通常我們做一次模型迭代，要做幾十次的調研才能最終實現一個全量。中間可能幾次調研才能夠實現一個小流量，幾次的小流量最後才能實現一次置信的收益。
因此特徵調研也是模型迭代的一個重要方向。目前在百度包括搜尋廣告和推薦廣告，在特徵的最佳化方面都有比較高的投入度。業內主要採用的是兩階段的調研模式。早期我們也是這樣的一種調研模式：通常採用 MR 去做特徵抽取，從原始日誌經過幾輪 MR 的處理，產生原始樣本，把原始樣本寫入到用 HDFS，再啟動一個訓練任務。訓練任務從叢集去讀取訓練樣本，產出模型，模型又存到 HDFS 上。這套方案有幾個方面的不足：首先，任務是割裂的模式，一個是訓練任務，一個是推動任務，其間是沒有關係的，應用性上是有問題的。同時 MR 的效能也存在問題。另外還需要佔用大量的樣本儲存。所以我們就提出一個思路，要做一個一體化的方案，也就是 FeaBox 與 PaddleBox 聯合的模式。
上圖上面是我們原來的解決方案，內部系統叫 ADT，後來又演進到瓦利，瓦利是在 ADT 基礎上避免了很多的重複計算，後來又實現流式的瓦利一直迭代到現在的 FeaBox。我們早期的兩階段模式，跟業界是類似的。但我們有一些改進：在基線方面，有基線的複用，就是從全量做一基線，然後從原始樣本去投增量。這裡會有非常大的 IO，即便不是最大的場景，一天中 HDFS 相關的中間資料，IO 也有 200T。也有 15T 以及 4T 上原始資料的讀取。同時我們在特徵任務和訓練任務中間還需要清除十幾 T 的樣本，這是傳統的解法。一個是在原始讀上採用了增量調研，只是增量讀列分。在這一塊的讀取上，我們從原始 40 TB 原始資料的讀取直接降低到了 500G 的增量資料的讀取，所以降低了 95% 以上的 IO。在中間資料上我們將以前的 MR 又改成了流式計算的方式，所以中間的 IO 也都去掉了。因此基線的複用就是增量的讀取以及流式的計算，使得我們的 IO 大幅的降低。同時流式計算也大幅的最佳化了效能。另外因為我們採用一體化的方式，所以儲存也降到了 0。因為我們在 GPUBox 去完成，所以我們打造了一套異構的特徵抽取的框架，支援 CPU 和 GPU 混合的去做特徵抽取，發揮算力優勢。最終我們在調研時，從原來的天級才能看到效果，變成了分鐘級就能看到效果，提交一個任務幾分鐘之後我們就能看到 AUC 的產出。同時相比以前的訓練，效能也提升了 5 到 10 倍，儲存資源直接降到零。
這裡涉及的技術比較多，我們主要還是來討論 GPU 方面的一些工作。我們要使用 GPU 去做特徵抽取，首先要實現一套異構的排程方案。因為並不是所有的運算元都是 GPU 的。一方面，我們可能有一些運算元不是那麼的重，用非 GPU 是 OK 的，所以我們不希望所有的運算元都必須有一個 GPU 的實現；從迭代的角度並不是一個方面的事情，所以我們希望能夠既支援 CPU 又支援 GPU，要實現一套異構的排程方案。如圖所示，我們異構的排程方式經歷了幾個發展階段。我們首先將原始的函式呼叫的特徵處理方式變成了節點依賴的方式。進一步我們又對節點進行分層，來加大我們的並行異構排程的過程。首先我們要做資料的準備，把原始的日誌資料從 CPU 複製到 GPU，然後在 GPU 內部去做裁剪和列儲存。我們希望儘量多的操作在 GPU 完成，因為 GPU 算力明顯更強。同時我們要做一個高效的邊界的排程。這裡主要體現幾個方面：一是我們要做一個好的、依據我們的 DAG 的拓撲實現分層排程。並且在同層之內，我們要儘量使得 CPU 和 GPU 去並行。在同一層內，我們首先去非同步的排程 GPU 節點，讓他去做 GPU 操作。再同步去呼叫 CPU 節點，使得我們在 GPU 和 GPU 這兩硬體之間去並行。另外對於 GPU 這些節點，同層的 GPU 節點，我們還又會做 KernelFusion 來減小 Launch 的開銷。最後在 GPU 透傳之後，再把它的結果列轉行，轉到 CPU 的內部，最後彈出資料。
另外一個比較重要的工作是提高視訊記憶體分配的效率。因為我們的特徵是特別多的，每天有幾億到幾十億的樣本，樣本量特別大。而且還有一個特點是樣本的長度變化非常大，所以我們並不能夠直接使用 GPU 平時的視訊記憶體分配方式，因為 GPU 能夠處理的都是定長的資料，但如果用定長資料，視訊記憶體消耗非常大。加入兩條資料，一條資料可能長度只有幾十個位元組，另一條資料可能是 1k ，如果都按最大長度去申請，那麼視訊記憶體需求顯然是不可能滿足要求的，而且流量也特別大。同時為了滿足 GPU 高計算能力相匹配，視訊記憶體分配的效能要求非常高。而且在視訊記憶體分配的佈局上，要能夠支援擴大視訊記憶體的高效訪問。所以我們要滿足模擬合併的需求。我們實現了動態的視訊記憶體分配的方案。整體思路是要構造一個視訊記憶體池，並且在視訊記憶體池上要進行分層。我們從擴大執行緒級別，將原來的執行緒級別降級到了 block 級別的執行緒，來減輕操作的頻率。同時我們要藉助 cuda 並行的計算能力來加速視訊記憶體的分配。05
PaddleBox、FeaBox 在百度的應用情況
最後介紹 PaddleBox 和 FeaBox 在百度內的應用情況，FeaBox 和 PaddleBox 以及 AI Box 目前在百度廣告已經全面的落地了，已經落地到百度的鳳巢原生和百青藤所有的業務場景。這裡面鳳巢指的是我們的資訊流廣告，百青藤對應的是我們的聯盟廣告。同時我們支援了多種多類模型，包括點選率模型、轉化率模型，還有召回模型能力，並且產生了很好的業務價值。從訓練資源上，價效比相比傳統的解決方案是提升了 5 到 40 倍的。因為不同的模型場景，我們的優勢也是不一樣的，模型越複雜，我們的優勢會越大。同時我們也提供了更大的策略創新空間。剛開始也提到分散式 CPU 並沒有辦法去支援我們複雜的模型。那麼在 GPU 和 Paddle 的靈活性加持之下，策略可操作的空間越來越多。現在我們商業這邊的策略已經不僅僅是早期的全連線模型，而是將各種各樣的，比如 Attention 、Ernie、甚至 CNN 都已經引入到了點選率預估。所以 GPU 運算元和 PaddlePaddle 的結合為我們的商業系統提供了一個更大的策略空間。另外我們的這一套框架目前也不僅僅在廣告場景發揮作用，在其他一些場景也逐漸的去做了一些落地。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024923/viewspace-2939338/，如需轉載，請註明出處，否則將追究法律責任。
