GPU在外賣場景精排模型預估中的應用實踐

GPU等專用芯片以較低的成本提供海量算力，已經成爲機器學習領域的核心利器，在人工智能時代發揮着越來越重要的作用。如何利用GPU這一利器賦能業務場景，是很多技術研發者都要面臨的問題。本文分享了美團外賣搜索/推薦業務中模型預估的GPU架構設計及落地的過程，希望能對從事相關應用研發的同學有所幫助或啓發。

1 前言

近些年，隨着機器學習技術的蓬勃發展，以GPU爲代表的一系列專用芯片以優越的高性能計算能力和愈發低廉的成本，在機器學習領域得到廣泛認可和青睞，且與傳統的CPU體系不斷融合，形成了新的異構硬件生態。

在這種技術浪潮之中，很多技術研發者會面臨着這樣的問題：在我們的業務上應用GPU硬件能獲得什麼？如何快速、平滑地從傳統CPU體系基礎上完成切換？站在機器學習算法設計的角度，又會帶來什麼影響和改變？在GPU生態下衆多的技術路線和架構選型中，如何找到一條最適合自身場景的路徑？

美團外賣搜索推薦團隊，也面臨着類似的挑戰和問題。本文我們會分享美團外賣搜索/推薦業務中，模型預估的GPU架構設計與落地過程，並將一些技術細節和測試數據做了詳盡的披露，希望能爲廣大的技術同行提供一些有價值的參考。

2 背景

當前，美團外賣主要通過搜索和推薦兩種流量分發方式，滿足用戶對“萬物到家”的需求。除了首頁的搜索、推薦功能外，重點品類會在首頁增加獨立入口（下文稱之爲“金剛”），每個金剛入口中都有類似於首頁搜索、推薦的區域，而不同場景入口共同服務於外賣的最終成單。首頁、金剛、店內的聯動關係如下圖所示：

面向點擊率（CTR）/轉化率（CVR）預估的深度學習，是每一個電商類搜索/推薦產品中的核心技術，直接決定了產品的用戶體驗和轉化效果，同時也是機器資源消耗的“大戶”。而CTR/CVR精排模型的設計和實踐，也是美團外賣搜索推薦（下稱搜推）技術團隊必須要攻克且不斷追求卓越的必爭之地。

從搜推系統設計的角度上看，不同的搜索、推薦入口會自然形成獨立的調用鏈路。在傳統的模型設計思路下，會對不同入口鏈路、不同漏斗環節的CTR/CVR/PRICE多個目標獨立設計模型，這也是美團外賣搜推過往模型設計的經典方式。而從2021年起，基於多場景全局優化的考量，搜推場景的CTR/CVR預估模型開始逐步走向多模型統一，綜合利用多個入口的數據、結合不同入口自身的業務特點實現多個入口的聯動優化，逐步實現“One Model to Serve All”的目標。

從模型計算實踐的角度上看，外賣精排模型的發展，讓模型Dense網絡的計算量顯著膨脹，以CPU爲計算主力的軟硬件架構已經難以應對算法的發展需求，即便成本消耗大幅加劇，算力天花板仍然“近在咫尺”。而GPU硬件面向稠密計算的算力優勢，恰恰吻合新的模型特點，可以從根本上打破精排模型預估/訓練中的算力困局。因此，從2021年開始，美團外賣搜推場景的深度學習體系開始逐步從純CPU架構走向CPU+GPU的異構硬件計算平臺，以滿足美團外賣模型算法演進對算力的新要求。

本文接下來的內容，會從外賣搜推場景的精排模型設計出發，結合美團實際的軟硬件特點，爲大家詳細分享在外賣精排模型預估領域，從純CPU架構轉型到CPU+GPU異構平臺的探索和實踐過程，供廣大技術同行參考。

3 外賣搜推場景下的精排模型

本章節主要介紹在外賣場景下多模型統一的演進思路、模型特點以及在實踐中的挑戰。本文只對模型設計思路做簡單的說明，引出後續模型計算在GPU落地中的實踐思考。

