作者：亞劼 英亮 陳龍等

導語

隨著美團外賣業(yè)務不斷發(fā)展，外賣廣告引擎團隊在多個領(lǐng)域進行了工程上的探索和實踐，也取得了一些成果。我們將以連載的方式進行分享，內(nèi)容主要包括：① 業(yè)務平臺化的實踐；② 大規(guī)模深度學習模型工程實踐；③ 近線計算的探索與實踐；④ 大規(guī)模索引構(gòu)建與在線檢索服務實踐；⑤ 機制工程平臺化實踐。不久前，我們已發(fā)表過業(yè)務平臺化的實踐（詳情請參閱《??美團外賣廣告平臺化的探索與實踐??》一文）。本文為連載文章的第二篇，我們將重點針對大規(guī)模深度模型在全鏈路層面帶來的挑戰(zhàn)，從在線時延、離線效率兩個方面進行展開，闡述廣告在大規(guī)模深度模型上的工程實踐，希望能為大家?guī)硪恍椭蛘邌l(fā)。

1 背景

在搜索、推薦、廣告（下簡稱搜推廣）等互聯(lián)網(wǎng)核心業(yè)務場景下，進行數(shù)據(jù)挖掘及興趣建模，為用戶提供優(yōu)質(zhì)的服務，已經(jīng)成為改善用戶體驗的關(guān)鍵要素。近幾年，針對搜推廣業(yè)務，深度學習模型憑借數(shù)據(jù)紅利和硬件技術(shù)紅利，在業(yè)界得以廣泛落地，同時在CTR場景，業(yè)界逐步從簡單DNN小模型過渡到數(shù)萬億參數(shù)的Embedding大模型甚至超大模型。外賣廣告業(yè)務線主要經(jīng)歷了“LR淺層模型（樹模型）” -> “深度學習模型” -> “大規(guī)模深度學習模型”的演化過程。整個演化趨勢從以人工特征為主的簡單模型，逐步向以數(shù)據(jù)為核心的復雜深度學習模型進行過渡。而大模型的使用，大幅提高了模型的表達能力，更精準地實現(xiàn)了供需側(cè)的匹配，為后續(xù)業(yè)務發(fā)展提供了更多的可能性。但隨著模型、數(shù)據(jù)規(guī)模的不斷變大，我們發(fā)現(xiàn)效率跟它們存在如下的關(guān)系：根據(jù)上圖所示，在數(shù)據(jù)規(guī)模、模型規(guī)模增長的情況下，所對應的“時長”變得會越來越長。這個“時長”對應到離線層面，體現(xiàn)在效率上；對應到在線層面，就體現(xiàn)在Latency上。而我們的工作就是圍繞這個“時長”的優(yōu)化來開展。

2 分析

相比普通小模型，大模型的核心問題在于：隨著數(shù)據(jù)量、模型規(guī)模增加數(shù)十倍甚至百倍，整體鏈路上的存儲、通信、計算等都將面臨新的挑戰(zhàn)，進而影響算法離線的迭代效率。如何突破在線時延約束等一系列問題？我們先從全鏈路進行分析，如下所示：

“時長”變長，主要會體現(xiàn)在以下幾個方面：

• 在線時延：特征層面，在線請求不變的情況下，特征量的增加，帶來的IO、特征計算耗時增加等問題尤為突出，需要在特征算子解析編譯、特征抽取內(nèi)部任務調(diào)度、網(wǎng)絡I/O傳等方面重塑。在模型層面，模型歷經(jīng)百M/G到幾百G的變化，在存儲上帶來了2個數(shù)量級的上升。此外，單模型的計算量也出現(xiàn)了數(shù)量級的上漲（FLOPs從百萬到現(xiàn)在千萬），單純的靠CPU，解決不了巨大算力的需求，建設(shè)CPU+GPU+Hierarchical Cache推理架構(gòu)來支撐大規(guī)模深度學習推理勢在必行。
• 離線效率：隨著樣本、特征的數(shù)倍增加，樣本構(gòu)建，模型訓練的時間會被大大拉長，甚至會變得不可接受。如何在有限的資源下，解決海量樣本構(gòu)建、模型訓練是系統(tǒng)的首要問題。在數(shù)據(jù)層面，業(yè)界一般從兩個層面去解決，一方面不斷優(yōu)化批處理過程中掣肘的點，另一方面把數(shù)據(jù)“化批為流”，由集中式轉(zhuǎn)到分攤式，極大提升數(shù)據(jù)的就緒時間。在訓練層面，通過硬件GPU并結(jié)合架構(gòu)層面的優(yōu)化，來達到加速目的。其次，算法創(chuàng)新往往都是通過人來驅(qū)動，新數(shù)據(jù)如何快速匹配模型，新模型如何快速被其他業(yè)務應用，如果說將N個人放在N條業(yè)務線上獨立地做同一個優(yōu)化，演變成一個人在一個業(yè)務線的優(yōu)化，同時廣播適配到N個業(yè)務線，將會有N-1個人力釋放出來做新的創(chuàng)新，這將會極大地縮短創(chuàng)新的周期，尤其是在整個模型規(guī)模變大后，不可避免地會增加人工迭代的成本，實現(xiàn)從“人找特征/模型” 到“特征/模型找人”的深度轉(zhuǎn)換，減少“重復創(chuàng)新”，從而達到模型、數(shù)據(jù)智能化的匹配。
• Pipeline其他問題：機器學習Pipeline并不是在大規(guī)模深度學習模型鏈路里才有，但隨著大模型的鋪開，將會有新的挑戰(zhàn)，比如：① 系統(tǒng)流程如何支持全量、增量上線部署；② 模型的回滾時長，把事情做正確的時長，以及事情做錯后的恢復時長。簡而言之，會在開發(fā)、測試、部署、監(jiān)測、回滾等方面產(chǎn)生新的訴求。

本文重點從在線時延（模型推理、特征服務）、離線效率（樣本構(gòu)建、數(shù)據(jù)準備）等兩個方面來展開，逐步闡述廣告在大規(guī)模深度模型上的工程實踐。如何去優(yōu)化“時長”等相關(guān)問題，我們會在后續(xù)篇章介進行分享，敬請期待。

3 模型推理

在模型推理層面，外賣廣告歷經(jīng)了三個版本，從1.0時代，支持小眾規(guī)模的DNN模型為代表，到2.0時代，高效、低代碼支持多業(yè)務迭代，再到如今的3.0時代，逐步面向深度學習DNN算力以及大規(guī)模存儲的需求。主要演進趨勢如下圖所示：

面向大模型推理場景，3.0架構(gòu)解決的兩個核心問題是：“存儲問題”和“性能問題”。當然，面向N個百G+模型如何迭代，運算量數(shù)十倍增加時在線穩(wěn)定性如何保障，Pipeline如何加固等等，也是工程面臨的挑戰(zhàn)。下面我們將重點介紹模型推理3.0架構(gòu)是如何通過“分布式”來解決大模型存儲問題，以及如何通過CPU/GPU加速來解決性能、吞吐問題。

3.1 分布式

大模型的參數(shù)主要分為兩部分：Sparse參數(shù)和Dense參數(shù)。

