CTR模型在互聯(lián)網(wǎng)的搜索、推薦、廣告等場景有著廣泛的應(yīng)用。近年來，隨著深度神經(jīng)網(wǎng)絡(luò)的引入，CTR模型的推理對硬件算力的要求逐漸增加。本文介紹了美團在CTR模型優(yōu)化的實踐。通過分析模型結(jié)構(gòu)特點，結(jié)合GPU硬件架構(gòu)，我們設(shè)計了一系列流程對模型進行定制優(yōu)化，達到了降低延遲、提高吞吐、節(jié)省成本的目標(biāo)。

1 背景

CTR（Click-Through-Rate）即點擊通過率，是指網(wǎng)絡(luò)廣告的點擊到達率，即該廣告的實際點擊次數(shù)除以廣告的展現(xiàn)量。為CTR指標(biāo)服務(wù)的打分模型，一般稱為CTR模型。我們可以將此概念進一步擴展到互聯(lián)網(wǎng)應(yīng)用中各種預(yù)估轉(zhuǎn)化率的模型。CTR模型在推薦、搜索、廣告等場景被廣泛應(yīng)用。相對于CV（計算機視覺）、NLP（自然語音處理）場景的模型，CTR模型的歷史結(jié)構(gòu)比較簡單，計算量較小。美團的CTR模型一直沿用CPU推理的方式。隨著近幾年深度神經(jīng)網(wǎng)絡(luò)的引入，CTR模型結(jié)構(gòu)逐漸趨于復(fù)雜，計算量也越來越大，CPU開始不能滿足模型對于算力的需求。

而GPU擁有幾千個計算核心，可以在單機內(nèi)提供密集的并行計算能力，在CV、NLP等領(lǐng)域展示了強大的能力。通過CUDA[1]及相關(guān)API，英偉達建立了完整的GPU生態(tài)?；诖耍缊F基礎(chǔ)研發(fā)平臺通過一套方案將CTR模型部署到GPU上。單從模型預(yù)測階段看，我們提供的基于英偉達T4的GPU深度優(yōu)化方案，在相同成本約束下，對比CPU，提升了10倍的吞吐能力。同時，在典型的搜索精排場景中，從端到端的維度來看，整體吞吐能力提升了一倍以上。

除了提高吞吐、降低成本外，GPU方案還為CTR模型的應(yīng)用帶來了額外的可能。例如，在某搜索框自動補全的場景，由于天然的交互屬性，時延要求非?？量?，一般來說無法使用復(fù)雜的模型。而在GPU能力的加持下，某復(fù)雜模型的平均響應(yīng)時間從15毫秒降低至6~7毫秒，已經(jīng)達到了上線要求。

接下來，本文將與大家探討美團機器學(xué)習(xí)平臺提供的新一代CTR預(yù)測服務(wù)的GPU優(yōu)化思路、效果、優(yōu)勢與不足，希望對從事相關(guān)工作的同學(xué)有所幫助或者啟發(fā)。

2 CTR模型GPU推理的挑戰(zhàn)

2.1 應(yīng)用層的挑戰(zhàn)

1. CTR模型結(jié)構(gòu)多變，包含大量業(yè)務(wù)相關(guān)的結(jié)構(gòu)，同時新的SOTA模型也層出不窮，硬件供應(yīng)商由于人力受限，會重點優(yōu)化常用的經(jīng)典結(jié)構(gòu)，如ResNet。對于沒有收斂的結(jié)構(gòu)，官方?jīng)]有端到端的優(yōu)化工具可以支持。
2. CTR模型中通常包含較大的Embedding表結(jié)構(gòu)，要考慮到Embedding表存在顯存放不下的情況。
3. 在典型的推薦場景中，為了達到更快的POI曝光的目的，模型的時效性要求很高，在線模型服務(wù)需要提供增量更新模型的能力。

2.2 框架層的挑戰(zhàn)

1. 算子層面：目前主流的深度學(xué)習(xí)框架，如TensorFlow和PyTorch，可以說是深度學(xué)習(xí)第二代框架，它們首先要解決第一代框架Caffe的問題，Caffe有一個明顯問題就是Layer的粒度過粗，導(dǎo)致那個時代的算法開發(fā)者都必須有“自己寫自定義層”的能力。TensorFlow和PyTorch都把模型表達能力放在較高的優(yōu)先級，導(dǎo)致算子粒度比較小，無論是對CPU還是GPU架構(gòu)，都會帶來很大的額外開銷。
2. 框架層面：TensorFlow和PyTorch本質(zhì)都是訓(xùn)練框架，對算法開發(fā)者比較友好，但非部署友好。其中隱含了很多為了方便分布式訓(xùn)練做的設(shè)計，比如TensorFlow為了方便將Variable拆到不同的PS上，內(nèi)置了Partitioned_Variable的設(shè)計。在基于GPU單機預(yù)測的場景下，這些結(jié)構(gòu)也會帶來額外的開銷。

