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

1 背景

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

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

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

接下來(lái)，本文將與大家探討美團(tuán)機(jī)器學(xué)習(xí)平臺(tái)提供的新一代CTR預(yù)測(cè)服務(wù)的GPU優(yōu)化思路、效果、優(yōu)勢(shì)與不足，希望對(duì)從事相關(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)，同時(shí)新的SOTA模型也層出不窮，硬件供應(yīng)商由于人力受限，會(huì)重點(diǎn)優(yōu)化常用的經(jīng)典結(jié)構(gòu)，如ResNet。對(duì)于沒(méi)有收斂的結(jié)構(gòu)，官方?jīng)]有端到端的優(yōu)化工具可以支持。
2. CTR模型中通常包含較大的Embedding表結(jié)構(gòu)，要考慮到Embedding表存在顯存放不下的情況。
3. 在典型的推薦場(chǎng)景中，為了達(dá)到更快的POI曝光的目的，模型的時(shí)效性要求很高，在線模型服務(wù)需要提供增量更新模型的能力。

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

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

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

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

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

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

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

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

3 優(yōu)化手段

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

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

3.1 算子融合

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

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

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

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

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

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

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

3.1.2 計(jì)算圖等價(jià)替換

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

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

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

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

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

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

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

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

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

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

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

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

3.4 CPU-GPU分流

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

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

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

4 壓測(cè)性能分析

我們選取一個(gè)模型進(jìn)行線上性能壓測(cè)分析。