外送廣告大規模深度學習模型工程實踐

作者：亞劼英亮陳龍等

導語

隨著美團外送業務不斷發展，外賣廣告引擎團隊在多個領域進行了工程上的探索和實踐，也取得了一些成果。我們將以連載的方式進行分享，內容主要包括：① 業務平台化的實踐；② 大規模深度學習模型工程實踐；③ 近線計算的探索與實踐；④ 大規模索引構建與在線檢索服務實踐；⑤機制工程平台化實務。不久前，我們已發表過業務平台化的實踐（詳情請參閱《#美團外帶廣告平台化的探索與實踐 #》一文）。本文為連載文章的第二篇，我們將重點放在大規模深度模型在全鏈路層面帶來的挑戰，從線上延遲、離線效率兩個面向展開，闡述廣告在大規模深度模型上的工程實踐，希望能為大家帶來一些幫助或啟發。

1 背景

在搜尋、推薦、廣告（下簡稱搜推廣）等網路核心業務場景下，進行資料探勘及興趣建模，為使用者提供優質的服務，已成為改善使用者體驗的關鍵要素。近幾年，針對搜推廣業務，深度學習模型憑藉數據紅利和硬體技術紅利，在業界得以廣泛落地，同時在CTR場景，業界逐步從簡單DNN小模型過渡到數萬億參數的Embedding大模型甚至超大模型。外送廣告業務線主要經歷了“LR淺層模型（樹模型）” -> “深度學習模型” -> “大規模深度學習模型”的演化過程。整個演化趨勢從以人工特徵為主的簡單模型，逐步向以資料為核心的複雜深度學習模型進行過渡。而大模型的使用，大幅提高了模型的表達能力，更精準地實現了供需側的匹配，為後續業務發展提供了更多的可能性。但隨著模型、資料規模的不斷變大，我們發現效率跟它們存在如下的關係：#根據上圖所示，在資料規模、模型規模成長的情況下，所對應的「時長」變得會越來越長。這個「時長」對應到離線層面，體現在效率上；對應到線上層面，就體現在Latency上。而我們的工作就是圍繞著這個「時長」的優化來進行。

2 分析

比起一般小模型，大模型的核心問題在於：隨著資料量、模型規模增加數十倍甚至百倍，整體鏈路上的儲存、通訊、運算等都將面臨新的挑戰，進而影響演算法離線的迭代效率。如何突破線上時延約束等一連串問題？我們先從全連結進行分析，如下：

「時長」變長，主要會體現在以下幾個方面：

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

本文重點從線上延遲（模型推理、特徵服務）、離線效率（樣本建構、資料準備）等兩個面向展開，逐步闡述廣告在大規模深度模型上的工程實踐。如何優化「時長」等相關問題，我們會在後續篇章介進行分享，敬請期待。

3 模型推理

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

#面向大模型推理場景，3.0架構解決的兩個核心問題是：「儲存問題」和「效能問題」。當然，面向N個百G 模型如何迭代，運算量數十倍增加時在線穩定性如何保障，Pipeline如何加固等等，也是工程面臨的挑戰。以下我們將重點介紹模型推理3.0架構如何透過「分散式」來解決大模型儲存問題，以及如何透過CPU/GPU加速來解決效能、吞吐問題。

3.1 分散式

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

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

因此，解決大模型參數規模增長的關鍵是將Sparse參數由單機存儲改造為分佈式存儲，改造的方式包括兩部分：① 模型網絡結構轉換；② Sparse參數導出。

3.1.1 模型網路結構轉換

業界對於分散式參數的取得方式大致分為兩種：外部服務提前取得參數並傳給預估服務；預估服務內部透過改造TF（TensorFlow）算符來從分散式儲存取得參數。為了減少架構改造成本和降低對現有模型結構的侵入性，我們選擇透過改造TF算子的方式來取得分散式參數。

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

算符的作用是從Embedding表中讀取ID列表索引對應的Embedding資料並傳回，本質上是一個Hash查詢的過程。其中，Embedding表儲存的Sparse參數，其在單機模型中全部儲存在單機記憶體中。

改造TF算子本質上是對模型網路結構的改造，改造的核心點主要包括兩部分：① 網路圖重構；② 自訂分散式算子。

1. 網路圖重構：改造模型網路結構，將原生TF算子替換為自訂分散式算子，同時進行原生Embedding表的固化。

• 分散式運算子替換：遍歷模型網絡，將需要替換的GatherV2算子替換為自訂分散式算子MtGatherV2，同時修改上下游節點的Input/Output。
• 原生Embedding表固化：原生Embedding表固化為佔位符，既能保留模型網路結構完整，又能避免Sparse參數對單機記憶體的佔用。

2. 自訂分散式運算子：改造根據ID清單查詢Embedding流程，從本地Embedding表查詢，改造為從分散式KV查詢。

• 請求查詢：將輸入ID進行去重以降低查詢量，並透過分片的方式並發查詢二級快取（ 本機Cache 遠端KV）取得Embedding向量。
• 模型管理：維護對模型Embedding Meta註冊、卸載流程，以及對Cache的建立、銷毀功能。
• 模型部署：觸發模型資源資訊的加載，以及對Embedding資料並行導入KV的流程。

