百度搜尋深度學習模型業務及最佳化實踐

來源：百度Geek說

作者 | Xin

導讀 

introduction

百度搜尋架構部模型架構組，致力於將最新的人工智慧技術以更低的成本被百度數億使用者體驗到。這個過程中會面臨非常多的系統、工程層面的問題，甚至在深度學習模型領域，我們看到越來越多的工作並不拘泥於工程本身。

本文主要分享模型架構組的日常工作，希望感興趣的同學，可以把簡歷投給我們。歡迎社招、實習同學投遞簡歷，備註【投遞搜尋架構組】，郵箱：sti01@baidu.com。

全文5361字，預計閱讀時間14分鐘。

GEEK TALK

01

搜尋深度學習模型業務及架構演進

如下圖所示，我們問一個河流的長度，搜尋結果精確返回了河流的長度，而不是返回有答案資訊的網頁連結讓使用者依次查詢。能做到這樣，是深度學習起著至關重要的作用，模型從語料中尋找、判斷、擷取準確答案，然後呈現給使用者。此外，使用者還能輸入圖片並詢問圖片的內容是什麼。

1.1 搜尋語義檢索通路

縱觀搜尋的發展的歷程，從最初的人工特徵，到淺層的機器學習模型，再到不斷加深的深度學習模型，我們對使用者需求和候選內容的理解能力是持續的提升的，能力提升到一定程度就會影響架構的變化。近幾年，架構最大的變化之一，是大規模的深層知識學習模型和系統的落地。

傳統的檢索的通路的思路，是倒排索引。我們通常理解的索引，是先有文字，再去統計文字中關鍵詞的出現頻次，這是正排。那倒排是什麼？是使用者搜了一個詞，我們去看它出現在哪些文字中。但是在中文語境中，一個句子通常會因為改變一兩個字或詞，整個句子的語義會發生劇烈的變化，比如"山桃紅了" vs "山桃花紅了"，前者描述的是山桃果實的顏色，後者指的是山桃花的顏色。

倒排檢索很難捕捉到這種變化，語義索引就很擅長解決這類問題。

那麼，語義索引是什麼？我們將使用者的query做嵌入表示，對映到一個向量（128/256維）中，然後對全網內容進行檢索、embedding對映至向量空間。我們可以把這個向量空間看作語義空間，在向量空間中越接近，語義就越近似，也就能反饋使用者更加滿意的結果。

1.2 搜尋深度學習模型

很多時候，搜尋和推薦有一定的共性，但也有諸多不同，這裡我對比著講。

搜尋的語義理解模型中，transform 類的結構被廣泛應用，文字作為特徵，詞表範圍一般<20萬，模型深度深，需要的運算量大。

而推薦模型，涉及大量使用者及物料特徵、互動特徵，詞表大小大到TB級，具有寬而較淺的特點。

搜尋模型特點：

1、原始文字/影像->embedding

2、Query-Url/title/content

3、深度模型

4、離線預訓練 線上多階段預估

5、計算密集->異構硬體

△圖片來源：Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[J]. Advances in neural information processing systems, 2017, 30.

CTR/推薦模型特點：

1、高維離散特徵->embedding

2、特徵工程 樣本拼接 特徵抽取

3、淺層DNN

4、時效性->online-learning

5、吞吐密集->CPU+PS

△ctr經典模型 Wide&Deep示意圖 (圖片來源：Cheng H T, Koc L, Harmsen J, et al. Wide & deep learning for recommender systems[C])

1.3 搜尋深度學習模型在語義檢索通路中的應用

語義檢索通路主要包括離線通路（下圖左側）和線上通路（下圖右側）。我們可以看到無論是離線還是線上，都用到了深度學習模型ERNIE。

△圖片來源：Liu Y, Lu W, Cheng S, et al. Pre-trained language model for web-scale retrieval in baidu search[C]

離線側，全網文字數量非常多，都需要檢索到我們的庫中做embedding，這個工作需要離線通路提前算好，存在資料庫中。

線上側，當使用者輸入query text後，同時進入傳統檢索通路（Query processing）和語義檢索通路（Query Encoder）。語義檢索通路中，使用者query透過深度學習模型（圖中是ERNIE模型）計算出一個向量，再與庫中向量對比檢索，快速找出與query向量儘可能接近的文字。這是第一步，後續還有非常多的複雜工作。

GEEK TALK

02

搜尋超大規模線上推理系統

2.1 線上系統與近線/離線系統

搜尋線上推理系統，是根據使用者query進行實時計算並返回結果，模型主要分為三部分：需求分析/query改寫、相關性/排序、分類。

