丨目錄：

- 前沿

1. 算力需求與供給

1.1 算力需求：模型復(fù)雜度

1.2 算力供給：異構(gòu)硬件計(jì)算能力

1.3 問題與優(yōu)化方法

2. 算法-系統(tǒng)-硬件協(xié)同性能優(yōu)化

2.1 算法優(yōu)化

2.2 系統(tǒng)優(yōu)化：以GPU優(yōu)化為例

2.3 硬件升級(jí)：以含光NPU為例

2.4 性能結(jié)果

-?總結(jié)與展望

???前言

在全球數(shù)字化時(shí)代，數(shù)字廣告產(chǎn)業(yè)舉足輕重，數(shù)字廣告占廣告整體支出的比重逐年上升，2019年數(shù)字廣告支出首次超過傳統(tǒng)廣告；全球數(shù)字廣告市場(chǎng)規(guī)模超過3000億美元[1]，中國數(shù)字廣告市場(chǎng)規(guī)模超過700億美元[2]。對(duì)于國內(nèi)外頭部互聯(lián)網(wǎng)公司，數(shù)字廣告收入在整體營收中均占很大比重。與傳統(tǒng)廣告不同，數(shù)字廣告的收入與點(diǎn)擊率和轉(zhuǎn)化率等投放效果指標(biāo)直接相關(guān)，因此基于深度學(xué)習(xí)的廣告精準(zhǔn)投放是一個(gè)價(jià)值很高的問題。

??1. 算力需求與供給

1.1 算力需求：模型復(fù)雜度

為滿足在線服務(wù)的延時(shí)約束，深度學(xué)習(xí)計(jì)算一般需要CPU與GPU/NPU等加速器的協(xié)同計(jì)算，以CPU-GPU單機(jī)系統(tǒng)為例（如圖1.1），服務(wù)能力（QPS）可以簡(jiǎn)單表示為如下公式：

其中，QPS由請(qǐng)求并行度（parallelism）和延時(shí)（latency）共同決定，α1和α2表示并發(fā)效率，最優(yōu)時(shí)多并發(fā)與單并發(fā)延時(shí)相同，最差時(shí)多并發(fā)等同于串行計(jì)算；對(duì)于每個(gè)請(qǐng)求而言，延時(shí)為CPU和GPU計(jì)算時(shí)間的總和。

圖1.1 CPU-GPU單機(jī)系統(tǒng)[3]

結(jié)合上述公式，我們對(duì)廣告深度學(xué)習(xí)在線服務(wù)做兩點(diǎn)說明：

(1) 在線系統(tǒng)的優(yōu)化目標(biāo)是 latency-bounded QPS。 如圖1.2，請(qǐng)求并行執(zhí)行（parallelism > 1）在一般情況下（cache等共享資源競(jìng)爭(zhēng)不太激烈時(shí)）能有效提高資源利用率（例如CPU和GPU利用率），但并行執(zhí)行時(shí)每個(gè)請(qǐng)求的延時(shí)也將上漲。由于在線系統(tǒng)有比較嚴(yán)格的延時(shí)限制，因此服務(wù)能力不能通過資源利用率簡(jiǎn)單換算，需要在延時(shí)約束下進(jìn)行評(píng)估。當(dāng)系統(tǒng)各種資源利用率均較低，延時(shí)是制約因素時(shí)，優(yōu)化或適當(dāng)放寬延時(shí)可以有效提升系統(tǒng)服務(wù)能力。

圖1.2 多并發(fā)延時(shí)和資源利用率

(2) 模型復(fù)雜度由計(jì)算量和計(jì)算密度共同決定。 CPU/GPU的計(jì)算時(shí)間主要由數(shù)據(jù)移動(dòng)效率（包括CPU/GPU內(nèi)存讀寫、PCIe數(shù)據(jù)傳輸、GPU kernel launch）和計(jì)算效率（CPU/GPU各種計(jì)算單元的速度）決定。需要注意的是，FLOPs是最經(jīng)常被用作評(píng)估模型復(fù)雜度的指標(biāo)，但FLOPs僅直接影響compute_cycles；即使是compute_cycles，FLOPs一般也只能用于評(píng)估MatMul/Conv等計(jì)算密集型算子的復(fù)雜度，對(duì)于訪存密集型算子沒有指導(dǎo)意義。因此，FLOPs只是眾多計(jì)算復(fù)雜度指標(biāo)之一，不能直接換算服務(wù)能力。