3.1.2 Sparse參數導出

• #分片並行導出：解析模型的Checkpoint文件，取得Embedding表對應的Part訊息，並根據Part進行劃分，將每個Part檔案透過多個Worker節點並行匯出到HDFS上。
• 導入KV：提前預先分配多個Bucket，Bucket會儲存模型版本等信息，以便線上路由查詢。同時模型的Embedding資料也會儲存到Bucket中，以分片並行方式匯入KV中。

整體流程如下圖所示，我們透過離線分散式模型結構轉換、近線資料一致性保證、線上熱點資料快取等手段，保障了百G大模型的正常迭代需求。

可以看到，分散式借助的儲存是外部KV能力，後續會被替換為更有效率、更靈活、更容易管理的Embedding Service。

3.2 CPU加速

拋開模型本身的最佳化手段外，常見的CPU加速手段主要有兩種：① 指令集最佳化，例如使用AVX2、AVX512指令集；② 使用加速函式庫（TVM、OpenVINO）。

1. 指令集最佳化：如果使用TensorFlow模型，在編譯TensorFlow框架程式碼時，直接在編譯選項中加入指令集優化項即可。實務證明引入AVX2、AVX512指令集優化效果明顯，線上推理服務吞吐提升30% 。
2. 加速函式庫最佳化：加速函式庫透過對網路模型結構進行最佳化融合，以達到推理加速效果。業界常用的加速庫有TVM、OpenVINO等，其中TVM支援跨平台，通用性較好。 OpenVINO針對Intel廠商硬體進行針對性最佳化，通用性一般，但加速效果較好。

下面，將會重點介紹我們使用OpenVINO進行CPU加速的一些實務經驗。 OpenVINO是Intel推出的一套基於深度學習的運算加速最佳化框架，支援機器學習模型的壓縮最佳化、加速運算等功能。 OpenVINO的加速原理簡單概括為兩部分：線性算子融合和資料精度校準。

1. 線性算子融合：OpenVINO透過模型最佳化器，將模型網路中的多層算子進行統一線性融合，以降低算子調度開銷和算子間的資料訪存開銷，例如將Conv BN Relu三個算子合併成一個CBR結構算子。
2. 資料精確度校準：模型經過離線訓練後，由於在推理的過程中不需要反向傳播，完全可以適當地降低資料精度，例如降為FP16或INT8的精確度，使得記憶體佔用更小，推理延遲更低。

CPU加速通常是針對固定Batch的候選隊列進行加速推理，但在搜推廣場景中，候選隊列往往都是動態的。這意味著在模型推理之前，需要增加Batch匹配的操作，即將請求的動態Batch候選隊列映射到一個離它最近的Batch模型上，但這需建立N個匹配模型，導致N倍的記憶體佔用。而目前模型體積已達百G規模，記憶體嚴重吃緊。因此，選取合理的網路結構用於加速是需要考慮的重點問題。下圖是整體的運行架構：

1. 網路分佈：CTR模型網路結構整體抽象化為三個部分：Embedding層、Attention層和MLP層，其中Embedding層用於資料擷取，Attention層包含較多邏輯運算和輕量級的網路運算，MLP層則為密集網路運算。
2. 加速網路選擇：OpenVINO針對純網路運算的加速效果較好，可以很好地應用於MLP層。另外，模型大部分資料儲存在Embedding層中，MLP層佔記憶體只有幾十兆左右。若針對MLP層網路分割出多個Batch，模型記憶體佔用在最佳化前（Embedding Attention MLP）≈ 最佳化後（Embedding Attention MLP×Batch個數），對於記憶體佔用的影響較小。因此，我們最終選取MLP層網路作為模型加速網路。

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

3.3 GPU加速

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

3.3.1 加速分析

• 異構運算：我們的想法跟CPU加速比較一致，200G的深度學習CTR模型不能直接全放入GPU裡，訪存密集型算子適用（例如Embedding相關運算）CPU，計算密集型算子（例如MLP）適用GPU。
• GPU使用需要關注的幾個點：① 記憶體與顯存的頻繁交互作用；② 時延與吞吐；③ 擴展性與效能最佳化的Trade Off；④ GPU Utilization 。
• 推理引擎的選擇：業界常用推理加速引擎有TensorRT、TVM、XLA、ONNXRuntime等，由於TensorRT在算子優化相比其他引擎更加深入，同時可以透過自訂plugin的方式實現任意算子，具有很強的擴展性。而TensorRT支援常見學習平台（Caffe、PyTorch、TensorFlow等）的模型，其周邊越來越完善（ #模型轉換工具onnx-tensorrt、效能分析工具nsys等），因此在GPU側的加速引擎使用TensorRT。
• 模型分析：CTR模型網路結構整體抽象為三部分：Embedding層、Attention層和MLP層，其中Embedding層用於資料獲取，適合CPU ；Attention層包含較多邏輯運算和輕量級的網路運算，MLP層則重網路運算，而這些運算可以並行進行，適合GPU，可以充分利用GPU Core（Cuda Core、Tensor Core ），提高並行度。