3.1 精排模型的設計思路

如前文所述，在美團外賣多入口聯動的場景特點下，經典的單體模型設計存在着以下侷限：

首頁推薦與各金剛入口推薦各維護一個精排模型，不僅維護成本高而且訓練數據割裂，導致精排模型不能捕捉到用戶在所有推薦場景的興趣。
推薦場景的精排模型只使用推薦場景的訓練樣本，未利用用戶在其他重要入口的訓練樣本，比如搜索、訂單頁，模型只學習到用戶在局部場景的偏好信息。
推薦場景的訓練樣本中存在Position Bias問題，具體是指用戶點擊一個商家，有可能只是因爲該商家在推薦Feeds中排序位置比較靠前，而非因爲用戶對此商家真正感興趣，此類Bias會引起模型訓練有偏。
多目標之間存在貝葉斯約束，網絡結構中未考慮，CXR=CTR × CVR，CXR預估值應比CTR小，模型在驗證集上會出現CXR比CTR還高的現象，預估不準確。

基於此，在2021年，美團外賣搜推場景提出了向超越單體的多模型統一演進、逐步實現“One Model to Serve All”的思想，這一理念在模型設計中具體體現在：

CTR/CXR多目標的融合，實現多目標預測的模型統一。
場景專家網絡與Attention網絡的融合，實現不同流量入口之間的模型泛化和統一。
領域專屬網絡和共享網絡的融合，實現推薦場景向搜索場景的遷移學習。

隨着外賣精排模型的發展和演進，模型Dense網絡的參數量顯著增加，單次推理的FLOPs達到26M，對CPU計算架構造成了巨大壓力。另一方面，我們採用Float 16壓縮、特徵自動選擇、網絡交叉替代手動交叉特徵等技術手段，將模型由100G縮小到10G以內，並且過程中通過模型的優化，做到了模型效果無損。

綜上，外賣搜推精排模型稠密部分計算複雜、稀疏部分體積可控，這些良好的特性，爲我們在GPU硬件架構上落地推理計算提供了相對適宜的模型算法基礎。接下來，我們將探討如何在高吞吐、低耗時的外賣搜索推薦系統中，利用GPU硬件有效解決外賣精排模型在線預估中的成本和性能問題，並給出我們的實踐過程和結果。

3.2 模型應用的特點與挑戰

在搜索/推薦技術領域中，稀疏模型預估（CTR/CVR）是決定算法效果的核心要素，模型預估服務是搜索推薦系統中必不可少的組成部分，業內各大公司已有很多經典的實現方案。在討論具體實踐之前，先介紹一下我們的場景特點：

① 需求層面

模型結構：如前文介紹，外賣場景下的精排模型的稠密網絡部分相對複雜，單次推理的FLOPs達到26M；而模型的稀疏部分經過大量的優化，體積得到了有效的控制，模型規模在10G以內。
服務質量要求：推薦服務作爲經典的高性能To C場景，業內大部分同類系統的超時控制在百毫秒量級，分解到預估服務，超時一般需要控制在十毫秒的量級。

② 軟件框架層面

開發框架：模型開發採用TensorFlow框架[1]。作爲主流的深度學習第二代框架，TensorFlow具備強大的模型表達能力，這也導致其算子粒度比較小，這一特點無論是對CPU還是GPU架構都會帶來很大的額外開銷。
在線服務框架：採用TensorFlow Serving框架[2]。基於此框架，可將離線訓練好的機器學習模型部署到線上，並利用rpc對外提供實時預估服務。TensorFlow Serving支持模型熱更新及模型版本管理，主要特點是使用靈活，性能較好。

③ 硬件層面