對(duì)于GPU等加速器，計(jì)算密集型算子的性能（例如每秒浮點(diǎn)計(jì)算次數(shù)，FLOPS）增長很快，這使得另一個(gè)方面的性能優(yōu)化越來越重要：提升計(jì)算密度，即在模型FLOPs相當(dāng)?shù)那闆r下減少訪存量，減少kernel個(gè)數(shù)，提高FLOPs/byte或FLOPs/kernel_launch。例如：盡量減少使用tensor變換算子（Concat/Split/Transpose等算子）、減少Tile/Gather等算子導(dǎo)致的中間結(jié)果內(nèi)存讀寫膨脹、盡量增大每次請(qǐng)求的batch size等。

1.2 算力供給：異構(gòu)硬件計(jì)算能力

在計(jì)算需求增長的同時(shí)，芯片制造工藝和計(jì)算機(jī)體系結(jié)構(gòu)推動(dòng)計(jì)算機(jī)硬件（處理器、內(nèi)存和外存系統(tǒng)、網(wǎng)絡(luò)互聯(lián)設(shè)備）不斷推陳出新[3]。這里僅簡(jiǎn)述與深度學(xué)習(xí)計(jì)算最直接相關(guān)的處理器和內(nèi)存系統(tǒng)的近期發(fā)展趨勢(shì)，主要體現(xiàn)為三個(gè)方面：

(1) 處理器專用化和異構(gòu)化成為趨勢(shì)。 近年來CPU性能提升速度無法匹配應(yīng)用日益增長的計(jì)算需求。為大幅提升典型應(yīng)用的性能和效率（性價(jià)比、能效比等），處理器向?qū)Ｓ没较虬l(fā)展（例如針對(duì)深度學(xué)習(xí)的專用處理器）。伴隨著處理器專用化的趨勢(shì)，計(jì)算機(jī)系統(tǒng)中集成的處理器類型日漸豐富，形成異構(gòu)處理器計(jì)算機(jī)系統(tǒng)。以阿里媽媽廣告系統(tǒng)為例，為滿足不同應(yīng)用和場(chǎng)景的需求，CPU、GPU和ASIC均有不同程度的使用。

(2) 體系結(jié)構(gòu)創(chuàng)新推動(dòng)數(shù)值計(jì)算性能快速提升。 處理器數(shù)值計(jì)算性能提升主要源自兩方面：芯片制造工藝的持續(xù)進(jìn)步，芯片內(nèi)晶體管數(shù)目逐步增長；體系結(jié)構(gòu)設(shè)計(jì)根據(jù)應(yīng)用需求優(yōu)化晶體管使用，例如為典型應(yīng)用/算法增加專門處理單元（例如深度學(xué)習(xí)專用處理器，以及針對(duì)深度學(xué)習(xí)中常見GEMM運(yùn)算，NVIDIA GPU中增加的TensorCore、Intel CPU中增加的AVX512/AMX）。其中，后者對(duì)數(shù)值計(jì)算性能的提升尤為顯著，例如TensorCore單元大幅提高NVIDIA GPU的計(jì)算能力（圖1.3）。

圖1.3 NVIDIA Tesla GPU浮點(diǎn)/整數(shù)計(jì)算性能

(3) 數(shù)據(jù)訪問帶寬決定計(jì)算性能的發(fā)揮。 內(nèi)存數(shù)據(jù)讀寫的速度無法匹配處理器的計(jì)算速度限制了應(yīng)用性能的提升（memory wall），為緩解這個(gè)問題目前主要有兩種思路：在處理器內(nèi)部集成更大規(guī)模的SRAM，減少對(duì)速度相對(duì)較慢的DRAM的訪問，這在深度學(xué)習(xí)專用處理器中廣泛應(yīng)用；通過2.5D/3D封裝技術(shù)提升DRAM帶寬，例如高帶寬存儲(chǔ)器 (HBM)和混合存儲(chǔ)立方體 (HMC)，前者在AMD/NVIDIA高端GPU中已有集成。阿里媽媽深度學(xué)習(xí)計(jì)算采用多種異構(gòu)硬件，這些硬件之間的數(shù)據(jù)訪問帶寬差異較大：阿里巴巴自研的AI芯片含光800 NPU集成較大的SRAM，NVIDIA P100/V100S GPU集成HBM/HBM2，數(shù)據(jù)訪問瓶頸相對(duì)較小；Intel Skylake/Cacade Lake CPU和NVIDIA T4 GPU的SRAM空間和DRAM帶寬相對(duì)較小，數(shù)據(jù)訪問瓶頸較大。除內(nèi)存數(shù)據(jù)訪問外，對(duì)于協(xié)處理器，跨設(shè)備的輸入輸出和計(jì)算指令等數(shù)據(jù)傳輸也影響計(jì)算性能發(fā)揮，例如GPU計(jì)算中CPU-GPU數(shù)據(jù)傳輸、GPU kernel launch的速度。