3.3.2 最佳化目標

深度學習推理階段對算力和延遲具有很高的要求，如果將訓練好的神經網路直接部署到推理端，很有可能出現算力不足無法運作或推理時間較長等問題。因此，我們需要對訓練好的神經網路進行一定的優化。業界神經網路模型優化的一般思路，可以從模型壓縮、不同網路層合併、稀疏化、採用低精度資料類型等不同方面進行最佳化，甚至還需要根據硬體特性進行針對性優化。為此，我們主要圍繞以下兩個目標進行最佳化：

1. 延時和資源限制下的吞吐：當register、Cache等共享資源不需要競爭時，提高並發可有效提高資源利用率（CPU、 GPU等利用率），但隨之可能帶來請求延遲的上漲。由於線上系統的延時限制非常苛刻，所以不能只透過資源利用率這個指標簡單換算在線系統的吞吐上限，需要在延遲約束下結合資源上限進行綜合評估。當系統延遲較低，資源（Memory/CPU/GPU等）利用率是限制因素時，可透過模型最佳化降低資源利用率；當系統資源利用率均較低，延時為限制因素時，可透過融合優化和引擎優化來降低延遲。透過結合以上各種優化手段可有效提升系統服務的綜合能力，進而達到提升系統吞吐的目的。
2. 計算量約束下的運算密度：CPU/GPU異構系統下，模型推理效能主要受資料拷貝效率和運算效率影響，它們分別由訪存密集型算子和運算密集型算子決定，而資料拷貝效率受PCIe資料傳輸、CPU/GPU記憶體讀寫等效率的影響，運算效率受各種運算單元CPU Core、CUDA Core、Tensor Core等運算效率的影響。隨著GPU等硬體的快速發展，運算密集型算子的處理能力同步快速提高，導致訪存密集型算子阻礙系統服務能力提升的現象越來越突出，因此減少訪存密集型算子，提升計算密度對系統服務能力也變得越來越重要，即在模型計算量變化不大的情況下，減少資料拷貝和kernel launch等。例如透過模型優化和融合優化來減少算子變換（例如Cast/Unsqueeze/Concat等算子）的使用，使用CUDA Graph減少kernel launch等。

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

3.3.3 模型最佳化

#1. 計算與傳輸去重：推理時同一Batch只包含一個使用者訊息，因此在進行inference之前可以將使用者資訊從Batch Size降為1，真正需要inference時再展開，降低資料的傳輸拷貝以及重複計算開銷。如下圖，inference前可以只查詢一次User類特徵信息，並在只有用戶相關的子網路中進行裁剪，待需要計算關聯時再展開。

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

2. 資料精確度最佳化：由於模型訓練時需要反向傳播更新梯度，對資料精度要求較高；而模型推理時，只進行前向推理不需要更新梯度，所以在保證效果的前提下，使用FP16或混合精度進行優化，節省記憶體空間，減少傳輸開銷，提升推理效能和吞吐。

3. 計算推：CTR模型結構主要由Embedding、Attention和MLP三層構成，Embedding層偏資料獲取， Attention有部分偏邏輯，部分偏計算，為了充分壓榨GPU的潛力，將CTR模型結構中Attention和MLP大部分運算邏輯由CPU下沉到GPU進行計算，整體吞吐大幅提升。

#

3.3.4 融合最佳化

線上模型inference時，每一層的運算運算都是由GPU完成，實際上是CPU透過啟動不同的CUDA kernel來完成運算，CUDA kernel計算張量的速度非常快，但是往往大量的時間是浪費在CUDA kernel的啟動和對每一層輸入/輸出張量的讀寫操作上，這造成了內存頻寬的瓶頸和GPU資源的浪費。這裡我們將主要介紹TensorRT部分自動優化以及手動優化兩塊工作。 1. 自動最佳化：TensorRT是一個高效能的深度學習inference優化器，可以為深度學習應用提供低延遲、高吞吐的推理部署。 TensorRT可用於對超大規模車型、嵌入式平台或自動駕駛平台進行推理加速。 TensorRT現已支援TensorFlow、Caffe、MXNet、PyTorch等幾乎所有的深度學習框架，將TensorRT和NVIDIA的GPU結合起來，幾乎可以在所有的框架中進行快速且有效率的部署推理。而且有些優化不需要使用者過度參與，例如部分Layer Fusion、Kernel Auto-Tuning等。

• Layer Fusion：TensorRT透過對層間的橫向或縱向合併，使網路層的數量大大減少，簡單說就是透過融合一些計算op或去掉一些多餘op，來減少資料流通次數、顯存的頻繁使用、調度的開銷。例如常見網路結構Convolution And ElementWise Operation融合、CBR融合等，下圖是整個網路結構中的部分子圖融合前後結構圖，FusedNewOP在融合過程中可能會涉及多種Tactic，例如CudnnMLPFC、CudnnMLPMM、CudaMLP等，最後會根據時長選擇一個最優的Tactic作為融合後的結構。透過融合操作，使得網路層數減少、資料通道變短；相同結構合併，使資料通道變寬；達到更有效率利用GPU資源的目的。