2.3 硬件層的挑戰(zhàn)

第一，TensorFlow的算子粒度劃分較細，導(dǎo)致一個模型通常由幾千個算子構(gòu)成，這些算子在GPU上的執(zhí)行轉(zhuǎn)變?yōu)閷?yīng)的GPU kernel的執(zhí)行。kernel是GPU上并行執(zhí)行的函數(shù)。

GPU kernel大體上可以劃分為傳輸數(shù)據(jù)、kernel啟動、kernel計算等幾個階段，其中每個kernel的啟動需要約10左右。大量的小算子導(dǎo)致每個kernel的執(zhí)行時間很短，kernel啟動的耗時占了大部分。相鄰的kernel之間需要通過讀寫顯存進行數(shù)據(jù)的傳輸，產(chǎn)生大量的訪存開銷。而GPU的訪存吞吐遠遠低于計算吞吐，導(dǎo)致性能低下，GPU利用率并不高。

第二，GPU卡上包含多個計算單元，理論上，不同計算單元是可以跑不同kernel的，但實際上為了編程簡單，CUDA默認(rèn)假設(shè)在同一時刻一個Stream里跑同一個kernel。雖然可以通過多Stream的方式跑，但是多Steam之間又缺少細粒度的協(xié)同機制。

在經(jīng)過充分調(diào)研與討論后，我們決定第一期重點關(guān)注TensorFlow框架下如何解決常見CTR模型結(jié)構(gòu)在英偉達GPU上執(zhí)行效率不高的問題，我們先將問題收斂為以下兩個子問題：

1. 算子粒度過細，GPU執(zhí)行效率低下。
2. 模型結(jié)構(gòu)多變，手工優(yōu)化投入大，通用性差。

3 優(yōu)化手段

為了解決上面的問題，我們對業(yè)界深度學(xué)習(xí)加速器進行了一些調(diào)研。業(yè)界比較成熟的推理優(yōu)化方案主要是TensorRT/XLA/TVM。TensorRT采用手工優(yōu)化，對一些定制的模型結(jié)構(gòu)進行算子融合，并對計算密集型算子（如卷積）進行了高效調(diào)優(yōu)。XLA是TensorFlow內(nèi)置的編譯優(yōu)化工具，主要針對訪存密集型結(jié)構(gòu)，通過編譯手段，實現(xiàn)算子的融合。TVM[2]具備較全面的優(yōu)化能力，使用編譯手段進行算子的融合，同時可以通過機器學(xué)習(xí)的方式實現(xiàn)計算密集型算子的自動調(diào)優(yōu)。

經(jīng)過廣泛的調(diào)研和對比，我們最終選擇了TVM作為優(yōu)化工具。TVM通過編譯手段，可以較好地應(yīng)對多變的模型結(jié)構(gòu)，解決了手工優(yōu)化通用性差的問題。但TVM應(yīng)用在業(yè)務(wù)模型也存在一系列問題：支持的算子數(shù)較少，而且目前對動態(tài)Shape的支持還不夠好。針對這兩個問題，我們將TVM和TensorFlow結(jié)合起來，結(jié)合CTR模型的結(jié)構(gòu)特點與GPU的硬件特性，開發(fā)一系列流程，實現(xiàn)了對CTR模型的優(yōu)化。

3.1 算子融合

通過將多個小算子融合為一個語義等價的大算子，可以有效減少GPU上的kernel數(shù)量。一方面，kernel數(shù)量減少直接降低了kernel發(fā)射的開銷；另一方面，融合后的大kernel執(zhí)行的計算量增加，避免了多個kernel間數(shù)據(jù)傳輸導(dǎo)致的頻繁訪存，提高了計算的訪存比。

可以看到，上圖中的左右等價結(jié)構(gòu)，左側(cè)的21個算子執(zhí)行的運算，可以在1個等價算子中完成。反映到GPU的活動上，左側(cè)至少有21個GPU kernel以及21次顯存的讀寫，而右側(cè)只需要執(zhí)行1個kernel以及1次顯存讀寫。對于每個融合后的算子，需要有對應(yīng)的kernel實現(xiàn)。然而，模型的算子組合是無窮的，對每種融合后算子手工實現(xiàn)kernel是不現(xiàn)實的。TVM通過編譯手段，可以自動進行算子的融合以及設(shè)備代碼生成，避免了逐一手寫kernel的負(fù)擔(dān)。