表1.1概述了目前阿里媽媽主力深度學(xué)習(xí)硬件的計(jì)算能力，包括數(shù)值計(jì)算性能（FLOPS/OPS）、DRAM帶寬、PCIe帶寬、kernel launch throughput。由于硬件本身的差異，不同硬件的性能瓶頸可能不同（表1中粗體數(shù)字表示在實(shí)際應(yīng)用中已經(jīng)/在短期內(nèi)可能成為瓶頸）。其中，kernel launch throughput通過多線程反復(fù)啟動(dòng)空kernel得到，由于軟件約束在某些版本docker中P100 GPU無法使用MPS；NPU使用PCIe Gen 4.0，但受限于CPU型號(hào)Intel Cascade Lake 8269CY (僅支持PCIe3.0)，帶寬僅為32GB/s；GPU DRAM帶寬通過在kernel中僅進(jìn)行不同模式的數(shù)據(jù)訪問得到；CPU為two-sockets，DRAM理論帶寬為每個(gè)socket帶寬*2簡(jiǎn)單估計(jì)得到，實(shí)測(cè)帶寬為線上系統(tǒng)關(guān)閉NUMA測(cè)試結(jié)果；GPU實(shí)測(cè)FLOPS為GEMM結(jié)果；CPU FP32 FLOPS為cores * AVX512 * 2 AVX512 units/core * 1.6GHz下估算結(jié)果。

表1.1 典型深度學(xué)習(xí)硬件計(jì)算能力

1.3 問題與優(yōu)化方法

為實(shí)現(xiàn)更精準(zhǔn)的投放，廣告的計(jì)算需求在日益增長。以阿里媽媽信息流廣告排序模型為例：在DIEN (Deep Interest Evolution Network) [4] 基礎(chǔ)上引入基于搜索范式的超長用戶行為建模新方法，升級(jí)為SIM (Search-based user Interest Model) [5]；在SIM基礎(chǔ)上引入交叉特征相關(guān)內(nèi)容，升級(jí)為CAN (Co-Action Network) [6]。從DIEN到CAN模型，FLOPS增加3x，訪存增加3x，輸入規(guī)模增加4x（以上為粗略估計(jì)，具體增長與業(yè)務(wù)場(chǎng)景有關(guān)）。面對(duì)迅速增長的算力需求，我們打造了新一代廣告深度學(xué)習(xí)計(jì)算引擎XDL-Blaze，算法-系統(tǒng)-硬件密切配合，充分利用硬件能力，掩蓋硬件自身的弱點(diǎn)，實(shí)現(xiàn)性能目標(biāo)（latency-bounded QPS）的最大化。

??2. 算法-系統(tǒng)-硬件協(xié)同性能優(yōu)化

2.1 算法優(yōu)化

我們?cè)趶V告場(chǎng)景中的算法優(yōu)化實(shí)踐大致分為三個(gè)方向：(1)模型裁剪，裁剪無用和低貢獻(xiàn)結(jié)構(gòu)；(2)近似計(jì)算，用近似且輕量的計(jì)算結(jié)構(gòu)替換耗時(shí)的計(jì)算結(jié)構(gòu)；(3)計(jì)算壓縮，根據(jù)數(shù)據(jù)特點(diǎn)，壓縮重復(fù)計(jì)算。

以算法與工程配合最緊密的計(jì)算壓縮為例，廣告精排模型在訓(xùn)練和推理時(shí)輸入數(shù)據(jù)各有特點(diǎn)，訓(xùn)練時(shí)由于數(shù)據(jù)壓縮比非常低，所有的輸入特征都是展開的；而推理時(shí)壓縮比就相當(dāng)可觀了，如果對(duì)重復(fù)數(shù)據(jù)進(jìn)行壓縮，就可以大幅降低PCIe拷貝量、計(jì)算量和訪存量。

如圖2.1，模型中存在三種計(jì)算壓縮：

(1)推理時(shí)每個(gè)batch只包含一個(gè)user，因此可以將user類的特征從候選廣告的batch size壓縮為1，利用TensorFlow算子的broadcast語義完成計(jì)算后，在最后進(jìn)入全連接前Tile到ad batch size；