• Kernel Auto-Tuning：網路模型在inference時，是呼叫GPU的CUDA kernel進行計算。 TensorRT可以針對不同的網路模型、顯示卡結構、SM數量、核心頻率等進行CUDA kernel調整，選擇不同的最佳化策略和計算方式，尋找適合當前的最優計算方式，以確保當前模型在特定平台上獲得最優的性能。上圖是最佳化主要思想，每一個op會有多種kernel最佳化策略（cuDNN、cuBLAS等），根據目前架構從所有最佳化策略中過濾低效kernel，同時選擇最優kernel，最終形成新的Network。

2. #手工最佳化：眾所周知，GPU適合計算密集型的算子，對於其他類型算子（輕量級計算算子，邏輯運算算子等）不太友善。使用GPU運算時，每次運算一般要經過幾個流程：CPU在GPU上分配顯存 -> CPU把資料傳送給GPU -> CPU啟動CUDA kernel -> CPU把資料取回 -> CPU釋放GPU顯存。為了減少調度、kernel launch以及訪存等開銷，需要進行網路融合。由於CTR大模型結構靈活多變，網路融合手段難以統一，只能具體問題具體分析。例如在垂直方向，Cast、Unsqueeze和Less融合，TensorRT內部Conv、BN和Relu融合；在水平方向，同維度的輸入算子進行融合。為此，我們基於線上實際業務場景，使用NVIDIA相關效能分析工具（NVIDIA Nsight Systems、NVIDIA Nsight Compute等）進行具體問題的分析。把這些效能分析工具整合到線上inference環境中，以獲得inference過程中的GPU Profing檔案。透過Profing文件，我們可以清楚的看到inference過程，我們發現整個inference中部分算子kernel launch bound現象嚴重，而且部分算子之間gap間隙較大，存在優化空間，如下圖所示：

為此，基於效能分析工具和轉換後的模型對整個Network分析，找出TensorRT已經最佳化的部分，然後對Network中其他可以最佳化的子結構進行網路融合，同時也要確保這樣的子結構在整個Network佔有一定的比例，確保融合後運算密度能夠有一定程度的上升。至於採用什麼樣的網路融合手段，根據具體的場景進行靈活運用即可，如下圖是我們融合前後的子結構圖對比：

3.3 .5 引擎最佳化

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

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

5. 多層次PS：為了進一步挖掘GPU加速引擎效能，對Embedding資料的查詢操作可透過多層PS的方式進行：GPU顯存Cache->CPU記憶體Cache->本地SSD/分散式KV。其中，熱點資料可快取在GPU顯存中，並透過資料熱點的遷移、晉升和淘汰等機制對快取資料進行動態更新，充分挖掘GPU的並行算力和訪存能力進行高效查詢。經離線測試，GPU Cache查詢效能相比CPU Cache提升10倍；對於GPU Cache未命中數據，可透過存取CPU Cache進行查詢，兩級Cache可滿足90% 的資料存取；對於長尾請求，則需要透過存取分散式KV進行資料擷取。具體架構如下：

3.3.6 Pipeline

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

#

Pipeline建置包含兩部分：離線側模型分割轉換流程，以及線上側模型部署流程：

1. ##離線側：只需提供模型分割節點，平台會自動將原始TF模型拆分成Embedding子模型和計算圖子模型，其中Embedding子模型透過分散式轉換器進行分散式運算子替換和Embedding導入工作；計算圖子模型則根據選擇的硬體環境（GPU型號、TensorRT版本、CUDA版本）進行TensorRT模型的轉換和編譯優化工作，最終將兩個子模型的轉換結果儲存到S3中，用於後續的模型部署上線。整個流程都是平台自動完成，無需使用方感知執行細節。
2. 線上測試：只需選擇模型部署硬體環境（與模型轉換的環境保持一致），平台會根據環境配置，進行模型的自適應推送加載，一鍵完成模型的部署上線。

Pipeline透過配置化、一鍵化能力的建設，大幅提升了模型迭代效率，幫助演算法和工程同學能更專注的做好本職工作。下圖是GPU實務上比起純CPU推理所取得的整體效益：

4 特徵服務CodeGen最佳化

4 特徵服務CodeGen最佳化##特徵抽取是模型計算的前置階段，無論是傳統的LR模型或日趨流行的深度學習模型，都需要透過特徵抽取來得到輸入。在先前的部落格#美團外帶特徵平台的建立與實踐

#中，描述了我們基於模型特徵自描述MFDL，將特徵計算流程配置化，盡量保證了線上預估和離線訓練時樣本的一致性。隨著業務快速迭代，模型特徵數量不斷增加，特別是大模型引入了大量的離散特徵，導致計算量有了倍數的增長。為此，我們對特徵抽取層做了一些優化，在吞吐和耗時都取得了顯著的效益。