3.1.1 TF-TVM自動切圖優(yōu)化

TensorFlow模型中，如果包含TVM不支持的算子，會導(dǎo)致無法執(zhí)行TVM轉(zhuǎn)換。我們的思路是將可以用TVM優(yōu)化的部分切出來，轉(zhuǎn)為TVM的engine，其他部分依然使用TensorFlow的算子。在XLA和TRT轉(zhuǎn)換的時候也有類似問題，我們分析了TF-XLA和TF-TRT二者的實現(xiàn)：

1. TF-XLA的實現(xiàn)方案，在Grappler[4]優(yōu)化圖之后，有一個POST_REWRITE_FOR_EXEC（通過這個關(guān)鍵字可以在源碼中搜索到）階段，在這個階段，會執(zhí)行三個針對Graph的Pass，分別是用來標(biāo)記算子，封裝子圖，改寫子圖并構(gòu)建LaunchOp。
2. TF-TRT的實現(xiàn)方案，TF-TRT在Grappler中注冊了一個優(yōu)化器，在這個優(yōu)化器中，找到連通子圖，并將其替換為TRT Engine。

在最終方案實現(xiàn)上，我們參考了TF-TRT的設(shè)計。這個設(shè)計對比XLA的優(yōu)勢在于XLA切圖方案與TensorFlow源碼緊耦合，直接將XLA的三個Pass嵌入到了啟動Session的主流程中。而切圖策略，優(yōu)化策略后續(xù)會有非常頻繁的迭代，我們不希望與TensorFlow的源碼太過耦合。我們擴展了TF-TVM的方案，在實際使用中我們把這個切圖過程為一個獨立流程。在模型部署或更新時，自動觸發(fā)。

在推理階段，優(yōu)化過的子圖使用TVM執(zhí)行，其余的計算圖使用TensorFlow原生實現(xiàn)執(zhí)行，將兩者結(jié)合共同完成模型的推理。由于TVM和TensorFlow的Runtime各自使用獨立的內(nèi)存管理，數(shù)據(jù)在不同框架間傳輸會導(dǎo)致額外的性能開銷。為了降低這部分開銷，我們打通了兩個框架的底層數(shù)據(jù)結(jié)構(gòu)，盡可能避免額外的數(shù)據(jù)拷貝。

3.1.2 計算圖等價替換

TensorFlow模型中過多的不被TVM支持的算子會導(dǎo)致TF-TVM切圖零碎，影響最終的優(yōu)化效果。為了讓TF-TVM切圖盡量大且完整，以及讓TVM優(yōu)化過程中的融合力度更大，我們對模型中的一些復(fù)雜結(jié)構(gòu)進行檢測，替換為執(zhí)行更高效或更易于融合的等價結(jié)構(gòu)。

例如，TensorFlow原生EmbeddingLookup結(jié)構(gòu)，為了支持分布式訓(xùn)練，會對Embedding表進行切分，產(chǎn)生DynamicPartition和ParallelDynamicStitch等動態(tài)算子。這些動態(tài)算子不被TVM支持，導(dǎo)致TF-TVM圖切分過于細碎。為了讓TF-TVM切圖更完整，我們通過圖替換，對這種結(jié)構(gòu)進行修改，通過將Embedding分表提前合并，得到簡化的EmbeddingLookup結(jié)構(gòu)。

3.2 CPU-GPU數(shù)據(jù)傳輸優(yōu)化

TVM優(yōu)化后的子圖被替換為一個節(jié)點，該節(jié)點在GPU上執(zhí)行，通常有幾十甚至幾百個輸入，該節(jié)點的前置輸入（如Placeholder）通常是在CPU上執(zhí)行，會涉及多次的CPU-GPU傳輸。頻繁的小數(shù)據(jù)量傳輸，無法充分利用帶寬。為了解決這個問題，我們對模型結(jié)構(gòu)進行修改，在計算圖中添加合并與拆分節(jié)點，控制切圖的位置，減少數(shù)據(jù)傳輸?shù)拇螖?shù)。

一種可能的合并方式是，對這些輸入按相同的Shape和Dtype進行合并，后續(xù)進行拆分，將拆分節(jié)點切入TVM的子圖一起優(yōu)化。這種方式會導(dǎo)致一些問題，如部分子圖的算子融合效果不佳；另一方面，GPU kernel函數(shù)的參數(shù)傳遞內(nèi)存限制在4KB，對于TVM節(jié)點輸入非常多的情況（如超過512個），會遇到生成代碼不合法的情況。

3.3 高頻子圖手工優(yōu)化