(2)用戶長歷史類目與候選廣告的類目一一對(duì)應(yīng)，候選廣告中有多個(gè)商品的類目是相同的，因此可以將長歷史類目特征壓縮到總類目數(shù)，然后構(gòu)造對(duì)應(yīng)的indicator，通過Gather擴(kuò)展到ad batch size；

(3)每條候選廣告對(duì)應(yīng)多個(gè)創(chuàng)意，每條創(chuàng)意都是一條待打分的廣告，多條創(chuàng)意中廣告部分特征是相同的，只有創(chuàng)意相關(guān)的少量特征不同，因此可以將創(chuàng)意壓縮到廣告batch size，然后構(gòu)造創(chuàng)意的indicator，通過gather擴(kuò)展到創(chuàng)意batch size。

圖2.1 推理計(jì)算壓縮

user類特征和歷史行為類別特征擴(kuò)展到ad維度，再擴(kuò)展到創(chuàng)意維度的映射關(guān)系如圖2.2所示，多級(jí)的壓縮從多個(gè)維度降低了推理模型的計(jì)算復(fù)雜度，降低模型latency，提高吞吐量。

圖2.2 數(shù)據(jù)展開映射關(guān)系

我們可以根據(jù)數(shù)據(jù)特點(diǎn)對(duì)推理的計(jì)算圖進(jìn)行優(yōu)化，盡量將數(shù)據(jù)展開操作延后，計(jì)算壓縮使每次請(qǐng)求的FLOPS、訪存、輸入規(guī)模均大幅下降，QPS @ T4提升3x。

2.2 系統(tǒng)優(yōu)化：以GPU優(yōu)化為例

從1.1節(jié)QPS和latency公式可以看到，GPU執(zhí)行時(shí)間由計(jì)算效率（計(jì)算密集型算子、訪存密集型算子效率）、kernel launch和PCIe拷貝決定，我們的優(yōu)化也針對(duì)這幾個(gè)方面展開。

2.2.1 計(jì)算密集型算子優(yōu)化

廣告場(chǎng)景中GEMM是最重要的計(jì)算密集型算子，對(duì)于常見的GEMM規(guī)模，cuBLAS一般情況下能提供性能較優(yōu)的實(shí)現(xiàn)，但是在工程中遇到一些特殊規(guī)模的 GEMM，cuBLAS提供的性能不盡人意。例如在相同的 FLOPS 下，M 與 K、N 相差較大的長條型 GEMM 與勻稱型GEMM相比，cuBLAS GEMM 計(jì)算時(shí)間增加了3倍。對(duì)于廣告模型中常見的長條形 GEMM 規(guī)模，我們用 TVM 自動(dòng)生成更優(yōu)的 kernel，與 cuBLAS 庫函數(shù)相比有 7x 以上的加速比。

此外，我們針對(duì)廣告模型在 GPU FP32+FP16 混合精度上做了一些工作，包括精度評(píng)估和使用 TensorCore 加速 GEMM，并且在 FP32 和 FP16 之間精度轉(zhuǎn)換的開銷上做了一些優(yōu)化。由于 GEMM 計(jì)算效率的提升以及 FP16 帶來的訪存減少，FP32+FP16 混合精度取得了 1.3-2x 的加速比。

2.2.2 OP/Kernel Fusion

對(duì)于廣告模型推理場(chǎng)景而言，GPU計(jì)算密集型算子的性能增長很快，這就需要有足夠的數(shù)據(jù)喂給GPU計(jì)算單元，但大多的情況下，訪存和 kernel launch 更容易先到達(dá)瓶頸。為了降低訪存和 kernel launch 開銷，我們做了大量代碼生成方面的工作，主要有兩個(gè)方面：基于 XLA/MLIR 等編譯器進(jìn)行 Kernel fusion 和針對(duì)訪存熱點(diǎn)的pattern fusion。代碼生成優(yōu)化在降低訪存開銷的同時(shí)，也會(huì)大幅減少kernel個(gè)數(shù)，因此kernel launch開銷也會(huì)降低。