4.1 全流程CodeGen最佳化

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

#############

借鑒了Spark的WholeStageCodeGen，我們的目標是將整個特徵計算DSL編譯形成一個可執行方法，從而減少程式碼運行時的效能損耗。整個編譯過程可以分為：前端（FrontEnd），優化器（Optimizer）和後端（BackEnd）。前端主要負責解析目標DSL，將原始碼轉換為AST或IR；最佳化器則是在前端的基礎上，對所得到的中間程式碼進行最佳化，使程式碼更有效率；後端則是將已經最佳化的中間程式碼轉換為針對各自平台的本地代碼。具體實現如下：

1. 前端：每個模型對應一張節點DAG圖，逐一解析每個特徵計算DSL，產生AST，並將AST節點加入圖中。
2. 優化器：針對DAG節點進行最佳化，例如公共算子擷取、常數折疊等。
3. 後端：將經過最佳化後的圖編譯成字節碼。

已優化後，對節點DAG圖的翻譯，即後端程式碼實現，決定了最終的效能。這其中的一個困難點，同時也是不能直接使用已有開源表達式引擎的原因：特徵計算DSL並非是一個純計算型表達式。它可以透過讀取算子和轉換算子的組合來描述特徵的取得和處理過程：

1. #讀取算子：從存儲系統取得特徵的過程，是個IO型任務。例如查詢遠端KV系統。
2. 轉換算符：特徵取得到本地之後對特徵進行轉換，是個計算密集型任務。例如對特徵值做Hash。

所以在實際實作中，需要考慮不同類型任務的調度，盡可能提高機器資源利用率，優化流程整體耗時。結合業界的研究以及自身實踐，進行了以下三種實現：

#

1. 基於任務類型分割Stage：將整個流程分割成取得和計算兩種Stage，Stage內部分片並行處理，上一個Stage完成之後再執行下一個Stage。這是我們早期使用的方案，實作簡單，可以基於不同的任務類型選擇不同的分片大小，例如IO型任務可以使用更大的分片。但缺點也很明顯，會造成不同Stage的長尾疊加，每個Stage的長尾都會影響整個流程的耗時。
2. 以管線劃分Stage#：為了減少不同Stage的長尾疊加，可以先將資料分片，為每個特徵讀取分片加入回調，在IO任務完成後回調計算任務，使整個流程像管線一樣平滑。分片調度可以讓上一個Stage就緒更早的分片提前進入下一個Stage，減少等待時間，從而減少整體請求耗時長尾。但缺點就是統一的分片大小無法充分提高每個Stage的利用率，較小的分片會為IO型任務帶來更多的網路消耗，較大的分片會加劇計算型任務的耗時。
3. 基於SEDA（Staged Event-Driven Architecture）方式：階段式事件驅動方式使用佇列來隔離取得Stage和運算Stage，每個Stage分配有獨立的執行緒池和批次佇列，每次消費N（batching factor）個元素。這樣既能夠實現每個Stage單獨選擇分片大小，同時事件驅動模型也可以讓流程保持平滑。這是我們目前正在探索的方式。

CodeGen方案也並非完美，動態產生的程式碼降低了程式碼可讀性，增加了除錯成本，但以CodeGen作為適配層，也為更深入的優化開啟了空間。基於CodeGen和非同步非阻塞的實現，在線上取到了不錯的收益，一方面減少了特徵計算的耗時，另一方面也明顯的降低了CPU負載，提高了系統吞吐。未來我們將繼續發揮CodeGen的優勢，在後端編譯過程中進行針對性的最佳化，如探索結合硬體指令（如SIMD）或異質運算（如GPU）來做更深層的優化。

4.2 傳輸最佳化

線上預估服務整體上是雙層架構，特徵抽取層負責模型路由和特徵計算，模型計算層負責模型計算。原有的系統流程是將特徵計算後的結果拼接成M（預測的Batch Size） × N（樣本寬度）的矩陣，再經過序列化傳送到計算層。之所以這麼做，一方面出於歷史原因，早期很多非DNN的簡單模型的輸入格式是個矩陣，經過路由層拼接後，計算層可以直接使用，無需轉換；另一方面，數組格式比較緊湊，可以節省網路傳輸耗時。 然而隨著模型迭代發展，DNN模型逐漸成為主流，基於矩陣傳輸的缺點也非常明顯：

1. 擴展性差：資料格式統一，不相容非數值類型的特徵值。
2. 傳輸效能損耗：基於矩陣格式，需要對特徵做對齊，例如Query/User維度需要被拷貝對齊到每個Item上，增大了請求計算層的網路傳輸資料量。