（1）需求分析/query改寫，是透過深度學習模型返回一個語義相近的query

當使用者問：“熔斷是什麼意思啊？” 其中含有口語化表達，透過呼叫深度模型返回一個語義相近的query：“熔斷是什麼意思”，使召回的答案更豐富、準確。

（2）相關性/排序，需要用到粗排/精排模型，將使用者query與title相關的網頁資訊做拼接，讓模型計算相關性，得出的分數決定了返回使用者結果時的排名。

當使用者問：“西安旅遊必去景點攻略”，模型給出的分數越高，就代表網頁和使用者需求越接近，返回“float：0.876”。

（3）分類，即透過模型進行型別識別，返回型別。

當使用者問：“周杰倫 稻香” ，模型識別出這是一個音樂需求，我們就可以為使用者展現音樂型別的卡片。

搜尋離線系統，用於處理時效性不高的任務。搜尋的使用者使用會呈現明顯的波峰波谷形態，尤其是後半夜使用者流量非常低，冗餘的資源就可以進行離線計算，將計算結果存入語料庫。比如文章最開始提到的珠峰海拔的問題，深度模型可以直接從語料庫中抽取答案。還有一些是純粹的離線任務，我們採用批次建庫、批次刷庫的形式拿到索引，並儲存到資料庫中。

2.2 深度模型推理系統

搜尋系統中非常多的任務都會用到深度模型，我們希望各使用者、各業務方都能用同一套API來呼叫深度模型，這部分就是我們做的工作了。

在深度推理系統之後，它的後端由於大家模型種類、大小、尺寸都不一樣，包括異構算力，都需要我們把深度模型推理服務部署上去。

那麼，如果併發量變大，我們如何做到均勻排程、讓系統穩定可靠呢？

首先是均勻排程。下圖為公司內部模型部署的一種典型方案，我們每個人拿到的計算機叫做單機，但是單機粒度較大需要進行虛擬化，切分出更小的粒度來提供服務、做擴縮容等，我們稱作例項。

在對外提供服務時，單機多例項無法支撐巨大的併發量，所以需要擴充套件多機多例項，在百度搜尋這種海量使用者的場景，會在多地多個機房部署這樣的服務。均勻排程的意思，是當大量併發請求產生時，需要讓各地例項最小粒度能夠均勻利用，不能發生一些機器擁堵、一些機器沒利用起來的情況。

再者是穩定可靠。架構領域有一個非常有名說法，說“架構工作就是在不穩定的硬體之上構建一套穩定的系統”。當我們的例項和機器數量變得多時，某個硬體出故障其實就成為必然現象了，如何及時檢測故障並遷移，保證使用者體驗，就是我們需要保障的事情。

此外，我們還希望整個推理系統的速度足夠快，有足夠高的吞吐，儘可能降低資源成本。如下圖所示，推理系統的請求由brpc輸入，brpc是在公司內部各模組間透過網路呼叫的，可以讓使用者用類似本地函式的呼叫方式呼叫其他服務。系統收到請求後會識別inferfence request裡的資訊，包括要訪問什麼模型、訪問什麼版本、輸入了什麼等，之後進入處理流水線。

處理流水線包含四個部分：

（1）快取，如果一段時間內有相同請求計算過了，會直接透過快取返回給使用者，而不呼叫GPU

（2）Dynamic Batch，很多線上模組是以Batch=1觸發模型計算，但batch=1對硬體利用不充分，部分計算單元也會因為batch較小變為頻寬瓶頸。為了充分利用硬體會在時延允許的條件下儘可能把batch開大，所以我們會以一定的時間視窗或其他規則將請求合併以batch的形式做推理，之後再拆開返回使用者。

（3）使用者自定義的預處理，對應於自然語言處理模型，相遇將明文轉化為ID。為什麼要使用者自定義的預處理？這跟搜尋對接的業務方向多有關，各業務方有不同的資料預處理方式，所以交給使用者自定義更合適。

（4）預估佇列，經過預處理的請求會進入一個佇列中，這個佇列會按順序進入後端的預估引擎，經過預估引擎計算後進入使用者的自定義的後處理，後處理可以將輸出結果進行最佳化，再返回上游。

以上是超大規模線上推理系統的概況。

GEEK TALK

03

深度模型最佳化實踐

3.1 模型最佳化瓶頸

我們的深度模型最佳化，其實是針對某些瓶頸去做最佳化。GPU模型通常面臨著三類瓶頸：IO瓶頸、CPU瓶頸、GPU瓶頸。如下圖所示，訓練的整個過程包括：讀取資料、前向推理、反向傳播，我們推理過程可以拆分成讀取資料、前向推理兩部分。