在定向廣告場(chǎng)景中我們的自動(dòng)Kernel fusion工作主要在TensorFlow XLA層面展開，包括兩個(gè)方面工作。一方面是編譯策略優(yōu)化，針對(duì)業(yè)務(wù)場(chǎng)景中XLA生成的指令執(zhí)行效率比較低的策略進(jìn)行調(diào)優(yōu)。另一方面是解決XLA不支持dynamic shape的問題，一種解決方法是分桶warmup：將輸入規(guī)模歸類劃分，padding到多個(gè)固定shape ；另一種解決方法是AutoPadding：在XLA cluster前后自動(dòng)插入padding/unpadding OP，自適應(yīng)的調(diào)配桶大小。

通過深入分析廣告模型中訪存熱點(diǎn)，有些情況無法通過編譯優(yōu)化自動(dòng)融合。針對(duì)這個(gè)情況我們實(shí)現(xiàn)了更加高效的算子融合來優(yōu)化訪存熱點(diǎn)，下面以Gather和BatchMatMul融合為例說明。我們?cè)赟IM模型的工程實(shí)踐中，發(fā)現(xiàn)一個(gè)典型的訪存熱點(diǎn)：Gather+BatchedMatmul，Gather和BatchedMatmul之間存在大量的global memory讀寫操作，如圖2.3所示。其中，Gather和BatchedMatmul的memory讀寫規(guī)模總共為12.4MB；SIM模型中有6個(gè)相同的結(jié)構(gòu)，這些memory訪問顯著增加了訪存壓力，例如當(dāng)QPS=1000時(shí)，總共消耗約74.4GB/s的訪存帶寬。

圖2.3 Gather+BatchedMatmul優(yōu)化

為降低帶寬壓力，我們通過kernel fusion將Gather + BatchedMatmul合并成一個(gè)自定義OP（IndicatorMatMul），減少96%的global memory讀寫。IndicatorMatMul的語義如下：Gather操作在這里的本質(zhì)含義，實(shí)際上是將BatchedMatmul左邊a矩陣的batch維度batch_a升到跟右邊b矩陣batch_b對(duì)齊，進(jìn)行batch_b個(gè)MatMul計(jì)算；cuBLAS的gemmBatched函數(shù)，可以輸入一組a矩陣的指針和b矩陣指針，因此我們將Gather(a)簡(jiǎn)化為指針計(jì)算，將計(jì)算好的指針直接送往gemmBatched函數(shù)，完成Gather + BatchedMatmul的計(jì)算。這個(gè)優(yōu)化可以大幅提升latency-bounded QPS（例如，使SIM模型10ms latency約束下的QPS提升2.6x）。

2.2.3 調(diào)度和開銷優(yōu)化

性能優(yōu)化是個(gè)復(fù)雜的系統(tǒng)工程，計(jì)算優(yōu)化只是其中的一部分。除計(jì)算優(yōu)化外，還需要實(shí)現(xiàn)各種硬件高效協(xié)同，以充分壓榨硬件潛力，在有限的預(yù)算下保證服務(wù)質(zhì)量。系統(tǒng)層面上，我們一方面降低系統(tǒng)各部分開銷，比如優(yōu)化TensorFlow圖執(zhí)行器 (executor)的線程調(diào)度，避免線程上下文頻繁切換，從而降低高負(fù)載壓力下的長尾延時(shí)；另一方面提高異構(gòu)加速器的并發(fā)度，從而提高資源利用率，下面從這個(gè)角度展開說明。

與面向大batch的訓(xùn)練任務(wù)不同，在線預(yù)估服務(wù)中計(jì)算一般有兩個(gè)特點(diǎn)：單次請(qǐng)求的batchsize小，單個(gè)服務(wù)的并發(fā)規(guī)模大。這導(dǎo)致GPU kernel執(zhí)行時(shí)間一般較短，無法充分掩蓋kernel launch開銷，因此需要優(yōu)化kernel launch效率。針對(duì)這個(gè)問題，我們進(jìn)行了兩個(gè)優(yōu)化：多stream并發(fā)launch kernel，實(shí)現(xiàn)stream間相互overlap；使用多CUDA context降低kernel launch的互斥鎖開銷。

