作為圖片屆的“Twitter”，Pinterest首頁展示給用戶的圖片也離不開背后的推薦模型。近期，其工程團隊通過將機器學習服務從CPU轉移到GPU上，使得Pinterest可以上線比之前大100倍的推薦模型。上線大模型給模型質量帶來了階躍式的提升，最終將Pinterest首頁feed流的用戶活躍度提高了16%。

【資料圖】

在本文中，他們分享了如何只經過微小的投入和延遲的成本實現這一優化目標，這包括優化特定算子，整合內存傳輸，通過CUDA Graph技術在設備上執行靜態圖，以及分布式系統的重新設置。他們的實踐證明，要想提高模型效果，模型參數就得變大，而使用GPU服務方案的經濟效益遠超CPU服務方案。

來源｜Pinterest Engineering

翻譯｜鄭澤康

Pinterest的使命是給每個人帶來創造他們所熱愛生活的靈感。為了實現這一使命，我們所有產品中都包含的一個關鍵組件就是各式各樣的推薦模型，它們負責在合適的時間給合適的人展示合適的內容。我們的推薦模型是通過高級算法進行訓練的一系列機器學習模型，用于理解用戶在Pinterest上花費時間時的行為，這些推薦模型是通過定制的機器學習模型服務器（Scorpion Model Server, 即SMS）來運行的。

SMS 上需要面對十分艱巨的技術挑戰，基于3000多億個Pin的語料庫，它必須在毫秒內為4億多個用戶提供相關推薦。之前，SMS在CPU上進行模型推理，其內核經過了多年的優化以滿足我們對延遲和基礎設施成本的嚴格要求，但即使最新一代的CPU也幾乎達到了SMS服務的極限。我們必須非常審慎地確保，每次因模型變化而帶來的延遲和基礎設施成本的增加都是合情合理的。

機器學習領域里模型參數和計算量增加的趨勢讓問題變得更加嚴峻。在推薦系統中，具有1000億參數量的模型已經很常見，并在業內常被提及。

在Pinterest，我們采用了稍微不同的方式，通過使用諸如Transformer的現代模型架構來擴大模型。在更大模型下，我們立即觀測到模型準確率發生的質變——其大幅提升了Pinner（譯注：Pinterest用戶）的參與度。但是，在CPU服務器上運行這些現代模型架構幾乎讓成本和延遲都提升了40倍，這一代價難以承受。因此，我們轉而尋求使用GPU來加速模型推理，從而可以使用合理的成本來運行這些模型。

1

優化

當我們嘗試那些開箱即用的GPU服務時，很快意識到在經濟高效地利用GPU運行推薦模型服務之前需要對其優化。我們首先使用分析工具來分析在模型推理過程中發生了什么，在仔細觀察分析結果時，我們注意到時間線上有大量的小CUDA Kernel在執行。

這是推薦系統模型的預期行為，其中數百個特征在模型后期階段進行特征拼接之前需要單獨處理。然而，對于大量的小算子，啟動CUDA Kernel帶來的開銷比計算開銷還要昂貴。與訓練時的batchsize相比，模型服務時的batchsize相對更小，進而加劇了這一問題。

上圖分別是模型優化前和優化后的分析結果。CUDA Kernel時間線（用紅框突出顯示）表明，Kernel的啟動開銷（藍色塊之間的間隙）顯著減少，因此GPU得到了更好得利用，它將大部分時間花費在Kernel執行中。

2

減少小op的數量

