- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2022-07-08來源:最后的問候瀏覽數:285次
從內容理解的應用場景來看,主要通過深度學習框架進行模型訓練,然后完成模型上線得到內容的向量表示。在內容理解的大部分場景的最終產出主要是內容的特征和特征的embedding表示。
導讀:隨著推薦技術的不斷發展,推薦系統的應用變得更加廣泛。相比CV/NLP場景,推薦場景的模型訓練和線上預測需要更強的實時性。因為場景的多樣性,推薦系統的優化目標也更為復雜多變。推薦業務用戶量大、實時服務吞吐量高、優化目標多變等特點使得常用的高維模型的訓練和預測存在許多挑戰。本次分享主要針對騰訊無量深度學習系統在推薦類業務中的應用。
全文將圍繞以下三個部分展開:
無量的背景和面對的問題
無量的解決方案
無量系統的演進
01無量的背景和面對的問題
在介紹無量系統前,首先來看一下AI計算框架的全流程和無量的關系,以及無量系統在實際應用當中需要解決的問題。
1. AI 全流程和無量的關系

如上圖所示我們可以將深度學習框架大致分為兩種類型:一種是內容理解的應用場景,另外一種是推薦的應用場景。
推薦領域和傳統內容理解面對的問題差異的如下:
數據的實時性
從內容理解的應用場景來看,主要通過深度學習框架進行模型訓練,然后完成模型上線得到內容的向量表示。在內容理解的大部分場景的最終產出主要是內容的特征和特征的embedding表示。
推薦的業務場景和內容理解的區別在于有用戶的介入。在推薦場景中,用戶作為系統的起點產生了實時的用戶行為,經過數據上報、樣本生成、訓練建模、線上serving等過程,最終完成推薦結果的展示。整個數據閉環中因為用戶實時行為的參與需要推薦系統具備更高的數據時效性。
建模目標的多變
由于用戶的介入導致模型訓練的學習目標是變化的。當用戶使用場景和推薦上下文發生變化之后,推薦系統建模需要能夠捕獲到用戶興趣的變化。這是和傳統內容理解場景下的深度學習框架比較大的區別。
2. 推薦業務的技術瓶頸

推薦系統的深度學習框架主要需要面臨的技術瓶頸如下:
數據量大。推薦系統的用戶量和物品量級都非常大,具備百億級別的曝光,十億級別的點擊和億級別的DAU。
具備很強的用戶交互關系,整個系統的時效性要求更高。
需要完成千億級別的模型在線訓練和TB級別的模型上線。
需要完成高吞吐、低時延的在線服務。
02無量的解決方案
1. 計算框架

在介紹無量的整體計算框架之前,我們先了解一下推薦模型具備的特點。
推薦模型的特點
推薦場景下大型的TB級的模型的參數量主要取決于深度模型中的稀疏層。在模型訓練和線上推理的過程中,稀疏層的特點是每次能夠命中到的key并且激活的參數都是有限的。
我們以id類型的稀疏特征為例, ?當batch大小為1024的時候,訓練過程中每個batch所能命中的key最多為1024個。模型稀疏層實際大小可能有千億級別的參數,和訓練過程中真實使用的情況存在巨大的差異。系統在訓練過程中使用key的時候可以按需獲取,從而提高深度學習系統的性能。
參數服務器架構
基于推薦系統的模型特性,大部分推薦類型的深度學習框架都采用了參數服務器的架構。基于參數服務器架構的推薦框架能夠比較方便地完成按需的參數獲取和參數激活。
在模型訓練過程中,可以只獲取當前使用的參數計算梯度并推送回參數服務器做梯度更新,在參數服務器架構的基礎上進行算子融合、并行訓練。
在參數服務器架構中,由于參數服務器和訓練worker的分離,使得深度學習系統可能存在通訊上的性能瓶頸。無量主要采用參數壓縮、零拷貝通訊來減少通訊過程中的數據量。在server端, 無量主要做了一些無鎖化和并行更新的優化。
無量系統的模型計算
在面對算法人員提供模型訓練和建模能力時,無量系統主要是將參數服務器和TensorFlow的能力進行了融合。在server端對參數服務器參數獲取和TensorFlow模型計算的能力進行橋接。在無量系統中比較完整地復用了TensorFlow的圖構建以及自動求導能力,使得TensorFlow用戶能夠花費極小的學習成本掌握無量系統的使用。無量通過這種橋接方式能夠完成高性能分布式模型訓練和GPU部署能力的支持。
2. 推理服務