• Sparse參數(shù)：參數(shù)量級很大，一般在億級別，甚至十億/百億級別，這會導致存儲空間占用較大，通常在百G級別，甚至T級別。其特點：①單機加載困難：在單機模式下，Sparse參數(shù)需全部加載到機器內(nèi)存中，導致內(nèi)存嚴重吃緊，影響穩(wěn)定性和迭代效率；②讀取稀疏：每次推理計算，只需讀取部分參數(shù)，比如User全量參數(shù)在2億級別，但每次推理請求只需讀取1個User參數(shù)。
• Dense參數(shù)：參數(shù)規(guī)模不大，模型全連接一般在2~3層，參數(shù)量級在百萬/千萬級別。特點：① 單機可加載：Dense參數(shù)占用在幾十兆左右，單機內(nèi)存可正常加載，比如：輸入層為2000，全連接層為[1024, 512, 256]，總參數(shù)為：2000 * 1024 + 1024 * 512 + 512 * 256 + 256 = 2703616，共270萬個參數(shù)，內(nèi)存占用在百兆內(nèi)；② 全量讀?。好看瓮评碛嬎?，需要讀取全量參數(shù)。

因此，解決大模型參數(shù)規(guī)模增長的關(guān)鍵是將Sparse參數(shù)由單機存儲改造為分布式存儲，改造的方式包括兩部分：① 模型網(wǎng)絡結(jié)構(gòu)轉(zhuǎn)換；② Sparse參數(shù)導出。

3.1.1 模型網(wǎng)絡結(jié)構(gòu)轉(zhuǎn)換

業(yè)界對于分布式參數(shù)的獲取方式大致分為兩種：外部服務提前獲取參數(shù)并傳給預估服務；預估服務內(nèi)部通過改造TF（TensorFlow）算子來從分布式存儲獲取參數(shù)。為了減少架構(gòu)改造成本和降低對現(xiàn)有模型結(jié)構(gòu)的侵入性，我們選擇通過改造TF算子的方式來獲取分布式參數(shù)。

正常情況下，TF模型會使用原生算子進行Sparse參數(shù)的讀取，其中核心算子是GatherV2算子，算子的輸入主要有兩部分：① 需要查詢的ID列表；② 存儲Sparse參數(shù)的Embedding表。

算子的作用是從Embedding表中讀取ID列表索引對應的Embedding數(shù)據(jù)并返回，本質(zhì)上是一個Hash查詢的過程。其中，Embedding表存儲的Sparse參數(shù)，其在單機模型中全部存儲在單機內(nèi)存中。

改造TF算子本質(zhì)上是對模型網(wǎng)絡結(jié)構(gòu)的改造，改造的核心點主要包括兩部分：① 網(wǎng)絡圖重構(gòu)；② 自定義分布式算子。

1. 網(wǎng)絡圖重構(gòu)：改造模型網(wǎng)絡結(jié)構(gòu)，將原生TF算子替換為自定義分布式算子，同時進行原生Embedding表的固化。

• 分布式算子替換：遍歷模型網(wǎng)絡，將需要替換的GatherV2算子替換為自定義分布式算子MtGatherV2，同時修改上下游節(jié)點的Input/Output。
• 原生Embedding表固化：原生Embedding表固化為占位符，既能保留模型網(wǎng)絡結(jié)構(gòu)完整，又能避免Sparse參數(shù)對單機內(nèi)存的占用。

2. 自定義分布式算子：改造根據(jù)ID列表查詢Embedding流程，從本地Embedding表中查詢，改造為從分布式KV中查詢。

• 請求查詢：將輸入ID進行去重以降低查詢量，并通過分片的方式并發(fā)查詢二級緩存（本地Cache + 遠端KV）獲取Embedding向量。
• 模型管理：維護對模型Embedding Meta注冊、卸載流程，以及對Cache的創(chuàng)建、銷毀功能。
• 模型部署：觸發(fā)模型資源信息的加載，以及對Embedding數(shù)據(jù)并行導入KV的流程。

3.1.2 Sparse參數(shù)導出

• 分片并行導出：解析模型的Checkpoint文件，獲取Embedding表對應的Part信息，并根據(jù)Part進行劃分，將每個Part文件通過多個Worker節(jié)點并行導出到HDFS上。
• 導入KV：提前預分配多個Bucket，Bucket會存儲模型版本等信息，便于在線路由查詢。同時模型的Embedding數(shù)據(jù)也會存儲到Bucket中，按分片并行方式導入到KV中。

整體流程如下圖所示，我們通過離線分布式模型結(jié)構(gòu)轉(zhuǎn)換、近線數(shù)據(jù)一致性保證、在線熱點數(shù)據(jù)緩存等手段，保障了百G大模型的正常迭代需求。

可以看到，分布式借助的存儲是外部KV能力，后續(xù)會替換為更加高效、靈活、易管理的Embedding Service。

3.2 CPU加速

拋開模型本身的優(yōu)化手段外，常見的CPU加速手段主要有兩種：① 指令集優(yōu)化，比如使用AVX2、AVX512指令集；② 使用加速庫（TVM、OpenVINO）。

1. 指令集優(yōu)化：如果使用TensorFlow模型，在編譯TensorFlow框架代碼時，直接在編譯選項里加入指令集優(yōu)化項即可。實踐證明引入AVX2、AVX512指令集優(yōu)化效果明顯，在線推理服務吞吐提升30%+。
2. 加速庫優(yōu)化：加速庫通過對網(wǎng)絡模型結(jié)構(gòu)進行優(yōu)化融合，以達到推理加速效果。業(yè)界常用的加速庫有TVM、OpenVINO等，其中TVM支持跨平臺，通用性較好。OpenVINO面向Intel廠商硬件進行針對性優(yōu)化，通用性一般，但加速效果較好。

下面，將會重點介紹我們使用OpenVINO進行CPU加速的一些實踐經(jīng)驗。OpenVINO是Intel推出的一套基于深度學習的計算加速優(yōu)化框架，支持機器學習模型的壓縮優(yōu)化、加速計算等功能。OpenVINO的加速原理簡單概括為兩部分：線性算子融合和數(shù)據(jù)精度校準。

1. 線性算子融合：OpenVINO通過模型優(yōu)化器，將模型網(wǎng)絡中的多層算子進行統(tǒng)一線性融合，以降低算子調(diào)度開銷和算子間的數(shù)據(jù)訪存開銷，比如將Conv+BN+Relu三個算子合并成一個CBR結(jié)構(gòu)算子。
2. 數(shù)據(jù)精度校準：模型經(jīng)過離線訓練后，由于在推理的過程中不需要反向傳播，完全可以適當降低數(shù)據(jù)精度，比如降為FP16或INT8的精度，從而使得內(nèi)存占用更小，推理延遲更低。

CPU加速通常是針對固定Batch的候選隊列進行加速推理，但在搜推廣場景中，候選隊列往往都是動態(tài)的。這就意味著在模型推理之前，需要增加Batch匹配的操作，即將請求的動態(tài)Batch候選隊列映射到一個離它最近的Batch模型上，但這需構(gòu)建N個匹配模型，導致N倍的內(nèi)存占用。而當前模型體積已達百G規(guī)模，內(nèi)存嚴重吃緊。因此，選取合理的網(wǎng)絡結(jié)構(gòu)用于加速是需要考慮的重點問題。下圖是整體的運行架構(gòu)：

1. 網(wǎng)絡分布：CTR模型網(wǎng)絡結(jié)構(gòu)整體抽象為三部分：Embedding層、Attention層和MLP層，其中Embedding層用于數(shù)據(jù)獲取，Attention層包含較多邏輯運算和輕量級的網(wǎng)絡計算，MLP層則為密集網(wǎng)絡計算。
2. 加速網(wǎng)絡選擇：OpenVINO針對純網(wǎng)絡計算的加速效果較好，可以很好地應用于MLP層。另外，模型大部分數(shù)據(jù)存儲在Embedding層中，MLP層占內(nèi)存只有幾十兆左右。如果針對MLP層網(wǎng)絡劃分出多個Batch，模型內(nèi)存占用在優(yōu)化前（Embedding+Attention+MLP）≈ 優(yōu)化后（Embedding+Attention+MLP×Batch個數(shù)），對于內(nèi)存占用的影響較小。因此，我們最終選取MLP層網(wǎng)絡作為模型加速網(wǎng)絡。

