作者：

vivo - 人工智能推薦團隊：何鑫、李恒、周健、黃金寶

背景

vivo 人工智能推薦算法團隊在深耕業務同時，也在積極探索適用于搜索/廣告/推薦大規模性稀疏性算法訓練框架。分別探索了 tensornet/XDL/tfra 等框架及組件，這些框架組件在分布式、稀疏性功能上做了擴展，能夠彌補 tensorflow 在搜索/廣告/推薦大規模性稀疏性場景不足，但是在通用性、易用性以及功能特點上，這些框架存在各種不足。

(資料圖片)

DeepRec 是阿里巴巴集團提供的針對搜索、推薦、廣告場景模型的訓練/預測引擎，在分布式、圖優化、算子、Runtime 等方面對稀疏模型進行了深度性能優化，提供了豐富的高維稀疏特征功能的支持。基于 DeepRec 進行模型迭代不僅能帶來更好的業務效果，同時在 Training/Inference 性能有明顯的性能提升。

作為 DeepRec 最早的一批社區用戶，vivo 在 DeepRec 還是內部項目時，就與 DeepRec 開發者保持密切的合作。經過一年積累與打磨，DeepRec 賦能 vivo 各個業務增長，vivo 也作為 DeepRec 深度用戶，將業務中的需求以及使用中的問題積極回饋到 DeepRec 開源社區。

業務介紹

vivo 人工智能推薦算法組的業務包含了信息流、視頻、音樂、廣告等搜索/廣告/推薦各類業務，基本涵蓋了搜廣推各類型的業務。

為了支撐上述場景的算法開發上線，vivo 自研了集特征數據、模型開發、模型推理等流程于一體的推薦服務平臺。通過成熟、規范的推薦組件及服務，該平臺為 vivo 內各推薦業務（廣告、信息流等）提供一站式的推薦解決方案，便于業務快速構建推薦服務及算法策略高效迭代。

稀疏模型訓練

3.1 稀疏功能

3.1.1 痛點

在實際業務實踐發現，TensorFlow 原生 Embedding Layer 存在以下問題：

1.靜態 Embedding OOV 問題

在構建 Embedding Layer 的時候，TensorFlow 需要首先構建一個靜態 shape[Vocab_size, Embedding size ] 的 Variable，然后利用 Lookup 的算子將特征值的 Embedding 向量查詢出。在增量或者流式訓練中，會出現 OOV 的問題。

2. 靜態 Embedding hash 特征沖突

為了規避上述的 OOV 問題，通常做法是將特征值 hash 到一定的范圍，但是又會引入 hash 沖突的問題，導致不同的特征值共用同一個 Embedding，會造成信息丟失，對模型訓練是有損的。

3. 靜態 Embedding 內存浪費

為了緩解 hash 沖突，通常會設置比真實的特征值個數 N 大一到兩倍的 hash 范圍，而這又會強行地增加模型的體積。

4. 低頻特征冗余

在引入稀疏特征時，出現頻次較低以及許久未出現的特征 ID 對于模型而言是冗余的。此外，交叉特征占據了大量的存儲，可以在不影響訓練效果的前提下過濾掉這些特征 ID。因此，迫切需求特征淘汰以及準入機制。

總的來講，TensorFlow 的 Embedding Layer 對真實的業務場景有幾個不太友好的點，第一是可拓展性差，第二是 hash 沖突導致模型訓練有損，第三是無法處理冗余的稀疏特征。而 DeepRec 巧妙地解決了上述問題，主要提供了基于 Embedding Variable 的動態 Embeeding 功能和特征準入/淘汰功能。

3.1.2 Embedding Variable

DeepRec 中的 EmbeddingVariable 以 HashTable 作為內部存儲的基本結構，動態的創建/釋放 Embedding 向量，適配了 Embedding 前向查詢，反向更新等 OP，從而解決了用戶的痛點。

在構建 Embedding Layer 時使用 DeepRec的Embedding Variable。利用 Embedding Variable 具有動態維度的特性，模型訓練對新增的特征值無感知。此外，由于摒棄了 hash 的操作，訓練的模型也是無損的，同時模型的體積也會縮小。

3.1.3 特征準入/淘汰

1. 特征準入：

DeepRec 提供了基于 BloomFilter 和 Counter 兩種策略的準入機制。特征準入可以避免模型稀疏特征的快速增長，拒絕低頻特征進入模型，影響模型收斂效果。

2. 特征淘汰：

DeepRec 支持兩種淘汰策略，一種是按照 global step 進行淘汰，一種是按照 L2 weight 進行淘汰，它們將不符合規則的特征從模型參數中剔除，保證特征的有效性。

