Bert語義在360搜索中的探索實踐-工程優化

Bert模型網絡結構較深，參數量龐大，將Bert模型部署成在線服務在實時性和吞吐上面臨巨大挑戰。本文主要介紹360搜索將Bert模型部署成在線服務的過程當中碰到的一些困難以及作的工程方面的優化。

背景

在360搜索場景下對在線Bert服務的延遲和吞吐有極高的要求。通過前期的調研探索和試驗，將Bert模型作成在線服務主要有如下3個挑戰：

1. 模型參數量巨大。12層Bert模型有超過1億參數量，相比於其餘語義模型計算量高不少。
2. 推理時間長。經驗證，12層Bert模型在CPU上延遲約爲200ms，在GPU上未經優化的推理延遲爲80ms，在搜索這個場景下如此性能是不可接受的。
3. 推理計算量大，須要的資源多。通過壓測驗證，單個機房須要幾百張GPU卡才能承接所有的線上流量，投入的成本遠高於預期收益。

基於以上幾個困難點，咱們前期調研了TF-Serving、OnnxRuntime、TorchJIT、TensorRT等幾個熱門的推理框架，在比較了是否支持量化、是否須要預處理、是否支持變長、穩定性和性能以及社區活躍度等幾個維度後，最終選用了Nvidia開源的TensorRT。肯定了框架選型以後，咱們針對Bert在線服務作了幾個不一樣層面的優化。

Bert在線服務優化

框架層面提供的優化

TensorRT推理框架自己提供的優化有：

1. 層間融合和張量融合。本質是經過減小核函數調用次數來提升GPU利用率。
2. Kernel自動調優。TensorRT會在目標GPU卡上選擇最優的層和並行優化算法，保證最優性能。
3. 多流執行。經過共享權重的方式並行處理多條任務流，優化顯存。
4. 動態申請Tensor顯存。當Tensor使用時再真正申請顯存，顯著提升顯存利用率。
5. 模型量化。在保證精度的狀況下大幅提高模型的吞吐，同時下降推理延遲。

知識蒸餾

12層Bert模型的線上延遲不能知足性能要求，咱們將其蒸餾至6層的輕量級小模型。作完知識蒸餾後，在下降計算量的同時也保證了預測效果，6層模型能夠達到12層模型精度的99%。通過試驗驗證，Bert模型層數和在線服務的性能呈正相關的關係，6層模型TP99指標相對於12層模型性能提高1倍。

FP16量化

在Bert模型結構中，大部分Tensor都是fp32精度，可是在推理時不須要反向傳播，此時能夠下降精度，在保證模型效果的基礎上大幅提升模型的吞吐。通過FP16量化以後，模型推理延遲變爲原先1/3的同時，吞吐提高爲原先的3倍，此時顯存佔用也爲原先模型的1/2。可是相比較原先模型，fp16量化後的模型在萬分位後有損失，在360搜索的場景下通過驗證，量化後的模型對最終效果幾乎無影響。權衡之下，量化後的收益遠大於損失。

流水優化

上圖中H2D和D2H分別表示從內存往顯存中拷貝數據和從顯存往內存中拷貝數據，Kernel表示正在執行核函數。線上請求推理時所作的三個動做爲首先將請求數據由內存拷貝至顯存，而後GPU發起核函數調用作推理計算，最後將計算結果由顯存拷貝至內存。GPU真正執行計算的部分是執行核函數的部分（上圖中藍色部分），數據拷貝時GPU是空閒的（上圖中白色部分），此時不管壓測壓力多大GPU都會有空閒時間，所以利用率不會壓滿。

解決上述問題的一個方法是增長一條Stream，使得兩條Stream的核函數計算部分能夠交替執行，增長GPU有效工做時間佔比，GPU利用率能夠壓到98%以上。Stream能夠理解爲任務隊列，H2D能夠理解爲一次任務，多增長一條Stream不會增長額外的顯存佔用，多條Stream是共享模型權重的。

運行架構

上圖描述了一個佔有2張GPU卡的單個Bert服務進程的運行架構。從左至右依次解釋出現的名詞，task表示待處理的預測請求，context用來存儲這條請求的上下文信息，stream表示任務流，profile描述了模型輸入的限制（好比限制輸入的最大batch size），engine是TensorRT將原始模型編譯優化後的模型。每張GPU卡上加載一個模型，每一個模型會有2條Stream共享模型權重對外提供預測服務。