Multi-streams：在線預(yù)估場(chǎng)景中，可以通過同時(shí)提供多個(gè)模型服務(wù)，每個(gè)模型同時(shí)處理多個(gè)打分請(qǐng)求，提高資源利用率（尤其是GPU 利用率）。目前，在線預(yù)估服務(wù)通過在單個(gè)進(jìn)程內(nèi)啟動(dòng)多個(gè)CPU線程實(shí)現(xiàn)上述并行執(zhí)行。但是，在單進(jìn)程模式下，我們發(fā)現(xiàn)使用TensorFlow默認(rèn)執(zhí)行選項(xiàng)時(shí)，提高并行度并不能顯著提升throughput，且CPU和GPU利用率均不高。其原因是：TensorFlow默認(rèn)不會(huì)開啟GPU多stream，造成所有并行請(qǐng)求在GPU上均使用單個(gè)stream串行執(zhí)行。另外，TensorFlow多stream的實(shí)現(xiàn)也不適合在線預(yù)估場(chǎng)景：TensorFlow在stream assignment時(shí)，目標(biāo)是利用多stream實(shí)現(xiàn)單個(gè)計(jì)算圖內(nèi)inter-op的并行，縮短單個(gè)計(jì)算圖的執(zhí)行時(shí)間；這種stream assignment策略導(dǎo)致低效的stream同步，在大多數(shù)場(chǎng)景下多stream不能帶來性能提升。

為解決這個(gè)問題，分析發(fā)現(xiàn)：(1) TensorFlow中stream與GPU device一一對(duì)應(yīng)；(2) TensorFlow提供virtual_device選項(xiàng)將一個(gè)physical GPU劃分成為多個(gè)虛擬GPU，每個(gè)虛擬GPU有獨(dú)立的stream。因此，我們開啟TensorFlow virtual_devices選項(xiàng)，允許并行的打分請(qǐng)求在不同的virtual GPU和stream上并行執(zhí)行。注意，更高的并行度需要消耗的更多的GPU device memory（包括存儲(chǔ)權(quán)值和臨時(shí)數(shù)據(jù)的空間消耗）；但是device memory空間有限（一般小于16GB），導(dǎo)致在一些場(chǎng)景中device memory成為系統(tǒng)瓶頸。后續(xù)需要針對(duì)這個(gè)問題重點(diǎn)優(yōu)化。

Multi-contexts：分析廣告應(yīng)用在GPU上的性能時(shí)發(fā)現(xiàn)：多線程并發(fā)launch kernel時(shí)，幾乎每一次kernel launch均有一次開銷較大的獲取鎖的函數(shù)調(diào)用（pthread_mutex_lock），極大影響了kernel launch的效率（圖2.4）。

圖2.4 CUDA runtime/driver mutex開銷

與廠商確認(rèn)上述mutex與CUDA runtime/driver中context [7]相關(guān)，mutex與context一一對(duì)應(yīng)，因此我們嘗試通過增加context數(shù)目減少mutex競(jìng)爭(zhēng)。我們進(jìn)行了幾組測(cè)試（圖2.5），在不同contexts數(shù)目的情況下，用CPU多線程啟動(dòng)空GPU kernels（不計(jì)算直接返回）得到理想情況下的GPU kernel launch throughput。測(cè)試結(jié)果顯示：多contexts可以改善kernel launch throughput，P100、V100S、T4上改善程度遞增。基于上述測(cè)試，我們修改TensorFlow框架，將每個(gè)物理GPU對(duì)應(yīng)一個(gè)default context修改為多個(gè)contexts，并發(fā)任務(wù)使用不同的context進(jìn)行kernel launch從而降低開銷。注意這里有兩個(gè)限制：在目前CUDA runtime/driver的實(shí)現(xiàn)中，GPU不能在不同contexts的并發(fā)GPU kernel之間spatial sharing（即使單個(gè)kernel無法充分利用所有GPU streaming multiprocessor），需要啟用CUDA MPS (Multi-Process Service)避免這個(gè)限制；目前我們的服務(wù)均運(yùn)行在docker中，P100不支持在某些docker版本中開啟MPS。

圖2.5 CUDA runtime/driver mutex開銷

2.2.4 PCIe拷貝優(yōu)化

廣告模型有數(shù)百個(gè)embedding特征輸入需要從CPU host memory經(jīng)過PCIe拷貝到GPU device memory，PCIe每次數(shù)據(jù)傳輸均會(huì)帶來額外的開銷。我們通過合并瑣碎數(shù)據(jù)減少拷貝次數(shù)，PCIe數(shù)據(jù)傳輸耗時(shí)從4.5ms降低到400us。

2.3 硬件升級(jí)：以含光NPU為例