推理面臨的問題
在推薦業務中訓練得到的模型往往是TB級別的。在模型排序階段,假設用戶的單個請求item為300個。每個item特征需要的key為500個,那么對于線上推理而言,每次請求激活的key為15W個。在資訊類業務中線上1WQPS請求的情況下需要存儲的key為15億。同時推理服務還需要滿足線上服務的實時響應(10ms以內的耗時)和模型的版本控制。
在推薦系統模型訓練的參數訪問中主要是key-value的模式。采用傳統的分布式存儲系統存在主備一致性問題,數據讀寫需要加鎖,從而使得推理服務轉化成CPU型的服務。對1WQPS的模型上線所需要的機器數量龐大,大概需要上千臺機器,對業務方而言成本太高。
分布式serving服務
在模型訓練過程中,主要的性能瓶頸在機器內存上,采用分布式訓練主要是為了解決模型過大的問題。在推理服務階段為了不增加CPU的占用,無量將性能的瓶頸控制在內存上,設計了一個分布式serving的服務采用多機多副本的并行讀取來實現并發讀取,通過多線程的無鎖機制實現了模型版本的讀寫分離,通過L1緩存的查詢優化來實現單機處理能力的提升。在提升單機處理能力的基礎上,對高頻熱key進行緩存優化,將整個模型的推理服務改造成基于內存型服務。
3. 持續上線邏

在無量的深度學習框架中需要考慮從訓練端到上線端完成實時的整體閉環。主要考慮如何進行TB級別的模型實時上線,減少TB級模型的存儲量并降低高并發的分布存儲請求量。
無量在模型訓練和上線過程中對模型進行切片,將DNN部分和Sparse Embedding部分分別上線到不同的節點上。在模型上線過程中,將DNN和特征里面的熱key推送到推理節點上線,另外將模型整體的embedding推送到分布式Serving集群節點上。
在Serving集群節點embedding的更新主要采用三級的更新方式:
全量模型,TB級別的更新,用戶根據業務情況設定在低峰值或者24小時更新。
增量模型,GB級別的更新,設置1小時或者是10分鐘級別的更新。
實時模型,KB級別的更新,采用消息中間件實現毫秒級更新。
4. 模型壓縮

在深度學習的訓練過程中得到了TB級模型,但是在線上推理過程中不一定需要上線TB級別的模型。在傳統CV、NLP領域里面常用的模型壓縮方法包括:蒸餾、量化等。
傳統的CV、NLP場景在模型訓練后通常有重訓和效果調試的過程。在推薦場景下由于推薦全鏈路的實時性要求,使得CV、NLP中的模型壓縮方法無法在推薦中使用。
在推薦業務中模型的大小主要取決于稀疏層key-value的大小。在推薦系統的深度學習框架中主要采用的優化方式有兩種:
① 使用更少的values
通過采用變長的embedding方式,對低頻特征使用較少的value去表征,并且結合優化目標去控制value的長度,主要適用于有大量稀疏特征的情況下。
優點: 主要是與優化器無關
缺點:使用變長編碼,影響推理端的性能優化。
② 使用更少的key
阿里的group lasso通過加入L21的正則項去除稀疏key減少數據量的存儲。
優點: L1正則強度可控,在效果不影響的情況下可以將稀疏度控制到64%~94%;實現簡單,只修改訓練優化器。
缺點: 在FTRL才有稀疏效果,與原生Adam有AUC差距。
③ 使用更短的values
混合精度
采用float16、int8、int4的壓縮。
量化壓縮
采用1bit或者2bit的壓縮。
優點:?與優化器無關;可以與矩陣計算庫適配加速。
缺點:二值/三值量化壓縮需要量化訓練,有效果驗證成本。
03無量的演進