我們采取的第一個方法是找出減少小op數量的機會。我們尋找常被使用的模型組件，并盡可能對其優化。其中一個例子是Embedding的查表模塊，它包含兩個計算步驟：原始ID到索引的查找，索引到Embedding的查找。由于我們有大量特征，這兩步操作會被重復數百次。通過使用cuCollections?(https://github.com/NVIDIA/cuCollections)?以支持GPU上原始ID的哈希表，并實現了自定義的Embedding查找模塊以合并多個查找操作，我們顯著地減少了op的數量。在執行一些優化后，馬上看到了更優的性能表現。

3

合并內存拷貝

同樣，當我們在主機和GPU顯存之間搬運Tensor時，也存在整合數據傳輸的機會。通用推薦模型里的一個候選樣例通常會使用數百個特征作為輸入，對于每一次推理，各個特征作為一個單獨的tensor被拷貝到GPU顯存中。雖然在主機和GPU顯存之間搬運數據非常快，但是為每個請求調度數百個cudaMemcpy()函數調用的開銷很快成為瓶頸。

從主機單獨拷貝Tensor到 GPU?vs?一次拷貝整個內存緩沖區

為了解決這個問題，我們應用了一個簡單的優化將cudaMemcpy()調用次數從幾百次減少到一次：不再使用Torch框架將Tensor單獨移動到GPU上，而是先將所有Tensor的數據放置到一塊預先分配好的連續內存緩沖區中，并一次性將緩沖區內容拷貝到GPU里，最終通過指向GPU顯存緩沖區的不同偏移量來重構得到GPU上的所有張量。

該優化帶來的代價是要顯式管理預先分配的內存緩沖區的生命周期，以及需要對不同數據類型手動處理GPU顯存對齊。但作為結果，P50數據拷貝延遲從10ms 降低到1ms以下，這證明了該優化帶來的復雜性是可以接受的。

4

利用CUDA Graph

為了進一步優化模型推理過程，我們使用CUDA Graph(https://pytorch.org/blog/accelerating-pytorch-with-cuda-graphs/)來完全消除剩余小op的開銷。CUDA Graph允許我們將模型推理過程捕捉為靜態圖，而不是單獨調度。它可以讓整個計算作為一個單元進行執行，而不產生任何Kernel啟動開銷。我們支持將CUDA Graph作為模型服務的一個新后端。一開始加載模型時，模型服務執行一次模型推理以構建圖實例，該實例可以針對實時流量重復執行。

CUDA Graph在一個批處理內（下圖）執行Kernel，而不是在一個序列中逐個執行（上圖），這減少了Kernel之間CPU啟動帶來的開銷。圖表來自：https://pytorch.org/blog/accelerating-pytorch-with-cuda-graphs/

CUDA Graph自身的一些限制給我們的模型服務帶來了額外的復雜性。其中最大的限制是CUDA Graph要求所有Tensor都具有靜態形狀和布局，這對動態大小批次和不規則的變長Tensor帶來了挑戰。然而，我們相信為了獲得更好性能進行的權衡是值得的，并且我們可以將輸入Tensor補齊到精心挑選的靜態形狀。

5

使用更大的batchsize

最后，我們重新研究了SMS為模型推理執行的批處理策略。SMS支持動態批處理，可以讓多個請求合并成更大的批次。它通常能帶來更好的吞吐量，但代價是需要較短的時間以等待請求序列收集足夠多的項（item）。對于CPU上的ML推斷，我們通常想要將請求分成小批量來提高并行度以減小延時。然而對于GPU，其延時對batchsize并不敏感，使用更大的batchsize對GPU提升工作負載效率更重要。

這種batchsize的需求使我們重新思考了SMS里的分布式系統設置。對于CPU上的ML推斷，我們使用scatter-gather結構將原始請求拆分，并在多個葉子結點上并行執行，以獲得更小的延時。

此外，該架構允許我們為每個葉子結點分配一個固定的數據切片，以優化特征提取期間的緩存命中率。然而，由于GPU傾向使用大batchsize，因此刪除root layer直接在原始請求中使用大batchsize更有意義。最終我們使用了CacheLib的混合緩存，它用DRAM和SSD來補償與scatter-gather 架構設置相比的緩存容量損失。

6

結果

我們首先測量了模型單次推理的延時。我們使用c5.18x AWS實例提供CPU服務，g5.4 AWS實例提供GPU服務。

CPU延時隨著batchsize線性增長，在較小的batchsize下，GPU延時幾乎相同，此時Kernel啟動開銷占延時主導因素。然而隨著batchsize增加，實際計算時間主導了延時，GPU延時以亞線性形式增長。在實踐中，GPU效率提升的亮點在于SMS可以使用更大的batch工作。結合了所有優化之后，我們獲得了驚人的結果，相比 CPU 服務，GPU服務在較大batchsize下的每批次的延遲提升了100倍以上。

我們的服務指標也展示了令人印象深刻的結果。通過優化模型操作，重新設置分布式系統以及優化數據傳輸并使用CUDA Graph，我們以30%的更低延時上線了77倍大的模型，并以適當成本增加了20%的吞吐量。

最后，兩個數量級效率提升開啟了Pinterest最先進的推薦模型架構。可以看到，模型質量顯著地提升直接轉化為更高的用戶參與度。在過去的一年，我們以適當的基礎設施成本將一個主要產品的用戶參與度提升了16%。很快，我們將推出比我們的CPU模型大100倍的最大模型。

7

結論

將基于CPU模型服務轉換成基于GPU服務的過程很復雜，但這是我們在Pinterest使用最先進推薦模型的一個必要步驟。我們能夠以適當的成本提供大100倍的推薦模型，這為我們的機器學習工程師給Pinner解鎖更相關和響應更迅速的推薦內容提供了基礎。

（本文經授權后編譯發布，原文：

https://medium.com/pinterest-engineering/gpu-accelerated-ml-inference-at-pinterest-ad1b6a03a16d）

其他人都在看

OneFlow v0.8.0正式發布

18張圖，直觀理解神經網絡、流形和拓撲

Geoffrey Hinton：深度學習的下一個大事件

分布式深度學習編程新范式：Global Tensor

LLVM之父：為什么我們要重建AI基礎設施軟件

OneFlow源碼解析：算子指令在虛擬機中的執行

大模型訓練難？效率超群、易用的“李白”模型庫來了

歡迎體驗OneFlow v0.8.0：GitHub - Oneflow-Inc/oneflow: OneFlow is a deep learning framework designed to be user-friendly, scalable and efficient.OneFlow is a deep learning framework designed to be user-friendly, scalable and efficient. - GitHub - Oneflow-Inc/oneflow: OneFlow is a deep learning framework designed to be user-friendly, scalable and efficient.https://github.com/Oneflow-Inc/oneflow/

關鍵詞：