我們?cè)趶V告場(chǎng)景部署阿里自研AI芯片含光800 NPU。由于其專用低精度計(jì)算邏輯，NPU在部分深度學(xué)習(xí)應(yīng)用上的性能大幅優(yōu)于CPU/GPU。但是NPU也存在一些短板：對(duì)主流深度學(xué)習(xí)OP的支持程度弱于CPU/GPU，不利于模型快速迭代，不支持的OP回退到CPU上執(zhí)行導(dǎo)致額外的數(shù)據(jù)轉(zhuǎn)換和傳輸開銷；矩陣乘僅支持INT16/INT8低精度運(yùn)算（模型在部署前需要進(jìn)行量化），INT16/INT8計(jì)算與FP32計(jì)算結(jié)果存在一定偏差，對(duì)一些累積誤差較大的結(jié)構(gòu)不適用，部署難度大于CPU/GPU。

為了發(fā)揮NPU的算力優(yōu)勢(shì)、規(guī)避短板，場(chǎng)景和模型的選擇非常關(guān)鍵。我們選取粗排模型DQM作為第一個(gè)適配場(chǎng)景：這個(gè)場(chǎng)景候選廣告數(shù)多，一次用戶請(qǐng)求需要對(duì)幾千到上萬個(gè)廣告的CTR進(jìn)行預(yù)估，算力消耗占到整個(gè)廣告系統(tǒng)算力消耗的一半以上；模型主要結(jié)構(gòu)是全連接，GEMM計(jì)算占很大比重，適合使用NPU專用計(jì)算邏輯，且算子大多能被NPU原生支持，少數(shù)特殊OP也能通過簡(jiǎn)單變換得以支持。

為了適配NPU量化計(jì)算模式，需要引入量化流程。量化最簡(jiǎn)單的做法就是在模型設(shè)計(jì)/訓(xùn)練階段固定tensor數(shù)值范圍，從而省去通過calibration收集tensor數(shù)值范圍的過程。但是目前廣告模型在設(shè)計(jì)時(shí)沒有考慮這點(diǎn)，因此我們通過若干在線樣本回流到模型量化流程，收集tensor數(shù)值范圍，計(jì)算量化參數(shù)。在具體實(shí)踐中我們發(fā)現(xiàn)對(duì)于粗排模型量化參數(shù)非常穩(wěn)定，一次calibration的結(jié)果可以復(fù)用到之后的模型量化。實(shí)測(cè)DQM模型INT16量化與FP32的誤差分布如下（圖2.6）。

圖2.6 DQM INT16量化與FP32精度對(duì)比（1000條樣本）

精度對(duì)比測(cè)試發(fā)現(xiàn)，NPU量化前后99%的數(shù)值結(jié)果相對(duì)誤差可以控制在1%以內(nèi)，對(duì)廣告點(diǎn)擊率預(yù)估(粗排)的相對(duì)序的影響可以忽略，從業(yè)務(wù)效果上看量化前后的效果持平。

值得注意的是，在真實(shí)線上環(huán)境中NPU的算力并沒有得到充分發(fā)揮（僅使用了4個(gè)NPU cores中的1個(gè)，能力發(fā)揮不到25%），其原因在于：embedding計(jì)算和NPU輸入量化均由CPU完成，隨QPS升高CPU利用率先到達(dá)瓶頸（約60%）；在embedding規(guī)模較小的場(chǎng)景，CPU與NPU之間的PCIe帶寬先成為瓶頸。這個(gè)現(xiàn)象不僅出現(xiàn)在NPU上，隨著協(xié)處理器算力增強(qiáng)，這個(gè)問題將更加普遍。因此，我們后面的優(yōu)化需要超越模型計(jì)算，在整個(gè)廣告系統(tǒng)層面進(jìn)行feature-embedding-dense計(jì)算的全局優(yōu)化；另外，與模型計(jì)算專用硬件加速類似，也可以考慮針對(duì)embedding等短板選擇/實(shí)現(xiàn)更優(yōu)的硬件。

2.4 性能結(jié)果

圖2.7展示了XDL-Blaze對(duì)定向主要模型在線上典型batchsize下的性能優(yōu)化效果。對(duì)比不同的硬件：(1)對(duì)僅有簡(jiǎn)單FC結(jié)構(gòu)的DQM模型，NPU與T4/V100S相比有很大的性能優(yōu)勢(shì)（約兩倍）；(2)由于GPU硬件的升級(jí)，在SIM和CAN上，P100、T4、V100S的性能遞增。對(duì)比不同的優(yōu)化實(shí)現(xiàn)：(1)計(jì)算優(yōu)化（子圖合并、OP替換等與TensorFlow框架無關(guān)的圖等價(jià)變換）對(duì)SIM和CAN可以帶來4-5X的加速比，DQM因?yàn)槠鋱D結(jié)構(gòu)相對(duì)簡(jiǎn)單（只有FC結(jié)構(gòu)）收益不大；(2)除DQM@P100以外，基于定制/自動(dòng)編譯優(yōu)化和系統(tǒng)優(yōu)化，XDL-Blaze與社區(qū)原生TF1.15+XLA相比，均有2X以上的加速比。