目前，基于OpenVINO的CPU加速方案已經(jīng)在生產(chǎn)環(huán)境取得不錯效果：CPU與基線持平時，服務吞吐提升40%，平均時延下降15%。如果大家想在CPU層面做些加速的話，OpenVINO是個不錯的選擇。

3.3 GPU加速

一方面，隨著業(yè)務的發(fā)展，業(yè)務形態(tài)越來越豐富，流量越來越高，模型變寬變深，算力的消耗急劇增加；另一方面，廣告場景主要使用DNN模型，涉及大量稀疏特征Embedding和神經(jīng)網(wǎng)絡浮點運算。作為訪存和計算密集型的線上服務，在保證可用性的前提下，還要滿足低延遲、高吞吐的要求，對單機算力也是一種挑戰(zhàn)。這些算力資源需求和空間的矛盾，如果解決不好，會極大限制業(yè)務的發(fā)展：在模型加寬加深前，純CPU 推理服務能夠提供可觀的吞吐，但是在模型加寬加深后，計算復雜度上升，為了保證高可用性，需要消耗大量機器資源，導致大模型無法大規(guī)模應用于線上。目前，業(yè)界比較通用的解決辦法是利用GPU來解決這個問題，GPU本身比較適用于計算密集型任務。使用GPU需要解決如下挑戰(zhàn)：如何在保證可用性、低延遲的前提下，盡可能做到高吞吐，同時還需要考慮易用性和通用性。為此，我們也在GPU上做了大量實踐工作，比如TensorFlow-GPU、TensorFlow-TensorRT、TensorRT等，為了兼顧TF的靈活性以及TensorRT的加速效果，我們采用TensorFlow+TensorRT獨立兩階段的架構(gòu)設(shè)計。

3.3.1 加速分析

• 異構(gòu)計算：我們的思路跟CPU加速比較一致，200G的深度學習CTR模型不能直接全放入到GPU里，訪存密集型算子適用（比如Embedding相關(guān)操作）CPU，計算密集型算子（比如MLP）適用GPU。
• GPU使用需要關(guān)注的幾個點：① 內(nèi)存與顯存的頻繁交互；② 時延與吞吐；③ 擴展性與性能優(yōu)化的Trade Off；④ GPU Utilization 。
• 推理引擎的選擇：業(yè)界常用推理加速引擎有TensorRT、TVM、XLA、ONNXRuntime等，由于TensorRT在算子優(yōu)化相比其他引擎更加深入，同時可以通過自定義plugin的方式實現(xiàn)任意算子，具有很強的擴展性。而且TensorRT支持常見學習平臺（Caffe、PyTorch、TensorFlow等）的模型，其周邊越來越完善（模型轉(zhuǎn)換工具onnx-tensorrt、性能分析工具nsys等），因此在GPU側(cè)的加速引擎使用TensorRT。
• 模型分析：CTR模型網(wǎng)絡結(jié)構(gòu)整體抽象為三部分：Embedding層、Attention層和MLP層，其中Embedding層用于數(shù)據(jù)獲取，適合CPU；Attention層包含較多邏輯運算和輕量級的網(wǎng)絡計算，MLP層則重網(wǎng)絡計算，而這些計算可以并行進行，適合GPU，可以充分利用GPU Core（Cuda Core、Tensor Core），提高并行度。

3.3.2 優(yōu)化目標

深度學習推理階段對算力和時延具有很高的要求，如果將訓練好的神經(jīng)網(wǎng)絡直接部署到推理端，很有可能出現(xiàn)算力不足無法運行或者推理時間較長等問題。因此，我們需要對訓練好的神經(jīng)網(wǎng)絡進行一定的優(yōu)化。業(yè)界神經(jīng)網(wǎng)絡模型優(yōu)化的一般思路，可以從模型壓縮、不同網(wǎng)絡層合并、稀疏化、采用低精度數(shù)據(jù)類型等不同方面進行優(yōu)化，甚至還需要根據(jù)硬件特性進行針對性優(yōu)化。為此，我們主要圍繞以下兩個目標進行優(yōu)化：

1. 延時和資源約束下的吞吐：當register、Cache等共享資源不需要競爭時，提高并發(fā)可有效提高資源利用率（CPU、GPU等利用率），但隨之可能帶來請求延時的上漲。由于在線系統(tǒng)的延時限制非?？量?，所以不能只通過資源利用率這一指標簡單換算在線系統(tǒng)的吞吐上限，需要在延時約束下結(jié)合資源上限進行綜合評估。當系統(tǒng)延時較低，資源（Memory/CPU/GPU等）利用率是制約因素時，可通過模型優(yōu)化降低資源利用率；當系統(tǒng)資源利用率均較低，延時是制約因素時，可通過融合優(yōu)化和引擎優(yōu)化來降低延時。通過結(jié)合以上各種優(yōu)化手段可有效提升系統(tǒng)服務的綜合能力，進而達到提升系統(tǒng)吞吐的目的。
2. 計算量約束下的計算密度：CPU/GPU異構(gòu)系統(tǒng)下，模型推理性能主要受數(shù)據(jù)拷貝效率和計算效率影響，它們分別由訪存密集型算子和計算密集型算子決定，而數(shù)據(jù)拷貝效率受PCIe數(shù)據(jù)傳輸、CPU/GPU內(nèi)存讀寫等效率的影響，計算效率受各種計算單元CPU Core、CUDA Core、Tensor Core等計算效率的影響。隨著GPU等硬件的快速發(fā)展，計算密集型算子的處理能力同步快速提高，導致訪存密集型算子阻礙系統(tǒng)服務能力提升的現(xiàn)象越來越突出，因此減少訪存密集型算子，提升計算密度對系統(tǒng)服務能力也變得越來越重要，即在模型計算量變化不大的情況下，減少數(shù)據(jù)拷貝和kernel launch等。比如通過模型優(yōu)化和融合優(yōu)化來減少算子變換（比如Cast/Unsqueeze/Concat等算子）的使用，使用CUDA Graph減少kernel launch等。

下面將圍繞以上兩個目標，具體介紹我們在模型優(yōu)化、融合優(yōu)化和引擎優(yōu)化所做的一些工作。

3.3.3 模型優(yōu)化

1. 計算與傳輸去重：推理時同一Batch只包含一個用戶信息，因此在進行inference之前可以將用戶信息從Batch Size降為1，真正需要inference時再進行展開，降低數(shù)據(jù)的傳輸拷貝以及重復計算開銷。如下圖，inference前可以只查詢一次User類特征信息，并在只有用戶相關(guān)的子網(wǎng)絡中進行裁剪，待需要計算關(guān)聯(lián)時再展開。

• 自動化過程：找到重復計算的結(jié)點（紅色結(jié)點），如果該結(jié)點的所有葉子結(jié)點都是重復計算結(jié)點，則該結(jié)點也是重復計算結(jié)點，由葉子結(jié)點逐層向上查找所有重復結(jié)點，直到結(jié)點遍歷查找完，找到所有紅白結(jié)點的連接線，插入User特征擴展結(jié)點，對User特征進行展開。

2. 數(shù)據(jù)精度優(yōu)化：由于模型訓練時需要反向傳播更新梯度，對數(shù)據(jù)精度要求較高；而模型推理時，只進行前向推理不需要更新梯度，所以在保證效果的前提下，使用FP16或混合精度進行優(yōu)化，節(jié)省內(nèi)存空間，減少傳輸開銷，提升推理性能和吞吐。

