很多公司都在結合 GPU 的算力發展，探索出適合自己的機器學習問題解決方案。例如，小紅書在 2021 年開始進行推廣搜模型的 GPU 化改造，以提升推理效能和效率。在遷移過程中，我們也面臨一些困難，例如如何平滑地遷移到異質硬件，如何結合小紅書的業務場景和線上架構發展出自己的解決方案等等。在全球降本增效的趨勢下，異構運算成為了一種很有前途的方向，可以透過將不同類型的處理器（如CPU、GPU、FPGA 等）組合在一起來提高運算效能，從而實現更好的效率和更低的成本。
1.背景
小紅書推薦、廣告、搜尋等主要場景的模型服務，統一由中台推理架構承載。隨著小紅書業務的不斷發展， 推廣搜等場景的模型規模也不斷增加。以主推薦場景精排的主模型為例， 從 2020 年初開始，演算法推出了全興趣建模，使用者歷史行為記錄長度均值擴大了約 100 倍。模型結構也從最初的 muti-task 經過多輪迭代，模型結構複雜度也不斷提升 ，這些變化導致模型推理的浮點運算數增加了 30 倍，模型訪存增加了約 5 倍。
圖片
#2.模型服務架構概覽
模型特點：以小紅書2022 年底的推薦主模型為例，該模型具有充分的稀疏性， 部分結構由連續值特徵和矩陣運算構成， 也存在大規模的稀疏參數例如，單一模型的sparse 特徵多達1TB，但透過比較有效的模型結構優化，dense 部分控制在10GB 以內，可放在顯存中。使用者每刷一次小紅書，計算的總 FLOPs 達到了 40B， 超時的控制在 300ms 以內 ( 除去特徵處理，帶 lookup ) 。
推理框架：在2020 年之前，小紅書採用TensorFlow Serving 框架作為線上服務框架，2020 年後，逐漸迭代成基於TensorFlowCore 自研的Lambda Service 服務。 TensorFlow Serving 在進圖之前進行一次記憶體拷貝 TensorProto -> CTensor，以確保模型推理的正確性和可靠性。然而，隨著業務規模的擴大，記憶體拷貝操作會對模型效能產生影響。小紅書自研框架透過優化免去一次不必要的拷貝，同時保留Runtime、圖調度能力、優化能力可插拔的特點，並為後期TRT、BLADE、TVM 等不同優化框架的配合使用奠定了基礎。現在看來，在適當的時候選擇自研是一個明智的選擇， 同時為了最大化減少數據傳輸帶來的成本， 推理框架還承擔了一部分特徵抽取和轉化的實現，這裡小紅書還在預估服務近側部署自研的邊緣存儲， 解決了遠端拉取資料的成本問題。
機型特性：小紅書沒有自建機房， 所有機器採購自雲廠商，因此，選擇不同機型的決策很大程度上取決於能夠採購到什麼型號的機器。而模型推理的計算並不是純粹的 GPU 運算，合理找到硬體配比，除考慮 GPU\CPU 外，還涉及頻寬、記憶體頻寬、跨 numa 通訊延遲等問題。
圖片
GPU 特性
GPU 特性：#在這裡，小紅書和其它公司遇到的問題是一樣的，GPU kernel 的執行可以分為以下幾個階段：資料傳輸、kernel 啟動、kernel 計算和結果傳輸。其中，資料傳輸是將資料從主機記憶體傳輸到GPU記憶體；kernel 啟動是將kernel 程式碼從主機端傳送到GPU 端，並在GPU 上啟動kernel；kernel 計算是實際執行kernel 程式碼計算結果；結果傳輸是將計算結果從GPU 記憶體傳回主機記憶體。如果大量時間都花費在資料傳輸和 kernel 啟動上，而交付給 kernel 計算的活不重，實際計算時間很短，則會導致 GPU 的利用率無法提升，甚至出現空跑的情況。
圖片
預估服務框架
3.GPU最佳化實務
3.1 系統最佳化
#3.1.1 實體機
在實體機最佳化方面，可以採取一些常規的最佳化思路， 主要目的是降低除GPU 以外的其它系統開銷成本， 降低虛擬化的中間商賺差價。一般來說，一套系統優化可以提升 1%-2% 的效能，從我們實務來看，需要結合雲端廠商實際能力來進行最佳化。
● 中斷隔離：將 GPU 的中斷單獨分離出來，避免因為其他裝置的中斷而影響 GPU 的運算效能。
● 核心版本升級：提升系統的穩定性與安全性，提升 GPU 驅動程式的相容性與效能。
● 指令透傳：將 GPU 的指令直接透傳到實體裝置上，加速 GPU 的運算速度。
3.1.2 虛擬化與容器
#在多卡情況下，將單一pod 綁定到特定的NUMA 節點上，從而提高CPU 與GPU 之間的資料傳輸速度。
● CPU NUMA Affinity，親和性是指從 CPU 角度來看，哪些記憶體存取更快，延遲更低。如前所述，與該 CPU 直接相連的本地記憶體是更快的。因此，作業系統可以根據任務所在 CPU 來分配本地內存，以提高存取速度和效能，這就是基於 CPU NUMA Affinity 的考慮，盡量讓任務運行在本地的 NUMA Node 裡。在小紅書場景裡，CPU 上面的訪存開銷並不小。能夠讓 CPU 直連本地記憶體可以節省大量的 CPU 上 kernel 執行的耗時， 從而為 GPU 留出足夠的空間。
● 將 CPU 使用率控制在 70% 下，可以將延遲由 200ms -> 150ms。
3.1.3 鏡像
#編譯最佳化。不同 CPU 對指令級的支援能力是有差異的， 不同雲廠商採買的機種也有所不同。一個比較簡單的思路是在不同的硬體場景下，編譯鏡像時帶上不同的指令集合。在實現算子時，大量的算子本身已經帶有如 AVX512 等指令。以阿里雲的Intel(R) Xeon(R) Platinum 8163 2 A10 的機型為例，我們根據該機型的特點和支持的指令集，編譯優化調整合適的指令集， 整體相比於不進行指令在優化的情況下，在該機型上的CPU 吞吐量提高了10% 。
# Intel(R) Xeon(R) Platinum 8163 for ali intelbuild:intel --copt=-march=skylake-avx512 --copt=-mmmx --copt=-mno-3dnow --copt=-mssebuild:intel --copt=-msse2 --copt=-msse3 --copt=-mssse3 --copt=-mno-sse4a --copt=-mcx16build:intel --copt=-msahf --copt=-mmovbe --copt=-maes --copt=-mno-sha --copt=-mpclmulbuild:intel --copt=-mpopcnt --copt=-mabm --copt=-mno-lwp --copt=-mfma --copt=-mno-fma4build:intel --copt=-mno-xop --copt=-mbmi --copt=-mno-sgx --copt=-mbmi2 --copt=-mno-pconfigbuild:intel --copt=-mno-wbnoinvd --copt=-mno-tbm --copt=-mavx --copt=-mavx2 --copt=-msse4.2build:intel --copt=-msse4.1 --copt=-mlzcnt --copt=-mrtm --copt=-mhle --copt=-mrdrnd --copt=-mf16cbuild:intel --copt=-mfsgsbase --copt=-mrdseed --copt=-mprfchw --copt=-madx --copt=-mfxsrbuild:intel --copt=-mxsave --copt=-mxsaveopt --copt=-mavx512f --copt=-mno-avx512erbuild:intel --copt=-mavx512cd --copt=-mno-avx512pf --copt=-mno-prefetchwt1build:intel --copt=-mno-clflushopt --copt=-mxsavec --copt=-mxsavesbuild:intel --copt=-mavx512dq --copt=-mavx512bw --copt=-mavx512vl --copt=-mno-avx512ifmabuild:intel --copt=-mno-avx512vbmi --copt=-mno-avx5124fmaps --copt=-mno-avx5124vnniwbuild:intel --copt=-mno-clwb --copt=-mno-mwaitx --copt=-mno-clzero --copt=-mno-pkubuild:intel --copt=-mno-rdpid --copt=-mno-gfni --copt=-mno-shstk --copt=-mno-avx512vbmi2build:intel --copt=-mavx512vnni --copt=-mno-vaes --copt=-mno-vpclmulqdq --copt=-mno-avx512bitalgbuild:intel --copt=-mno-movdiri --copt=-mno-movdir64b --copt=-mtune=skylake-avx512
登入後複製
3.2 計算最佳化
3.2.1 充分使用算力
● #計算最佳化，首先需要充分了解硬體效能，將其吃透。在小紅書的場景中，如下圖所示，我們遇到了兩個核心問題：
1. CPU 上的訪存較多， 記憶體page fault 頻率較高，導致CPU 資源浪費，以及請求latency 過高
2. 在線上推理服務中，計算通常具有兩個特點：單次請求的batch size 小，單一服務的並發規模大。小 batch size 會導致 kernel 無法充分利用 GPU 的運算能力。 GPU kernel 執行時間一般較短，無法充分掩蓋 kernel launch 的開銷，甚至 kernel launch 的時間比 kernel 執行時間還長。在 TensorFlow 中，單一 Cuda Stream launch kernel 成為瓶頸，導致推理場景下 GPU 利用率只有 50% 。此外，對於小模型場景（簡單的 dense 網路），用 GPU 取代 CPU 完全不划算，限制了模型的複雜度。
圖片
● 為解決上述兩個問題，我們採取了以下措施：
#1.針對記憶體page fault 頻率高的問題，我們使用jemalloc 函式庫來優化記憶體回收機制，並開啟了作業系統的透明大頁功能。此外，針對 lambda 特殊的記憶體存取特點，我們設計專門的資料結構，並優化記憶體分配策略，盡可能避免記憶體碎片。同時，我們直接繞開了 tf_serving 的接口，直接呼叫 TensorFlow，減少了一次資料的序列化與反序列化。這些優化在首頁精排和內流精排場景下，提升了 10 % 的吞吐，在廣告大多數場景下，降低了 50% 的 latency。
圖片
相容 tensorflow::Tensor 格式，在將特徵傳遞給 tensorflow::SessionRun 之前是零拷貝
#
2. 針對 TensorFlow 單 Cuda Stream 的問題，我們支援了 Multi Streams , Multi Contexts 的功能，避免了互斥鎖導致的效能瓶頸，成功將 GPU 利用率提升到 90 % 。同時，我們利用 Nvidia 提供的 Cuda MPS 功能，實現了 GPU 的空分複用 (同一時間支援多個 kernel 執行)，使得 GPU 的利用率進一步提升。基於此，Search 的排序模型成功在 GPU 上實現。此外，我們也在其他業務線上成功落地，包括首頁初排、廣告等等。下表是在搜尋排場景下的一個最佳化情況。
圖片
3. Op/Kernel fusion 技術：透過手寫或圖編譯最佳化工具產生效能較高的Tensorflow 算子，充分利用CPU 的Cache 以及GPU 的Shared Memory，提升系統的吞吐。
圖片
在內流場景下， 算符進行融合，可以看到單次呼叫 12ms -> 5ms
3.2.2 避免算力浪費
1. 系統連結上存在最佳化空間
a. 初排前置計算：在處理使用者側相關計算時，初排需要計算大量筆記，例如以外流為例，需要計算約5000 篇筆記，lambda 對其有切片處理。為避免重複計算，將初排的用戶側計算前置到和召回階段並行，從而使得用戶向量的計算從多次重複變成了只需要 1 次，在粗排場景下優化了 40% 機器。
2. 圖內訓練到推理過程中：
a. 計算前置：透過 graph freeze 可以將一部分計算提前處理。在推理時，不需要重複計算。
b. 產出模型freeze 最佳化：模型產出時把所有的參數和圖本身一起產生凍結圖（ frozen graph ）並進行預處理計算，可以將很多預先計算的Variable 算子轉換成Const 算子（ GPU 使用率下降12% ）
c. 推理場景下的合併計算：每個batch 只包含一個user ， 即用戶側存在大量重複計算， 具備合併的可能性
d. CPU/GPU 算子拆分：將lookup 之後的全部算子移至GPU ，避免了CPU 與GPU 之間的資料拷貝
e. GPU 到CPU 資料拷貝：將資料打包一次拷貝
f. BilinearNet 算子GPU cuda 實作：透過GPU 加速運算，提升效能
g. 部分算子GPU 化：省去CPU -> GPU 拷貝
h. BatchNorm & MLP 合併：透過實現新的MLP 層，依照一個目標減少進GPU 的次數（ N -> 1 )， 增加一次運算的運算量（重複利用GPU 小核心的並發能力)
##圖片
3.2.3 全天動態算力
● 動態運算降級提升全天資源使用效率，秒級的對lambda 負載進行自動負回饋調整，做到對單區壓測前不需要人工做降級準備。
● 在外流精排、外流初排、內流精排、內流初排、搜尋等主要業務場景均已上線。
● 在多個業務線解決了容量問題，有效緩解了業務成長導致的資源線性上升，同時大幅提升了系統的穩健性。在功能上線後的業務線中，都沒有出現因為瞬間成功率大幅下降導致的 P3 以上事故。 ● 大幅提升全天資源使用效率，以內流精排為例（如下圖），五一假期三天的10:00-24:00 的CPU 使用核數均保持50 核的一條平線（抖動對應發版）
圖片
######3.2.4 換更好的硬體#### ########● A10 GPU 的效能是T4 GPU 效能的1.5 倍，同時A10 機型配備的CPU ( icelake, 10nm ) 比T4 機型( skylake, 14nm ) 更新一代，價格僅為T4 機型的1.2 倍。未來我們也會考慮在線上使用 A30 等機型。 #########3.3 圖形最佳化###############圖片###############3.3.1 DL 堆疊的自動編譯優#########
● BladeDISC 是阿里最新開源的基於MLIR 的動態shape 深度學習編譯器，小紅書的自動圖優化部分來自於這套框架（ Blade 推理加速庫是Apache 2.0 開源，可以跨任何雲使用，無智慧財產權風險）。此架構提供了 TF 圖編譯最佳化（包含 Dynamic Shape Compiler ，稀疏子圖最佳化），同時能疊加我們本身所做的算子客製化最佳化，可以較好的適配我們的業務場景。在壓測單機 inference 中，QPS 能提升 20% 。
● 這套框架關鍵技術
（1） MLIR 基礎架構
MLIR，即多層次中間表示語言（Multi-Level Intermediate Representation ），是由Google 發起的開源專案。其目的是提供一個靈活、可擴展的多層 IR 基礎設施和編譯器實用工具庫，為編譯器和語言工具的開發者提供一個統一的框架。
MLIR 的設計受到 LLVM 的影響，但與 LLVM 不同的是，MLIR 主要專注於中間表示（ IR ）的設計和擴充。 MLIR 提供了一個多層次的 IR 設計，可以支援從高層語言到底層硬體的編譯過程，並提供了豐富的基礎設施支援和模組化設計架構，使得開發者可以輕鬆擴展 MLIR 的功能。此外，MLIR 還具有較強的膠水能力，可與不同的程式語言和工具整合。 MLIR 是一個強大的編譯器基礎設施和工具庫，為編譯器和語言工具的開發者提供了一種統一的、靈活的中間表示語言，可以方便地進行編譯最佳化和程式碼生成。
（2） 動態shape 編譯
靜態shape 的限制意味著在編寫深度學習模型時需要提前確定每個輸入和輸出的形狀，並且不能在運行時改變它們。這限制了深度學習模型的靈活性和可擴展性，因此需要一個支援動態 shape 的深度學習編譯器。
3.3.2 精確度調整
● 量化的實作方式之一是使用FP16
#FP16 運算最佳化：在MLP 層時用FP16 取代FP32 計算，能夠較大地減少GPU 使用率(相對下降13% )
在調整FP16 的過程中，選擇白盒方式進行精度最佳化意味著可以更精細地控制哪些層使用低精度計算，並且能夠根據經驗進行不斷調整和最佳化。這種方式需要對模型結構有較深入的了解和分析，可以根據模型的特性和計算要求進行有針對性的調整，以達到更高的性價比。
相較之下，黑盒方式則相對簡單，不需要了解模型的內部結構，只需要設定一定的容忍閾值即可完成精度最佳化。這種方式的優點是操作簡單，對模型同學的要求也相對較低，但是可能會犧牲一定的表現和精確度。
因此，選擇白盒或黑盒方式進行精確度最佳化需要根據具體情況而定。如果需要追求更高的性能和精確度，同時擁有足夠的經驗和技術能力，那麼白盒方式可能更適合。如果操作簡單、快速迭代更重要，那麼黑盒方式可能會更加實用。
4.總結
從2021 年開始到2022 年底， 經過本項目優化，小紅書推理計算算力增加30 倍，關鍵用戶指標提升10% ，同時累積節約集群資源50% 。在我們看來，小紅書在 AI 技術方面的發展路徑應該是以業務需求為導向，平衡技術和商業的發展：實現技術創新的同時，也要考慮成本、效益和永續性。以下是一些優化過程中的思考：
優化演算法和提升系統效能。 這是小紅書機器學習團隊的核心任務。優化演算法和提高系統性可以更好地支援業務需求，提高用戶體驗。然而，在資源有限的情況下，團隊需要明確優化的重點，避免過度優化。
建立基礎架構和提高資料處理能力。 基礎架構對於支援 AI 應用是非常關鍵的。小紅書可以考慮進一步投入基礎設施的建設，包括運算和儲存能力、資料中心和網路架構等。此外，提高數據處理能力也是非常重要的，可以更好地支援機器學習和數據科學應用。
提高團隊人才密度與組織架構。 一個優秀的機器學習團隊需要擁有具有不同技能和背景的人才，包括資料科學家、演算法工程師、軟體工程師等；優化組織架構也有助於提高團隊效率和創新能力。
合作共贏和開放創新。 小紅書持續與其他公司、學術機構和開源社群合作，共同推動 AI 技術的發展，這有助於小紅書獲取更多資源和知識，成為更開放和創新的組織。
此方案讓小紅書機器學習架構水準達到了業界一流水準。未來，我們將持續推進引擎升級和降本增效， 引進新技術提高小紅書機器學習的生產力， 將更加結合小紅書的實際業務場景， 從單模組的優化升級為全系統優化，並進一步引入業務側流量的個人化差異特徵， 將降本增效做到極致。期待有誌之士，一同加入我們！
5.團隊
張楚嵐（杜澤宇）：商業技術部
畢業於華東師範大學，商業化引擎團隊負責人， 主要負責商業化線上服務搭建。
陸光（彭鵬）：智慧分發部
畢業於上海交通大學 ，機器學習引擎工程師，主要負責 Lambda GPU 最佳化。
I（陳建新）：智慧分發部門
畢業於北京郵電大學，機器學習引擎工程師， 主要負責 Lambda 參數伺服器和 GPU 最佳化。
赤羽（劉兆宇）：智慧分發部
畢業於清華大學，機器學習引擎工程師， 主要負責特徵引擎方向的相關研究和探索。
特別感謝 ：智能分發部 所有同學
#
以上是讓算力不再成為瓶頸，小紅書機器學習異質硬體推理優化之道的詳細內容。更多資訊請關注PHP中文網其他相關文章！