圖2.7 DQM/SIM/CAN性能優(yōu)化效果

為了給后續(xù)性能優(yōu)化或硬件選型/設(shè)計(jì)提供依據(jù)，我們整理了不同模型對(duì)不同硬件的使用情況。圖2.8展示了DQM、SIM和CAN在不同batchsize下對(duì)GPU主要硬件資源的利用率（實(shí)際使用量/achievable峰值能力，achievable峰值數(shù)據(jù)見表1.1）。可以很清楚的看出：在batchsize較小時(shí)，P100、V100S、T4存在不同程度的kernel launch瓶頸，其中P100的瓶頸更大；T4則經(jīng)常遇到GPU顯存帶寬的瓶頸；三者橫向比較，V100S除FLOPS稍顯過剩外，整體表現(xiàn)相對(duì)更均衡。另外，在V100S上增大batchsize可以在一定程度上緩解kernel launch瓶頸，提高整體硬件利用效率。DQM在NPU上的性能瓶頸相對(duì)簡(jiǎn)單，主要是CPU利用率和PCIe帶寬，不在這里詳細(xì)列出。

圖2.8 DQM/SIM/CAN硬件利用效率

??總結(jié)與展望

持續(xù)的算法創(chuàng)新和業(yè)務(wù)升級(jí)給廣告營收帶來大幅增長的同時(shí)，也給系統(tǒng)能力帶來了巨大的挑戰(zhàn)，其中以對(duì)深度學(xué)習(xí)引擎計(jì)算能力的挑戰(zhàn)為甚。針對(duì)這個(gè)問題，我們打造了新一代廣告深度學(xué)習(xí)計(jì)算引擎XDL-Blaze，以充分釋放數(shù)十萬CPU處理器核和數(shù)千張GPU/NPU加速卡的計(jì)算能力，服務(wù)數(shù)百萬峰值QPS。未來我們要持續(xù)通過軟硬件協(xié)同優(yōu)化挖掘硬件潛力，例如：針對(duì)計(jì)算密集型算子嘗試INT8/BFLOAT16/TF32/Sparse等低精度/近似計(jì)算；針對(duì)訪存密集型算子實(shí)現(xiàn)更激進(jìn)的kernel fusion。此外，我們需要將廣告典型深度學(xué)習(xí)模型總結(jié)為完善的benchmark集合，以全面評(píng)估CPU/GPU/NPU等深度學(xué)習(xí)處理器、以及多種處理器的組合方式，為硬件選型提供科學(xué)指導(dǎo)。

[1] Global Digital Ad Spending Update Q2 2020, https://www.emarketer.com/content/global-digital-ad-spending-update-q2-2020

[2] China Digital Ad Spending Update Q2 2020, https://www.emarketer.com/content/china-digital-ad-spending-update-q2-2020

[3] CUDA toolkit Documentation, https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html

[4] Zhou, Guorui, et al. "Deep interest evolution network for click-through rate prediction." Proceedings of the AAAI conference on artificial intelligence. Vol. 33. 2019.

[5] Qi, Pi, et al. "Search-based User Interest Modeling with Lifelong Sequential Behavior Data for Click-Through Rate Prediction." arXiv preprint arXiv:2006.05639 (2020).

[6] Zhou, Guorui, et al. CAN: Revisiting Feature Co-Action for Click-Through Rate Prediction, 2020. https://arxiv.org/abs/2011.05625

[7] CUDA Driver API, https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__CTX.html#group__CUDA__CTX

END

招聘信息：

我們是阿里媽媽工程平臺(tái)預(yù)測(cè)引擎團(tuán)隊(duì)，歡迎感興趣同學(xué)加入我們~

點(diǎn)擊下方↓↓「閱讀原文」了解崗位詳情 😉

也許你還想看

丨廣告深度學(xué)習(xí)計(jì)算：召回算法和工程協(xié)同優(yōu)化的若干經(jīng)驗(yàn)

歡迎關(guān)注「阿里媽媽技術(shù)」，了解更多~

瘋狂暗示↓↓↓↓↓↓↓

總結(jié)

以上是生活随笔為你收集整理的广告深度学习计算：异构硬件加速实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。