機型特性：美團基於提升算力密度的考量，在預估服務採用了GPU BOX機型。相對於傳統的GPU插卡機型，這一類機型每張GPU卡配套的CPU和內存相對有限，這需要我們在設計在線服務時，精細化的考量CPU、GPU上的計算和數據分佈，達到更好的利用率均衡。
GPU固有屬性：GPU kernel大體上可以劃分爲傳輸數據、kernel啓動、kernel計算等幾個階段[3]，其中每個kernel的啓動需要約10us左右。因此，GPU預估會面臨一個普適問題，大量的小算子導致每個kernel的執行時間很短，kernel啓動的耗時佔了大部分。相鄰的kernel之間需要通過讀寫顯存進行數據的傳輸，產生大量的訪存開銷。而GPU的訪存吞吐遠遠低於計算吞吐，導致性能低下，GPU的利用率並不高。

總結而言，與業內其他主流搜推場景相對比，我們的CTR模型預估場景有兩個明顯特點：

稠密網絡部分計算複雜度高，相對的，稀疏網絡在模型設計環節經過了大量的優化，體積相對較小。
使用GPU BOX機型，單GPU卡的CPU配額受限，需要針對性優化CPU的計算負荷。

基於這兩個特點，我們在面向GPU的優化實踐中就可以更具針對性了。

4 模型服務架構概覽

本章節簡要介紹美團外賣搜推在線預估服務的整體架構和角色分工，也是外賣搜推精排模型在GPU落地實踐的工程系統基礎。

系統關鍵角色

Dispatch：承擔着特徵獲取和特徵計算的職能，如前文所述，美團使用GPU BOX機型搭建預估服務，推理計算的CPU資源本身就十分喫緊，因此自然會考慮將在線特徵工程部分獨立部署，避免CPU資源的搶佔。本部分和GPU實踐關係不大，不是本文的重點。
Engine：承擔着模型在線推理的職能，通過RPC的方式輸入特徵矩陣、輸出預估結果。採用GPU BOX機型（單容器8核+1 NVIDIA Tesla T4），平均響應時間需控制在20ms以內，下文所述GPU優化實踐主要面向這一模塊的特點進行。
Booster：在模型更新過程中離線執行的模型優化器，內部以Optimizer插件的方式，混合了手工優化器插件和DL編譯優化器插件，是下文所述GPU優化操作的執行者。

5 GPU優化實踐

本章節將展開分享精排模型預估計算在GPU架構落地中的優化過程。

與CV、NLP等經典機器學習領域不同，以CTR模型爲代表的稀疏模型由於結構多變、包含大量業務特化等原因，硬件供應商難以對這一類未收斂的模型結構提供端到端優化工具。因此，在CTR模型大規模應用的領域中，一般會結合GPU特性，面向使用場景對模型執行Case By Case的優化措施。按模型優化的目標來區分，可以大致分類爲系統優化和計算優化：

① 系統優化：一般指通過對計算、存儲、傳輸的調度，使CPU+GPU的異構硬件體系可以更有效率的協同和被使用。典型的系統優化包括：

設備擺放
算子融合
GPU併發/流水線優化

② 計算優化：一般指面向硬件特性，優化模型前向推理網絡的結構設計和算子執行邏輯，使模型推理計算在GPU上的計算開銷更小，效率更高。典型的計算優化包括：

冗餘計算去除
量化計算
高性能庫的應用

在本文介紹的優化工作中，我們對上述常見優化中的大部分思路進行了探索和實踐，下文會逐一進行闡述，並給出優化效果和麪向實際場景的總結分析。

5.1 系統優化

5.1.1 設備擺放

TensorFlow會爲計算圖中每個Node自動設置Runtime Device，計算較重者放置在GPU，計算較輕者放置在CPU。在複雜計算圖中完成一次完整的inference，數據會在CPU和GPU之間反覆傳輸。由於H2D/D2H傳輸很重，這會造成數據傳輸耗時遠大於op（operator）內部計算耗時，在GPU下模型一次預估耗時爲秒級別，遠高於只使用CPU時的耗時。此外，如前所述，我們所使用的GPU機型上CPU資源受限（一張T4卡僅對應8核CPU），這也是我們在異構架構設計中需要解決的核心技術挑戰。