為了解決以上問題，優化後的流程在傳輸層之上加入一層轉換層，用來根據MDFL的配置將計算的模型特徵轉換成所需的格式，如Tensor、矩陣或離線所使用的CSV格式等。 實際線上大多數模型都是TF模型，為了進一步節省傳輸消耗，平台設計了Tensor Sequence格式來儲存每個Tensor矩陣：其中，r_flag用來標記是否是item類別特徵，length表示item特徵的長度，值為M（Item個數）×NF（特徵長度），data用來儲存實際的特徵值，對於Item特徵將M個特徵值扁平化存儲，對於請求類別特徵則直接填充。基於緊湊型Tensor Sequence格式使資料結構更加緊湊，減少網路傳輸資料量。優化後的傳輸格式在線上也取得不錯的效果，路由層呼叫計算層的請求大小下降了50% ，網路傳輸耗時明顯下降。

4.3 高維ID特徵編碼

離散特徵和序列特徵可以統一為Sparse特徵，特徵處理階段會把原始特徵經過Hash處理，變成ID類特徵。在面對千億等級維度的特徵，基於字串拼接再Hash的過程，在表達空間和性能上，都無法滿足要求。基於對業界的調查，我們設計並應用了基於Slot編碼的方式特徵編碼格式：

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

5 樣本建構

5.1 串流樣本

業界為了解決線上線下一致性的問題，一般都會線上dump即時評分所使用的特徵數據，稱為特徵快照；而不是透過簡單離線Label拼接，特徵回填的方式來建立樣本，因為這種方式會帶來較大的數據不一致。架構原始的方式如下圖所示：

這種方案隨著特徵規模越來越大、迭代場景越來越複雜，突出的問題就是線上特徵抽取服務壓力大，其次是整個資料流收集成本太高。此樣本收集方案有以下問題：

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

5.1.1 常見的方案

為了解決上面的問題，業界常見有兩個方案：①Flink即時串流處理；②KV快取二次處理。具體流程如下圖所示：

#

1. 串流拼接方案：借助串流處理框架（Flink、Storm等）低延遲的串流處理能力，直接讀取曝光/點擊即時流，與特徵快照流資料在記憶體中進行關聯（Join）處理；先生成流式訓練樣本，再轉存為模型離線訓練樣本。其中流式樣本和離線樣本分別儲存在不同的儲存引擎中，支援不同類型的模型訓練方式。此方案的問題：在資料流動環節的資料量依然很大，佔用較多的消息流資源（例如Kafka）；Flink資源消耗過大，如果每秒百G的資料量，做視窗Join則需要30分鐘×60×100G的記憶體資源。
2. KV快取方案：所有特徵抽取的特徵快照寫入KV儲存（如Redis）快取N分鐘，業務系統通過訊息機制，把候選佇列中的Item傳入到即時計算系統（Flink或消費應用），此時的Item的量會比之前請求的Item量少很多，這樣再將這些Item特徵從特徵快照快取中取出，資料透過訊息流輸出，支援串流訓練。這種方法藉助了外存，不管隨著特徵還是流量增加，Flink資源可控，而且運作更加穩定。但突出的問題還是需要較大的記憶體來快取大批量資料。

5.1.2 改進最佳化

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

1. 資料拆分：解決資料傳輸量大問題（特徵快照流大問題），預測的Label與即時資料一一Match，離線資料可以透過回流的時候二次訪問，這樣可以大幅降低鏈路資料流的大小。

• 樣本流中只有上下文 即時特徵，增加讀取資料流穩定性，同時由於只需要儲存即時特徵，Kafka硬碟儲存下降10 倍。

2. 延時消費Join方式：解決佔用記憶體大問題。

• 曝光流作為主流，寫入到HBase中，同時為了後續能讓其他流在HBase中Join上曝光，將RowKey寫入Redis；後續流通過RowKey寫入HBase，曝光與點擊、特徵的拼接借助外存完成，確保資料量增加後系統能穩定運作。
• 樣本流延時消費，後台服務的樣本流往往會比曝光流先到，為了能Join上99% 的曝光數據，樣本流等待視窗統計至少要N分鐘以上；實作方式是將視窗期的資料全部壓在Kafka的磁碟上，利用磁碟的順序讀取效能，省略掉了視窗期內需要快取資料量的大量記憶體。

3. 特徵補錄拼樣本：透過Label的Join，此處補錄的特徵請求量不到線上的20%；樣本延遲讀取，與曝光做拼接後過濾出有曝光模型服務請求（Context 即時特徵），再補錄全部離線特徵，拼成完整樣本數據，寫入HBase。

5.2 結構化儲存

隨著業務迭代，特徵快照中的特徵數量越來越大，使得整體特徵快照在單一業務場景下達到幾十TB級別/天；從儲存上看，多天單業務的特徵快照就已經PB級別，快到達廣告演算法存儲閾值，存儲壓力大；從計算角度上看，使用原有的計算流程，由於計算引擎（Spark）的資源限制（使用到了shuffle，shuffle write階段資料會落盤，如果分配記憶體不足，會出現多次落盤和外排序# ），需要與自身資料等大小的記憶體和較多的計算CU才能有效的完成計算，佔用記憶體高。樣本建立流程核心流程如下圖所示：

#

在補錄特徵時，有下列問題：