每當Bert服務收到來自客戶端的預測請求，這個請求將會被放入任務隊列。上圖線程池中的4個工做線程每當空閒時會從任務隊列中取出一條預測任務，保存好上下文信息後便將請求數據經過Stream拷貝到顯存，GPU調用核函數作完推理後再將結果經過Stream傳回到內存，此時工做線程將結果存入指定位置後通知上層，一條完整的請求預測流程就完成了。

緩存優化

在搜索場景下，當天的搜索內容會有一部分熱詞出現，加上緩存能夠有效減輕一部分計算量。在搜索系統加入請求級別的緩存以後，平均緩存命中率可達35%，極大地緩解了Bert在線服務的壓力。

動態sequence length

最開始的在線服務是採用輸入維度固定的方式，即輸入shape的最後一個維度爲離線統計出現過的最大sequence長度，通過線上小流量驗證而且統計線上請求以後，發現線上請求長度超過70的sequence佔比不到10%。因而咱們採起了動態sequence長度的優化方式，即採用一個請求batch中長度最長的sequence爲輸入長度，對其他的sequence作補零操做，通過這一優化線上性能提高7%。

Bert在線服務探索

作完上述優化後在測試以及小流量驗證的過程當中，咱們也碰到了一些問題，分享給你們。

模型動態加載致使延遲升高

在搜索場景下，有一個多版本模型熱加載的需求。開發完上線後觀測到一個現象，在熱加載新模型的時候，會出現TP99升高的現象，後來通過定位分析找到了緣由。

在Bert在線服務作預測的時候，會有一個將模型輸入數據從內存拷貝到顯存的操做。而Bert服務動態加載模型的時候，也會有一個將模型權重數據從內存拷貝到顯存的動做，拷貝模型到顯存的時候佔據了PCI總線，這時候預測請求數據從內存拷貝到顯存就會受到影響，從而TP99就會升高。模型權重拷貝持續約幾秒的時間，此時TP95正常，經統計僅有幾條請求會有延遲升高，對業務基本無影響。

精度震盪

在前期開發過程當中，咱們觀測到相同的sequence輸入模型，在不一樣的batch size下返回的結果老是不盡相同，而是在某一固定的區間內震盪，例如返回的結果老是介於0.93-0.95之間且不固定。這個現象在TensorRT 7.1.3.4下穩定復現，後與Nvidia的同事溝通反饋，在7.2.2.3這個版本下已經修復。

顯存佔用

單個Bert模型僅佔用幾百MB的顯存，可是上了多版本模型的功能後，Bert在線服務有可能加載5-8個模型，若是處理很差有可能會出現OOM的問題。目前咱們的處理手段是若是因顯存不夠而沒法正常加載模型，僅僅會提示模型加載失敗不會影響正常服務。加載一個新的模型的顯存佔用量是能夠提早判斷出來的，主要依據有3個：

1. 模型自己的權重。模型自己的權重是須要佔用顯存的，佔用顯存的大小約等於模型在磁盤上的文件大小。
2. 模型推理時須要的一些上下文信息。此部分顯存佔用分爲兩部分，一部分是保存上下文的持久化信息，包括輸入輸出數據佔用的顯存。另外一部分是推理時佔用的中間信息，中間信息顯存佔用通常不會超過模型權重大小。
3. CUDA運行時也耗費一些顯存，但這些顯存佔用是固定的。

總結與展望

通過前期框架調研驗證，模型優化，工程架構優化以及部署探索過程後，最終Bert在線服務在360搜索場景下正式上線了。目前通過優化後的6層模型單張T4卡每秒可計算1500條qt，線上高峯期TP99爲13ms。工程方面Bert在線服務穩定性和性能獲得了保障的基礎上，業務效果上相較於baseline也取得了可觀的收益。

咱們後續會持續探索推動Bert在360的應用落地，目前在搜索場景下工程方面還有一些亟需優化點：

1. 目前Bert服務仍是物理機部署，存在升級擴容困難、容災差以及資源浪費的問題，咱們正在推動Bert K8S化部署進程。
2. 當前Bert的訓練、蒸餾、數據和模型管理以及部署各個工做模塊比較分散，咱們在作的一個工做是把這些模塊慢慢集成到公司內部的機器學習平臺中，作到模型訓練，數據管理，模型管理，服務部署升級，AB實驗的平臺化和流程化，縮短上線週期，提升工做效率。