3.1.4 收益

1. 靜態 Embedding 升級到動態 Embedding

使用 DeepRec 的動態 Eembedding 替換 TensorFlow 的靜態 Embedding 后，保證所有特征 Embedding 無沖突，離線auc提升 0.5%，線上點擊率提升 1.2%，同時模型體積縮小 20%。

2. ID 特征的利用

在使用 TensorFlow 時，vivo 嘗試過對 ID 特征進行 hash 處理輸入模型，實驗表明這種操作對比基線具有負收益。這是由于 ID 特征過于稀疏，同時 ID 具有唯一指示性，hash 處理會帶來大量的 Embedding 沖突。基于動態 Embedding，使用 ID 特征離線 auc 提升 0.4%，線上點擊率提升 1%；同時配合 global step 特征淘汰，離線 auc 提升 0.2%，線上點擊率提升 0.5%。

3.2 IO優化

3.2.1 痛點

目前 vivo 內部使用的是 TFRecord 數據格式存儲訓練數據，這種存儲格式存在以下缺陷：

1. 占用存儲空間大

由于 TFRecord 采用 protocol buffer 結構化數據存儲，存儲不夠緊湊，占用空間比較大，在訓練時 I/O 開銷也非常大。vivo 嘗試過利用 prebatch 的方式存儲 TFRecord 以節省存儲空間，但是此方案解析相對復雜，I/O 開銷進一步加劇。

2. 非明文存儲

由于 TFRecord 以二進制格式存儲，無法直接查看數據內容，存在解析困難、不便進行數據分析的問題。

3.2.2 Parquet Dataset

Parquet 是一種列式存儲的數據格式，能夠節省存儲資源，加快數據讀取速度。DeepRec 的 Parquet Dataset 支持讀取 Parquet 文件，開箱即用，無需額外安裝第三庫，使用簡單方便。同時，Parquet Dataset 能夠加快數據讀取速度，提高模型訓練的 I/O 性能。

3.2.3 收益

vivo 內部嘗試使用 Parquet Dataset 來替換現有 TFRecord，提高訓練速度 30%，減少樣本存儲成本 38%，降低帶寬成本。同時，vivo 內部支持 hive 查詢 Parquet 文件，算法工程師能夠高效快捷地分析樣本數據。

高性能推理框架

在業務逐漸發展過程中，廣告召回量增長 3.5 倍，同時目標預估數增加兩倍，推理計算復雜度增加，超時率超過 5%，嚴重影響線上服務可用性以及業務指標。因此，vivo 嘗試探索升級改造現有推理服務，保證業務可持續發展。vivo 借助 DeepRec 開源的諸多推理優化功能，在 CPU 推理改造以及 GPU 推理升級方面進行探索，并取得一定收益。

4.1 CPU 推理優化

vivo 直接使用 TensorFlow 提供的 C++ 接口調用 Session::Run，無法實現多 Session 并發處理 Request，導致單 Session 無法實現 CPU 的有效利用。如果通過多 Instance 方式（多進程），無法共享底層的 Variable，導致大量使用內存，并且每個 Instance 各自加載一遍模型，嚴重影響資源的使用率和模型加載效率。為了提高 CPU 使用率，也嘗試多組 Session Intra/Inter，均會導致 latency升高，服務可用性降低。

基于 ShareNothing 架構的 SessionGroup

DeepRec 提供的 SessionGroup 能夠有效地解決上述問題，其基本架構如下圖所示：

SessionGroup 可配置一組 Session，并且通過 Round Robin (支持用戶自定義策略)方式將用戶請求分發到某一個 Session。SessionGroup 對不同 Session 之間的資源進行隔離，每個 Session 擁有私有的線程池，并且支持每個線程池綁定底層的 CPU Core(numa-aware)，可以最大程度地避免共享資源導致的鎖沖突開銷。SessionGroup 中唯一共享的資源是 Variable，所有 Session 共享底層的 Variable，并且模型加載只需要加載一次。

在使用 SessionGroup 功能后，CPU 使用率低的問題明顯得到緩解，在保證 latency 的前提下極大提高 QPS，單機 QPS 提升高達 80%，單機 CPU 利用率提升 75%。

4.2 GPU 推理優化

經過 SessionGroup 的優化，雖然 CPU 推理性能得到改善，但是超時率依舊無法得到緩解。由于以下幾點原因，vivo 嘗試探索 GPU 推理來優化線上性能。

1. 多目標模型目標塔數較多

2. 模型中使用 Attention、LayerNorm、GateNet 等復雜結構

3. 特征多，存在大量稀疏特征