（1）IO瓶頸，是指batch1和batch2資料處理的間隔期，需要加速資料的讀取速度；

（2）CPU瓶頸，是由於CPU給GPU分配的工作量少導致GPU利用率不夠的情況。場景是多OP的深度模型在GPU回拆解成多OP序列進行計算，在此之前需要CPU先做處理，GPU運算結束但CPU還沒把下一個任務發射過來；

（3）GPU瓶頸，如果出現了GPU瓶頸，說明GPU的利用率已經比較充分了，這是比較好的狀態。

3.2 模型最佳化工作

模型最佳化工作分為三個方面：訓練、推理和小型化。

3.2.1 訓練最佳化

（1）資料讀取

我們針對場景做資料讀取的最佳化。原因是在模型不斷增大後，我們不斷的嘗試將模型切分，在單機多卡上訓練，甚至在多機上訓練，不同的切分方式也會導致很多時候資料處理並沒有對場景做深度適配。

（2）框架排程

我們在訓練模型的過程中，一般是訓練一些step後做一次評估。在實際工作中，我們發現很多框架的訓練是在多卡上，但評估確在單卡上，這就出現了可最佳化的空間。

（3）kernel融合/開發

這是在訓練和推理場景都會遇到的工作， kernel融合可以減少 CPU的發射開銷，此外 GPU單kernel任務也會相對增大，不容易出現CPU瓶頸。

在識別到不夠高效的kernel後，我們會進行kernel融合的開發。

（4）模型實現-等價替換

無論用paddle框架或是其他，都會提供很多OP，這是想實現一個功能，就可以用不同的op來達到同樣的功能，這為使用者帶來非常高的自由度。但是不同的op在實際的執行過程中有低效和高效之分的，所以我們一部分工作就是去識別並替換成更高效的實現。

3.2.2 推理最佳化

除了kernel融合/開發、等價替換等，推理最佳化還包括GPU/CPU負載均衡、模型結構剪裁。

（1）GPU/CPU負載均衡

在推理場景，CPU的工作量並不太多，包括預處理、kernel lunch和後處理，我們可以把一些 GPU並不擅長的工作放在CPU執行，包括對訪存比較高但運算量較少的op，放在CPU進行更合理。

（2）模型結構剪裁

對於業務模型，可能會在存在訓練時需要但推理時不需要的運算部分，可以在模型匯出過程中將不需要的部分去掉。

3.2.3 模型小型化

小型化分為三個方向：蒸餾、量化、剪枝

（1）服務化蒸餾

蒸餾是一種模型壓縮技術，將一個複雜的、大型的模型 (teacher) 的知識轉移到另一個更小、更簡單的模型(student)中。小模型可以與大模型保持相似的訓練結果。

在實際業務場景中，隨著teacher數量不斷增長，蒸餾過程無法並行，teacher模型前向推理是序列的且耗時佔比會越來越高，成為主要瓶頸。所以從工程師的視角，我們將 teacher放在異構的算力上去推理，一方面將序列的teacher前向推理並行化，另一方面可以將閒置的資源利用起來，如下圖所示，整體加速蒸餾效率。

（2）量化

在推理過程中，我們希望將FLOAT32量化到更低位數，如INT8、INT4等，以期達到更低的記憶體佔用、更低的功耗和更快的計算速度。

一方面我們在儘可能保持量化工具的先進性，探索前沿各種新的量化演算法，將量化前後的指標效果損失降到最低。另一方面我們在構建自動量化的機制，讓更多模型能夠享受量化帶來的速度提升。

（3）剪枝

剪枝按照粒度來講，從細粒度的單引數裁剪，按照一定pattern將不重要的權重置為0，但需要搭配特定的硬體才能在整體看到速度提升。

粒度更粗一點，對於transformer類的模型，可以裁剪attention head，將不重要或者提供資訊較少的head識別出來並去除。甚至可以更大膽一點，直接跳過一些層的推理。

GEEK TALK

04

總結

百度搜尋架構部模型架構組的工作非常有挑戰性和意義，我們致力於將最新的人工智慧技術以更低的成本帶給百度數億使用者體驗到。我們不僅關注深度學習模型在搜尋領域的工程應用和最佳化，還不斷探索和研究新的技術手段，以不斷提升搜尋模型的效率和效能，同時也在嘗試用深度模型重塑架構。如果你對搜尋、語義檢索、深度模型最佳化加速等領域感興趣，歡迎加入我們的團隊，一起為使用者的搜尋體驗做出貢獻。