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

1 背景

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

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

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

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

2 CTR模型GPU推理的挑戰

2.1 應用層的挑戰

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

2.2 框架層的挑戰

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

2.3 硬件層的挑戰

第一，TensorFlow的算子粒度劃分較細，導致一個模型通常由幾千個算子構成，這些算子在GPU上的執行轉變為對應的GPU kernel的執行。kernel是GPU上并行執行的函數。

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

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

在經過充分調研與討論后，我們決定第一期重點關注TensorFlow框架下如何解決常見CTR模型結構在英偉達GPU上執行效率不高的問題，我們先將問題收斂為以下兩個子問題：

1. 算子粒度過細，GPU執行效率低下。
2. 模型結構多變，手工優化投入大，通用性差。

3 優化手段

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

經過廣泛的調研和對比，我們最終選擇了TVM作為優化工具。TVM通過編譯手段，可以較好地應對多變的模型結構，解決了手工優化通用性差的問題。但TVM應用在業務模型也存在一系列問題：支持的算子數較少，而且目前對動態Shape的支持還不夠好。針對這兩個問題，我們將TVM和TensorFlow結合起來，結合CTR模型的結構特點與GPU的硬件特性，開發一系列流程，實現了對CTR模型的優化。

3.1 算子融合

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

可以看到，上圖中的左右等價結構，左側的21個算子執行的運算，可以在1個等價算子中完成。反映到GPU的活動上，左側至少有21個GPU kernel以及21次顯存的讀寫，而右側只需要執行1個kernel以及1次顯存讀寫。對于每個融合后的算子，需要有對應的kernel實現。然而，模型的算子組合是無窮的，對每種融合后算子手工實現kernel是不現實的。TVM通過編譯手段，可以自動進行算子的融合以及設備代碼生成，避免了逐一手寫kernel的負擔。

3.1.1 TF-TVM自動切圖優化

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

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

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

在推理階段，優化過的子圖使用TVM執行，其余的計算圖使用TensorFlow原生實現執行，將兩者結合共同完成模型的推理。由于TVM和TensorFlow的Runtime各自使用獨立的內存管理，數據在不同框架間傳輸會導致額外的性能開銷。為了降低這部分開銷，我們打通了兩個框架的底層數據結構，盡可能避免額外的數據拷貝。

3.1.2 計算圖等價替換

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

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

3.2 CPU-GPU數據傳輸優化

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

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

3.3 高頻子圖手工優化

對于TVM無法支持的子圖，我們對業務中高頻使用的結構進行抽象，采用手寫自定義算子的方式，進行了高效GPU實現。

例如，模型中有部分時序特征使用String類型輸入，將輸入的字符串轉為補齊的數字Tensor，將int類型的Tensor作為下標進行Embedding操作。這部分子圖的語義如圖，以下簡稱SE結構（StringEmbedding）：

這一部分結構，TensorFlow的原生實現只有基于CPU的版本，在數據量較大且并行度較高的情景下，性能下降嚴重，成為整個模型的瓶頸。為了優化這部分結構的性能，我們在GPU上實現了高效的等價操作。

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

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

除了StringEmbedding結構，我們對StringSplit + Tonumber + SparseSegmentSqrt、多路并行StringEmbedding等結構都進行了高效融合實現，在優化流程中通過結構匹配進行相應的替換。

3.4 CPU-GPU分流

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

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

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

4 壓測性能分析

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