1. 資料冗餘：補錄特徵的離線表一般為全量數據，條數在億級別，樣本構建用到的條數約為當日DAU的數量即千萬級別，因此補錄的特徵表數據在參與計算時存在冗餘資料。
2. Join順序：補錄特徵的計算過程即維度特徵補全，存在多次Join計算，因此Join計算的性能和Join的表的順序有很大關係，如上圖所示，如果左表為幾十TB級別的大表，那麼之後的shuffle計算過程都會產生大量的網路IO、磁碟IO。

為了解決樣本建構效率慢的問題，短期先從資料結構化治理，詳細流程如下圖：

1. 結構化分割。 資料拆分成Context資料和結構化儲存的維度資料取代混合儲存。解決Label樣本拼接新特徵過程中攜帶大量冗餘資料問題；並且做結構化儲存後，針對離線特徵，得到了很大的儲存壓縮。
2. 有效率地過濾前置。資料過濾提前到Join前，減少參與特徵計算的資料量，可以有效降低網路IO。在拼接過程中，補錄特徵的Hive表一般來說是全量表，資料條數一般為月活量，而實際拼接過程中使用的資料條數約為日活量，因此有較大的資料冗餘，無效的資料會帶來額外的IO和計算。最佳化方式為預先計算使用的維度Key，並產生對應的布隆過濾器，在資料讀取的時候使用布隆過濾器進行過濾，可大幅降低補錄過程中冗餘資料傳輸和冗餘計算。
3. 高效能Join。使用高效率的策略去編排Join順序，提升特徵補錄環節的效率和資源佔用。在特徵拼接過程中，會存在多張表的Join操作，Join的先後順序也會大大影響拼接效能。如上圖所示，如果拼接的左表資料量較大時，那麼整體效能就會差。可以使用哈夫曼演算法的思想，把每個表看成一個節點，對應的資料量看成是他的權重，表之間的Join計算量可以簡單類比兩個節點的權重相加。因此，此問題可以抽象化成構造哈夫曼樹，哈夫曼樹的構造過程即為最優的Join順序。

資料離線儲存資源節省達80% ，樣本建置效率提升200% ，目前整個樣本資料也正在進行基於資料湖的實踐，進一步提升資料效率。

6 資料準備

平台累積了大量的特徵、樣本和模型等有價值的內容，希望透過對這些資料資產進行複用，幫助策略人員更好的進行業務迭代，取得更好的業務效益。特徵最佳化佔了演算法人員提升模型效果的所有方法中40%的時間，但傳統的特徵挖掘的工作方式存在著花費時間長、挖掘效率低、特徵重複挖掘等問題，所以平台希望在特徵維度賦能業務。如果有自動化的實驗流程去驗證任意特徵的效果，並將最終效果指標推薦給用戶，無疑會幫助策略同學節省大量的時間。當整個連結建設完成，後續只需要輸入不同的特徵候選集，即可輸出對應效果指標。為此平台建構了特徵、樣本的「加」、「減」、「乘」、「除」智慧機制。

6.1 做「加法」

特徵推薦基於模型測試的方法，將特徵重複使用到其他業務線現有模型，建構出新的樣本和模型；比較新模型和Base模型的離線效果，取得新功能的效益，自動推送給相關的業務負責人。具體特徵推薦流程如下圖所示：

#

1. 特徵感知：透過上線牆或業務間存量方式觸發特徵推薦，這些特徵已經過一定驗證，可以保證特徵推薦的成功率。
2. 樣本生產：樣本生產時透過設定檔抽取特徵，流程會自動將新增特徵加到設定檔中，然後進行新樣本資料的生產。取得到新特徵後，解析這些特徵依賴的原始特徵、維度、和UDF算子等，將新特徵配置和依賴的原始資料融合到基線模型的原有配置中，建構出新的特徵配置。自動進行新樣本構建，樣本構建時透過特徵名稱在特徵倉庫中抽取相關特徵，並調用配置好的UDF進行特徵計算，樣本構建的時間段可配置。
3. 模型訓練：自動對模型結構和樣本格式配置進行改造，然後進行模型訓練，使用TensorFlow作為模型訓練框架，使用tfrecord格式作為樣本輸入，將新特徵依照數值類別和ID類別分別放到A和B兩組中，ID類特徵進行查表操作，然後統一追加到現有特徵後面，不需要修改模型結構便可接收新的樣本進行模型訓練。
4. 會自動配置新模型訓練參數：包含訓練日期、樣本路徑、模型超參等，分割出訓練集和測試集，自動進行新模型的訓練。
5. 模型評測：呼叫評估介面得到離線指標，比較新舊模型評測結果，並預留單特徵評估結果，打散某些特徵後，給出單特徵貢獻度。將評估結果統一傳送給使用者。

6.2 做「減法」

特徵推薦在廣告內部落地並取得了一定收益後，我們在特徵賦能層面做一些新的探索。隨著模型的不斷優化，特徵膨脹的速度非常快，模型服務消耗資源急劇上升，剔除冗餘特徵，為模型「瘦身」勢在必行。因此，平台建置了一套端到端的特徵篩選工具。

