1、前言

推薦領(lǐng)域算法模型的在線推理是一個(gè)對(duì)高并發(fā)、高實(shí)時(shí)有較強(qiáng)要求的場(chǎng)景。算法最初是基于Wide & Deep相對(duì)簡(jiǎn)單的網(wǎng)絡(luò)結(jié)構(gòu)進(jìn)行建模，容易滿足高實(shí)時(shí)、高并發(fā)的推理性能要求。但隨著廣告模型效果優(yōu)化進(jìn)入深水區(qū)，基于Transformer用戶行為序列和Attention的建模逐漸成為主流，這個(gè)階段模型的特點(diǎn)是參數(shù)的體量、網(wǎng)絡(luò)結(jié)構(gòu)復(fù)雜度呈指數(shù)級(jí)增長(zhǎng)，算法建模的創(chuàng)新工作往往由于吞吐和耗時(shí)的性能算力問題，導(dǎo)致無法落地于在線推理獲得效果收益。傳統(tǒng)通過擴(kuò)容資源的方式，其邊際效應(yīng)也在減弱，算力優(yōu)化存在諸多挑戰(zhàn)：

1、高算力需求下的資源成本邊際效應(yīng)問題：集群資源擴(kuò)容是提升算力的一種傳統(tǒng)方案，但算力需求的增加往往需要成倍數(shù)的資源增長(zhǎng)才能抹平，帶來了極強(qiáng)的邊際遞減效應(yīng)。

2、復(fù)雜算法模型的在線推理算力擴(kuò)展問題：推理引擎要求低延遲和高吞吐，而隨著模型算法復(fù)雜度提升，突破計(jì)算資源算力上限（存儲(chǔ)、計(jì)算），推理耗時(shí)顯著增加，無法滿足實(shí)時(shí)推薦系統(tǒng)的性能要求。

針對(duì)上述挑戰(zhàn)和問題，廣告算法架構(gòu)在迭代演變的過程中，構(gòu)建了一系列的優(yōu)化體系，主要集中在兩個(gè)方面：

1、架構(gòu)層面：設(shè)計(jì)分布式分圖異構(gòu)計(jì)算框架，通過模型分圖，分布式推理實(shí)現(xiàn)算力的向外擴(kuò)展；CPU&GPU異構(gòu)硬件差異化部署，算法結(jié)構(gòu)與計(jì)算硬件資源相得益彰，最大化硬件適配性，實(shí)現(xiàn)算力的指數(shù)級(jí)增長(zhǎng)。算力擴(kuò)展的架構(gòu)使得后續(xù)垂向優(yōu)化成為可能，可以針對(duì)特定業(yè)務(wù)需求進(jìn)行深度定制和調(diào)整。

2、高算力推理引擎層面：從底層架構(gòu)出發(fā)，GPU算子調(diào)度和計(jì)算邏輯精細(xì)化優(yōu)化，深入挖掘GPU專用計(jì)算設(shè)備的潛力，實(shí)現(xiàn)對(duì)推理性能的顯著提升。

2、分布式分圖異構(gòu)計(jì)算框架

分布式分圖異構(gòu)計(jì)算框架是我們針對(duì)算力擴(kuò)展問題提出的解決方案，通過模型結(jié)構(gòu)化拆分，分布式分圖計(jì)算，CPU&GPU異構(gòu)硬件差異化部署，使算法結(jié)構(gòu)與計(jì)算硬件資源高度適配，充分發(fā)揮各自優(yōu)勢(shì)。基于CPU計(jì)算集群構(gòu)建大規(guī)模稀疏模型建模，利用內(nèi)存資源易擴(kuò)展等優(yōu)勢(shì)，支撐千億規(guī)模參數(shù)的高性能推理?；贕PU計(jì)算集群構(gòu)建稠密模型建模，利用高算力優(yōu)勢(shì)，支撐超長(zhǎng)用戶行為序列建模，為算法建模的創(chuàng)新提供了堅(jiān)實(shí)的架構(gòu)基礎(chǔ)。我們基于該框架進(jìn)一步研發(fā)并落地了京東零售首個(gè)Online Learning建模場(chǎng)景，使得模型可以感知人、貨、場(chǎng)的實(shí)時(shí)變化。同時(shí)GPU服務(wù)集群作為獨(dú)立于整體服務(wù)體系的組成部分，便于針對(duì)GPU推理引擎進(jìn)行專項(xiàng)優(yōu)化，從而便捷地進(jìn)行性能提升措施的實(shí)施。