3. 計算下推：CTR模型結(jié)構(gòu)主要由Embedding、Attention和MLP三層構(gòu)成，Embedding層偏數(shù)據(jù)獲取，Attention有部分偏邏輯，部分偏計算，為了充分壓榨GPU的潛力，將CTR模型結(jié)構(gòu)中Attention和MLP大部分計算邏輯由CPU下沉到GPU進行計算，整體吞吐得到大幅提升。

3.3.4 融合優(yōu)化

在線模型inference時，每一層的運算操作都是由GPU完成，實際上是CPU通過啟動不同的CUDA kernel來完成計算，CUDA kernel計算張量的速度非?？欤峭罅康臅r間是浪費在CUDA kernel的啟動和對每一層輸入/輸出張量的讀寫操作上，這造成了內(nèi)存帶寬的瓶頸和GPU資源的浪費。這里我們將主要介紹TensorRT部分自動優(yōu)化以及手工優(yōu)化兩塊工作。1. 自動優(yōu)化：TensorRT是一個高性能的深度學習inference優(yōu)化器，可以為深度學習應用提供低延遲、高吞吐的推理部署。TensorRT可用于對超大規(guī)模模型、嵌入式平臺或自動駕駛平臺進行推理加速。TensorRT現(xiàn)已能支持TensorFlow、Caffe、MXNet、PyTorch等幾乎所有的深度學習框架，將TensorRT和NVIDIA的GPU結(jié)合起來，能在幾乎所有的框架中進行快速和高效的部署推理。而且有些優(yōu)化不需要用戶過多參與，比如部分Layer Fusion、Kernel Auto-Tuning等。

• Layer Fusion：TensorRT通過對層間的橫向或縱向合并，使網(wǎng)絡層的數(shù)量大大減少，簡單說就是通過融合一些計算op或者去掉一些多余op，來減少數(shù)據(jù)流通次數(shù)、顯存的頻繁使用以及調(diào)度的開銷。比如常見網(wǎng)絡結(jié)構(gòu)Convolution And ElementWise Operation融合、CBR融合等，下圖是整個網(wǎng)絡結(jié)構(gòu)中的部分子圖融合前后結(jié)構(gòu)圖，F(xiàn)usedNewOP在融合過程中可能會涉及多種Tactic，比如CudnnMLPFC、CudnnMLPMM、CudaMLP等，最終會根據(jù)時長選擇一個最優(yōu)的Tactic作為融合后的結(jié)構(gòu)。通過融合操作，使得網(wǎng)絡層數(shù)減少、數(shù)據(jù)通道變短；相同結(jié)構(gòu)合并，使數(shù)據(jù)通道變寬；達到更加高效利用GPU資源的目的。

• Kernel Auto-Tuning：網(wǎng)絡模型在inference時，是調(diào)用GPU的CUDA kernel進行計算。TensorRT可以針對不同的網(wǎng)絡模型、顯卡結(jié)構(gòu)、SM數(shù)量、內(nèi)核頻率等進行CUDA kernel調(diào)整，選擇不同的優(yōu)化策略和計算方式，尋找適合當前的最優(yōu)計算方式，以保證當前模型在特定平臺上獲得最優(yōu)的性能。上圖是優(yōu)化主要思想，每一個op會有多種kernel優(yōu)化策略（cuDNN、cuBLAS等），根據(jù)當前架構(gòu)從所有優(yōu)化策略中過濾低效kernel，同時選擇最優(yōu)kernel，最終形成新的Network。

2. 手工優(yōu)化：眾所周知，GPU適合計算密集型的算子，對于其他類型算子（輕量級計算算子，邏輯運算算子等）不太友好。使用GPU計算時，每次運算一般要經(jīng)過幾個流程：CPU在GPU上分配顯存 -> CPU把數(shù)據(jù)發(fā)送給GPU -> CPU啟動CUDA kernel -> CPU把數(shù)據(jù)取回 -> CPU釋放GPU顯存。為了減少調(diào)度、kernel launch以及訪存等開銷，需要進行網(wǎng)絡融合。由于CTR大模型結(jié)構(gòu)靈活多變，網(wǎng)絡融合手段很難統(tǒng)一，只能具體問題具體分析。比如在垂直方向，Cast、Unsqueeze和Less融合，TensorRT內(nèi)部Conv、BN和Relu融合；在水平方向，同維度的輸入算子進行融合。為此，我們基于線上實際業(yè)務場景，使用NVIDIA相關(guān)性能分析工具（NVIDIA Nsight Systems、NVIDIA Nsight Compute等）進行具體問題的分析。把這些性能分析工具集成到線上inference環(huán)境中，獲得inference過程中的GPU Profing文件。通過Profing文件，我們可以清晰的看到inference過程，我們發(fā)現(xiàn)整個inference中部分算子kernel launch bound現(xiàn)象嚴重，而且部分算子之間gap間隙較大，存在優(yōu)化空間，如下圖所示：

為此，基于性能分析工具和轉(zhuǎn)換后的模型對整個Network分析，找出TensorRT已經(jīng)優(yōu)化的部分，然后對Network中其他可以優(yōu)化的子結(jié)構(gòu)進行網(wǎng)絡融合，同時還要保證這樣的子結(jié)構(gòu)在整個Network占有一定的比例，保證融合后計算密度能夠有一定程度的上升。至于采用什么樣的網(wǎng)絡融合手段，根據(jù)具體的場景進行靈活運用即可，如下圖是我們?nèi)诤锨昂蟮淖咏Y(jié)構(gòu)圖對比：

3.3.5 引擎優(yōu)化

1. 多模型：由于外賣廣告中用戶請求規(guī)模不確定，廣告時多時少，為此加載多個模型，每個模型對應不同輸入的Batch，將輸入規(guī)模分桶歸類劃分，并將其padding到多個固定Batch，同時對應到相應的模型進行inference。
2. Multi-contexts和Multi-streams：對每一個Batch的模型，使用多context和多stream，不僅可以避免模型等待同一context的開銷，而且可以充分利用多stream的并發(fā)性，實現(xiàn)stream間的overlap，同時為了更好的解決資源競爭的問題，引入CAS。如下圖所示，單stream變成多stream：

3. Dynamic Shape：為了應對輸入Batch不定場景下，不必要的數(shù)據(jù)padding，同時減少模型數(shù)量降低顯存等資源的浪費，引入Dynamic Shape，模型根據(jù)實際輸入數(shù)據(jù)進行inference，減少數(shù)據(jù)padding和不必要的計算資源浪費，最終達到性能優(yōu)化和吞吐提升的目的。
4. CUDA Graph：現(xiàn)代GPU每個operation（kernel運行等）所花費的時間至少是微秒級別，而且，將每個operation提交給GPU也會產(chǎn)生一些開銷（微秒級別）。實際inference時，經(jīng)常需要執(zhí)行大量的kernel operation，這些operation每一個都單獨提交到GPU并獨立計算，如果可以把所有提交啟動的開銷匯總到一起，應該會帶來性能的整體提升。CUDA Graph可以完成這樣的功能，它將整個計算流程定義為一個圖而不是單個操作的列表，然后通過提供一種由單個CPU操作來啟動圖上的多個GPU操作的方法減少kernel提交啟動的開銷。CUDA Graph核心思想是減少kernel launch的次數(shù)，通過在推理前后capture graph，根據(jù)推理的需要進行update graph，后續(xù)推理時不再需要一次一次的kernel launch，只需要graph launch，最終達到減少kernel launch次數(shù)的目的。如下圖所示，一次inference執(zhí)行4次kernel相關(guān)操作，通過使用CUDA Graph可以清晰看到優(yōu)化效果。