二值/三值量化壓縮
在分布式訓練的角度上講對系統訓練的加速主要分為兩個方向:
Scale Out:使用更多的節點來加快訓練速度。
Scale Up:使得單機的訓練速度更快來加快訓練速度。
在使用GPU單機8卡機型的情況下,可以使用更少的節點。在分布式的深度學習系統中節點減少之后跨機的通訊會更少,同時減少了節點的異構問題,并且具備更高的性價比。在使用GPU的時候主要面對的問題在于顯存內無法存放TB級別的模型,GPU的多線程并行能力對稀疏數據不夠友好。

為了解決上面的問題,在支持GPU的情況下采用多級緩存的方案。在推薦當中使用到的數據具有很強的局部性。從訓練的角度來講,系統需要更高的訓練樣本吞吐能力。在推理階段除了吞吐能力之外還需要滿足系統的響應速度。
在訓練過程中存儲了全部的參數,在內存中存儲了稍后需要使用的參數,在顯存中存儲了立刻需要使用的參數。在推理階段在分布式Serving集群中存儲低頻的參數,在內存中存儲中頻的參數,在顯存中使用高頻的參數。在推理端位了減少參數頻率統計帶來的開銷,基于數據同分布的假設統計訓練端參數的頻率來進行Serving端的三級緩存。
04Q&A
Q1:無量推理端serving模型參數分布式和多副本是內存中存儲嗎?是通過serving來維護一致性嗎?
A1:推理端多副本是存儲在內存當中進行存儲的,這些副本之間可以進行強同步但是目前條件是放開的,在持續上線迭代的過程中對于推薦類模型的一致性要求相對來說不高。系統可以進行強一致,比如使用帶版本號的訪問,這個功能是否開啟由使用方來決定。
Q2:三值量化能詳細講一講嗎?
A2:在訓練過程中模型是全精度保存的,但是在進入訓練到應用的過程中會對模型進行量化。在量化完之后基于量化的結果訓練出一個梯度,并且將梯度更新到全精度的模型上去。如果在推理過程中只是導出量化結果,然后在推理過程中進行反量化,從而保證推理結果的一致性。
Q3:GPU多級緩存實際參數放到SSD對于推薦這些悉數參數多的場景訓練速度能跟上嗎?
A3:訓練速度能不能跟上關鍵的地方在于SSD處理和訓練相關的參數的速度,只要在訓練的時候提前拿到下一個訓練批次需要使用的參數就可以了。對于目前SSD的性能來說是可以滿足的。
Q4:零拷貝通訊是怎么實現的?
A4:零拷貝通訊是指計算完了假設有三個key,分別為key1、key2和key3。假設key1和key3在server1,key2在server2上。在通訊之前需要將key1和key3重新排布,這種情況下必然有一次拷貝過程。需要做零拷貝的話,只要預先知道key1和key3在server1上,key2在server2上。在發送的時候預先排布好key的順序,將數據發給下一層就沒有任何的拷貝操作。
Q5:如果訓練樣本都被污染了,導致線上模型都有問題如何保證線上模型預測的準確性?
A5: 只能將模型回滾到污染點之前的模型上。
Q6:特征提取和處理是在推理服務上嗎?
A6:兩種方案:業務可以在前端做好特征工程的工作,將數據處理放在業務方自己完成。無量的推理服務提供了一個特征工程的插件使得特征轉化的工作可以在推理階段完成。