爲解決TensorFlow自動設定Runtime Device不合理的問題，我們爲計算圖中每個Node手動Set Runtime Device。考慮到CPU資源受限，我們儘量的將計算較重的子圖（包括Attention子圖、MLP子圖）放置在GPU計算，計算較輕的子圖（主要爲Embedding查詢子圖）放置在CPU計算。

爲進一步減少設備間數據傳輸，我們在CPU和GPU之間增加Concat op和Split op，CPU數據先Concat到一起再傳輸到GPU，之後再按需Split成多份並傳給對應op，將H2D/D2H從上千次降低到數次。如下圖所示，設備擺放優化之前，有大量的H2D數據傳輸；優化之後，H2D減少爲3次，優化效果十分明顯。

5.1.2 All On GPU

完成基本的設備擺放優化後，計算較輕的Sparse查詢部分在CPU完成，計算較重的Dense計算部分在GPU完成。雖然CPU上計算較輕，但壓測發現其仍舊是整體吞吐瓶頸。考慮到整體計算圖較小（約2G），我們自然的想到是否可以將整圖放在GPU執行，繞開CPU配額的限制，此即All On GPU。爲了將原在CPU進行的Saprse查詢改爲在GPU執行，我們新增了LookupTable op的GPU實現。如下圖所示，HashTable放置在GPU Global Memory，它的Key與Value統一存儲在Bucket中。針對輸入的多組Key，利用多個Block的Threads並行查詢。

同時，爲提高GPU利用效率，降低kernel launch開銷，我們利用TVM對計算圖進行編譯優化（下文會進行詳細介紹）。優化後的All On GPU模型圖解決了CPU資源受限帶來的瓶頸，整體吞吐提升明顯（qps 55->220，約4倍）。

5.1.3 算子融合

外賣搜推精排模型十分複雜，計算圖中包含上萬個計算Node。GPU上執行計算圖時，每個Node都有kernel launch開銷，多個Node之間還有訪問顯存開銷。此外，TensorFlow框架本身在Node執行時會帶來一定開銷，每個Node執行時都會創建、銷燬Input/Output Tensor，內存控制引入額外成本。因此，計算圖中Node過多會嚴重影響執行效率。爲解決這一問題，常用的方法是進行算子融合，即在計算結果等價的前提下，將多個Node融合成一個Node，儘量降低計算圖Node數量，這樣既可以將Node之間的訪問顯存開銷轉爲訪問寄存器開銷，同時也可以減少計算圖中每個Node帶來的固定開銷。

算子融合主要通過三種方式進行：

特定算子手動融合。例如模型訓練階段中，針對一個Embedding Table會有多個Node訪問，在線預估階段可將其融合成一個Node，即查詢Node和Embedding Table一一對應。此後可進一步融合算子，一個Node負責查詢多個Embeddding Table。
常見算子自動融合，主要是利用TensorFlow Grappler[4]優化器進行算子自動融合。
利用深度學習編譯器自動融合，下文會詳細進行介紹。

5.2 計算優化

5.2.1 FP16低精度優化

一方面，在CPU架構下，爲了降低內存開銷，已經將Embedding Table壓縮爲FP16[5]存儲，但是計算時仍會展開爲FP32，這引入了轉換開銷；另一方面，模型預估僅進行模型圖的前向計算，使用低精度計算引入的誤差較小。因此，業界普遍使用低精度方式進行模型預估計算。

針對當前的業務場景，我們嘗試了FP16、INT8[6]等低精度計算，FP16半精度計算對模型效果無明顯影響，INT8量化則會造成效果衰減。因此，我們採用FP16半精度計算的方式，在不影響模型效果的前提下，進一步提升預估服務的吞吐。

5.2.2 broadcast優化

模型圖中的數據可以分爲user和item兩類。通常情況下，請求中包含一個user以及多個item。在模型Sparse部分，user和item分別獲取Embedding；在模型Dense部分，兩類Embedding組合成矩陣後進行計算。經過深入分析，我們發現模型圖中存在冗餘查詢和計算。如下圖橙色部分所示，在模型Sparse部分，user信息先被broadcast成batchsize大小再去查詢Embedding，導致同一個Embedding查詢了batchsize次；在模型Dense部分，user信息同樣被broadcast成batchsize大小，再進行之後所有計算，實際上在和item交叉之前不必broadcast user，同樣存在冗餘計算。