5. 多級PS：為了進一步挖掘GPU加速引擎性能，對Embedding數(shù)據(jù)的查詢操作可通過多級PS的方式進行：GPU顯存Cache->CPU內(nèi)存Cache->本地SSD/分布式KV。其中，熱點數(shù)據(jù)可緩存在GPU顯存中，并通過數(shù)據(jù)熱點的遷移、晉升和淘汰等機制對緩存數(shù)據(jù)進行動態(tài)更新，充分挖掘GPU的并行算力和訪存能力進行高效查詢。經(jīng)離線測試，GPU Cache查詢性能相比CPU Cache提升10倍+；對于GPU Cache未命中數(shù)據(jù)，可通過訪問CPU Cache進行查詢，兩級Cache可滿足90%+的數(shù)據(jù)訪問；對于長尾請求，則需要通過訪問分布式KV進行數(shù)據(jù)獲取。具體結(jié)構(gòu)如下：

3.3.6 Pipeline

模型從離線訓練到最終在線加載，整個流程繁瑣易出錯，而且模型在不同GPU卡、不同TensorRT和CUDA版本上無法通用，這給模型轉(zhuǎn)換帶來了更多出錯的可能性。因此，為了提升模型迭代的整體效率，我們在Pipeline方面進行了相關(guān)能力建設(shè)，如下圖所示：

Pipeline建設(shè)包括兩部分：離線側(cè)模型拆分轉(zhuǎn)換流程，以及在線側(cè)模型部署流程：

1. 離線側(cè)：只需提供模型拆分節(jié)點，平臺會自動將原始TF模型拆分成Embedding子模型和計算圖子模型，其中Embedding子模型通過分布式轉(zhuǎn)換器進行分布式算子替換和Embedding導入工作；計算圖子模型則根據(jù)選擇的硬件環(huán)境（GPU型號、TensorRT版本、CUDA版本）進行TensorRT模型的轉(zhuǎn)換和編譯優(yōu)化工作，最終將兩個子模型的轉(zhuǎn)換結(jié)果存儲到S3中，用于后續(xù)的模型部署上線。整個流程都是平臺自動完成，無需使用方感知執(zhí)行細節(jié)。
2. 在線測：只需選擇模型部署硬件環(huán)境（與模型轉(zhuǎn)換的環(huán)境保持一致），平臺會根據(jù)環(huán)境配置，進行模型的自適應推送加載，一鍵完成模型的部署上線。

Pipeline通過配置化、一鍵化能力的建設(shè)，極大提升了模型迭代效率，幫助算法和工程同學能夠更加專注的做好本職工作。下圖是在GPU實踐中相比純CPU推理取得的整體收益：

4 特征服務CodeGen優(yōu)化

特征抽取是模型計算的前置階段，無論是傳統(tǒng)的LR模型還是日趨流行的深度學習模型，都需要通過特征抽取來得到輸入。在之前的博客??美團外賣特征平臺的建設(shè)與實踐??中，描述了我們基于模型特征自描述MFDL，將特征計算流程配置化，盡量保證了在線預估和離線訓練時樣本的一致性。隨著業(yè)務快速迭代，模型特征數(shù)量不斷增加，特別是大模型引入了大量的離散特征，導致計算量有了成倍的增長。為此，我們對特征抽取層做了一些優(yōu)化，在吞吐和耗時上都取得了顯著的收益。

4.1 全流程CodeGen優(yōu)化

DSL是對特征處理邏輯的描述。在早期的特征計算實現(xiàn)中，每個模型配置的DSL都會被解釋執(zhí)行。解釋執(zhí)行的優(yōu)點是實現(xiàn)簡單，通過良好的設(shè)計便能獲得較好的實現(xiàn)，比如常用的迭代器模式；缺點是執(zhí)行性能較低，在實現(xiàn)層面為了通用性避免不了添加很多的分支跳轉(zhuǎn)和類型轉(zhuǎn)換等。實際上，對于一個固定版本的模型配置來說，它所有的模型特征轉(zhuǎn)換規(guī)則都是固定的，不會隨請求而變化。極端情況下，基于這些已知的信息，可以對每個模型特征各自進行Hard Code，從而達到最極致的性能。顯然，模型特征配置千變?nèi)f化，不可能針對每個模型去人工編碼。于是便有了CodeGen的想法，在編譯期為每一個配置自動生成一套專有的代碼。CodeGen并不是一項具體的技術(shù)或框架，而是一種思想，完成從抽象描述語言到具體執(zhí)行語言的轉(zhuǎn)換過程。其實在業(yè)界，計算密集型場景下使用CodeGen來加速計算已是常用做法。如Apache Spark通過CodeGen來優(yōu)化SparkSql執(zhí)行性能，從1.x的ExpressionCodeGen加速表達式運算到2.x引入的WholeStageCodeGen進行全階段的加速，都取得了非常明顯的性能收益。在機器學習領(lǐng)域，一些TF模型加速框架，如TensorFlow XLA和TVM，也是基于CodeGen思想，將Tensor節(jié)點編譯成統(tǒng)一的中間層IR，基于IR結(jié)合本地環(huán)境進行調(diào)度優(yōu)化，從而達到運行時模型計算加速的目的。

借鑒了Spark的WholeStageCodeGen，我們的目標是將整個特征計算DSL編譯形成一個可執(zhí)行方法，從而減少代碼運行時的性能損耗。整個編譯過程可以分為：前端（FrontEnd），優(yōu)化器（Optimizer）和后端（BackEnd）。前端主要負責解析目標DSL，將源碼轉(zhuǎn)化為AST或IR；優(yōu)化器則是在前端的基礎(chǔ)上，對得到的中間代碼進行優(yōu)化，使代碼更加高效；后端則是將已經(jīng)優(yōu)化的中間代碼轉(zhuǎn)化為針對各自平臺的本地代碼。具體實現(xiàn)如下：

1. 前端：每個模型對應一張節(jié)點DAG圖，逐個解析每個特征計算DSL，生成AST，并將AST節(jié)點添加到圖中。
2. 優(yōu)化器：針對DAG節(jié)點進行優(yōu)化，比如公共算子提取、常量折疊等。
3. 后端：將經(jīng)過優(yōu)化后的圖編譯成字節(jié)碼。

經(jīng)過優(yōu)化之后，對節(jié)點DAG圖的翻譯，即后端代碼實現(xiàn)，決定了最終的性能。這其中的一個難點，同時也是不能直接使用已有開源表達式引擎的原因：特征計算DSL并非是一個純計算型表達式。它可以通過讀取算子和轉(zhuǎn)換算子的組合來描述特征的獲取和處理過程：

1. 讀取算子：從存儲系統(tǒng)獲取特征的過程，是個IO型任務。比如查詢遠程KV系統(tǒng)。
2. 轉(zhuǎn)換算子：特征獲取到本地之后對特征進行轉(zhuǎn)換，是個計算密集型任務。比如對特征值做Hash。

所以在實際實現(xiàn)中，需要考慮不同類型任務的調(diào)度，盡可能提高機器資源利用率，優(yōu)化流程整體耗時。結(jié)合對業(yè)界的調(diào)研以及自身實踐，進行了以下三種實現(xiàn)：