對于TVM無法支持的子圖，我們對業(yè)務(wù)中高頻使用的結(jié)構(gòu)進行抽象，采用手寫自定義算子的方式，進行了高效GPU實現(xiàn)。

例如，模型中有部分時序特征使用String類型輸入，將輸入的字符串轉(zhuǎn)為補齊的數(shù)字Tensor，將int類型的Tensor作為下標(biāo)進行Embedding操作。這部分子圖的語義如圖，以下簡稱SE結(jié)構(gòu)（StringEmbedding）：

這一部分結(jié)構(gòu)，TensorFlow的原生實現(xiàn)只有基于CPU的版本，在數(shù)據(jù)量較大且并行度較高的情景下，性能下降嚴(yán)重，成為整個模型的瓶頸。為了優(yōu)化這部分結(jié)構(gòu)的性能，我們在GPU上實現(xiàn)了高效的等價操作。

如圖所示，PadString算子在CPU端將多個字符串按最大長度進行補齊，拼接成一個內(nèi)存連續(xù)的uint8類型Tensor，以便一次性傳輸?shù)紾PU。StringEmbedding接收到補齊后的字符串后，利用GPU并行計算的特性，協(xié)同大量線程完成字符串的切分與查表操作。在涉及規(guī)約求和、求前綴和等關(guān)鍵過程中，使用了GPU上的Reduce/Scan算法，編碼過程使用warp_shuffle指令，不同線程通過寄存器交換數(shù)據(jù)，避免了頻繁訪存的開銷，獲得了很好的性能。

GPU Scan算法示意，一個8個元素的前綴和操作，只需要3個迭代周期。在一個有幾十路類似操作的模型中，手工優(yōu)化前后的GPU timeline對比如下圖，可以看到H2D + StringEmbedding這部分結(jié)構(gòu)的耗時有很大的縮減，從42毫秒縮減到1.83毫秒。

除了StringEmbedding結(jié)構(gòu)，我們對StringSplit + Tonumber + SparseSegmentSqrt、多路并行StringEmbedding等結(jié)構(gòu)都進行了高效融合實現(xiàn)，在優(yōu)化流程中通過結(jié)構(gòu)匹配進行相應(yīng)的替換。

3.4 CPU-GPU分流

實際線上的RPC請求，每個請求內(nèi)的樣本數(shù)（下文稱Batch）是在[1,MaxValue]范圍內(nèi)變化的，MaxValue受上游業(yè)務(wù)系統(tǒng)，其他基礎(chǔ)系統(tǒng)能力等多方面因素制約，相對固定。如上圖所示，以某個搜索服務(wù)為例，我們統(tǒng)計了線上的Batch數(shù)值分布，Batch=MaxValue的請求占比約45%，Batch=45占比7.4%，Batch=1占比2.3%。其余的Batch占比從0.5%到1%不等。對于GPU來說，提高單個請求的Batch能更好地利用硬件資源，發(fā)揮GPU的并行計算能力，表現(xiàn)出相對CPU更優(yōu)的延遲和吞吐；當(dāng)Batch較小時，GPU相對CPU的優(yōu)勢就不明顯了（下圖是我們測試同樣的模型在固定壓力下，CPU/GPU上延遲的變化）。

大部分請求都由GPU在做了，CPU資源有較多空余，我們將一些小Batch的碎請求放在CPU運行，這樣可以讓整個Worker的資源利用更加均衡，提高系統(tǒng)整體的性能。我們根據(jù)測試設(shè)定了一個Batch閾值，以及計算圖在異構(gòu)硬件上區(qū)別執(zhí)行的判斷邏輯：對于小Batch的情況，直接在CPU上執(zhí)行計算圖，只有Batch超過閾值的請求才會在GPU上推理。從線上的統(tǒng)計數(shù)據(jù)來看，整體流量的77%跑在GPU上，23%跑在CPU上。

在GPU的一系列優(yōu)化策略和動作中，Batch大小是很重要的信息，不同Batch下優(yōu)化出的kernel實現(xiàn)可能是不同的，以達到對應(yīng)workload下最優(yōu)的計算性能；由于線上的流量特點，發(fā)送到GPU的請求Batch分布比較細碎，如果我們針對每個Batch都優(yōu)化一個模型的kernel實現(xiàn)顯然是不夠經(jīng)濟和通用的。因此，我們設(shè)計了一個Batch分桶策略，生成N個固定Batch的優(yōu)化模型，在實際請求到來時找到Batch距離最近的一個Bucket，將請求向上Padding到對應(yīng)的Batch計算，從而提高了GPU的利用效率。

4 壓測性能分析

我們選取一個模型進行線上性能壓測分析。