圖1 分布式分圖異構(gòu)計(jì)算框架

3、高算力推理引擎

為了打造高算力推理引擎，開始深入調(diào)研基于GPU推理引擎優(yōu)化推理性能的可行性，GPU作為一種高度并行的多核處理器，具備極強(qiáng)的并行計(jì)算能力，由于GPU高度并行化的結(jié)構(gòu)，先天適合以稠密矩陣計(jì)算為主的NLP、CV領(lǐng)域。但直接應(yīng)用于推薦領(lǐng)域會(huì)存在TP99耗時(shí)上漲，資源利用率不高等問題。這主要與推薦領(lǐng)域模型的自身特點(diǎn)相關(guān)：

1、建模過程復(fù)雜：為建模用戶與商品關(guān)系，推薦領(lǐng)域模型建模不僅包含DNN等稠密計(jì)算部分，還存在大量針對(duì)稀疏特征的Embedding建模方式以及特征預(yù)處理等模塊，集合了IO密集與計(jì)算密集兩大特性，造成計(jì)算過程與GPU親和性不高，難以充分發(fā)揮GPU的硬件優(yōu)勢(shì)。

2、模型規(guī)模大：推薦領(lǐng)域模型以稀疏參數(shù)為主，百G規(guī)模參數(shù)無法完全加載至GPU顯存，稀疏參數(shù)交換導(dǎo)致帶寬需求高，造成GPU無法充分利用。

3、模型結(jié)構(gòu)復(fù)雜：用戶行為序列建模成為模型建模的主流方法，而用戶特征的多樣性（瀏覽行為、購(gòu)買行為、加購(gòu)行為）需要單獨(dú)建模以提升模型對(duì)用戶的感知能力，因此造成模型分支結(jié)構(gòu)多，結(jié)構(gòu)復(fù)雜。TensorFlow推理框架雖然提供了算子級(jí)別的建模方案，通過堆疊細(xì)粒度算子完成各種復(fù)雜的模型建模，靈活的支撐了多種行為序列建模方式。但也因此造成了算子粒度過細(xì)，單算子計(jì)算量小，不易于GPU充分調(diào)度的問題，尤其是對(duì)于在線推理本身計(jì)算量就相對(duì)較小的場(chǎng)景問題更為致命。

得益于分布式分圖異構(gòu)計(jì)算框架，有效解決了上述1，2問題，并且可以讓我們針對(duì)GPU算子調(diào)度和計(jì)算邏輯精細(xì)化優(yōu)化，深入挖掘GPU專用計(jì)算設(shè)備的潛力，實(shí)現(xiàn)對(duì)推理性能的顯著提升。具體工作體現(xiàn)在以下三個(gè)方面：a）TensorBatch：通過聚合計(jì)算請(qǐng)求提升GPU計(jì)算吞吐；b）深度學(xué)習(xí)編譯器：通過自動(dòng)化的算子融合、圖優(yōu)化等方式優(yōu)化模型推理性能；c）多流計(jì)算：通過打造GPU多計(jì)算通道，構(gòu)建真正的并行計(jì)算推理引擎。

3.1、TensorBatch

廣告精排模型推理主要表現(xiàn)是單個(gè)請(qǐng)求耗時(shí)較短(毫秒級(jí))，同時(shí)每個(gè)請(qǐng)求中g(shù)pu kernel調(diào)用次數(shù)較多，每次gpu kernel的調(diào)度都會(huì)伴隨相應(yīng)的kernel launch，瑣碎繁多的kernel launch會(huì)嚴(yán)重制約GPU模型的吞吐能力，同時(shí)會(huì)導(dǎo)致模型系統(tǒng)耗時(shí)較高，通過Nsight性能分析性能數(shù)據(jù)如下。