1. 基于任務類型劃分Stage：將整個流程劃分成獲取和計算兩種Stage，Stage內(nèi)部分片并行處理，上一個Stage完成后再執(zhí)行下一個Stage。這是我們早期使用的方案，實現(xiàn)簡單，可以基于不同的任務類型選擇不同的分片大小，比如IO型任務可以使用更大的分片。但缺點也很明顯，會造成不同Stage的長尾疊加，每個Stage的長尾都會影響整個流程的耗時。
2. 基于流水線劃分Stage：為了減少不同Stage的長尾疊加，可以先將數(shù)據(jù)分片，為每個特征讀取分片添加回調(diào)，在IO任務完成后回調(diào)計算任務，使整個流程像流水線一樣平滑。分片調(diào)度可以讓上一個Stage就緒更早的分片提前進入下一個Stage，減少等待時間，從而減少整體請求耗時長尾。但缺點就是統(tǒng)一的分片大小不能充分提高每個Stage的利用率，較小的分片會給IO型任務帶來更多的網(wǎng)絡消耗，較大的分片會加劇計算型任務的耗時。
3. 基于SEDA（Staged Event-Driven Architecture）方式：階段式事件驅(qū)動方式使用隊列來隔離獲取Stage和計算Stage，每個Stage分配有獨立的線程池和批處理處理隊列，每次消費N（batching factor）個元素。這樣既能夠?qū)崿F(xiàn)每個Stage單獨選擇分片大小，同時事件驅(qū)動模型也可以讓流程保持平滑。這是我們目前正在探索的方式。

CodeGen方案也并非完美，動態(tài)生成的代碼降低了代碼可讀性，增加了調(diào)試成本，但以CodeGen作為適配層，也為更深入的優(yōu)化打開了空間。基于CodeGen和異步非阻塞的實現(xiàn)，在線上取到了不錯的收益，一方面減少了特征計算的耗時，另一方面也明顯的降低了CPU負載，提高了系統(tǒng)吞吐。未來我們會繼續(xù)發(fā)揮CodeGen的優(yōu)勢，在后端編譯過程中進行針對性的優(yōu)化，如探索結(jié)合硬件指令（如SIMD）或異構(gòu)計算（如GPU）來做更深層次的優(yōu)化。

4.2 傳輸優(yōu)化

在線預估服務整體上是雙層架構(gòu)，特征抽取層負責模型路由和特征計算，模型計算層負責模型計算。原有的系統(tǒng)流程是將特征計算后的結(jié)果拼接成M（預測的Batch Size） × N（樣本寬度）的矩陣，再經(jīng)過序列化傳輸?shù)接嬎銓印Ｖ赃@么做，一方面出于歷史原因，早期很多非DNN的簡單模型的輸入格式是個矩陣，經(jīng)過路由層拼接后，計算層可以直接使用，無需轉(zhuǎn)換；另一方面，數(shù)組格式比較緊湊，可以節(jié)省網(wǎng)絡傳輸耗時。然而隨著模型迭代發(fā)展，DNN模型逐漸成為主流，基于矩陣傳輸?shù)谋锥艘卜浅Ｃ黠@：

1. 擴展性差：數(shù)據(jù)格式統(tǒng)一，不兼容非數(shù)值類型的特征值。
2. 傳輸性能損耗：基于矩陣格式，需要對特征做對齊，比如Query/User維度需要被拷貝對齊到每個Item上，增大了請求計算層的網(wǎng)絡傳輸數(shù)據(jù)量。

為了解決以上問題，優(yōu)化后的流程在傳輸層之上加入一層轉(zhuǎn)換層，用來根據(jù)MDFL的配置將計算的模型特征轉(zhuǎn)換成需要的格式，比如Tensor、矩陣或離線使用的CSV格式等。實際線上大多數(shù)模型都是TF模型，為了進一步節(jié)省傳輸消耗，平臺設(shè)計了Tensor Sequence格式來存儲每個Tensor矩陣：其中，r_flag用來標記是否是item類特征，length表示item特征的長度，值為M（Item個數(shù)）×NF（特征長度），data用來存儲實際的特征值，對于Item特征將M個特征值扁平化存儲，對于請求類特征則直接填充?；诰o湊型Tensor Sequence格式使數(shù)據(jù)結(jié)構(gòu)更加緊湊，減少網(wǎng)絡傳輸數(shù)據(jù)量。優(yōu)化后的傳輸格式在線上也取得不錯的效果，路由層調(diào)用計算層的請求大小下降了50%+，網(wǎng)絡傳輸耗時明顯下降。

4.3 高維ID特征編碼

離散特征和序列特征可以統(tǒng)一為Sparse特征，特征處理階段會把原始特征經(jīng)過Hash處理，變?yōu)镮D類特征。在面對千億級別維度的特征，基于字符串拼接再Hash的過程，在表達空間和性能上，都無法滿足要求?；趯I(yè)界的調(diào)研，我們設(shè)計和應用了基于Slot編碼的方式特征編碼格式：

其中，feature_hash為原始特征值經(jīng)過Hash后的值。整型特征可以直接填充，非整型特征或交叉特征先經(jīng)過Hash后再填充，超過44位則截斷。基于Slot編碼方案上線后，不僅提升了在線特征計算的性能，同時也為模型效果的帶來了明顯提升。

5 樣本構(gòu)建

5.1 流式樣本

業(yè)界為了解決線上線下一致性的問題，一般都會在線dump實時打分使用的特征數(shù)據(jù)，稱為特征快照；而不是通過簡單離線Label拼接，特征回填的方式來構(gòu)建樣本，因為這種方式會帶來較大的數(shù)據(jù)不一致。架構(gòu)原始的方式如下圖所示：

這種方案隨著特征規(guī)模越來越大、迭代場景越來越復雜，突出的問題就是在線特征抽取服務壓力大，其次是整個數(shù)據(jù)流收集成本太高。此樣本收集方案存在以下問題：

1. 就緒時間長：在現(xiàn)有資源限制下，跑那么大數(shù)據(jù)幾乎要在T+2才能將樣本數(shù)據(jù)就緒，影響算法模型迭代。
2. 資源耗費大：現(xiàn)有樣本收集方式是將所有請求計算特征后與曝光、點擊進行拼接，由于對未曝光Item進行了特征計算、數(shù)據(jù)落表，導致存儲的數(shù)據(jù)量較大，耗費大量資源。

5.1.1 常見的方案

為了解決上面的問題，業(yè)界常見有兩個方案：①Flink實時流處理；②KV緩存二次處理。具體流程如下圖所示：

1. 流式拼接方案：借助流式處理框架（Flink、Storm等）低延遲的流處理能力，直接讀取曝光/點擊實時流，與特征快照流數(shù)據(jù)在內(nèi)存中進行關(guān)聯(lián)（Join）處理；先生成流式訓練樣本，再轉(zhuǎn)存為模型離線訓練樣本。其中流式樣本和離線樣本分別存儲在不同的存儲引擎中，支持不同類型的模型訓練方式。此方案的問題：在數(shù)據(jù)流動環(huán)節(jié)的數(shù)據(jù)量依然很大，占用較多的消息流資源（比如Kafka）；Flink資源消耗過大，如果每秒百G的數(shù)據(jù)量，做窗口Join則需要30分鐘×60×100G的內(nèi)存資源。
2. KV緩存方案：把特征抽取的所有特征快照寫入KV存儲（如Redis）緩存N分鐘，業(yè)務系統(tǒng)通過消息機制，把候選隊列中的Item傳入到實時計算系統(tǒng)（Flink或者消費應用），此時的Item的量會比之前請求的Item量少很多，這樣再將這些Item特征從特征快照緩存中取出，數(shù)據(jù)通過消息流輸出，支持流式訓練。這種方法借助了外存，不管隨著特征還是流量增加，F(xiàn)link資源可控，而且運行更加穩(wěn)定。但突出的問題還是需要較大的內(nèi)存來緩存大批量數(shù)據(jù)。

5.1.2 改進優(yōu)化

從減少無效計算的角度出發(fā)，請求的數(shù)據(jù)并不會都曝光。而策略對曝光后的數(shù)據(jù)有更強的需求，因此將天級處理前置到流處理，可以極大提升數(shù)據(jù)就緒時間。其次，從數(shù)據(jù)內(nèi)容出發(fā)，特征包含請求級變更的數(shù)據(jù)與天級變更的數(shù)據(jù)，鏈路靈活分離兩者處理，可以極大提升資源的利用，下圖是具體的方案：

