1、前言
推薦領域算法模型的在線推理是一個對高併發、高實時有較強要求的場景。算法最初是基於Wide & Deep相對簡單的網絡結構進行建模，容易滿足高實時、高併發的推理性能要求。但隨着廣告模型效果優化進入深水區，基於Transformer用戶行爲序列和Attention的建模逐漸成爲主流，這個階段模型的特點是參數的體量、網絡結構複雜度呈指數級增長，算法建模的創新工作往往由於吞吐和耗時的性能算力問題，導致無法落地於在線推理獲得效果收益。傳統通過擴容資源的方式，其邊際效應也在減弱，算力優化存在諸多挑戰：
1、高算力需求下的資源成本邊際效應問題：集羣資源擴容是提升算力的一種傳統方案，但算力需求的增加往往需要成倍數的資源增長才能抹平，帶來了極強的邊際遞減效應。
2、複雜算法模型的在線推理算力擴展問題：推理引擎要求低延遲和高吞吐，而隨着模型算法複雜度提升，突破計算資源算力上限（存儲、計算），推理耗時顯著增加，無法滿足實時推薦系統的性能要求。
針對上述挑戰和問題，廣告算法架構在迭代演變的過程中，構建了一系列的優化體系，主要集中在兩個方面：
1、架構層面：設計分佈式分圖異構計算框架，通過模型分圖，分佈式推理實現算力的向外擴展；CPU&GPU異構硬件差異化部署，算法結構與計算硬件資源相得益彰，最大化硬件適配性，實現算力的指數級增長。算力擴展的架構使得後續垂向優化成爲可能，可以針對特定業務需求進行深度定製和調整。
2、高算力推理引擎層面：從底層架構出發，GPU算子調度和計算邏輯精細化優化，深入挖掘GPU專用計算設備的潛力，實現對推理性能的顯著提升。
2、分佈式分圖異構計算框架
分佈式分圖異構計算框架是我們針對算力擴展問題提出的解決方案，通過模型結構化拆分，分佈式分圖計算，CPU&GPU異構硬件差異化部署，使算法結構與計算硬件資源高度適配，充分發揮各自優勢。基於CPU計算集羣構建大規模稀疏模型建模，利用內存資源易擴展等優勢，支撐千億規模參數的高性能推理。基於GPU計算集羣構建稠密模型建模，利用高算力優勢，支撐超長用戶行爲序列建模，爲算法建模的創新提供了堅實的架構基礎。我們基於該框架進一步研發並落地了京東零售首個Online Learning建模場景，使得模型可以感知人、貨、場的實時變化。同時GPU服務集羣作爲獨立於整體服務體系的組成部分，便於針對GPU推理引擎進行專項優化，從而便捷地進行性能提升措施的實施。
圖1 分佈式分圖異構計算框架
3、高算力推理引擎
爲了打造高算力推理引擎，開始深入調研基於GPU推理引擎優化推理性能的可行性，GPU作爲一種高度並行的多核處理器，具備極強的並行計算能力，由於GPU高度並行化的結構，先天適合以稠密矩陣計算爲主的NLP、CV領域。但直接應用於推薦領域會存在TP99耗時上漲，資源利用率不高等問題。這主要與推薦領域模型的自身特點相關：
1、建模過程複雜：爲建模用戶與商品關係，推薦領域模型建模不僅包含DNN等稠密計算部分，還存在大量針對稀疏特徵的Embedding建模方式以及特徵預處理等模塊，集合了IO密集與計算密集兩大特性，造成計算過程與GPU親和性不高，難以充分發揮GPU的硬件優勢。
2、模型規模大：推薦領域模型以稀疏參數爲主，百G規模參數無法完全加載至GPU顯存，稀疏參數交換導致帶寬需求高，造成GPU無法充分利用。
3、模型結構複雜：用戶行爲序列建模成爲模型建模的主流方法，而用戶特徵的多樣性（瀏覽行爲、購買行爲、加購行爲）需要單獨建模以提升模型對用戶的感知能力，因此造成模型分支結構多，結構複雜。TensorFlow推理框架雖然提供了算子級別的建模方案，通過堆疊細粒度算子完成各種複雜的模型建模，靈活的支撐了多種行爲序列建模方式。但也因此造成了算子粒度過細，單算子計算量小，不易於GPU充分調度的問題，尤其是對於在線推理本身計算量就相對較小的場景問題更爲致命。
得益於分佈式分圖異構計算框架，有效解決了上述1，2問題，並且可以讓我們針對GPU算子調度和計算邏輯精細化優化，深入挖掘GPU專用計算設備的潛力，實現對推理性能的顯著提升。具體工作體現在以下三個方面：a）TensorBatch：通過聚合計算請求提升GPU計算吞吐；b）深度學習編譯器：通過自動化的算子融合、圖優化等方式優化模型推理性能；c）多流計算：通過打造GPU多計算通道，構建真正的並行計算推理引擎。
3.1、TensorBatch
廣告精排模型推理主要表現是單個請求耗時較短(毫秒級)，同時每個請求中gpu kernel調用次數較多，每次gpu kernel的調度都會伴隨相應的kernel launch，瑣碎繁多的kernel launch會嚴重製約GPU模型的吞吐能力，同時會導致模型系統耗時較高，通過Nsight性能分析性能數據如下。
圖2 大批量KernelLaunch操作
kernel launch 本質上是從host端核函數調用到GPU開始計算之間的這段時間，主要包括準備計算需要數據的傳輸和執行需要warp線程束的獲取，無論是數據的傳輸還是選取執行所需要的warp線程束，多個請求之間是可以實現共享的，因此我們核心解決問題的思路是將多個模型推理請求合併成一個請求，完成模型推理後在對結果再進行合理的分割，減少請求級別 kernel launch 的數量，極大的提升kernel launch的效率，從而進一步提升GPU模型的吞吐能力，架構方案如 圖3， 例如 1個模型請求經過tensorflow推理需要進行 1000 次 kernel launch，3個請求需要3000次kernel launch，如果將3個請求合併成1個請求，那麼kernel launch數量會從3000 降至1000。
圖3 Tensor Batch架構圖
請求級別算子融合在廣告精排模型進行全量上線，在GPU利用率不變的情況下，GPU模型吞吐能力提升2倍。請求級別融合本質是優化GPU kernel launch 效率，但是優化GPU kernel launch 效率方案不止一種，下面詳細介紹一下基於"深度學習編譯器"的算子融合。
3.2、深度學習編譯器
KernelLaunch效率問題優化方面，我們首先採用了TensorBatch方案，在廣告算法場景，調試聚合數量在5-8左右較爲合適（聚合後廣告數200-1000）。雖然對請求進行了聚合，但算子執行的TimeLine仍較稀疏，如圖5所示，該現象解釋了GPU無法得到充分利用的原因。針對這一現象，我們進一步研發了基於深度學習編譯器的算子融合方案，通過算子融合n次 KernelLaunch至1次，大大降低整體KernelLaunch耗時，同時通過圖優化等策略進一步提升模型的推理性能。
圖4 GPU Kernel計算稀疏
3.2.1 深度學習編譯器分桶預編譯技術
XLA（Accelerated Linear Algebra）是google開源的深度學習編譯器，將高級別的模型描述轉換成高效的可執行代碼，自動化的解決算子融合、內存管理、數據佈局轉換等問題。該框架已融合進Tensorflow開源框架中，並提供較友好的編程接口。但原生深度學習編譯器在推薦領域模型應用方面存在一系列問題：
a）同一個XLA Graph針對不同的Tensor輸入屬性（數量、維度、類型）會觸發不同的編譯流程，形成多個XLA Runtime（編譯結果），導致開源方案只適用於CV領域，定長輸入（圖像維度不變）的場景。推薦領域模型變長特徵（用戶行爲序列）的存在使得在推理過程構建萬級別數量的XLA Runtime（編譯結果），在顯存消耗上不可接受。
b）Tensorflow-XLA爲運行時編譯（JIT），編譯過程緩慢，通常完成一個XLA Runtime的編譯耗時長達1秒，且對CPU、GPU資源佔用較大，在廣告高實時場景下，耗時不可接受。
針對上述問題，我們研發了深度學習編譯器分桶預編譯技術。爲避免不同特徵維度導致的多次編譯問題，首先對算法結構進行XLA子圖劃分，形成多個XLA子圖。其次針對XLA子圖的輸入特徵變長情況，實現分桶Padding能力，降低XLA Runtime編譯數量，解決了編譯中遇到的顯存問題。最後通過模型XLA子圖分桶標記算法，在模型加載階段進行預編譯，解決運行時編譯耗時問題。
在深度學習編譯器技術加持下，我們將廣告推薦精排模型的算子調度次數從553次優化至190次，XLA子圖模塊的算子執行的TimeLine得到極大改善，單次推理耗時從14ms優化至9ms。
圖5 XLA Runtime
3.2.2 深度學習編譯器異步編譯技術
通過深度學習編譯器分桶預編譯技術，我們解決了99.9%的問題，但仍有異常流量導致特徵維度超出預設的分桶範圍，導致觸發運行時編譯的可能。作爲一個高穩定的在線系統，我們進一步實現了異步編譯技術，解決異常流量帶來的耗時問題：
a）模型構圖方面，同時保留XLA子圖與模型原圖。
b）推理過程動態選擇，命中分桶情況則選擇XLA Runtime執行，未命中則選擇原圖執行，同時服務後臺觸發異步XLA編譯，供下次請求使用。
圖6 深度學習編譯器異步編譯
3.3、多流計算
圖7 GPU多流計算背景
Tensorflow深度學習框架雖然提供了GPU計算能力，但其CPU到GPU的交互通道僅爲單通道模式。在線併發推理的場景下，存在算子調度互斥、算子計算阻塞排隊等問題。針對上述痛點我們設計了GPU多通道模式-多流計算架構，真正實現了GPU的併發計算能力。
我們對Tensorflow框架中的底層GPU通道的創建和分配機制進行了深入的改造與升級，賦予了其在面對同一模型時，針對不同的在線請求，動態選擇GPU通道進行運算的能力。每個GPU通道獨立持有一份CUDA Stream和CUDA Context，既消除了算子併發調度導致的GPU資源爭搶問題，也使得不同請求擁有獨立的計算通道，提升GPU並行粒度。
圖8 多GPU通道
多GPU通道（多CudaStream + 多CudaContext）解決了KernelLaunch調度問題，算子調度可以並行執行，減少了執行的GAP。但在GPU硬件層面，CudaContext採用分時複用原則，即此某一時刻只有一個CudaContext被調度執行，沒有完全達到算子計算間的並行。
圖9 GPU Kernel交錯計算
MPS + 多流計算框架實現真正意義的並行計算
MPS侷限性：MPS(Multi-Process Service)是英偉達爲充分利用GPU資源的一種解決方案。MPS多進程服務，每個進程有自己的上下文管理機制，MPS使用合併共享的並行模式，即將多個任務合併成一個上下文，因此可以同時跑多個任務，是真正意義上的並行。但MPS方案需要多進程服務的場景下才能生效，這種情況下單卡顯存無法承載多進程任務，顯存成爲瓶頸，MPS機制失效，無法充分利用GPU算力。
圖10 Multi-Process Service侷限性
因此，我們升級了多流計算架構，將MPS與自研的多CudaStream + 多CudaContext的多流計算架構相結合，解決了顯存瓶頸的問題，最終通過單進程模型部署實現真正的並行計算。
圖11 GPU Kernel並行計算
綜上，我們實現了完整的GPU多流計算框架：創建多組通信渠道打通軟件和硬件通道，融合調度Context實現真正的計算並行化。
圖12 GPU多流計算架構圖
4、總結
綜上，通過設計高性能的計算方案，打造新一代算法架構推理體系，在架構層面通過分佈式分圖異構方案很好的解決了高算力需求下的資源成本邊際效應問題，在高算力推理引擎層面，通過一系列的專項優化，讓GPU的算力得到充分的釋放，實現複雜算法模型算力的擴展。目前新一代的高性能計算方案已經在廣告多個業務線進行了落地實踐，推薦首頁CTR模型、推薦通用信息CTR模型、推薦商詳CTR的規模擴展至千億，助力推薦、搜索等核心業務取得顯著的效果收益。
高性能算法推理系統是算法架構體系的重要組成部分，爲算法建模的創新提供了算力基礎，算力優化是一個極富挑戰性的領域，它需要我們在技術層面上不斷進行探索、學習和創新。目前，我們正在着手規劃下一代推理算法架構體系，其最顯著的特點將是算法、計算能力和架構的深度融合，以及在線和離線一體化的設計方案。
感謝廣告架構師小組的架構師們和算法方向的專家們在算法架構體系建設方面提供的寶貴指導建議。同時我們誠摯地邀請對此領域感興趣的同事們加入我們的討論。相信通過大家的共同努力和協作，一定能夠在這個前沿領域取得突破，爲未來的推理算法架構體系開闢新的可能性和機遇。
掃一掃，與作者技術交流一下吧！