圖2 大批量KernelLaunch操作

kernel launch 本質(zhì)上是從host端核函數(shù)調(diào)用到GPU開始計(jì)算之間的這段時(shí)間，主要包括準(zhǔn)備計(jì)算需要數(shù)據(jù)的傳輸和執(zhí)行需要warp線程束的獲取，無論是數(shù)據(jù)的傳輸還是選取執(zhí)行所需要的warp線程束，多個(gè)請(qǐng)求之間是可以實(shí)現(xiàn)共享的，因此我們核心解決問題的思路是將多個(gè)模型推理請(qǐng)求合并成一個(gè)請(qǐng)求，完成模型推理后在對(duì)結(jié)果再進(jìn)行合理的分割，減少請(qǐng)求級(jí)別 kernel launch 的數(shù)量，極大的提升kernel launch的效率，從而進(jìn)一步提升GPU模型的吞吐能力，架構(gòu)方案如 圖3， 例如 1個(gè)模型請(qǐng)求經(jīng)過tensorflow推理需要進(jìn)行 1000 次 kernel launch，3個(gè)請(qǐng)求需要3000次kernel launch，如果將3個(gè)請(qǐng)求合并成1個(gè)請(qǐng)求，那么kernel launch數(shù)量會(huì)從3000 降至1000。

圖3 Tensor Batch架構(gòu)圖

請(qǐng)求級(jí)別算子融合在廣告精排模型進(jìn)行全量上線，在GPU利用率不變的情況下，GPU模型吞吐能力提升2倍。請(qǐng)求級(jí)別融合本質(zhì)是優(yōu)化GPU kernel launch 效率，但是優(yōu)化GPU kernel launch 效率方案不止一種，下面詳細(xì)介紹一下基于"深度學(xué)習(xí)編譯器"的算子融合。

3.2、深度學(xué)習(xí)編譯器

KernelLaunch效率問題優(yōu)化方面，我們首先采用了TensorBatch方案，在廣告算法場(chǎng)景，調(diào)試聚合數(shù)量在5-8左右較為合適（聚合后廣告數(shù)200-1000）。雖然對(duì)請(qǐng)求進(jìn)行了聚合，但算子執(zhí)行的TimeLine仍較稀疏，如圖5所示，該現(xiàn)象解釋了GPU無法得到充分利用的原因。針對(duì)這一現(xiàn)象，我們進(jìn)一步研發(fā)了基于深度學(xué)習(xí)編譯器的算子融合方案，通過算子融合n次 KernelLaunch至1次，大大降低整體KernelLaunch耗時(shí)，同時(shí)通過圖優(yōu)化等策略進(jìn)一步提升模型的推理性能。

圖4 GPU Kernel計(jì)算稀疏

3.2.1 深度學(xué)習(xí)編譯器分桶預(yù)編譯技術(shù)

XLA（Accelerated Linear Algebra）是google開源的深度學(xué)習(xí)編譯器，將高級(jí)別的模型描述轉(zhuǎn)換成高效的可執(zhí)行代碼，自動(dòng)化的解決算子融合、內(nèi)存管理、數(shù)據(jù)布局轉(zhuǎn)換等問題。該框架已融合進(jìn)Tensorflow開源框架中，并提供較友好的編程接口。但原生深度學(xué)習(xí)編譯器在推薦領(lǐng)域模型應(yīng)用方面存在一系列問題：

a）同一個(gè)XLA Graph針對(duì)不同的Tensor輸入屬性（數(shù)量、維度、類型）會(huì)觸發(fā)不同的編譯流程，形成多個(gè)XLA Runtime（編譯結(jié)果），導(dǎo)致開源方案只適用于CV領(lǐng)域，定長(zhǎng)輸入（圖像維度不變）的場(chǎng)景。推薦領(lǐng)域模型變長(zhǎng)特征（用戶行為序列）的存在使得在推理過程構(gòu)建萬級(jí)別數(shù)量的XLA Runtime（編譯結(jié)果），在顯存消耗上不可接受。

