作者：亞劼 英亮 陳龍等

導語

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

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優化

特征抽取是模型計算的前置階段，無論是傳統的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 本文作者

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