1. 特徵評分：透過WOE（Weight Of Evidence, 證據權重）等多種評估演算法給出模型的所有特徵評分，評分較高特徵的品質較高，評估準確率高。
2. 效果驗證：訓練模型後，依評分排序，分批將特徵剔除。具體地透過採用特徵打散的方法，比較原模型和打散後模型評估結果，相差較大低於閾值後結束評估， 給出可以剔除的特徵。
3. 端對端方案：使用者配置好實驗參數和指標閾值後，無需人為干涉，即可給出可刪除的特徵以及刪除特徵後模型的離線評估結果。

最終，在內部模型下線40%的特徵後，業務指標下降仍然控制在合理的閾值內。

6.3 做「乘法」

為了得到更好的模型效果，廣告內部已經開始做一些新的探索，包括大模型、即時化、特徵庫等。這些探索背後都有一個關鍵目標：需要更多、更好的數據讓模型更聰明、更有效率。從廣告現況出發，提出樣本庫（Data Bank）建設，實現把外部更多種類、更大規模的資料拿進來，應用於現有業務。具體如下圖所示：

我們建立了一套通用的樣本共享平台，在這個平台上，可以藉用其他業務線來產生增量樣本。並且也建構通用的Embedding共享架構，實現業務的以大帶小。以下以廣告業務線複用非廣告樣本為例，具體做法如下：

#

1. 擴充樣本：基於Flink串流處理框架，建置了高擴充樣本庫DataBank，業務A很方便重複使用業務B、業務C的曝光、點擊等Label數據去做實驗。尤其是為小業務線，擴充了大量的價值數據，這種做法相比離線補錄Join，一致性會更強，特徵平台提供了線上、離線一致性保障。
2. 做共享：在樣本就緒後，一個很典型的應用程式場景就是遷移學習。另外，也建構Embedding共享的資料通路（不強依賴「擴樣本」流程），所有業務線可以基於大的Embedding訓練，每個業務方也可以update這個Embedding，線上透過建立Embedding版本機制，供多個業務線使用。

舉例來說，透過將非廣告樣本複用到廣告內一個業務，使樣本數增加了幾倍，結合遷移學習演算法，離線AUC提升千分之四，上線後CPM提升百分之一。此外，我們也在建立廣告樣本主題庫，將各業務產生的樣本資料進行統一管理（統一元資料），面向使用者透出統一樣本主題分類，快速註冊、尋找、重複使用，面向底層統一存儲，節省儲存、運算資源，減少資料Join，提高時效性。

6.4 做「除法」

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

在離線維度，我們建立了一套特徵價值評估系統，給出特徵的成本和價值，在線推理時可以透過特徵價值資訊進行流量降級、特徵彈性運算等操作，做「除法」關鍵步驟如下：

1. 問題抽象：如果我們能得到每個特徵的價值得分，又可以拿到特徵的成本（#儲存、通訊、計算加工），那麼問題就轉換成了在已知模型結構、固定資源成本下，如何讓特徵的價值最大化。
2. 成本限制下的價值評估：基於模型的特徵集，平台首先進行成本和價值的統計總和；成本包括了離線成本和線上成本，基於訓練好的評判模型，得出特徵的綜合排序。
3. 分割場景建模：可以依照不同的資源情況，選擇不同的特徵集，進行建模。在有限的資源下，選擇價值最大的模型在線Work。另外，可以針對比較大的特徵集建模，在流量低峰值啟用，提升資源利用率的同時為業務帶來更大收益。還有一種應用場景是流量降級，推理服務監控線上資源的消耗，一旦資源運算達到瓶頸，切換到降級模型。

7 總結與展望

#以上是我們在大規模深度學習工程上的反「增」實踐，去助力業務降本提效。未來我們也會持續在以下方面進行探索、實踐：

1. 全鏈路GPU化：在推理層面，透過GPU的切換，支撐更複雜業務迭代的同時，整體成本也極大的降低，後面會在樣本建構、特徵服務上進行GPU化改造，並協同推進離線訓練層面的升級。
2. 樣本資料湖：透過資料湖的Schema Evolution、Patch Update等特性建構更大規模的樣本倉庫，對業務方進行低成本、高價值的數據透出。
3. Pipeline：演算法全生命週期迭代過程中，很多環節的調試，鏈路資訊都不夠“串聯”，以及離線、在線、效果指標的觀點都比較割裂，基於全鏈路的標準化、可觀測大勢所趨，並且這是後續鏈路智能化彈性調配的基礎。現在業界比較火的MLOps、雲端原生都有較多的借鏡思路。
4. 資料、模型智能匹配：上文提到在模型結構固定前提下，自動為模型加、減特徵，同理在模型層面，固定在一定特徵輸入前提下，去自動嵌入一些新的模型結構。以及在未來，我們也將基於業務領域，透過平台的特徵、模型體系，自動化地完成資料、模型的匹配。

8 本文作者

亞劼、英亮、陳龍、成傑、登峰、東奎、仝曄、思敏、樂彬等，皆來自美團外送技術團隊。

以上是外送廣告大規模深度學習模型工程實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！