1. 數(shù)據(jù)拆分：解決數(shù)據(jù)傳輸量大問題（特征快照流大問題），預測的Label與實時數(shù)據(jù)一一Match，離線數(shù)據(jù)可以通過回流的時候二次訪問，這樣可以極大降低鏈路數(shù)據(jù)流的大小。

• 樣本流中只有上下文+實時特征，增加讀取數(shù)據(jù)流穩(wěn)定性，同時由于只需要存儲實時特征，Kafka硬盤存儲下降10+倍。

2. 延時消費Join方式：解決占用內(nèi)存大問題。

• 曝光流作為主流，寫入到HBase中，同時為了后續(xù)能讓其他流在HBase中Join上曝光，將RowKey寫入Redis；后續(xù)流通過RowKey寫入HBase，曝光與點擊、特征的拼接借助外存完成，保證數(shù)據(jù)量增大后系統(tǒng)能穩(wěn)定運行。
• 樣本流延時消費，后臺服務的樣本流往往會比曝光流先到，為了能Join上99%+的曝光數(shù)據(jù)，樣本流等待窗口統(tǒng)計至少要N分鐘以上；實現(xiàn)方式是將窗口期的數(shù)據(jù)全部壓在Kafka的磁盤上，利用磁盤的順序讀性能，省略掉了窗口期內(nèi)需要緩存數(shù)據(jù)量的大量內(nèi)存。

3. 特征補錄拼樣本：通過Label的Join，此處補錄的特征請求量不到在線的20%；樣本延遲讀取，與曝光做拼接后過濾出有曝光模型服務請求（Context+實時特征），再補錄全部離線特征，拼成完整樣本數(shù)據(jù)，寫入HBase。

5.2 結(jié)構(gòu)化存儲

隨著業(yè)務迭代，特征快照中的特征數(shù)量越來越大，使得整體特征快照在單業(yè)務場景下達到幾十TB級別/天；從存儲上看，多天單業(yè)務的特征快照就已經(jīng)PB級別，快到達廣告算法存儲閾值，存儲壓力大；從計算角度上看，使用原有的計算流程，由于計算引擎（Spark）的資源限制（使用到了shuffle，shuffle write階段數(shù)據(jù)會落盤，如果分配內(nèi)存不足，會出現(xiàn)多次落盤和外排序），需要與自身數(shù)據(jù)等大小的內(nèi)存和較多的計算CU才能有效的完成計算，占用內(nèi)存高。樣本構(gòu)建流程核心流程如下圖所示：

在補錄特征時，存在以下問題：

1. 數(shù)據(jù)冗余：補錄特征的離線表一般為全量數(shù)據(jù)，條數(shù)在億級別，樣本構(gòu)建用到的條數(shù)約為當日DAU的數(shù)量即千萬級別，因此補錄的特征表數(shù)據(jù)在參與計算時存在冗余數(shù)據(jù)。
2. Join順序：補錄特征的計算過程即維度特征補全，存在多次Join計算，因此Join計算的性能和Join的表的順序有很大關(guān)系，如上圖所示，如果左表為幾十TB級別的大表，那么之后的shuffle計算過程都會產(chǎn)生大量的網(wǎng)絡IO、磁盤IO。

為了解決樣本構(gòu)建效率慢的問題，短期先從數(shù)據(jù)結(jié)構(gòu)化治理，詳細過程如下圖所示：

1. 結(jié)構(gòu)化拆分。數(shù)據(jù)拆分成Context數(shù)據(jù)和結(jié)構(gòu)化存儲的維度數(shù)據(jù)代替混合存儲。解決Label樣本拼接新特征過程中攜帶大量冗余數(shù)據(jù)問題；并且做結(jié)構(gòu)化存儲后，針對離線特征，得到了很大的存儲壓縮。
2. 高效過濾前置。數(shù)據(jù)過濾提前到Join前，減少參與特征計算的數(shù)據(jù)量，可以有效降低網(wǎng)絡IO。在拼接過程中，補錄特征的Hive表一般來說是全量表，數(shù)據(jù)條數(shù)一般為月活量，而實際拼接過程中使用的數(shù)據(jù)條數(shù)約為日活量，因此存在較大的數(shù)據(jù)冗余，無效的數(shù)據(jù)會帶來額外的IO和計算。優(yōu)化方式為預計算使用的維度Key，并生成相應的布隆過濾器，在數(shù)據(jù)讀取的時候使用布隆過濾器進行過濾，可以極大降低補錄過程中冗余數(shù)據(jù)傳輸和冗余計算。
3. 高性能Join。使用高效的策略去編排Join順序，提升特征補錄環(huán)節(jié)的效率和資源占用。在特征拼接過程中，會存在多張表的Join操作，Join的先后順序也會極大影響拼接性能。如上圖所示，如果拼接的左表數(shù)據(jù)量較大時，那么整體性能就會差?？梢允褂霉蚵惴ǖ乃枷?，把每個表看作一個節(jié)點，對應的數(shù)據(jù)量量看成是他的權(quán)重，表之間的Join計算量可以簡單類比兩個節(jié)點的權(quán)重相加。因此，可以將此問題抽象成構(gòu)造哈夫曼樹，哈夫曼樹的構(gòu)造過程即為最優(yōu)的Join順序。

數(shù)據(jù)離線存儲資源節(jié)省達80%+，樣本構(gòu)建效率提升200%+，當前整個樣本數(shù)據(jù)也正在進行基于數(shù)據(jù)湖的實踐，進一步提升數(shù)據(jù)效率。

6 數(shù)據(jù)準備

平臺積累了大量的特征、樣本和模型等有價值的內(nèi)容，希望通過對這些數(shù)據(jù)資產(chǎn)進行復用，幫助策略人員更好的進行業(yè)務迭代，取得更好的業(yè)務收益。特征優(yōu)化占了算法人員提升模型效果的所有方法中40%的時間，但傳統(tǒng)的特征挖掘的工作方式存在著花費時間長、挖掘效率低、特征重復挖掘等問題，所以平臺希望在特征維度賦能業(yè)務。如果有自動化的實驗流程去驗證任意特征的效果，并將最終效果指標推薦給用戶，無疑會幫助策略同學節(jié)省大量的時間。當整個鏈路建設(shè)完成，后續(xù)只需要輸入不同的特征候選集，即可輸出相應效果指標。為此平臺建設(shè)了特征、樣本的“加”、“減”、“乘”、“除”智能機制。

6.1 做“加法”

特征推薦基于模型測試的方法，將特征復用到其他業(yè)務線現(xiàn)有模型，構(gòu)造出新的樣本和模型；對比新模型和Base模型的離線效果，獲取新特征的收益，自動推送給相關(guān)的業(yè)務負責人。具體特征推薦流程如下圖所示：

1. 特征感知：通過上線墻或業(yè)務間存量方式觸發(fā)特征推薦，這些特征已經(jīng)過一定驗證，可以保證特征推薦的成功率。
2. 樣本生產(chǎn)：樣本生產(chǎn)時通過配置文件抽取特征，流程自動將新增特征加到配置文件中，然后進行新樣本數(shù)據(jù)的生產(chǎn)。獲取到新特征后，解析這些特征依賴的原始特征、維度、和UDF算子等，將新特征配置和依賴的原始數(shù)據(jù)融合到基線模型的原有配置文件中，構(gòu)造出新的特征配置文件。自動進行新樣本構(gòu)建，樣本構(gòu)建時通過特征名稱在特征倉庫中抽取相關(guān)特征，并調(diào)用配置好的UDF進行特征計算，樣本構(gòu)建的時間段可配置。
3. 模型訓練：自動對模型結(jié)構(gòu)和樣本格式配置進行改造，然后進行模型訓練，使用TensorFlow作為模型訓練框架，使用tfrecord格式作為樣本輸入，將新特征按照數(shù)值類和ID類分別放到A和B兩個組中，ID類特征進行查表操作，然后統(tǒng)一追加到現(xiàn)有特征后面，不需要修改模型結(jié)構(gòu)便可接收新的樣本進行模型訓練。
4. 自動配置新模型訓練參數(shù)：包括訓練日期、樣本路徑、模型超參等，劃分出訓練集和測試集，自動進行新模型的訓練。
5. 模型評測：調(diào)用評估接口得到離線指標，對比新老模型評測結(jié)果，并預留單特征評估結(jié)果，打散某些特征后，給出單特征貢獻度。將評估結(jié)果統(tǒng)一發(fā)送給用戶。