b）Tensorflow-XLA為運(yùn)行時(shí)編譯（JIT），編譯過程緩慢，通常完成一個(gè)XLA Runtime的編譯耗時(shí)長(zhǎng)達(dá)1秒，且對(duì)CPU、GPU資源占用較大，在廣告高實(shí)時(shí)場(chǎng)景下，耗時(shí)不可接受。

針對(duì)上述問題，我們研發(fā)了深度學(xué)習(xí)編譯器分桶預(yù)編譯技術(shù)。為避免不同特征維度導(dǎo)致的多次編譯問題，首先對(duì)算法結(jié)構(gòu)進(jìn)行XLA子圖劃分，形成多個(gè)XLA子圖。其次針對(duì)XLA子圖的輸入特征變長(zhǎng)情況，實(shí)現(xiàn)分桶Padding能力，降低XLA Runtime編譯數(shù)量，解決了編譯中遇到的顯存問題。最后通過模型XLA子圖分桶標(biāo)記算法，在模型加載階段進(jìn)行預(yù)編譯，解決運(yùn)行時(shí)編譯耗時(shí)問題。

在深度學(xué)習(xí)編譯器技術(shù)加持下，我們將廣告推薦精排模型的算子調(diào)度次數(shù)從553次優(yōu)化至190次，XLA子圖模塊的算子執(zhí)行的TimeLine得到極大改善，單次推理耗時(shí)從14ms優(yōu)化至9ms。

圖5 XLA Runtime

3.2.2 深度學(xué)習(xí)編譯器異步編譯技術(shù)

通過深度學(xué)習(xí)編譯器分桶預(yù)編譯技術(shù)，我們解決了99.9%的問題，但仍有異常流量導(dǎo)致特征維度超出預(yù)設(shè)的分桶范圍，導(dǎo)致觸發(fā)運(yùn)行時(shí)編譯的可能。作為一個(gè)高穩(wěn)定的在線系統(tǒng)，我們進(jìn)一步實(shí)現(xiàn)了異步編譯技術(shù)，解決異常流量帶來的耗時(shí)問題：

a）模型構(gòu)圖方面，同時(shí)保留XLA子圖與模型原圖。

b）推理過程動(dòng)態(tài)選擇，命中分桶情況則選擇XLA Runtime執(zhí)行，未命中則選擇原圖執(zhí)行，同時(shí)服務(wù)后臺(tái)觸發(fā)異步XLA編譯，供下次請(qǐng)求使用。

圖6 深度學(xué)習(xí)編譯器異步編譯

3.3、多流計(jì)算

圖7 GPU多流計(jì)算背景

Tensorflow深度學(xué)習(xí)框架雖然提供了GPU計(jì)算能力，但其CPU到GPU的交互通道僅為單通道模式。在線并發(fā)推理的場(chǎng)景下，存在算子調(diào)度互斥、算子計(jì)算阻塞排隊(duì)等問題。針對(duì)上述痛點(diǎn)我們?cè)O(shè)計(jì)了GPU多通道模式-多流計(jì)算架構(gòu)，真正實(shí)現(xiàn)了GPU的并發(fā)計(jì)算能力。

我們對(duì)Tensorflow框架中的底層GPU通道的創(chuàng)建和分配機(jī)制進(jìn)行了深入的改造與升級(jí)，賦予了其在面對(duì)同一模型時(shí)，針對(duì)不同的在線請(qǐng)求，動(dòng)態(tài)選擇GPU通道進(jìn)行運(yùn)算的能力。每個(gè)GPU通道獨(dú)立持有一份CUDA Stream和CUDA Context，既消除了算子并發(fā)調(diào)度導(dǎo)致的GPU資源爭(zhēng)搶問題，也使得不同請(qǐng)求擁有獨(dú)立的計(jì)算通道，提升GPU并行粒度。