4.2.1 Device Placement Optimization

通常，對于稀疏特征的處理一般是將其 Embedding 化，由于模型中存在大量的稀疏特征，因此 vivo 的廣告模型使用大量的 Embedding 算子。從推理的 timeline 可以看出，Embedding 算子分散在 timeline 的各個階段，導致大量的 GPU kernel launch 以及數據拷貝，因此圖計算非常耗時。

Device Placement Optimization 完全將 Embedding Layer placed 到 CPU 上，解決Embedding layer 內部存在的 CPU 和 GPU 之間大量數據拷貝問題。

Device Placement Optimization 性能優化明顯，CPU 算子（主要是 Embedding Layer）的計算集中在 timeline 的最開端，之后 GPU 主要負責網絡層的計算。相較于 CPU 推理，Device Placement Optimization P99 降低 35%。

4.2.2 CUDA Multi-Stream 功能

在推理過程中，vivo 發現 GPU 利用率低，GPU 算力浪費。DeepRec 支持用戶使用 multi-stream 功能，多 stream 并發計算，提升 GPU 利用率。多線程并發 launch kernel 時，存在較大的鎖開銷，極大影響了 kernel launch 的效率，這里的鎖與 CUDA Driver 中 Context 相關。因此可以通過使用 MPS/Multi-context 來避免 launch 過程中鎖開銷，從而進一步提升 GPU 有效利用率。

此外，模型中存在大量的 H2D 以及 D2H 的數據拷貝，在原生代碼中，計算 stream 和拷貝 stream 是獨立的，這會導致 stream 之間存在大量同步開銷，同時對于在 Recv 算子之后的計算算子，必須等到 MemCopy 完成之后才能被 launch 執行，MemCopy 和 launch 難以 overlap 執行。基于以上問題，NV 專家計算團隊的同學在 multi-stream 功能基礎上進一步優化，開發了 MergeStream 功能，允許 MemCopy 和計算使用相同的 stream，從而減少上述的同步開銷以及允許 Recv 之后計算算子 launch 開銷被 overlap。

vivo 在線上推理服務中使用了 multi-stream 功能，P99 降低 18%。更進一步地，在使用 merge stream 功能后，P99 降低 11%。

4.2.3 編譯優化-BladeDISC

BladeDISC 是阿里集團自主研發的、原生支持存在動態尺寸模型的深度學習編譯器。DeepRec 中集成了 BladeDISC，通過使用 BladeDISC 內置的 aStitch 大尺度算子融合技術對于存在較多訪存密集型算子的模型有顯著的效果。利用 BladeDISC 對模型進行編譯優化，推理性能得到大幅度提升。

BladeDISC 將大量訪存密集型算子編譯成一個大的融合算子，可以大大減少框架調度和 kernel launch 的開銷。區別于其他深度學習編譯器的是，BladeDISC 還會通過優化 GPU 不同層次存儲（特別是 SharedMemory）的使用來提升了訪存操作和 Op 間數據交換的性能。圖中可以看到，綠色是 Blade DISC 優化合并的算子替代了原圖中大量的算子。

另外，由于線上模型比較復雜，為了進一步減少編譯耗時、提升部署效率，vivo 啟用了 BladeDISC 的編譯緩存功能。開啟此功能時，BladeDISC 僅會在新舊版本模型的 Graph 結構發生改變時觸發編譯，如果新舊模型僅有權重變更則復用之前的編譯結果。經過驗證，編譯緩存在保證正確性的同時，幾乎掩蓋了編譯模型的開銷，模型更新速度與之前幾乎相同。在使用 BladeDISC 功能后，線上服務 P99 降低 21%。

4.2.4 總結

DeepRec 提供大量的解決方案可以幫助用戶快速實施 GPU 推理。經過一系列優化，相較于 CPU 推理，GPU 推理 P99 降低 50%，GPU 利用率平均在 60% 以上。此外，線上一張英偉達 T4 顯卡的推理性能超過兩臺 CPU 機器，節省了大量的機器資源，機器成本降低 60%。

未來規劃

基于 CPU 的分布式異步訓練存在兩個問題：一是異步訓練會損失訓練精度，模型難以收斂到最佳；二是隨著模型結構逐漸復雜，訓練性能會急劇下降。未來，vivo 打算嘗試基于 GPU 的同步訓練來加速復雜模型訓練。DeepRec 支持兩種 GPU 同步框架——SparseOperationKit(SOK)和HybridBackend。后續 vivo 將嘗試這兩種 GPU 同步訓練來加速模型訓練。

DeepRec開源地址：??https://github.com/alibaba/Deep??