針對以上問題，我們對模型圖進行了手工優化，如下圖紫色部分所示，在模型Sparse部分，user信息只查詢一次Embedding；在模型Dense部分，user信息與item交叉時再broadcast成batchsize大小，即整體上將user信息的broadcast後置。

5.2.3 高性能庫應用

使用CPU時，可以利用Intel MKL[7]庫對計算進行加速。受限於CPU硬件特點，加速效果有限。使用GPU時，我們可以利用Tensor Core[8]進行加速計算。每個Tensor Core都是一個矩陣乘累加計算單元，當前使用的NVIDIA T4卡具有320個Tensor Core，在混合精度計算時算力爲65 TFLOPS，在單精度計算時算力爲8.1 TFLOPS，具有極強的推理性能。在TensorFlow中，可利用cuBLAS[9]調用Tensor Core進行GEMM加速計算，利用cuDNN[10]調用Tensor Core進行CNN、RNN網絡加速計算。

5.3 基於DL編譯器的自動優化

隨着深度學習網絡越來越複雜（Wider And Deeper），硬件設備越來越多樣（CPU、GPU、NPU），神經網絡的優化工作也變得越來越困難。在單一硬件、單一框架上的優化會受到優化庫限制，很難進一步調優。在不同硬件、不同框架的優化又很難做到通用，優化很難移植。這導致優化神經網絡時，需要大量的手動調優工作，成本很高。

爲了降低手動優化的成本，業界普遍使用深度學習編譯器（Deep Learning Compiler）對計算圖進行自動調優。比較流行的深度學習編譯器包括TensorRT[11]、TVM[12]、XLA[13]等，我們在當前的模型場景下利用深度學習編譯器做了較多的優化嘗試，下文會詳細進行介紹。

5.3.1 基於TensorRT的嘗試

TensorRT是NVIDIA推出的高性能深度學習推理優化框架，支持自動算子融合、量化計算、多流執行等多種優化手段，並且可以針對具體kernel選擇最優實現。TensorRT的各優化均通過對應開關控制，使用很簡單；但是整體閉源，並且支持的算子不多，只能對計算圖的部分算子做優化，遇到不識別的算子則會跳過，十分影響優化效率。利用TensorRT優化後的計算圖，仍舊存在大量op，整體性能提升有限。爲解決這個問題，我們從以下兩個角度進行嘗試。

① 手動切分子圖

利用TensorRT進行圖優化時，會先利用Union Find算法在全圖中尋找可識別op並將其聚類，每個聚類進行具體的編譯優化，併產生一個對應的TRTEngineOp。由於計算圖中存在大量不識別op，對聚類過程造成了干擾，即使可識別OP也不一定能完成聚類，則無法進行對應編譯優化，造成優化效率較低。爲解決這一問題，圖優化前我們先進行手動切圖，將全計算圖切分爲若干個子圖，每個可識別op都放入對應子圖中，並將子圖送入TensorRT進行優化。通過這一方法，有效解決了可識別op未優化的問題，有效降低了全圖OP數量。

② 算子替換

如前所述，TensorRT支持OP類型有限，全圖中存在大量TensorRT無法識別的op，導致優化效率偏低。爲了緩解這一問題，我們將TensorRT不識別的OP儘量替換成其支持的等價op。例如下圖中，TensorRT無法識別Select op，我們將其替換成TensorRT支持的Multiply op，並將Select關聯的ExpandDims op從圖中消掉。經過類似的等價轉換操作，有效降低了未識別op數量，提高了編譯優化覆蓋率。

5.3.2 基於TVM的嘗試

在嘗試TensorRT優化時我們發現，TensorRT對TensorFlow的算子覆蓋率較低（只能覆蓋約50+算子），在當前的模型計算圖中，有十多個算子無法支持。即使經過複雜的算子替換優化工作，仍然存在多個算子難以替換。由此我們思考採用其他的深度學習編譯器進行圖優化。