圖8 多GPU通道

多GPU通道（多CudaStream + 多CudaContext）解決了KernelLaunch調(diào)度問題，算子調(diào)度可以并行執(zhí)行，減少了執(zhí)行的GAP。但在GPU硬件層面，CudaContext采用分時(shí)復(fù)用原則，即此某一時(shí)刻只有一個(gè)CudaContext被調(diào)度執(zhí)行，沒有完全達(dá)到算子計(jì)算間的并行。

圖9 GPU Kernel交錯(cuò)計(jì)算

MPS + 多流計(jì)算框架實(shí)現(xiàn)真正意義的并行計(jì)算

MPS局限性：MPS(Multi-Process Service)是英偉達(dá)為充分利用GPU資源的一種解決方案。MPS多進(jìn)程服務(wù)，每個(gè)進(jìn)程有自己的上下文管理機(jī)制，MPS使用合并共享的并行模式，即將多個(gè)任務(wù)合并成一個(gè)上下文，因此可以同時(shí)跑多個(gè)任務(wù)，是真正意義上的并行。但MPS方案需要多進(jìn)程服務(wù)的場(chǎng)景下才能生效，這種情況下單卡顯存無法承載多進(jìn)程任務(wù)，顯存成為瓶頸，MPS機(jī)制失效，無法充分利用GPU算力。

圖10 Multi-Process Service局限性

因此，我們升級(jí)了多流計(jì)算架構(gòu)，將MPS與自研的多CudaStream + 多CudaContext的多流計(jì)算架構(gòu)相結(jié)合，解決了顯存瓶頸的問題，最終通過單進(jìn)程模型部署實(shí)現(xiàn)真正的并行計(jì)算。

圖11 GPU Kernel并行計(jì)算

綜上，我們實(shí)現(xiàn)了完整的GPU多流計(jì)算框架：創(chuàng)建多組通信渠道打通軟件和硬件通道，融合調(diào)度Context實(shí)現(xiàn)真正的計(jì)算并行化。

圖12 GPU多流計(jì)算架構(gòu)圖

4、總結(jié)

綜上，通過設(shè)計(jì)高性能的計(jì)算方案，打造新一代算法架構(gòu)推理體系，在架構(gòu)層面通過分布式分圖異構(gòu)方案很好的解決了高算力需求下的資源成本邊際效應(yīng)問題，在高算力推理引擎層面，通過一系列的專項(xiàng)優(yōu)化，讓GPU的算力得到充分的釋放，實(shí)現(xiàn)復(fù)雜算法模型算力的擴(kuò)展。目前新一代的高性能計(jì)算方案已經(jīng)在廣告多個(gè)業(yè)務(wù)線進(jìn)行了落地實(shí)踐，推薦首頁CTR模型、推薦通用信息CTR模型、推薦商詳CTR的規(guī)模擴(kuò)展至千億，助力推薦、搜索等核心業(yè)務(wù)取得顯著的效果收益。

高性能算法推理系統(tǒng)是算法架構(gòu)體系的重要組成部分，為算法建模的創(chuàng)新提供了算力基礎(chǔ)，算力優(yōu)化是一個(gè)極富挑戰(zhàn)性的領(lǐng)域，它需要我們?cè)诩夹g(shù)層面上不斷進(jìn)行探索、學(xué)習(xí)和創(chuàng)新。目前，我們正在著手規(guī)劃下一代推理算法架構(gòu)體系，其最顯著的特點(diǎn)將是算法、計(jì)算能力和架構(gòu)的深度融合，以及在線和離線一體化的設(shè)計(jì)方案。

作者：京東零售-平臺(tái)運(yùn)營(yíng)與營(yíng)銷中心-廣告研發(fā)部-系統(tǒng)技術(shù)部-算法應(yīng)用組

來源：京東云開發(fā)者社區(qū) 轉(zhuǎn)載請(qǐng)注明來源