6.2 做“減法”

特征推薦在廣告內(nèi)部落地并取得了一定收益后，我們在特征賦能層面做一些新的探索。隨著模型的不斷優(yōu)化，特征膨脹的速度非常快，模型服務消耗資源急劇上升，剔除冗余特征，為模型“瘦身”勢在必行。因此，平臺建設(shè)了一套端到端的特征篩選工具。

1. 特征打分：通過WOE（Weight Of Evidence, 證據(jù)權(quán)重）等多種評估算法給出模型的所有特征評分，打分較高特征的質(zhì)量較高，評估準確率高。
2. 效果驗證：訓練好模型后，按打分排序，分批次對特征進行剔除。具體通過采用特征打散的方法，對比原模型和打散后模型評估結(jié)果，相差較大低于閾值后結(jié)束評估， 給出可以剔除的特征。
3. 端到端方案：用戶配置好實驗參數(shù)和指標閾值后，無需人為干涉，即可給出可刪除的特征以及刪除特征后模型的離線評估結(jié)果。

最終，在內(nèi)部模型下線40%的特征后，業(yè)務指標下降仍然控制在合理的閾值內(nèi)。

6.3 做“乘法”

為了得到更好的模型效果，廣告內(nèi)部已經(jīng)開始做一些新的探索，包括大模型、實時化、特征庫等。這些探索背后都有一個關(guān)鍵目標：需要更多、更好的數(shù)據(jù)讓模型更智能、更高效。從廣告現(xiàn)狀出發(fā)，提出樣本庫（Data Bank）建設(shè)，實現(xiàn)把外部更多種類、更大規(guī)模的數(shù)據(jù)拿進來，應用于現(xiàn)有業(yè)務。具體如下圖所示：

我們建立了一套通用的樣本共享平臺，在這個平臺上，可以借用其他業(yè)務線來產(chǎn)生增量樣本。并且也搭建通用的Embedding共享架構(gòu)，實現(xiàn)業(yè)務的以大帶小。下面以廣告業(yè)務線復用非廣告樣本為例，具體做法如下：

1. 擴樣本：基于Flink流式處理框架，建設(shè)了高擴展樣本庫DataBank，業(yè)務A很方便復用業(yè)務B、業(yè)務C的曝光、點擊等Label數(shù)據(jù)去做實驗。尤其是為小業(yè)務線，擴充了大量的價值數(shù)據(jù)，這種做法相比離線補錄Join，一致性會更強，特征平臺提供了在線、離線一致性保障。
2. 做共享：在樣本就緒后，一個很典型的應用場景就是遷移學習。另外，也搭建Embedding共享的數(shù)據(jù)通路（不強依賴“擴樣本”流程），所有業(yè)務線可以基于大的Embedding訓練，每個業(yè)務方也可以update這個Embedding，在線通過建立Embedding版本機制，供多個業(yè)務線使用。

舉例來說，通過將非廣告樣本復用到廣告內(nèi)一個業(yè)務，使樣本數(shù)量增加了幾倍，結(jié)合遷移學習算法，離線AUC提升千分之四，上線后CPM提升百分之一。此外，我們也在建設(shè)廣告樣本主題庫，將各業(yè)務生成的樣本數(shù)據(jù)進行統(tǒng)一管理（統(tǒng)一元數(shù)據(jù)），面向用戶透出統(tǒng)一樣本主題分類，快速注冊、查找、復用，面向底層統(tǒng)一存儲，節(jié)約存儲、計算資源，減少數(shù)據(jù)Join，提高時效性。

6.4 做“除法”

通過特征“減法”可以剔除一些無正向作用的特征，但通過觀察發(fā)現(xiàn)模型中還存在很多價值很小的特征。所以更進一步我們可以通過價值、成本兩方面綜合考慮，在全鏈路基于成本的約束下價值最大，篩選出那些投入產(chǎn)出比較低特征，降低資源消耗。這個在成本約束下去求解的過程定義為做“除法”，整體流程如下圖所示。

在離線維度，我們建立了一套特征價值評估系統(tǒng)，給出特征的成本和價值，在線推理時可以通過特征價值信息進行流量降級、特征彈性計算等操作，做“除法”關(guān)鍵步驟如下：

1. 問題抽象：如果我們能得到每個特征的價值得分，又可以拿到特征的成本（存儲、通信、計算加工），那么問題就轉(zhuǎn)換成了在已知模型結(jié)構(gòu)、固定資源成本下，如何讓特征的價值最大化。
2. 成本約束下的價值評估：基于模型的特征集，平臺首先進行成本和價值的統(tǒng)計匯總；成本包括了離線成本和在線成本，基于訓練好的評判模型，得出特征的綜合排序。
3. 分場景建模：可以根據(jù)不同的資源情況，選擇不同的特征集，進行建模。在有限的資源下，選擇價值最大的模型在線Work。另外，可以針對比較大的特征集建模，在流量低峰啟用，提升資源利用率的同時給業(yè)務帶來更大收益。還有一種應用場景是流量降級，推理服務監(jiān)控在線資源的消耗，一旦資源計算達到瓶頸，切換到降級模型。

7 總結(jié)與展望

以上是我們在大規(guī)模深度學習工程上的反“增”實踐，去助力業(yè)務降本提效。未來我們還會持續(xù)在以下方面進行探索、實踐：

1. 全鏈路GPU化：在推理層面，通過GPU的切換，支撐更復雜業(yè)務迭代的同時，整體成本也極大的降低，后面會在樣本構(gòu)建、特征服務上進行GPU化改造，并協(xié)同推進離線訓練層面的升級。
2. 樣本數(shù)據(jù)湖：通過數(shù)據(jù)湖的Schema Evolution、Patch Update等特性構(gòu)建更大規(guī)模的樣本倉庫，對業(yè)務方進行低成本、高價值的數(shù)據(jù)透出。
3. Pipeline：算法全生命周期迭代過程中，很多環(huán)節(jié)的調(diào)試，鏈路信息都不夠“串聯(lián)”，以及離線、在線、效果指標的視角都比較割裂，基于全鏈路的標準化、可觀測大勢所趨，并且這是后續(xù)鏈路智能化彈性調(diào)配的基礎(chǔ)?，F(xiàn)在業(yè)界比較火的MLOps、云原生都有較多的借鑒思路。
4. 數(shù)據(jù)、模型智能匹配：上文提到在模型結(jié)構(gòu)固定前提下，自動為模型加、減特征，同理在模型層面，固定一定特征輸入前提下，去自動嵌入一些新的模型結(jié)構(gòu)。以及在未來，我們也將基于業(yè)務領(lǐng)域，通過平臺的特征、模型體系，自動化地完成數(shù)據(jù)、模型的匹配。

8 本文作者

亞劼、英亮、陳龍、成杰、登峰、東奎、仝曄、思敏、樂彬等，均來自美團外賣技術(shù)團隊。