TVM是陳天奇團隊推出的端到端機器學習自動編譯框架，在業界廣泛使用。和TensorRT相比，TVM代碼開源，具有更強的拓展性和定製能力。此外，TVM支持的TensorFlow算子超過130個，算子覆蓋率遠超TensorRT。在當前計算圖中，TVM不支持的OP只有自定義的LookupTable，這一OP負責查詢Embedding，無需進行編譯優化。

因此，我們嘗試利用TVM取代TensorRT對當前計算圖進行自動編譯優化。考慮到TensorFlow對TensorRT、XLA均做了官方支持，實現了對應的wrapper op，但目前尚未支持TVM，我們對TensorFlow做了適配改造，採用和TensorRT類似的方式，實現了TVMEngineOp以支持TVM。考慮模型特點，我們將計算較重的Attention子圖和MLP子圖放入了TVMEngineOp中，利用TVM進行編譯優化，如下圖所示：

6 性能表現與分析

本章節展示實際生產環境下的測試數據，並分析上文一系列業內典型優化思路，在我們的特定場景下的表現及其背後原因。

壓測環境中，CPU環境爲32核Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz+32G內存，GPU環境爲8核Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz+Tesla T4 GPU+16G內存。上圖中，左圖對比了不同QPS下（x軸），精排模型在不同優化手段下的推理耗時（y軸），其中base-gpu表示只經過簡單的圖優化並在GPU計算，trt表示經過TensorRT優化並在GPU計算，tvm表示經過TVM優化且疊加All On GPU優化並在GPU計算；右圖表示極限QPS下，不同優化手段對應的CPU和GPU利用率。從圖中可以看出：

只利用CPU進行預估計算時，極限qps爲55，此時CPU利用率已經高達76%，成爲瓶頸。
利用常規手工優化（設備擺放+算子融合+Broadcast優化+高性能庫）的GPU預估時，相同qps下latency大幅降低，且可以將極限qps提升至85（較CPU版提升55%）。到達極限吞吐時GPU利用率並不高，瓶頸仍舊爲CPU利用率。
利用TensorRT優化預估（手工優化+TensorRT+FP16）時，得益於圖編譯優化，相同qps下latency降低約40%。由於瓶頸仍爲CPU，極限吞吐未變化。
利用TVM優化預估（手工優化+TVM+FP16+All On GPU）時，將所有OP都放置於GPU計算，CPU只負責基本的RPC，極大緩解了CPU配額的瓶頸。相同qps下latency大幅降低約70%，極限吞吐大幅提升約120%。到達極限吞吐時，GPU利用率較高，成爲瓶頸。

經過一系列優化，整體吞吐提升約4倍（qps從55->220），優化效果十分明顯。

7 總結

綜上，我們針對美團外賣場景的業務特點，將經典的CTR/CVR模型從多入口、多環節、多目標的單體模型，逐步演進到“One Model to Serve All”的多模型統一形態。

同時，結合美團的硬件條件和基礎，實現了純CPU預估架構向CPU+GPU異構架構的切換，在固定成本前提下，有效的釋放了算力空間，計算吞吐提升了近4倍。針對GPU BOX機型對CPU資源的限制，我們採用手工優化+DL編譯優化結合、模型網絡計算All On GPU的思路，有效的提升了GPU在模型預估計算中的利用率，並在本文中詳細分享了GPU落地中的優化過程和實測數據指標。

8 作者簡介

楊傑、俊文、瑞東、封宇、王超、張鵬等，來自到家事業羣/到家研發平臺/搜索推薦技術部。
王新、陳卓、駃飛等，來自基礎研發平臺/數據科學與平臺部/數據平臺中心。

9 參考文獻

閱讀美團技術團隊更多技術文章合集

前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試

| 在公衆號菜單欄對話框回覆【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容，敬請註明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行爲，請發送郵件至[email protected]申請授權。